Subject: Re: [lemonade] Re: New draft: SEARCH return options
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Cyrus Daboo <[email-masked]>
Date: Sun, 27 Feb 2005 19:59:45 +0000
List-Id: <ietf-imapext.imc.org>

Arnt Gulbrandsen wrote:

> Cyrus Daboo writes:
>
>> OK, so are you suggesting that the tag for the SEARCH command is used 
>> as the 'ID' I was proposing, e.g.:
>>
>> a1234 SEARCH RETURN (TAG ALL) UNSEEN
>> * ESEARCH TAG a1234 ALL 1:100
>> a1234 OK
>
> I'm suggesting that IF you want to tag ESEARCH responses (whether you 
> call them "tagged searches" or "searches with ID" is no matter to me), 
> then the most honest response format is
>
> a1234 ESEARCH ALL 1:100
>
> There are alternatives, such as sneaking the tag in the back door:
>
> * ESEARCH TAG a1234 ALL 1:100

I've just updated the draft and it will look like:

* ESEARCH (TAG "a1234") ALL 1:100

tag is sent as a string, because "]" is allowed in a tag.

> Or such as using an Elvis lookalike instead of the real thing:
>
> * ESEARCH ID a1234 ALL 1:100
>
> Whether ESEARCH is tagged or not is no matter to me. I'm happy either 
> way.
>
> But if it is tagged, I'd like to see IMAP stay with just one tag 
> mechanism (unless there are pressing reasons for having multiple 
> similar mechanisms, of course).

I agree, of course.

Date: Mon, 14 Feb 2005 18:55:40 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Mark Crispin wrote:

> I've reviewed this document and while I have document nits the 
> protocol proposed looks OK to me.
>
> Is there much feeling as to how useful it would be?  I'm not talking 
> about Dave and Alexey since I'm sure they are already convinced.  It's 
> more of a question of whether the benefit is worth the added 
> complexity (don't forget, it does represent an additional task for 
> server implementors!).

Speaking as a server implementor: I only had to modify new syntax 
parsing and the loop the calls "evaluate this message against search 
criteria" for each message, so that the server can output ESEARCH data. 
The search matching code hasn't been touched. It took me about 3 hours 
to implement the whole extension.

I think Dave has some number about how much bandwidth is saved using 
SEARCH RETURN (ALL).

Alexey

Date: Fri, 25 Feb 2005 14:13:48 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Nit-checking 2086upd
Sender: [email-masked]

Dave Cridland wrote:

>
> On Thu Feb 24 21:03:27 2005, Lisa Dusseault wrote:
>
>> "If rights are tied in an implementation, the conservative approach 
>> would be to grant few of them in response to SETACL commands.  Thus, 
>> unless all rights in a tied set are specified, a server MUST NOT 
>> include any of that set in the ACL entry for that identifier.  A 
>> client can discover the set of rights granted to a given identifier 
>> in the ACL for a given mailbox name by using the LISTRIGHTS command."
>>
>> Note that I also removed "which may be" -- I think it changes the 
>> sense of the sentence from "finding out what's possible to grant", to 
>> "finding out what is granted", which I believe to be correct.  If I'm 
>> wrong then a different change should be made.
>
>
> That's incorrect - LISTRIGHTS lists sets of tied rights possible to 
> grant to the identifier [of which some or all sets may have only one 
> member], and a set of rights which is always granted, not what's 
> actually granted at the time. There is no MYRIGHTS equivalent for 
> other users, which is I think what you're thinking.

And the lack of such command might be addressed in ACL2, but 2086upd is 
not the proper place to do this change.

> What about:
>
> "If rights are tied in an implementation, the implementation MUST be 
> conservative in granting rights in response to SETACL commands--unless 
> all rights in a tied set are specified, an implementation MUST NOT 
> include any of that set in the ACL entry for the given identifier. A 
> client SHOULD discover the set of rights which may be granted to a 
> given identifier in the ACL for a given mailbox name by using the 
> LISTRIGHTS command."
>
> It's a less drastic rephrase. I'm not sure about the first MUST,

I am not sure either, the original text sounds like "SHOULD" (and the 
following "MUST NOT" should be changed to "SHOULD NOT" as well).
Comments?

> and note I've added a SHOULD for clients to use LISTRIGHTS. Many 
> implementations don't, currently.

That is fine with me.

Alexey

From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Nit-checking 2086upd
Date: Fri, 25 Feb 2005 10:08:08 +0000
Sender: [email-masked]

On Thu Feb 24 21:03:27 2005, Lisa Dusseault wrote:
> "If rights are tied in an implementation, the conservative approach would be to grant few of them in response to SETACL commands.  Thus, unless all rights in a tied set are specified, a server MUST NOT include any of that set in the ACL entry for that identifier.  A client can discover the set of rights granted to a given identifier in the ACL for a given mailbox name by using the LISTRIGHTS command."
> 
> Note that I also removed "which may be" -- I think it changes the sense of the sentence from "finding out what's possible to grant", to "finding out what is granted", which I believe to be correct.  If I'm wrong then a different change should be made.

That's incorrect - LISTRIGHTS lists sets of tied rights possible to grant to the identifier [of which some or all sets may have only one member], and a set of rights which is always granted, not what's actually granted at the time. There is no MYRIGHTS equivalent for other users, which is I think what you're thinking.

What about:

"If rights are tied in an implementation, the implementation MUST be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, an implementation MUST NOT include any of that set in the ACL entry for the given identifier. A client SHOULD discover the set of rights which may be granted to a given identifier in the ACL for a given mailbox name by using the LISTRIGHTS command."

It's a less drastic rephrase. I'm not sure about the first MUST, and note I've added a SHOULD for clients to use LISTRIGHTS. Many implementations don't, currently.

Dave.

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Nit-checking 2086upd
Date: Thu, 24 Feb 2005 13:03:27 -0800
Sender: [email-masked]

--Apple-Mail-4--24694467
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

In nit-checking 2086upd, I noticed some text where the use of must/MUST 
and may/MAY could be clarified.

  "If rights are tied in an
    implementation, the implementation must be conservative in granting
    rights in response to SETACL commands--unless all rights in a tied
    set are specified, none of that set should be included in the ACL
    entry for that identifier. A client may discover the set of rights
    which may be granted to a given identifier in the ACL for a given
    mailbox name by using the LISTRIGHTS command."

This seems like it might be partly normative but part is definitely 
descriptive. Can we write this to be clearer about what the server MUST 
do?  How about:

"If rights are tied in an implementation, the conservative approach 
would be to grant few of them in response to SETACL commands.  Thus, 
unless all rights in a tied set are specified, a server MUST NOT 
include any of that set in the ACL entry for that identifier.  A client 
can discover the set of rights granted to a given identifier in the ACL 
for a given mailbox name by using the LISTRIGHTS command."

Note that I also removed "which may be" -- I think it changes the sense 
of the sentence from "finding out what's possible to grant", to 
"finding out what is granted", which I believe to be correct.  If I'm 
wrong then a different change should be made.

Lisa
--Apple-Mail-4--24694467
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

In nit-checking 2086upd, I noticed some text where the use of
must/MUST and may/MAY could be clarified.

<color><param>0000,0000,DDDD</param> "If rights are tied in an

   implementation, the implementation must be conservative in granting

   rights in response to SETACL commands--unless all rights in a tied

   set are specified, none of that set should be included in the ACL

   entry for that identifier. A client may discover the set of rights

   which may be granted to a given identifier in the ACL for a given

   mailbox name by using the LISTRIGHTS command."

This seems like it might be partly normative but part is definitely
descriptive. Can we write this to be clearer about what the server
MUST do?  How about:

"If rights are tied in an implementation, the conservative approach
would be to grant few of them in response to SETACL commands.  Thus,
unless all rights in a tied set are specified, a server MUST NOT
include any of that set in the ACL entry for that identifier.  A
client can discover the set of rights granted
</color><color><param>0000,0000,DDDC</param>to a given identifier in
the ACL for a given mailbox name by using the LISTRIGHTS command."

Note that I also removed "which may be" -- I think it changes the
sense of the sentence from "finding out what's possible to grant", to
"finding out what is granted", which I believe to be correct.  If I'm
wrong then a different change should be made.

Lisa</color>
--Apple-Mail-4--24694467--

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: WG last call for ANNOTATE Feb 4-18
Date: Tue, 22 Feb 2005 11:24:23 -0800
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

BTW, this last call period has now completed... the next step is for 
the authors to give us some idea of what issues still need to be 
discussed, what changes are made to the draft as a result of the last 
call reviews, etc.

Lisa

On Feb 4, 2005, at 1:32 PM, Lisa Dusseault wrote:

>
> This is a notification of the beginning of last-call for the -12 draft 
> of ANNOTATE:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-12.txt
>
> If you review this draft, let the WG know even if you have no issues 
> or comments.  Also, we'd like to know who plans to implement this or 
> may have already begun (you can let me know privately or mail the WG). 
>  Last call will go until and including February 18 2005.
>
> Lisa Dusseault
>

Cc: [email-masked], Dave Cridland <[email-masked]>
From: Grant Baillie <[email-masked]>
Subject: Re: ANNOTATE comments
Date: Fri, 18 Feb 2005 18:18:20 -0800
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Hello, Cyrus

On Feb 18, 2005, at 9:21 AM, Cyrus Daboo wrote:

>
> Hi Grant,
>
> --On February 18, 2005 8:48:35 AM -0800 Grant Baillie 
> <[email-masked]> wrote:
>
>>> You could argue that it's easy to detect the ascii and utf-8 cases,
>>> and therefore these could be recorded - but in practise, since these
>>> are easy to detect, it's better to let clients detect them.
>>
>> The use case I had in mind is when users have to pick a charset 
>> manually,
>> in which case it would be nice to propagate across clients. But I 
>> agree
>> that incorrect setting of the charset, especially automatically, is a
>> concern.
>>
>
> I would like to keep the entries defined in the base document to a 
> minimum if possible.

Eminently reasonable and understandable.

> There is of course nothing to stop you from writing this up as a 
> separate draft and registering an entry for it yourself. If you do 
> that, then I would also suggest having a way to override the 
> content-type too. Often messages get sent with the wrong content-type 
> (e.g. text/plain for an HTML message, application/octet-stream for 
> Word document etc). In those cases it would also be nice to have the 
> first client to spot the problem set an annotation to provide a hint 
> to others. If you do that you can actually combine this with charset, 
> since charset is a parameter on the Content-Type header. So my 
> suggestion would be an 'altcontenttype' entry whose value was a 
> properly formed MIME Content-Type header field that could override 
> content type, name, charset etc.

Indeed. (Next, altcontentdisposition for fixing bogus 
Content-Disposition headers, too :-).

At the moment, I'm not working on an IMAP client, so I'm not inclined 
to write up a draft that I wouldn't actually be implementing in the 
near future. But I might be inclined to pursue this sometime down the 
road. Thanks for your observations/comments.

--Grant

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-03.txt
Date: Fri, 18 Feb 2005 15:23:51 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-2086upd-03.txt
	Pages		: 0
	Date		: 2005-2-18
	
The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP4rev1) permits mailbox access control
   lists to be manipulated through the IMAP protocol.

   This document is a revision of the RFC 2086. It defines several new
   access control rights and clarifies which rights are required for
   different IMAP commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-2086upd-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-2086upd-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-2086upd-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-2086upd-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 18 Feb 2005 17:53:57 +0000
From: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: List of WGLC changes to 2086upd-02
Sender: [email-masked]

I've just submitted -03 of 2086upd.

In addition to changed mentioned earlier (see 
http://www.imc.org/ietf-imapext/mail-archive/msg02389.html), I've 
updated section talking about virtual "c" and "d" rights, as per private 
discussion with Dave and Ken. The new text is as follows:

3.1.1.   Obsolete rights

   Due to ambiguity in RFC 2086 some existing RFC 2086 server 
implementations
   use the "c" right to control the DELETE command. Others chose to use the
   "d" right to control the DELETE command.
   For the former group, let's define the "create" right as union of the "k"
   and "x" rights, and the "delete" right as union of the "e" and "t" 
rights.
   For the latter group, let's define the "create" rights as a synonym 
to the
   "k" right, and the "delete" right as union of the "e", "t" and "x" 
rights.

   For compatibility with RFC 2086 this section defines two virtual rights
   "d" and "c".

   If a client includes the "d" right in a rights list, then it MUST be
   treated as if the client had included every member of the "delete" right.
   (It is not an error for a client to specify both the "d" right and
   one or more members of the "delete" right, but the effect is no different
   than if just the "d" right or all members of the "delete" right had been
   specified).

   When any of the "delete" member rights is set in a list of
   rights, the server MUST also include the "d" right when returning
   the list in a MYRIGHTS or ACL response. This is so to enable older 
clients
   conforming to RFC 2086 to work with newer servers. (*)

   Example:    C: A001 SETACL INBOX.Drafts David lrswida
               S: A001 OK Setacl complete

    The client has specified the "d" right in the SETACL command above 
and it
    expands to "et" on the server:

               C: A002 GETACL INBOX.Drafts
               S: * ACL INBOX Fred rwipslxetda David lrswideta
               S: A002 OK Getacl complete

   If the authentication identifier specified in the LISTRIGHTS command 
can be
   granted any of the "delete" member rights to access a mailbox, then 
the server
   MUST include the "d" right in the corresponding LISTRIGHTS response. (*)
   If the member rights aren't tied to non-member rights, then the "d" right
   is returned by itself in the LISTRIGHTS response.  If any of the 
member rights
   needs to be tied to one (or more) non-member right, then the "d" 
right and all
   of the member rights need to be tied to the same non-member right(s) 
(**).

   If a client includes the "c" right in a rights list, then it MUST be
   treated as if the client had included every member of the "create" right.
   (It is not an error for a client to specify both the "c" right and
   one or more members of the "create" right, but the effect is no different
   than if just the "c" right or all members of the "create" right had been
   specified).

   When any of the "create" member rights is set in a list of
   rights, the server MUST also include the "c" right when returning
   the list in a MYRIGHTS or ACL response. This is so to enable older 
clients
   conforming to RFC 2086 to work with newer servers. (*)

   Example:    C: A003 SETACL INBOX.Drafts Byron lrswikda
               S: A001 OK Setacl complete
               C: A002 GETACL INBOX.Drafts
               S: * ACL INBOX Fred rwipslxeta Byron lrswikcdeta
               S: A002 OK Getacl complete

    The client has specified the "d" right in the SETACL command above 
and it
    expands to "et" on the server:  As the client has specified the "k" 
right
    (which is a member of the "c" right), the server also returns the 
"c" right.

   If the authentication identifier specified in the LISTRIGHTS command 
can be
   granted any of the "create" member rights to access a mailbox, then 
the server
   MUST include the "c" right in the corresponding LISTRIGHTS response. (*)
   If the member rights aren't tied to non-member rights, then the "c" right
   is returned by itself in the LISTRIGHTS response.  If any of the 
member rights
   needs to be tied to one (or more) non-member right, then the "c" 
right and all
   of the member rights need to be tied to the same non-member right(s) 
(**).

   Example: The server that ties the rights as follows

               lr s w i p k x t

            and c=k

            will return:

               S: * LISTRIGHTS archive.imap anyone "" lr s w i p k x t c d

   Example: The server that ties the rights as follows

               lr s w i p k xte

            and c=k

            will return:

               S: * LISTRIGHTS archive.imap anyone "" lr s w i p k xte c d

   Example: The server that ties the rights as follows

               lr s w i p k x te

            and c=k

            will return:

               S: * LISTRIGHTS archive.imap anyone "" lr s w i p k c x te d

   Example: The server that ties the rights as follows

               lr swte i p k x

            and c=kx

            will return:

               S: * LISTRIGHTS archive.imap anyone "" lr swted i p k x c

   (*) Clients conforming to this document MUST ignore the virtual "d" 
and "c"
   rights in MYRIGHTS, ACL and LISTRIGHTS responses.

   (**) The IMAPEXT Working Group has debated this issue in great length
   and after reviewing existing ACL implementations concluded that this is
   a reasonable restriction.

Date: Fri, 18 Feb 2005 12:21:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Grant Baillie <[email-masked]>, Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATE comments
Sender: [email-masked]

Hi Grant,

--On February 18, 2005 8:48:35 AM -0800 Grant Baillie 
<[email-masked]> wrote:

>> You could argue that it's easy to detect the ascii and utf-8 cases,
>> and therefore these could be recorded - but in practise, since these
>> are easy to detect, it's better to let clients detect them.
>
> The use case I had in mind is when users have to pick a charset manually,
> in which case it would be nice to propagate across clients. But I agree
> that incorrect setting of the charset, especially automatically, is a
> concern.
>

I would like to keep the entries defined in the base document to a minimum 
if possible.

There is of course nothing to stop you from writing this up as a separate 
draft and registering an entry for it yourself. If you do that, then I 
would also suggest having a way to override the content-type too. Often 
messages get sent with the wrong content-type (e.g. text/plain for an HTML 
message, application/octet-stream for Word document etc). In those cases it 
would also be nice to have the first client to spot the problem set an 
annotation to provide a hint to others. If you do that you can actually 
combine this with charset, since charset is a parameter on the Content-Type 
header. So my suggestion would be an 'altcontenttype' entry whose value was 
a properly formed MIME Content-Type header field that could override 
content type, name, charset etc.

-- 
Cyrus Daboo

Cc: <[email-masked]>
From: Grant Baillie <[email-masked]>
Subject: Re: ANNOTATE comments
Date: Fri, 18 Feb 2005 08:48:35 -0800
To: Dave Cridland <[email-masked]>
Sender: [email-masked]

On Feb 18, 2005, at 6:18 AM, Dave Cridland wrote:

> On Thu Feb 17 21:22:07 2005, Grant Baillie wrote:
>> - A potential use of ANNOTATE would be to allow users/clients to 
>> re-label the charset of a message part. (Sadly, there are still many 
>> clients out there that produce text parts with missing or incorrect 
>> charset parameters). Is it worth defining, say, 
>> /<section-part>/altcharset and /altcharset for this?
>
> I agree that there are some dumb clients out there, and I also agree 
> that it's possible for a user or a client to detirmine the correct 
> character set in some cases.
>
> However, not all cases, and some existant examples of heuristically 
> discovering character sets fail horribly - I think this is one of 
> those things that a client has to deal with, rather than rely on 
> potentially another client getting right.
>
> To give some idea, I live in an area where at least five character 
> sets are in common usage - ascii, latin1,14, and 15, and utf-8 - and 
> two langauges. These are all quite difficult to detect heuristically, 
> with the exception of ascii and utf-8. I can live with the client I'm 
> using getting it wrong, but not if it then influenced other clients I 
> used.
>
> You could argue that it's easy to detect the ascii and utf-8 cases, 
> and therefore these could be recorded - but in practise, since these 
> are easy to detect, it's better to let clients detect them.

The use case I had in mind is when users have to pick a charset 
manually, in which case it would be nice to propagate across clients. 
But I agree that incorrect setting of the charset, especially 
automatically, is a concern.

--Grant

From: Dave Cridland <[email-masked]>
To: Grant Baillie <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ANNOTATE comments
Date: Fri, 18 Feb 2005 14:18:22 +0000
Sender: [email-masked]

On Thu Feb 17 21:22:07 2005, Grant Baillie wrote:
> - A potential use of ANNOTATE would be to allow users/clients to re-label the charset of a message part. (Sadly, there are still many clients out there that produce text parts with missing or incorrect charset parameters). Is it worth defining, say, /<section-part>/altcharset and /altcharset for this?

I agree that there are some dumb clients out there, and I also agree that it's possible for a user or a client to detirmine the correct character set in some cases.

However, not all cases, and some existant examples of heuristically discovering character sets fail horribly - I think this is one of those things that a client has to deal with, rather than rely on potentially another client getting right.

To give some idea, I live in an area where at least five character sets are in common usage - ascii, latin1,14, and 15, and utf-8 - and two langauges. These are all quite difficult to detect heuristically, with the exception of ascii and utf-8. I can live with the client I'm using getting it wrong, but not if it then influenced other clients I used.

You could argue that it's easy to detect the ascii and utf-8 cases, and therefore these could be recorded - but in practise, since these are easy to detect, it's better to let clients detect them.

Dave.

To: [email-masked]
From: Grant Baillie <[email-masked]>
Subject: ANNOTATE comments
Date: Thu, 17 Feb 2005 13:22:07 -0800
Sender: [email-masked]

Here are some comments I have on annotate-12 (apologies for the 
closeness to last call):

- From a readability point of view, I think it would be nice to have a 
somewhat less terse Abstract.  At least, I think it should mention that 
you can associate metadata with MIME parts (not just entire messages).

- A potential use of ANNOTATE would be to allow users/clients to 
re-label the charset of a message part. (Sadly, there are still many 
clients out there that produce text parts with missing or incorrect 
charset parameters). Is it worth defining, say, 
/<section-part>/altcharset and /altcharset for this?

- Section 2.2.1, /flags entry name: Is there difference between "0" and 
NIL for a flag's value? If so, that should be spelled out.

- In the examples, it would be good to use literals as well as 
quoted-strings in a couple of cases. This might help to remind 
implementers not to assume they should only accept quoted-strings.

- The resp-text-code grammar rule should use nil, not "NIL".

- The use of double-quotes is often contradictory or confusing. Eg. in 
the following:

      The server SHOULD indicate the maximum size for an annotation value
      by sending an untagged "ANNOTATESIZE" response during a SELECT or
      EXAMINE command

   why "ANNOTATESIZE" and not "SELECT"? In general, the IMAP spec itself 
is pretty consistent
   about referring to response codes, etc, without double quotes, and it 
would be nice to

--Grant

Date: Thu, 17 Feb 2005 16:03:44 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Informal list last call for ANNOTATEMORE
Sender: [email-masked]

Cyrus Daboo wrote:

> 
> Hi folks,
> I would like to submit the ANNOTATEMORE document to the IESG at the same 
> time as the ANNOTE document (once that has gone through WGLC and all 
> seems OK). However, since ANNOTATEMORE is an individual submission it is 
> not subject to a WGLC, but I would appreciate it if people looking at 
> ANNOTATE would also look at ANNOTATEMORE in the same vein and pass 
> comments back, thanks.
> 
> <http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-07.txt>

This looks good to me, and seems to jive with what we've already 
implemented in Cyrus.

I did find one in the examples in section 3.3.  The third example shows 
setting a single entry on multiple mailboxes, but the text immediately 
above states that multiple entries can be set in a single SETANNOTATION. 
  I think we need to add an example of setting multiple entries in one 
command.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 16 Feb 2005 12:27:08 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: New draft: SEARCH return options
Cc: IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Sender: [email-masked]

At 12:04 PM 2/16/2005, Alexey Melnikov wrote:
>Pete Maclean wrote:
>
>>I am wondering why you are not tempted to generalize the options a bit 
>>more.  I am thinking along the lines of:
>>
>>     DIRECTION UP or DOWN (meaning search up/down with respect to message 
>> numbers/UIDs)
>
>Isn't this part of the SORT extension?

Ah well, it may be so.  I must acknowledge that I have not acquainted 
myself with that extension.  But perhaps if a server chooses to implement 
the ESEARCH extension and not the SORT extension then it is relevant.

>  IMHO, the search order is an internal server business. Some servers can 
> optimize if the client specified something like "RETURN (MIN)".

I totally agree that the search order should be an internal server business 
by default.  However, for the type of situation I described, it does seem 
valuable for the client to be able override that.  Incidentally, I do not 
mean that to imply that the results should necessarily be returned in the 
specified order.  Furthermore, by "order", I guess I mean "effective order" 
such that the results returned would be the first N matches in the 
specified ordering.  Whether or not the server internally actually searches 
messages in that order is irrelevant.

>>     MATCHES n (meaning return a maximum of n matches)
>
>Yes, we've just discussed this with Dave :-).

Good show!

Pete 

Date: Wed, 16 Feb 2005 17:04:59 +0000
From: Alexey Melnikov <[email-masked]>
To: Pete Maclean <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Pete Maclean wrote:

> I am wondering why you are not tempted to generalize the options a bit 
> more.  I am thinking along the lines of:
>
>     DIRECTION UP or DOWN (meaning search up/down with respect to 
> message numbers/UIDs)

Isn't this part of the SORT extension? IMHO, the search order is an 
internal server business. Some servers can optimize if the client 
specified something like "RETURN (MIN)".

>     MATCHES n (meaning return a maximum of n matches)

Yes, we've just discussed this with Dave :-).

> This would allow a client that wanted to find at most a fixed number 
> of matches to fill a window, form or Web page to do so more 
> efficiently.  For example,
>
>     <tag> SEARCH RETURN (DIRECTION DOWN MATCHES 20) <criteria>
>
> These could even be combined by having MATCHES +n and MATCHES -n.
>
> Then MIN would be replaced by (DIRECTION UP MATCHES 1) and so on.

Date: Wed, 16 Feb 2005 11:10:53 -0500
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: New draft: SEARCH return options
Cc: Lemonade WG <[email-masked]>
Sender: [email-masked]

I am wondering why you are not tempted to generalize the options a bit 
more.  I am thinking along the lines of:

	DIRECTION UP or DOWN (meaning search up/down with respect to message 
numbers/UIDs)

	MATCHES n (meaning return a maximum of n matches)

This would allow a client that wanted to find at most a fixed number of 
matches to fill a window, form or Web page to do so more efficiently.  For 
example,

	<tag> SEARCH RETURN (DIRECTION DOWN MATCHES 20) <criteria>

These could even be combined by having MATCHES +n and MATCHES -n.

Then MIN would be replaced by (DIRECTION UP MATCHES 1) and so on.

Pete Maclean

content-class: urn:content-classes:message
Subject: RE: [lemonade] Re: New draft: SEARCH return options
Date: Tue, 15 Feb 2005 13:31:15 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> > What need is there for unsolicited ESEARCH?
> 
> Maybe there is none, but I didn't want to disallow this in 
> the future. 
> And the recent discussion about EXPUNGED made me think that a SEARCH 
> result might be caused by commands other than SEARCH.

I agree with Alexey.

To purposely design with the intent to not allow a particular 
response to be unsolicited is an unwise restriction.

We should intentionally design to make responses as command 
independent as possible. They should be viewed as packets of 
information a client can use independent of the command that was
used to elicit them.

I would like to see this response tagging referral idea become a 
general mechanism and not bound to ESEARCH.

Mike

Date: Tue, 15 Feb 2005 18:55:07 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On February 15, 2005 12:26:47 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>>> Right now I don't see why we need the new ESEARCH response at all, as
>>> opposed to just redefining the SEARCH response (which is fine because
>>> the client knows what it is going to get having used the extended
>>> SEARCH command). Perhaps Alexey can explain why we have to have a new
>>> response?
>>
>> ESEARCH response can be unsolicited, SEARCH response can't - the client
>> really doesn't know what has caused it and whether it contains UIDs or
>> message numbers.
>
> What need is there for unsolicited ESEARCH?

Maybe there is none, but I didn't want to disallow this in the future. 
And the recent discussion about EXPUNGED made me think that a SEARCH 
result might be caused by commands other than SEARCH.

I was also thinking that with ESEARCH (if extended to include ID/tag, as 
discussed recently), the server can send SEARCH results in chunks. But 
maybe the draft should be extended to list that this behavior is allowed 
and how the client should handle it.

Date: Tue, 15 Feb 2005 10:25:57 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Alexey,

--On February 15, 2005 11:36:09 AM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> This could prove very powerful for clients that want to present
>> multiple simultaneous 'views' on the same mailbox.
>
> Cyrus, what do you think is a practical limit on the number of search
> results a server should remember?

Of course there should be limit, with a recommended minimum (e.g. 10). Plus 
this feature must be explicitly turned on by the client. i.e. a regular 
search will always be remembered as the 'anonymous' search set $ (which 
gets replaced with each search), but the client has to explicitly 'name' a 
search to have its results saved for the session. That way servers are not 
required to remember multiple sets unless the client specifically asks for 
it. It would also be handy if the client can 'refresh' the results of a 
'named' search in a quick way, e.g.:

a1 SEARCH RETURN (ID 1) UNSEEN

a2 FETCH $[1] (ENVELOPE)

a3 SEARCH $[1]

The last search is a repeat of the first one with the $[1] set being 
updated with the new results.

Of course we could go further over the top here and reinvent ACAP contexts 
by allowing the search results to be dynamic (i.e. the $[1] set changes as 
message unseen state changes and there are appropriate unsolicited 
responses to indicate that). Maybe that is going too far, but Mark did 
bring that up...

-- 
Cyrus Daboo

Date: Tue, 15 Feb 2005 10:15:37 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Alexey,

--On February 15, 2005 12:26:47 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> Right now I don't see why we need the new ESEARCH response at all, as
>> opposed to just redefining the SEARCH response (which is fine because
>> the client knows what it is going to get having used the extended
>> SEARCH command). Perhaps Alexey can explain why we have to have a new
>> response?
>
> ESEARCH response can be unsolicited, SEARCH response can't - the client
> really doesn't know what has caused it and whether it contains UIDs or
> message numbers.
>

What need is there for unsolicited ESEARCH?

-- 
Cyrus Daboo

Date: Tue, 15 Feb 2005 12:26:47 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Mark,
>
> --On February 14, 2005 12:51:02 PM -0800 Mark Crispin 
> <[email-masked]> wrote:
>
>> tag SEARCH extended-poop
>> tag OK [SEARCH extended-poop-response] extended SEARCH OK
>>
>> as opposed to
>>
>> tag SEARCH extended-poop
>> * ESEARCH extended-poop-response
>> tag OK SEARCH completed
>>
>> Note that this precludes any sort of "watching" SEARCH extension, in
>> which you have a standing SEARCH and get unsolicited responses.  It has
>> been nearly 20 years and we have done no such thing, so maybe we don't
>> care.
>
> I guess I dislike the idea of having actual results come back in the 
> extended response code.

Me too.

> Right now I don't see why we need the new ESEARCH response at all, as 
> opposed to just redefining the SEARCH response (which is fine because 
> the client knows what it is going to get having used the extended 
> SEARCH command). Perhaps Alexey can explain why we have to have a new 
> response?

ESEARCH response can be unsolicited, SEARCH response can't - the client 
really doesn't know what has caused it and whether it contains UIDs or 
message numbers.

Date: Tue, 15 Feb 2005 11:36:09 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

> The fetch commands act on the result of the different searches, 
> referenced by the ID option value. This means that a client could use 
> multiple search result sets simultaneously, as opposed to in series, 
> as they would have to right now.
>
> This could prove very powerful for clients that want to present 
> multiple simultaneous 'views' on the same mailbox.

Cyrus, what do you think is a practical limit on the number of search 
results a server should remember?

Alexey

Date: Tue, 15 Feb 2005 11:33:56 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Philip Guenther wrote:

>[Not sent to lemonade.  Do we really need to carry on this discussion in
>both places?]
>  
>
Thanks!

>Cyrus Daboo <[email-masked]> writes:
>...
>  
>
>>There is also an interesting possibility of tying the two together via the 
>>ID return option I proposed. For example:
>>
>>C: a SEARCH RETURN (ID 1 ALL) UNSEEN
>>    
>>
>...
>  
>
>>C: FETCH $[1] (UID INTERNALDATE FLAGS RFC822.HEADER)
>>    
>>
>...
>  
>
>>The fetch commands act on the result of the different searches, referenced 
>>by the ID option value. This means that a client could use multiple search 
>>result sets simultaneously, as opposed to in series, as they would have to 
>>right now.
>>    
>>
>
>The '$' token in draft-melnikov-imap-search-res-01.txt references the
>last SEARCH result, so it only requires the server to remember the one
>such result.
>
Yes, that was the original intent. Even if the client has specified 
"RETURN (COUNT)", the "$" construct still references the set of found 
messages.

>  If multiple search responses need to be remembered then
>some limit needs to be placed on how many a client can expect a server
>to remember and perhaps the client will need some way of controlling
>their lifetime.
>  
>
Yes.
I was thinking about remembering multiple SEARCH results, but this might 
overcomplicate the extension without much benefit.
What people think about this?

Alexey

Date: Tue, 15 Feb 2005 11:08:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>Cyrus Daboo writes:
>  
>
>>The IDs make it clear which response corresponds to each search.
>>    
>>
>IMAP already has a mechanism to handle that: tagged responses.
>  
>
And I was thinking about returning the corresponding tag in ESEARCH.

To: Weingarten Jerry <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: Other ANNOTATEMORE Comments 
Date: Tue, 15 Feb 2005 02:16:24 -0800
Sender: [email-masked]

Weingarten Jerry <[email-masked]> writes:
>Is there any particular reason why there is no mention of a way to
>delete these annotations?

Looking at annotatemore-06, section 3.3, top of page 11:
...
   Sets the specified list of entries by adding or replacing the
   specified attributes with the values provided.  Clients can use NIL
   for values of attributes it wants to remove from entries.

So, you can remove attributes from an entry by setting them to NIL.
That leaves the question of what attributes you need to remove to make
an entry completely disappear.

The ANNOTATE draft is specific on that point for its entries:
annotate-12, section 2.2.2:
...
   value
      A UTF8 string representing the data value of the attribute.  To
      delete an annotation, the client can store NIL into the value.

I.e., setting the 'value' attribute to NIL removes the entire entry,
including any vendor attributes.  This seems like the right thing to me:
vendor attributes should only be used to further describe or supplement
an entry's value attribute and not have meaning independent of it; if
they have independent meaning they should be in their own entries.

Philip Guenther

Content-class: urn:content-classes:message
Subject: Other  ANNOTATEMORE Comments
Date: Tue, 15 Feb 2005 11:30:00 +0200
From: "Weingarten Jerry" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

 Hi, 

Is there any particular reason why there is no mention of a way to
delete these annotations?  Do these just accumulate by adding new server
annotations?

Thanx,
jerry

To: Cyrus Daboo <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: New draft: SEARCH return options 
Date: Mon, 14 Feb 2005 15:46:24 -0800
Sender: [email-masked]

[Not sent to lemonade.  Do we really need to carry on this discussion in
both places?]

Cyrus Daboo <[email-masked]> writes:
...
>There is also an interesting possibility of tying the two together via the 
>ID return option I proposed. For example:
>
>C: a SEARCH RETURN (ID 1 ALL) UNSEEN
...
>C: FETCH $[1] (UID INTERNALDATE FLAGS RFC822.HEADER)
...
>The fetch commands act on the result of the different searches, referenced 
>by the ID option value. This means that a client could use multiple search 
>result sets simultaneously, as opposed to in series, as they would have to 
>right now.

The '$' token in draft-melnikov-imap-search-res-01.txt references the
last SEARCH result, so it only requires the server to remember the one
such result.  If multiple search responses need to be remembered then
some limit needs to be placed on how many a client can expect a server
to remember and perhaps the client will need some way of controlling
their lifetime.

Philip Guenther

Date: Mon, 14 Feb 2005 23:49:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> The formal syntax for the 'response' element. If you follow that 
> through you will see that you can only have one 'response-tagged' 
> item in 'response'.

Right. And I found another bit near the bottom of page 62.

I have no opinion, then. All the alternatives are fine with me.

Arnt

To: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: ANNOTATE (-12) comments
Date: Mon, 14 Feb 2005 15:15:29 -0800
Sender: [email-masked]

My abject apology to all for not doing this review sooner.

Typos:
  tyhe -> the
  UTF8 -> UTF-8
  utf8 -> utf-8		(in the default charset)

The second paragraph of the introduction seems redundant and/or
incomplete given the list in the succeeding paragraph.

I believe "i.e." should have a comma after it.  That should also fix the
extra space being inserted there.

Line-breaking should be suppressed in the middle of entry and attribute
names.  For example, "/comment" shouldn't be split across the first two
lines of the second paragraph of 2.1.  There should also be a statement
somewhere that in examples, lines not starting with "C: " or "S: " are
continuations of the previous lines.  The extra leading white-space on
such lines should either be removed or somehow described as really being
just a single space.

Since an attribute can only have one value, I don't think 'values'
should be plural in the last paragraph of 2.1.  Hmm, and since a single
STORE or FETCH can operate across multiple messages, it should arguably
say "...and any entries in message annotations, ..."  <shrug>

In 2.4, after citing ACLUPD (2086upd), it then only refers to the ACL
extension and not the RIGHTS capability.  Is it intended that a server
that supports ANNOTATE and ACL but not RIGHTS must still support the 'm'
and 'n' rights?  I think so, but given the reference to 2086upd, perhaps
the third paragraph of 2.4 should start "When the ACL extension is
present, whether or not the RIGHTS capability is advertised, the server
MUST..."

Not to cause any hair-removal, but since entry and attribute names are
in UTF-8 and are both stored and searched, doesn't a stringprep profile
need to be specified for them?  Can I put U+FF0F (FULLWIDTH SLASH) in
the name of an entry?  How about unassigned codepoints?

Since <section-part> has to be non-zero, an entry starting with "0"
can't refer to a body part annotation.

The entry names MUST NOT contain consecutive or trailing slashes.
The attribute names MUST NOT contain consecutive or trailing periods.

To avoid ambiguity, attribute names should not be allowed to contain
'priv' or 'shared' as their final component, or perhaps as any
component.

An attribute value may be binary octets, including NUL, particularly
when its content-type is something other than text (image/jpeg?).
Should the FETCH response for such a value use the literal8 syntax from
the BINARY extension?  That would seem to be preferable to introducing
content-transfer-encodings to the mess.

May servers check the value of an entry against its content-type?
Off-hand, I would say they MUST NOT do so if the content-type isn't
text/*, but MAY for content-type text/*.  However, if checking is
permitted at all then a response-code should be added for failure to
validate.

If the content-type is just "text/plain", the charset would default to
us-ascii instead of utf-8.  If that's not intended, the wording there
needs to be tweaked.

Should the server be required to validate the syntax of a content-type
being stored?  (E.g., can I store a content-type of "/" ?)

It should probably be strongly recommended that UTF-8 be used for all
textual values.  I'd hate to see "text/plain; charset=iso-2022-jp" all
over the place, though we can't exactly ban it.

Should the registration for a new attribute specify what it may contain
(utf-8, binary, etc)?

According to the syntax, ANNOTATESIZE is a response-code, but the text
of section 3.1 calls it a response.  One or the other should be changed
and at least one example of it should be added.

If the server doesn't an untagged ANNOTATESIZE response-code, is the
client allowed to store annotations?

Would lack of the correct ACL rights be a reason for returning
"ANNOTATESIZE 0"?

Just for the fun of it, I suggest adding some other fetch attribute to
one of the examples or changing one to be a UID FETCH.

In 3.6, it should simply say that any annotation entry whose size is
larger than the destination mailbox's ANNOTATESIZE is silently dropped
during the copy.  The ANNOTATESIZE zero or NIL cases are just specific
examples of that which happen to include _all_ annotations.  Hmm, if
only one of the .priv or .shared values exceeds the size, should both be
dropped or only the one that exceeds the size?

The syntax for select-param can be simplified slightly to:
      select-param      = astring / "(" astring 1*(SP astring) ")"

If the literal8 syntax is pulled in from BINARY, then the syntax for
value would change to
      value             = nstring / literal8

Why is RFC1891 a normative reference?

Philip Guenther

Date: Mon, 14 Feb 2005 12:51:02 -0800
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 14 Feb 2005, Cyrus Daboo wrote:
> Can you explain with some examples...

tag SEARCH extended-poop
tag OK [SEARCH extended-poop-response] extended SEARCH OK

as opposed to

tag SEARCH extended-poop
* ESEARCH extended-poop-response
tag OK SEARCH completed

Note that this precludes any sort of "watching" SEARCH extension, in which 
you have a standing SEARCH and get unsolicited responses.  It has been 
nearly 20 years and we have done no such thing, so maybe we don't care.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

content-class: urn:content-classes:message
Subject: RE: [lemonade] Re: New draft: SEARCH return options
Date: Mon, 14 Feb 2005 15:45:51 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> then the most honest response format is
> 
> a1234 ESEARCH ALL 1:100

I disagree. 

The notion of having multiple responses with tag affinity 
is perfectly valid in my mind. Given that, a logical progression 
from what you are proposing is ...

1 SEARCH ...
1 ESEARCH ...
1 SOME FUTURE RESPONSE ....
1 OK ...

In my mind this is a much more ungainly solution then to just reuse
the already existing notion of untagged solicited responses. Just
add tag affinity with a data item in the response is much simpler
and elegant.

Mike

content-class: urn:content-classes:message
Subject: RE: [lemonade] Re: New draft: SEARCH return options
Date: Mon, 14 Feb 2005 15:12:22 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> On Mon, 14 Feb 2005, Cyrus Daboo wrote:
> > Can you explain with some examples...
> 
> tag SEARCH extended-poop
> tag OK [SEARCH extended-poop-response] extended SEARCH OK
> 
> as opposed to
> 
> tag SEARCH extended-poop
> * ESEARCH extended-poop-response
> tag OK SEARCH completed

Would there be any other reason then the pipelining id problem 
to do it this way?

Mike

Date: Mon, 14 Feb 2005 21:19:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> The IDs make it clear which response corresponds to each search.

IMAP already has a mechanism to handle that: tagged responses.

Arnt

Date: Mon, 14 Feb 2005 15:01:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
cc: Lemonade WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Alexey,

--On February 14, 2005 2:56:25 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

> Based on the recent discussion of the
> draft-melnikov-imap-expunged-00.txt, Dave and I wrote a draft that adds
> return options to the SEARCH command. Currently defined return options
> are: COUNT (number of found messages), MIN (the lowest message number/UID
> found), MAX (the highest message number/UID found) and ALL (return all
> found messages as a message/UID set).
>
> Dave has implemented the extension in his Polymer email client.
>
> I am also proud to announce the support for this extension in Isode IMAP
> server.
>
> Alexey
>
> P.S. If you are interested to test this extension against Isode server,
> please contact me directly.

One thing you might want to consider adding to this is a 'ID' return option 
that takes an atom as an argument. The server would be required to return 
that ID and atom in the ESEARCH response for the corresponding command. 
This will solve the problem of multiple pipelined search commands and 
figuring out which search response corresponds to which command.

e.g.

C: a SEARCH RETURN (ID 1 ALL) UNSEEN
C: b SEARCH RETURN (ID 2 ALL) DELETED
S: * ESEARCH ID 1 ALL 1:100
S: * ESEARCH ID 1 ALL 200:1000
S: * ESEARCH ID 2 ALL 150
S: a OK
S: b OK

The IDs make it clear which response corresponds to each search.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 15:09:28 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
cc: Lemonade WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Alexey,
I think you need to have some mention of how this interacts with 
draft-melnikov-imap-search-res-01.txt. Or that document should mention how 
it interacts with draft-melnikov-imap-search-ret-00.txt. One issue is:

a SEARCH RETURN (COUNT) UNSEEN

Strictly speaking the above command does not generate a message sequence 
set, so is the last search result $ item set or not?

There is also an interesting possibility of tying the two together via the 
ID return option I proposed. For example:

C: a SEARCH RETURN (ID 1 ALL) UNSEEN
C: a SEARCH RETURN (ID 2 ALL) DELETED
...

C: FETCH $[1] (UID INTERNALDATE FLAGS RFC822.HEADER)

C: FETCH $[2] (UID INTERNALDATE FLAGS RFC822.HEADER)

The fetch commands act on the result of the different searches, referenced 
by the ID option value. This means that a client could use multiple search 
result sets simultaneously, as opposed to in series, as they would have to 
right now.

This could prove very powerful for clients that want to present multiple 
simultaneous 'views' on the same mailbox.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 16:37:18 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Arnt,

--On February 14, 2005 10:33:49 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> As far as I recall the IMAP base-spec only allows one tagged response
>> to any command, so the above would not work without redefining IMAP's
>> entire response behaviour...
>
> That's an excellent argument, but where in the RFC does it say so?
>

The formal syntax for the 'response' element. If you follow that through 
you will see that you can only have one 'response-tagged' item in 
'response'.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 22:33:49 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> As far as I recall the IMAP base-spec only allows one tagged response 
> to any command, so the above would not work without redefining IMAP's 
> entire response behaviour...

That's an excellent argument, but where in the RFC does it say so?

Arnt

Date: Mon, 14 Feb 2005 15:30:57 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Arnt,

--On February 14, 2005 9:19:16 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> The IDs make it clear which response corresponds to each search.
>
> IMAP already has a mechanism to handle that: tagged responses.
>

Search results are always untagged.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 15:45:24 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Mark,

--On February 14, 2005 12:43:34 PM -0800 Mark Crispin 
<[email-masked]> wrote:

>>>> The IDs make it clear which response corresponds to each search.
>>> IMAP already has a mechanism to handle that: tagged responses.
>> Search results are always untagged.
>
> Yes, but instead of an ESEARCH untagged response this could be a status
> response in the tagged OK.  I think that this is the way to go.
>

Can you explain with some examples...

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 16:28:32 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Arnt,

--On February 14, 2005 10:22:58 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

> I'm suggesting that IF you want to tag ESEARCH responses (whether you
> call them "tagged searches" or "searches with ID" is no matter to me),
> then the most honest response format is
>
> a1234 ESEARCH ALL 1:100

As far as I recall the IMAP base-spec only allows one tagged response to 
any command, so the above would not work without redefining IMAP's entire 
response behaviour...

> There are alternatives, such as sneaking the tag in the back door:
>
> * ESEARCH TAG a1234 ALL 1:100
>
> Or such as using an Elvis lookalike instead of the real thing:
>
> * ESEARCH ID a1234 ALL 1:100
>
> Whether ESEARCH is tagged or not is no matter to me. I'm happy either way.
>
> But if it is tagged, I'd like to see IMAP stay with just one tag
> mechanism (unless there are pressing reasons for having multiple similar
> mechanisms, of course).

Ok - command tags would be sufficient.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 12:43:34 -0800
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 14 Feb 2005, Cyrus Daboo wrote:
>>> The IDs make it clear which response corresponds to each search.
>> IMAP already has a mechanism to handle that: tagged responses.
> Search results are always untagged.

Yes, but instead of an ESEARCH untagged response this could be a status 
response in the tagged OK.  I think that this is the way to go.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 14 Feb 2005 22:22:58 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> OK, so are you suggesting that the tag for the SEARCH command is used 
> as the 'ID' I was proposing, e.g.:
>
> a1234 SEARCH RETURN (TAG ALL) UNSEEN
> * ESEARCH TAG a1234 ALL 1:100
> a1234 OK

I'm suggesting that IF you want to tag ESEARCH responses (whether you 
call them "tagged searches" or "searches with ID" is no matter to me), 
then the most honest response format is

a1234 ESEARCH ALL 1:100

There are alternatives, such as sneaking the tag in the back door:

* ESEARCH TAG a1234 ALL 1:100

Or such as using an Elvis lookalike instead of the real thing:

* ESEARCH ID a1234 ALL 1:100

Whether ESEARCH is tagged or not is no matter to me. I'm happy either way.

But if it is tagged, I'd like to see IMAP stay with just one tag 
mechanism (unless there are pressing reasons for having multiple 
similar mechanisms, of course).

Arnt

content-class: urn:content-classes:message
Subject: RE: [lemonade] Re: New draft: SEARCH return options
Date: Mon, 14 Feb 2005 15:19:10 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> If you want ESEARCH to be bound to the command, you can 
> either use the 
> IMAP tag mechanism or reinvent it.
> 

Maybe not reinvent, but rather exploit.

To reuse Cyrus's example ...

C: a SEARCH RETURN (ALL) UNSEEN
C: b SEARCH RETURN (ALL) DELETED
S: * ESEARCH TAG a ALL 1:100,200:1000
S: * ESEARCH TAG b ALL 150
S: a OK
S: b OK

content-class: urn:content-classes:message
Subject: RE: [lemonade] New draft: SEARCH return options
Date: Mon, 14 Feb 2005 13:59:50 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> >There should be some Normative text stipulating that SEARCH and 
> >ESEARCH are mutually exclusive responses.
> >  
> >
> The document already says "MUST send  ESEARCH when a return option is 
> specified". Do you think this is not sufficient?

Yes, if your intent is to make the responses mutually exclusive.

Mike

Date: Mon, 14 Feb 2005 16:07:05 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Arnt,

--On February 14, 2005 9:58:42 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> Search results are always untagged.
>
> Why?
>
> If you want ESEARCH to be bound to the command, you can either use the
> IMAP tag mechanism or reinvent it.
>

OK, so are you suggesting that the tag for the SEARCH command is used as 
the 'ID' I was proposing, e.g.:

a1234 SEARCH RETURN (TAG ALL) UNSEEN
* ESEARCH TAG a1234 ALL 1:100
a1234 OK

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 16:04:10 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Mark,

--On February 14, 2005 12:51:02 PM -0800 Mark Crispin 
<[email-masked]> wrote:

> tag SEARCH extended-poop
> tag OK [SEARCH extended-poop-response] extended SEARCH OK
>
> as opposed to
>
> tag SEARCH extended-poop
> * ESEARCH extended-poop-response
> tag OK SEARCH completed
>
> Note that this precludes any sort of "watching" SEARCH extension, in
> which you have a standing SEARCH and get unsolicited responses.  It has
> been nearly 20 years and we have done no such thing, so maybe we don't
> care.
>

I guess I dislike the idea of having actual results come back in the 
extended response code.

Right now I don't see why we need the new ESEARCH response at all, as 
opposed to just redefining the SEARCH response (which is fine because the 
client knows what it is going to get having used the extended SEARCH 
command). Perhaps Alexey can explain why we have to have a new response?

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 21:58:42 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> Hi Arnt,
>
> --On February 14, 2005 9:19:16 PM +0100 Arnt Gulbrandsen 
> <[email-masked]> wrote:
>
>>> The IDs make it clear which response corresponds to each search.
>>
>> IMAP already has a mechanism to handle that: tagged responses.
>
> Search results are always untagged.

Why?

If you want ESEARCH to be bound to the command, you can either use the 
IMAP tag mechanism or reinvent it.

Arnt

Date: Mon, 14 Feb 2005 19:44:14 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [lemonade] New draft: SEARCH return options
Sender: [email-masked]

[email-masked] wrote:

>Comments:
>I don't understand what the anticipated use of RETURN () would be?
>  
>
This is a hook for the SEARCHRES extension 
(draft-melnikov-imap-search-res-01.txt).

>There should be some Normative text stipulating that SEARCH and 
>ESEARCH are mutually exclusive responses.
>  
>
The document already says "MUST send  ESEARCH when a return option is 
specified". Do you think this is not sufficient?

content-class: urn:content-classes:message
Subject: RE: [lemonade] New draft: SEARCH return options
Date: Mon, 14 Feb 2005 13:35:01 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I like it. I think it is done very smoothly.

Comments:
I don't understand what the anticipated use of RETURN () would be?

There should be some Normative text stipulating that SEARCH and 
ESEARCH are mutually exclusive responses.

Mike

content-class: urn:content-classes:message
Subject: RE: New draft: SEARCH return options
Date: Mon, 14 Feb 2005 13:25:07 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> Is there much feeling as to how useful it would be?  

I think the RETURN (ALL) semantics will be useful.

Mike

Date: Mon, 14 Feb 2005 10:12:00 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

I've reviewed this document and while I have document nits the protocol 
proposed looks OK to me.

Is there much feeling as to how useful it would be?  I'm not talking about 
Dave and Alexey since I'm sure they are already convinced.  It's more of a 
question of whether the benefit is worth the added complexity (don't 
forget, it does represent an additional task for server implementors!).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 14 Feb 2005 14:56:25 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: New draft: SEARCH return options
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: IMAP4 extension to SEARCH command for controlling what 
>			  kind of information is returned
>	Author(s)	: A. Melnikov, D. Cridland
>	Filename	: draft-melnikov-imap-search-ret-00.txt
>	Pages		: 0
>	Date		: 2005-2-11
>	
>This document extends SEARCH and UID SEARCH commands with result
>   specifier, which can control what kind of information is returned.
>   Several result specifiers are defined: minimal value, maximal
>   value, all found messages and number of found messages. A new
>   response ESEARCH is also specified.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-melnikov-imap-search-ret-00.txt
>
Based on the recent discussion of the 
draft-melnikov-imap-expunged-00.txt, Dave and I wrote a draft that adds 
return options to the SEARCH command. Currently defined return options 
are: COUNT (number of found messages), MIN (the lowest message 
number/UID found), MAX (the highest message number/UID found) and ALL 
(return all found messages as a message/UID set).

Dave has implemented the extension in his Polymer email client.

I am also proud to announce the support for this extension in Isode IMAP 
server.

Alexey

P.S. If you are interested to test this extension against Isode server, please contact me directly.

 __________________________________________
IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Mon, 14 Feb 2005 13:02:52 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-11.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.
>
>	Title		: IMAP4 LIST Command Extensions
>	Author(s)	: B. Leiba, A. Melnikov
>	Filename	: draft-ietf-imapext-list-extensions-11.txt
>	Pages		: 10
>	Date		: 2005-2-10
>	
>IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
>have added extensions that have required specialized lists (see
>[MboxRefer] for an example) we have had to expand the number of list
>commands, since each extension must add its function to both LIST and
>LSUB, and these commands are not, as they are defined, extensible.
>If we've needed the extensions to work together, we've had to add a
>set of commands to mix the different options, the set increasing in
>size with each new extension.  This document describes an extension
>to the base LIST command that will allow these additions to be done
>with mutually compatible options to the LIST command, avoiding the
>exponential increase in specialized list commands.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-11.txt
>  
>
After reviewing the mailing list archive I've decided that CHILDINFO is the way to go, because we want to allow for multiple LIST and unsolicited responses. This indeed made explanation much easier. Of course CHILDINFO is a bit verbose, so I would welcome suggestions.

I've also renamed MATCHPARENT to RECURSIVEMATH and made rules about CHILDREN extension more strict (as discussed during the last interim meeting). I've also tried to address some minor editorial issues raised by Philip previously.

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-11.txt
Date: Thu, 10 Feb 2005 15:51:14 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-11.txt
	Pages		: 10
	Date		: 2005-2-10
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-list-extensions-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: Dave Cridland <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ANNOTATEMORE Comments
Date: Thu, 10 Feb 2005 19:40:54 +0000
Sender: [email-masked]

On Thu Feb 10 14:34:22 2005, [email-masked] wrote:
> Would it be worth while adding an entry for declaring capabilities?
> IMAP obviously has a way to declare an extension via the 
> CAPABILITY command, but it would seem that an optional declaration 
> via an annotation could easily provide for a richer declaration. 
> 
> For example a new server entry like:
> 
> /capabilities/<capability>
> 
> Attributes could then be defined that may describe or modify the 
> capability further. 

This is very like the capability dataset class in ACAP, which allows for active clients to provide services via the ACAP server, like addressbook expansion.

It sounds like a great idea in principle, and could provide the same capability - that is, per-user capabilities provided in some cases by external modules, sometimes specific to the user.

The problems are quite similar, too, though - with ACAP, it wasn't ever fully defined precisely how a client detirmines that the agent providing the capability is really present and working. In my ACAP work, I've always avoided the dataset class as a whole - it's simply unreliable, great idea or not. Either that, or I just can't see how it ought to work, which is equally likely.

This needn't be the case with IMAP/ANNOTATEMORE, of course, but it needs thinking about carefully, I think.

Dave.

content-class: urn:content-classes:message
Subject: ANNOTATEMORE Comments
Date: Thu, 10 Feb 2005 08:34:22 -0600
From: <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I like it.

Would it be worth while adding an entry for declaring capabilities?
IMAP obviously has a way to declare an extension via the 
CAPABILITY command, but it would seem that an optional declaration 
via an annotation could easily provide for a richer declaration. 

For example a new server entry like:

/capabilities/<capability>

Attributes could then be defined that may describe or modify the 
capability further. 

Mike

content-class: urn:content-classes:message
Subject: Body Part Content Conversion using ANNOTATEMORE
Date: Thu, 10 Feb 2005 08:27:32 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I've put together a draft describing a proposal that uses ANNOTATEMORE
as the vehicle for discovery. Please provide comments.

I've copied both imapext and lemonade because it is relevant to both.
I would suggest any discussion be confined to the lemonade list.

I've submitted the draft, but until then you can find it at the link 
below.

http://ietf.webdav.org/imapext/draft-wener-lemonade-conversion-00.txt

Mike

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Tue, 8 Feb 2005 18:56:08 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Dave Cridland [mailto:[email-masked]]
> Sent: Tuesday, February 08, 2005 5:45 PM
...
> > Maybe a better solution is ...
> > 
> > C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTUIDS)
> > S: * SEARCH etc ...
> > S: 1 OK FETCH Complete
> > 
> > In this case you completely remove the problem of having
> > any EXPUNGE memory, and it alleviates the server from having
> > to even worry about MODSEQ for expunges.
> > 
> 
> Is having an EXPUNGE memory that difficult?

No, but that is not the point. The point is that we are looking
for an optimal way for a client to synchronize server mailbox 
state. If it can be equivalently done with out requiring the 
server to maintain additional state I see this as an upside. 
After all what got us to this point in the discussion was the 
possibility of a server forgetting expunges.

> In short, I don't actually think that an extension as you 
> propose here - that simply sends out an unsolicited UID 
> SEARCH - is actually telling the client what it wants to know.

In this case it was solicited.

We did conclude, a message or two ago, that this was equivalent 
to the UIDEXPUNGE. 

Universe = ExpungedSet U UidSearchSet

We know the universe. So we can send one of the other two and 
deduce the third. Also, what the client ultimately wants is 
UidSearchSet.  

> 
> The rest of this email is, I hope, teaching any watching 
> grandmothers to suck eggs. (Not my grandmother, though, as 
> she was the only person I ever met who liked CPM.) Feel free 
> to tune out.

I have no idea what you are talking about, here.

Mike

From: Dave Cridland <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Tue, 08 Feb 2005 22:44:31 +0000
Sender: [email-masked]

On Tue Feb  8 19:27:23 2005, [email-masked] wrote:
> I understand the appeal of having the same response, but I think 
> you overstate the issue of returning the SEARCH response. Clients 
> will have code to deal with the SEARCH response.
> 

But, quite possibly, only in the context of a sent SEARCH/UID SEARCH command.

> 
> Maybe a better solution is ...
> 
> C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTUIDS)
> S: * SEARCH etc ...
> S: 1 OK FETCH Complete
> 
> In this case you completely remove the problem of having
> any EXPUNGE memory, and it alleviates the server from having
> to even worry about MODSEQ for expunges.
> 

Is having an EXPUNGE memory that difficult?

> 
> A couple of interesting notes regarding the above solution ...
> 1) It is just a shorthand way of doing both a FETCH and UID 
> SEARCH in the same command.

With extra processing above and beyond the pipelined UID SEARCH/UID FETCH that is otherwise identical to it other than a handful of octets - if the packet size were so small that this made any practical difference, I'd be shocked.

Besides which, a client can always be in posession of the knowledge of whether it knows about all the expunges, or whether some may remain undetected, simply by examining UIDNEXT/EXISTS.

In short, I don't actually think that an extension as you propose here - that simply sends out an unsolicited UID SEARCH - is actually telling the client what it wants to know.

The rest of this email is, I hope, teaching any watching grandmothers to suck eggs. (Not my grandmother, though, as she was the only person I ever met who liked CPM.) Feel free to tune out.

I assume this algorithm is reasonably well known, I've been using various stages of refinement of it for around a year, with pleasant success, but I'll hold it up for people to shoot it down:

1) Let the values of UIDNEXT and EXISTS as reported in the previous SELECT be LAST_UIDNEXT and LAST_EXISTS respectively.

2) Let the tracked value of EXISTS, as detirmined by EXPUNGE and EXISTS responses received by the client during the previous mailbox session be CURRENT_EXISTS.

3) Let the count of EXPUNGE responses received by the client during the previous mailbox session be SEEN_EXPUNGES

4) Let the values of UIDNEXT and EXISTS reported during the new select be NEW_UIDNEXT and NEW_EXISTS, respectively.

Now:

A) If LAST_UIDNEXT==NEW_UIDNEXT and CURRENT_EXISTS==NEW_EXISTS, then there have been no expunges between sessions. (And no appends, of course, this being trivial.)

B) If ( NEW_UIDNEXT - LAST_UIDNEXT ) == ( NEW_EXISTS - LAST_EXISTS + SEEN_EXPUNGES ), then there have been no expunges between sessions. (And some appends)

In any other case, there may have been expunges.

Since servers can, I believe, issue UIDs non-monotonically, this algorithm can fail, but does so safely (ie, the client believes there may have been EXPUNGEs when in fact there weren't).

On the other hand, if some mechanism were available that allowed the server to report a collection of UIDs which had recently been EXPUNGEd, the client could issue this instead, add the number found to SEEN_EXPUNGES above, and check case B to see if it had them all. (Again, this fails where UIDNEXT does not increase monotonically). Some information, here, is more use than none.

If the client believes there to have been EXPUNGEs, then it can simply perform a UID SEARCH across, for instance, CURRENT_EXISTS-100 to NEW_EXISTS, and simply replace the end of the known UID list if the first UID in the new list matches. (This is relatively common, since EXPUNGEs do appear to typically happen at the end of the mailbox.) Therefore, no need to UID SEARCH 1:* at all in most cases. Given the potential size of SEARCH results, it may be best to scan backwards at intervals in order to find the matching point which indicates that no EXPUNGEs affected anything before.

Of course, I do all this already, but then, my client is a caching online client, and I imagine most of the client authors here are more interested in the disconnected mode case. For my client, it enables me to resync as much as I need to in two round trips, usually one, and often zero, for mailboxes under 75,000 messages. This is as much scalability as I can reasonably hope for, especially as huge mailboxes tend to be mailing list archives, and thus are caught by rule (B) every time.

Dave.

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Tue, 8 Feb 2005 13:27:23 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext 
> Alexey Melnikov
> Sent: Friday, February 04, 2005 8:05 AM
...
> >Don't force a round trip.
> >
> >C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
> >S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
> >S: * SEARCH etc ...
> >S: 1 OK FETCH Complete
> >
> >Though, I'm not sure a round trip in this case would be bad.
> >
> >What worries me is the pathological case. It strikes me as 
> >wrong to send a list of an unbounded set, when what the client 
> >really wants is the compliment of that.
> >  
> >
> I frankly don't like that the server sends two different 
> responses that 
> mean pretty much the same thing. This definitely makes client 
> implementations more difficult.

I understand the appeal of having the same response, but I think 
you overstate the issue of returning the SEARCH response. Clients 
will have code to deal with the SEARCH response.

Maybe a better solution is ...

C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTUIDS)
S: * SEARCH etc ...
S: 1 OK FETCH Complete

In this case you completely remove the problem of having
any EXPUNGE memory, and it alleviates the server from having
to even worry about MODSEQ for expunges.

A couple of interesting notes regarding the above solution ...
1) It is just a shorthand way of doing both a FETCH and UID 
SEARCH in the same command.
2) It points out how adding EXPUNGE to CONDSTORE is a bit of a 
force fit.

Mike

From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Date: Mon, 07 Feb 2005 22:55:14 +0000
Sender: [email-masked]

On Mon Feb  7 20:40:09 2005, Mark Crispin wrote:
> 
> Do we really need "has" in front of all these flags?
> 
> Why not \Children, \NoChildren, etc.?
> 

As Alexey says, these are widely deployed - existing client code that I've had a chance to examine appears to rank CHILDREN as one of the most widely deployed extensions.

My suspicion is that many clients will start using LISTEXT merely by requesting CHILDREN formally. Some may well not notice if we subtlely rename the flags. (Although no doubt some server writers never bothered to spell them right to begin with).

> 
> Another point: using binary flags for a tri-state condition is troublesome, since it creates silly states.  \Marked and \UnMarked created the problem -- a mistake that I still deeply regret -- and it would be a shame if it gets worse.
> 
> Since we have binary flags as a given, can we think of a methodology that avoids tri-state conditions?
> 

Barry Leiba commented that \HasNoChildren is required to handle unsolicited LIST responses.

However, the same argument can be made of \Subscribed, and presumably other flags - does an unsolicited LIST without \Subscribed indicate that the mailbox is not subscribed, or merely that subscription information isn't included?

It strikes me that unsolicited LIST responses, currently barred by 3501 [I think: It's 11pm here, and I can't find the text], either need to be barred by LISTEXT explicitly pending a future standard, or we should actually solve the issue.

Dave.

Date: Mon, 07 Feb 2005 21:47:12 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for ANNOTATE Feb 4-18
Sender: [email-masked]

Lisa Dusseault wrote:

>
> This is a notification of the beginning of last-call for the -12 draft 
> of ANNOTATE:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-12.txt
>
> If you review this draft, let the WG know even if you have no issues 
> or comments.  Also, we'd like to know who plans to implement this or 
> may have already begun (you can let me know privately or mail the 
> WG).  Last call will go until and including February 18 2005.

Minor comment:
 The description of "/<section-part>/flags" only allows for "1" or "0". 
However, the description of "/flags" still allows for NIL.

Alexey

Date: Mon, 7 Feb 2005 13:18:57 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 7 Feb 2005, Alexey Melnikov wrote:
>> Do we really need "has" in front of all these flags?
>> Why not \Children, \NoChildren, etc.?
> Because they are already widely deployed.

The CHILDREN extension may be widely-deployed, but this is LISTEXT, not 
CHILDREN.

We have a chance to review the lessons of RFC 3348 (which I'll remind you 
is *NOT* standards-track!!) and maybe do something better.

I didn't say "break RFC 3348", but I am implying "replace RFC 3348".

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 07 Feb 2005 20:55:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

Mark Crispin wrote:

> Do we really need "has" in front of all these flags?
>
> Why not \Children, \NoChildren, etc.?

Because they are already widely deployed.

> Another point: using binary flags for a tri-state condition is 
> troublesome, since it creates silly states.  \Marked and \UnMarked 
> created the problem -- a mistake that I still deeply regret -- and it 
> would be a shame if it gets worse.
>
> Since we have binary flags as a given, can we think of a methodology 
> that avoids tri-state conditions?

Date: Mon, 7 Feb 2005 12:40:09 -0800
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Organization: Networks & Distributed Computing
Sender: [email-masked]

Do we really need "has" in front of all these flags?

Why not \Children, \NoChildren, etc.?

Another point: using binary flags for a tri-state condition is 
troublesome, since it creates silly states.  \Marked and \UnMarked created 
the problem -- a mistake that I still deeply regret -- and it would be a 
shame if it gets worse.

Since we have binary flags as a given, can we think of a methodology that 
avoids tri-state conditions?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 07 Feb 2005 19:55:12 +0000
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

Barry Leiba wrote:

>>These were discussed fairly completely during the meeting and we came
>>to consensus that
>>-) MATCHPARENT would stay; not much point in making LIST extendable if
>>   things that can reasonably be options are instead implicitly
>>   triggered
>>    
>>
>Yes, but we decided to call it "recursivematch".
>  
>
Done.

>>-) \placeholder and \hassubmailboxes will be replaced by a single flag
>>   named something like \hasmatchingchild.  Whether the returned name
>>   itself matches can be trivially deduced from the other returned
>>   flags.
>>    
>>
>
>Correct, and "\hasmatchingchildren" was what we were calling it.  I'm
>open to other names, but I think this name makes its purpose clear
>(where "hassubmailboxes" did not).
>
I've renamed the flag as well.

>>If the client pipelines requests that result in ambiguous
>>responses, well, "Doctor it hurts when I do _this_...".
>>    
>>
>
>Or put more IETF-ly, clients MUST NOT send simultaneous LIST commands,
>the responses from which they would not be able to sort out
>unambiguously.
>
It sounds there is a strong desire to allow for multiple extended LISTs 
and unsolicited LIST responses.

>>-) keeping the CHILDREN option and its behavior separate from
>>   MATCHPARENT was deemed to be clearer than merging them.  CHILDREN
>>   would be changed to require exact responses:
>>    
>>
>
>In other words, correct implementation of CHILDREN *will* be required
>by the LISTEXT spec, but the "\haschildren" and "\hasnochildren" flags
>will only be returned if they're asked for.  We DO need the
>"\hasnochildren" flag to distinguish the absence of children from the
>case where the server decides to send an unsolicited LIST response at
>the same time as it's responding to a LIST command.
>
>We've gone back and forth on this one, and I hope we have now decided
>it firmly.  The reasoning is that clients that want the has<no>children
>help will do the work with a series of commands anyway, and even if
>it's not convenient for some server implementations to provide it, it's
>still a LOT cheaper for them to do it in the server than for the client
>to have to request them separately.
>
Is the existing text Ok:

   In some instances a server that supports the LISTEXT extension
   might not be able to determine whether a mailbox has children.  For
   example it may have difficulty determining whether there are child
   mailboxes when LISTing mailboxes while operating in a particular
   namespace.
   In these cases, a server MAY exclude both the \HasChildren and
   \HasNoChildren attributes in the LIST response.  As such, a client
   can not make any assumptions about whether a mailbox has children
   based upon the absence of a single attribute. In particular, some
   servers may not be able to combine the SUBSCRIBED selection option
   and CHILDREN return option.  Such servers MUST honor the SUBSCRIBED
   selection option, and they will simply ignore the CHILDREN return option
   if both are requested. It is an error for the server to return both a
   \HasChildren and a \HasNoChildren attribute in a LIST response.
?
Or should I make it stricter?

>>There was some discussion of requiring LIST to return BAD if
>>MATCHPARENT was used with a pattern containing '*', but I'm not sure
>>that was dropped later as being too restrictive.
>>    
>>
>
>It was dropped.  We decided, after thinking about it, that it's not
>*really* a problem.  The consensus at the end was that there need be no
>restrictions on when "recursivematch" can be used.
>
>There was the issue of recursion loops, and we decided to allow a
>server, probably with a MAY clause, to limit the depth.  We did not
>pick a minimum depth that MUST be implemented, so we should pick one
>here.
>
I frankly don't recall any such discussion.
But any suggested text will be welcomed.

>
>We should have examples in the jabber log, assuming that Rob was able
>accurately to enter my scratchings on the white-boards, since I
>annoyingly refused to write from left to right.  Should we copy those
>examples here, or just point to the jabber logs?
>
>  
>

From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for ANNOTATE Feb 4-18
Date: Fri, 04 Feb 2005 23:00:18 +0000
Sender: [email-masked]

On Fri Feb  4 21:32:16 2005, Lisa Dusseault wrote:
> If you review this draft, let the WG know even if you have no issues or comments.  Also, we'd like to know who plans to implement this or may have already begun (you can let me know privately or mail the WG).  Last call will go until and including February 18 2005.

I'm certainly planning to implement this my client, and with any luck I'll manage it quite soon. I do need to rework aspects of my CONDSTORE implementation to properly support it, though.

Given this is entirely new functionality, I personally believe it's vital to obtain real experience of interoperable implementation before we can safely put it through to RFC status.

As such, if anyone is implementing this on the server, I would be very grateful for a test account, whether or not it's under NDA. (Or just an agreement not to say anything publically.)

Dave.

Date: Fri, 04 Feb 2005 17:16:52 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Informal list last call for ANNOTATEMORE
Sender: [email-masked]

Hi folks,
I would like to submit the ANNOTATEMORE document to the IESG at the same 
time as the ANNOTE document (once that has gone through WGLC and all seems 
OK). However, since ANNOTATEMORE is an individual submission it is not 
subject to a WGLC, but I would appreciate it if people looking at ANNOTATE 
would also look at ANNOTATEMORE in the same vein and pass comments back, 
thanks.

<http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-07.txt>

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WG last call for ANNOTATE Feb 4-18
Date: Fri, 4 Feb 2005 13:32:16 -0800
Sender: [email-masked]

This is a notification of the beginning of last-call for the -12 draft 
of ANNOTATE:

http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-12.txt

If you review this draft, let the WG know even if you have no issues or 
comments.  Also, we'd like to know who plans to implement this or may 
have already begun (you can let me know privately or mail the WG).  
Last call will go until and including February 18 2005.

Lisa Dusseault

Date: Fri, 04 Feb 2005 13:05:00 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[email-masked] wrote:

>>>>>>> <><><> <<What if the server can?t remember some expunged UIDs, for
>>>>>>
>...
>  
>
>>>I think a better choice would be:
>>>C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
>>>S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
>>>S: 1 OK FETCH Complete
>>>
>>>The NO response with a UIDEXPUNGE response code would then 
>>>communicate to the client to resort to SEARCH.
>>>      
>>>
>>And the client will perform "UID SEARCH 1:*"? 
>>    
>>
>
>Yes.
>  
>
>>But this would give the 
>>same result as the server returning all expunges. Actually, 
>>    
>>
>
>Same end result, sure, but the set of UIDs returned is the 
>compliment of the set returned from UIDEXPUNGE. In the limit
>this is gauranteed to be smaller. :)
>  
>
Unless we have an archive folder, where nothing gets deleted. But for an 
average INBOX, you are right.

>>it would be 
>>worse, because SEARCH can't use ranges.
>>    
>>
>The lack of a range expression in the SEARCH response is 
>unfortunate. Isn't there a need to fix this independent 
>of this discussion? 
>  
>
>>In many cases just sending all expunged messages would be faster than 
>>forcing a round trip on the client.
>>    
>>
>
>Don't force a round trip.
>
>C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
>S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
>S: * SEARCH etc ...
>S: 1 OK FETCH Complete
>
>Though, I'm not sure a round trip in this case would be bad.
>
>What worries me is the pathological case. It strikes me as 
>wrong to send a list of an unbounded set, when what the client 
>really wants is the compliment of that.
>  
>
I frankly don't like that the server sends two different responses that 
mean pretty much the same thing. This definitely makes client 
implementations more difficult.

>>I also suspect that the list of expunges messages will 
>>compress nicely using ranges.
>>    
>>
>
>Over time what will happen is there will be a large range at the 
>beginning and then some amount of fragmentation that completely 
>depends on the mailbox maintenance habits of the user.
>  
>
I agree.

Date: Thu, 03 Feb 2005 22:02:45 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[email-masked] wrote:

>>>Sec 3.3
>>>  <<alternative #1: extend syntax for the CHANGEDSINCE FETCH
>>>  modifier.
>>>
>>>Why even have the keyword REPORTEXPUNGES? Why not just overload
>>>CHANGEDSINCE to imply expunges? 
>>>      
>>>
>>Sending expunge information to the client who hasn't asked for it 
>>doesn't sound right, even though any client should be able to ignore 
>>such information.
>>
>>If we choose to replace CONDSTORE, there would be no REPORTEXPUNGES.
>>    
>>
>If it does not sound right in draft-melnikov-imap-expunged-00 why
>would it be okay in CONDSTORE?
>  
>
What I really meant was "if EXPUNGED were a part of CONDSTORE, we 
wouldn't have to have REPORTEXPUNGES".

Anyway, Dave Cridland has told me that sometimes a client might only 
want to know about expunged messages and not about flag changes. This 
suggests that we should keep REPORTEXPUNGES.

Alexey

Date: Fri, 04 Feb 2005 12:23:20 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Compact SEARCH results
Sender: [email-masked]

[email-masked] wrote:

>The lack of a range expression in the SEARCH response is 
>unfortunate. Isn't there a need to fix this independent 
>of this discussion? 
>  
>
Yes.

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Fri, 4 Feb 2005 06:23:24 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, February 03, 2005 5:03 PM
...
> Anyway, Dave Cridland has told me that sometimes a client might only 
> want to know about expunged messages and not about flag changes. This 
> suggests that we should keep REPORTEXPUNGES.

Okay. More flexible does not hurt.

Mike

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 3 Feb 2005 16:32:55 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Timo Sirainen
> Sent: Thursday, February 03, 2005 3:22 PM
...
> > I think a better choice would be:
> > C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
> > S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
> > S: 1 OK FETCH Complete
> > 
> > The NO response with a UIDEXPUNGE response code would then 
> > communicate to the client to resort to SEARCH.
> 
> Bad idea. This is a rare exceptional case which would rarely 
> get tested
> for clients, if the client writer had even bothered to write code for
> handling it.

I don't believe your reasoning is valid.

1) At this point in time I would not assume it was rare. We don't 
know the likelihood of this event. It depends on how the server
implements "EXPUNGE Memory" and the clients usage patterns.

2) To not do something because it is rare would be to write 
incomplete and broken specifications. There are always rare
events in all software, including protocol software.

3) The problem you bring up is a software engineering problem
not a protocol problem. If an implementer is concerned about 
clients not handling rare events they should create a test 
vehicle that artificially increases the likelihood of rare
events.

4) Obviously clients have handled NO responses. They also
have obviously used SEARCH responses. The only thing new 
is the response code. Are there no other rare response codes?

Mike

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 3 Feb 2005 15:33:36 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, February 03, 2005 2:27 PM
...
> >>>>> <><> <<What if the server can?t remember some expunged 
> UIDs, for 
...
> >I think a better choice would be:
> >C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
> >S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
> >S: 1 OK FETCH Complete
> >
> >The NO response with a UIDEXPUNGE response code would then 
> >communicate to the client to resort to SEARCH.
> >
> And the client will perform "UID SEARCH 1:*"? 

Yes.

> But this would give the 
> same result as the server returning all expunges. Actually, 

Same end result, sure, but the set of UIDs returned is the 
compliment of the set returned from UIDEXPUNGE. In the limit
this is gauranteed to be smaller. :)

> it would be 
> worse, because SEARCH can't use ranges.

The lack of a range expression in the SEARCH response is 
unfortunate. Isn't there a need to fix this independent 
of this discussion? 

> 
> In many cases just sending all expunged messages would be faster than 
> forcing a round trip on the client.

Don't force a round trip.

C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
S: * SEARCH etc ...
S: 1 OK FETCH Complete

Though, I'm not sure a round trip in this case would be bad.

What worries me is the pathological case. It strikes me as 
wrong to send a list of an unbounded set, when what the client 
really wants is the compliment of that.

> I also suspect that the list of expunges messages will 
> compress nicely 
> using ranges.

Over time what will happen is there will be a large range at the 
beginning and then some amount of fragmentation that completely 
depends on the mailbox maintenance habits of the user.

Mike 

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-12.txt
Date: Thu, 03 Feb 2005 15:56:25 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-12.txt
	Pages		: 40
	Date		: 2005-2-3
	
The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "metadata" for messages
   stored in an IMAP mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-12.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-annotate-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-annotate-12.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-annotate-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Subject: RE: Comments on draft-melnikov-imap-expunged-00
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 03 Feb 2005 22:21:42 +0200
Sender: [email-masked]

--=-WkoxeaaPtvSa8jKekaBn
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2005-02-03 at 12:58 -0600, [email-masked] wrote:
> I think a better choice would be:
> C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
> S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
> S: 1 OK FETCH Complete
>=20
> The NO response with a UIDEXPUNGE response code would then=20
> communicate to the client to resort to SEARCH.

Bad idea. This is a rare exceptional case which would rarely get tested
for clients, if the client writer had even bothered to write code for
handling it.

--=-WkoxeaaPtvSa8jKekaBn
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-WkoxeaaPtvSa8jKekaBn--

Date: Thu, 03 Feb 2005 19:27:01 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[email-masked] wrote:

>>>>> <><> <<What if the server can?t remember some expunged UIDs, for 
>>>>> example
>>>>
>>>>> <> the provided mod-sequence is too old? Can the server just return
>>>>> all UIDs not in the UID set? This can generate additional traffic,
>>>>
>>>>> but should be Ok otherwise.>>
>>>>>          
>>>>>
>...
>  
>
>>>I see two options ...
>>>1) An unsolicited * SEARCH 
>>>2) A response code that tells the client to use UID SEARCH 1:*
>>>
>>>In either case the client knows.
>>>      
>>>
>>My comment is trying to say that the server MUST always 
>>return expunged 
>>messages, if it doesn't remember which messages got expunged 
>>since the 
>>specified modification sequence, it should return ALL 
>>messages expunged 
>>(but only for UID set the specified in the UID FETCH (REPORTEXPUNGES).
>>    
>>
>
>The most common use case will be 1:*. In this case you will send 
>back a response with every UID expunged since the UIDVALIDITY value was 
>created (I understand you have range syntax). This makes no sense to
>me.
>
>I think a better choice would be:
>C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
>S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
>S: 1 OK FETCH Complete
>
>The NO response with a UIDEXPUNGE response code would then 
>communicate to the client to resort to SEARCH.
>
And the client will perform "UID SEARCH 1:*"? But this would give the 
same result as the server returning all expunges. Actually, it would be 
worse, because SEARCH can't use ranges.

In many cases just sending all expunged messages would be faster than 
forcing a round trip on the client.
I also suspect that the list of expunges messages will compress nicely 
using ranges.

Date: Thu, 03 Feb 2005 19:19:26 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>, "[email-masked]" <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

Dave Cridland wrote:

>> I see no point for the client to violate the MUST, that is why I've 
>> used upper case MUST. (please, prove me wrong with an example).
>> The client can do many other stupid things and I don't want to 
>> encourage them.
>
>
> Well... I can't think of an example. But I can't think of a case where 
> it would hurt, either.
>
> I think I'd write SHOULD NOT here, because even if a client does, it's 
> certainly not harming interoperability by doing so, it's just being 
> dumb. Clients SHOULD NOT be badly written, certainly, but to state 
> that IMAP clients MUST NOT be badly written would mean that many 
> existing clients would be technically broken... 

and
[email-masked] wrote:

>>I see no point for the client to violate the MUST, that is 
>>why I've used upper case MUST. (please, prove me wrong with an example).
>>    
>>
>
>Prove what? This is not a case for proof. The client does not 
>have to perform the operation you just mentioned and it can 
>still be a compliant client. It would be less efficient, hence
>it should.
>  
>
Fine, I will change MUST NOT to SHOULD NOT.

The whole section is informative. Except for "MUST clear cache if 
UIDVALIDITY changes" everything else is not required for compliance. So 
maybe I shouldn't use uppercase words in this section.

Alexey

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 3 Feb 2005 12:58:06 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, February 03, 2005 10:14 AM
...
> >>> <> <<What if the server can?t remember some expunged 
> UIDs, for example
> >>
> >>>  the provided mod-sequence is too old? Can the server just return
> >>>  all UIDs not in the UID set? This can generate 
> additional traffic,
> >>>  but should be Ok otherwise.>>
...
> >I see two options ...
> >1) An unsolicited * SEARCH 
> >2) A response code that tells the client to use UID SEARCH 1:*
> >
> >In either case the client knows.
> >
> My comment is trying to say that the server MUST always 
> return expunged 
> messages, if it doesn't remember which messages got expunged 
> since the 
> specified modification sequence, it should return ALL 
> messages expunged 
> (but only for UID set the specified in the UID FETCH (REPORTEXPUNGES).

The most common use case will be 1:*. In this case you will send 
back a response with every UID expunged since the UIDVALIDITY value was 
created (I understand you have range syntax). This makes no sense to
me.

I think a better choice would be:
C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
S: 1 OK FETCH Complete

The NO response with a UIDEXPUNGE response code would then 
communicate to the client to resort to SEARCH.

> 
> >>> <> " ... HIGHESTMODSEQ with the one returned by the 
> server. If the 
> >>> cached
> >>
> >>>  HIGHESTMODSEQ value also matches the one returned by the server,
> >>>  then the client MUST NOT fetch flags for cached messages, as they
> >>>  hasn't changed. "
> >>>
> >>>Shouldn't this be "SHOULD NOT".
> >>>      
> >>>
> >>This is an informative section, so I should probably 
> >>lowercase the term.    
> >>
> >
> >Informative or not the client does not have to perform this 
> >behavior hence it seems it should be "should".
> >  
> >
> I see no point for the client to violate the MUST, that is 
> why I've used 
> upper case MUST. (please, prove me wrong with an example).

Prove what? This is not a case for proof. The client does not 
have to perform the operation you just mentioned and it can 
still be a compliant client. It would be less efficient, hence
it should.

> The client can do many other stupid things and I don't want 
> to encourage 
> them.

Except for anarchists and teenagers, I know of no one that 
would claim that the statement, "You should not do X", encourages 
them to do X.

Mike

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 03 Feb 2005 15:42:48 +0000
Sender: [email-masked]

On Thu Feb  3 15:13:49 2005, Alexey Melnikov wrote:
> 
> [Let's have this discussion on IMAPEXT only].
> 

Reply-list curtailed...

> [email-masked] wrote:
> 
>>>> <> <<What if the server can?t remember some expunged UIDs, for example
>>> 
>>>>  the provided mod-sequence is too old? Can the server just return
>>>>  all UIDs not in the UID set? This can generate additional traffic,
>>>>  but should be Ok otherwise.>>
>>>>      
>> ...
>>  
>>> Client doesn't know and need not know. I think this is a server only issue.    
>> 
>> I guess I need to see what you mean by "Can the server just return
>> all UIDs not in the UID set?"
>> 
>> The client has to know that something is amiss on the server. It is not getting an expunge. A fetch response is only supposed to be returned subject to the CHANGEDSINCE modifier.
>> 
>> I see two options ...
>> 1) An unsolicited * SEARCH 2) A response code that tells the client to use UID SEARCH 1:*
>> 
>> In either case the client knows.
>> 
> My comment is trying to say that the server MUST always return expunged messages, if it doesn't remember which messages got expunged since the specified modification sequence, it should return ALL messages expunged (but only for UID set the specified in the UID FETCH (REPORTEXPUNGES).
> 
> So, the client doesn't really need to know whether the server remembers or not. The client should be able to handle duplicate expunge notifications anyway.
> 

The client can always tell if the server doesn't remember. It's a simple case of using UIDNEXT and EXISTS responses during the SELECT, and rechecking after expunges have been requested off the server.

I'd rather have the client fallback to older methods itself if it detirmines that it still doesn't have the list of all EXPUNGEs, and the client, in general, has more information than the server on this matter.

> 
>>>> <> " ... HIGHESTMODSEQ with the one returned by the server. If the cached
>>> 
>>>>  HIGHESTMODSEQ value also matches the one returned by the server,
>>>>  then the client MUST NOT fetch flags for cached messages, as they
>>>>  hasn't changed. "
>>>> 
>>>> Shouldn't this be "SHOULD NOT".
>>>>      
>>> This is an informative section, so I should probably lowercase the term.    
>> 
>> Informative or not the client does not have to perform this behavior hence it seems it should be "should".
>>  
> I see no point for the client to violate the MUST, that is why I've used upper case MUST. (please, prove me wrong with an example).
> The client can do many other stupid things and I don't want to encourage them.
> 

Well... I can't think of an example. But I can't think of a case where it would hurt, either.

I think I'd write SHOULD NOT here, because even if a client does, it's certainly not harming interoperability by doing so, it's just being dumb. Clients SHOULD NOT be badly written, certainly, but to state that IMAP clients MUST NOT be badly written would mean that many existing clients would be technically broken...

Dave.

Date: Thu, 03 Feb 2005 15:13:49 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[Let's have this discussion on IMAPEXT only].

Answering the second part of your message.

[email-masked] wrote:

>>> <> <<What if the server can?t remember some expunged UIDs, for example
>>
>>>  the provided mod-sequence is too old? Can the server just return
>>>  all UIDs not in the UID set? This can generate additional traffic,
>>>  but should be Ok otherwise.>>
>>>      
>>>
>...
>  
>
>>Client doesn't know and need not know. I think this is a 
>>server only issue.    
>>
>
>I guess I need to see what you mean by "Can the server just return
>all UIDs not in the UID set?"
>
>The client has to know that something is amiss on the server. It is 
>not getting an expunge. A fetch response is only supposed to be 
>returned subject to the CHANGEDSINCE modifier.
>
>I see two options ...
>1) An unsolicited * SEARCH 
>2) A response code that tells the client to use UID SEARCH 1:*
>
>In either case the client knows.
>
My comment is trying to say that the server MUST always return expunged 
messages, if it doesn't remember which messages got expunged since the 
specified modification sequence, it should return ALL messages expunged 
(but only for UID set the specified in the UID FETCH (REPORTEXPUNGES).

So, the client doesn't really need to know whether the server remembers 
or not. The client should be able to handle duplicate expunge 
notifications anyway.

>>> <> " ... HIGHESTMODSEQ with the one returned by the server. If the 
>>> cached
>>
>>>  HIGHESTMODSEQ value also matches the one returned by the server,
>>>  then the client MUST NOT fetch flags for cached messages, as they
>>>  hasn't changed. "
>>>
>>>Shouldn't this be "SHOULD NOT".
>>>      
>>>
>>This is an informative section, so I should probably 
>>lowercase the term.    
>>
>
>Informative or not the client does not have to perform this 
>behavior hence it seems it should be "should".
>  
>
I see no point for the client to violate the MUST, that is why I've used 
upper case MUST. (please, prove me wrong with an example).
The client can do many other stupid things and I don't want to encourage 
them.

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 3 Feb 2005 06:59:44 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext 
> Alexey Melnikov
> Sent: Wednesday, February 02, 2005 5:18 PM
...
> >Sec 3.3
> >   <<alternative #1: extend syntax for the CHANGEDSINCE FETCH
> >   modifier.
> >
> >Why even have the keyword REPORTEXPUNGES? Why not just overload
> >CHANGEDSINCE to imply expunges? 
> >  
> >
> Sending expunge information to the client who hasn't asked for it 
> doesn't sound right, even though any client should be able to ignore 
> such information.
> 
> If we choose to replace CONDSTORE, there would be no REPORTEXPUNGES.

If it does not sound right in draft-melnikov-imap-expunged-00 why
would it be okay in CONDSTORE?

> 
> >   <<What if the server can?t remember some expunged UIDs, 
> for example
> >   the provided mod-sequence is too old? Can the server just return
> >   all UIDs not in the UID set? This can generate additional traffic,
> >   but should be Ok otherwise.>>
> >
...
> Client doesn't know and need not know. I think this is a 
> server only issue.

I guess I need to see what you mean by "Can the server just return
all UIDs not in the UID set?"

The client has to know that something is amiss on the server. It is 
not getting an expunge. A fetch response is only supposed to be 
returned subject to the CHANGEDSINCE modifier.

I see two options ...
1) An unsolicited * SEARCH 
2) A response code that tells the client to use UID SEARCH 1:*

In either case the client knows.

> >
> >   " ... HIGHESTMODSEQ with the one returned by the server. 
> If the cached
> >   HIGHESTMODSEQ value also matches the one returned by the server,
> >   then the client MUST NOT fetch flags for cached messages, as they
> >   hasn't changed. "
> >
> >Shouldn't this be "SHOULD NOT".
> >
> This is an informative section, so I should probably 
> lowercase the term.

Informative or not the client does not have to perform this 
behavior hence it seems it should be "should".

Mike

Date: Wed, 02 Feb 2005 22:17:59 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[email-masked] wrote:

>Sec 3.3
>   <<alternative #1: extend syntax for the CHANGEDSINCE FETCH
>   modifier.
>
>Why even have the keyword REPORTEXPUNGES? Why not just overload
>CHANGEDSINCE to imply expunges? 
>  
>
Sending expunge information to the client who hasn't asked for it 
doesn't sound right, even though any client should be able to ignore 
such information.

If we choose to replace CONDSTORE, there would be no REPORTEXPUNGES.

>   <<What if the server can?t remember some expunged UIDs, for example
>   the provided mod-sequence is too old? Can the server just return
>   all UIDs not in the UID set? This can generate additional traffic,
>   but should be Ok otherwise.>>
>
>How does the client know when there are forgotten expunges? In this case
>the client must use the conventional approach to determining expunged 
>mail, which is okay, it just needs to know when to do it.
>  
>
Client doesn't know and need not know. I think this is a server only issue.

>Sec 3.5
>
>   <<Add CHANGEDSINCE SELECT/EXAMINE parameter?>>
>
>I assume this is an orthogonal item that was just missed in the original
>CONDSTORE?
>
Yes, you are right.

> What is it? It is kind of weird to include this in an Expunge 
>doc. Maybe this doc should be CONDSTOREPLUS. ;-)
>
>Sec 4
>
>   " ... HIGHESTMODSEQ with the one returned by the server. If the cached
>   HIGHESTMODSEQ value also matches the one returned by the server,
>   then the client MUST NOT fetch flags for cached messages, as they
>   hasn't changed. "
>
>Shouldn't this be "SHOULD NOT".
>
This is an informative section, so I should probably lowercase the term.

>Also, "hasn't" should be "haven't"
>  
>
Thank you for the comments!

Alexey

Date: Wed, 02 Feb 2005 20:28:10 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: expunged draft
Sender: [email-masked]

[email-masked] wrote:

>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]]On Behalf Of ext Timo Sirainen
>>Sent: Monday, January 31, 2005 3:52 PM
>>    
>>
>...
>  
>
>>It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What
>>about when other session did the EXPUNGE and we're seeing untagged
>>EXPUNGEs? Maybe always send it after untagged expunges (and don't
>>mention EXPUNGE command at all)?
>>    
>>
>...
>  
>
>>Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it 
>>more clear
>>that it's sending UIDs and not sequences?
>>    
>>
>
>What about something like ...
>
>* EXPUNGE (UID N MODSEQ (MMMM))
>  
>
Dave Cridland has suggested something similar during a private conversation.

>This would disambiguate nicely ...
>1) Covers unsolicited as well as untagged solicited EXPUNGE responses.
>2) The parenthetical element is just a subset of a FETCH response, meaning I
>see some nice code reuse potential.
>  
>
I am not sure the parsing code is going to be as big so it can benefit 
from code reuse.

I will change the draft to have something like:

* UIDEXPUNGE 1:5,7,505 (MODSEQ MMMM)

I.e., it will contain UID set and modification sequence at the end.

Date: Wed, 02 Feb 2005 20:23:14 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: expunged draft
Sender: [email-masked]

[email-masked] wrote:

>>> <>Servers supporting UNSELECT should most likely also send HIGHESTMODSEQ
>>
>>>just as with CLOSE, but this isn't mentioned.
>>>      
>>>
>>UNSELECT doesn't cause any message to be expunged.
>>    
>>
>>>And what about with
>>>SELECT?
>>>      
>>>
>>Same as above.
>>    
>>
>
>SELECT will generate a HIGHESTMODSEQ as per CONDSTORE
>even if the SELECT is from the selected state. No?
>  
>
Yes, it will.
SELECT from a selected state doesn't cause expunge, so nothing should be 
sent for the mailbox that is being closed.

>A CLOSE is generating a HIGHESTMODSEQ response code relative
>to the *closed* mailbox, whereas the SELECT is generating a 
>HIGHESTMODSEQ response code relative to the opened mailbox.
>This is an important, albeit subtle, distinction. Correct?
>  
>
Yes.

content-class: urn:content-classes:message
Subject: RE: ANNOTATEMORE
Date: Wed, 2 Feb 2005 14:01:30 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Lisa Dusseault [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2005 2:45 PM
...
>   2.  The ANNOTATE draft currently has at least one open issue, 
> described in the notes from the interim meeting as needing "Text to 
> describe behavior of unsolicited responses -- that you only get the 
> annotation names and not the values back (unless the client goes to 
> actually get the values)"
>    --> can you give us your opinion, does this resolve the 
> open issues 
> currently in ANNOTATE?

If I'm not mistaken this was instigated by my comments on 
ANNOTATEMORE. I'll review the next draft version.

>   3.  Let the WG know that you've reviewed ANNOTATEMORE and 
> what issues 
> were found

I did see ...

http://www.imc.org/ietf-imapext/mail-archive/msg02264.html

... And of course the exchange with Cyrus.

Thanks,
Mike

Date: Wed, 02 Feb 2005 14:51:31 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: ANNOTATEMORE
Sender: [email-masked]

Hi Lisa,

--On Wednesday, February 02, 2005 11:44 -0800 Lisa Dusseault 
<[email-masked]> wrote:

> Randy and Cyrus owe us a new draft of ANNOTATE (which is the one you
> should review) -- it was promised Monday.  Randy, Cyrus, you're now
> behind!

Its in my queue and being worked on...

-- 
Cyrus Daboo

Cc: <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: ANNOTATEMORE
Date: Wed, 2 Feb 2005 11:44:52 -0800
To: <[email-masked]>
Sender: [email-masked]

Hi Michael,

There are a couple places where your help would be very welcome in 
moving this draft forward.
  1.  This draft relies on the ANNOTATE draft. Can you review that in 
last call and notify the group that you've done a review (and what 
issues found)
  2.  The ANNOTATE draft currently has at least one open issue, 
described in the notes from the interim meeting as needing "Text to 
describe behavior of unsolicited responses -- that you only get the 
annotation names and not the values back (unless the client goes to 
actually get the values)"
   --> can you give us your opinion, does this resolve the open issues 
currently in ANNOTATE?
  3.  Let the WG know that you've reviewed ANNOTATEMORE and what issues 
were found

Randy and Cyrus owe us a new draft of ANNOTATE (which is the one you 
should review) -- it was promised Monday.  Randy, Cyrus, you're now 
behind!

Lisa

On Feb 2, 2005, at 10:44 AM, <[email-masked]> wrote:

>
> I would like to see this draft move forward.
>
> Mike
>

content-class: urn:content-classes:message
Subject: Comments on draft-melnikov-imap-expunged-00
Date: Wed, 2 Feb 2005 13:13:19 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Sec 3.3
   <<alternative #1: extend syntax for the CHANGEDSINCE FETCH
   modifier.

Why even have the keyword REPORTEXPUNGES? Why not just overload
CHANGEDSINCE to imply expunges? 

   <<What if the server can?t remember some expunged UIDs, for example
   the provided mod-sequence is too old? Can the server just return
   all UIDs not in the UID set? This can generate additional traffic,
   but should be Ok otherwise.>>

How does the client know when there are forgotten expunges? In this case
the client must use the conventional approach to determining expunged 
mail, which is okay, it just needs to know when to do it.

Sec 3.5

   <<Add CHANGEDSINCE SELECT/EXAMINE parameter?>>

I assume this is an orthogonal item that was just missed in the original
CONDSTORE? What is it? It is kind of weird to include this in an Expunge 
doc. Maybe this doc should be CONDSTOREPLUS. ;-)

Sec 4

   " ... HIGHESTMODSEQ with the one returned by the server. If the cached
   HIGHESTMODSEQ value also matches the one returned by the server,
   then the client MUST NOT fetch flags for cached messages, as they
   hasn't changed. "

Shouldn't this be "SHOULD NOT". Also, "hasn't" should be "haven't"

Mike

content-class: urn:content-classes:message
Subject: RE: expunged draft
Date: Wed, 2 Feb 2005 13:00:56 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> >Servers supporting UNSELECT should most likely also send 
> HIGHESTMODSEQ
> >just as with CLOSE, but this isn't mentioned.
> >
> UNSELECT doesn't cause any message to be expunged.
> 
> > And what about with
> >SELECT?
> >
> Same as above.

SELECT will generate a HIGHESTMODSEQ as per CONDSTORE
even if the SELECT is from the selected state. No?

A CLOSE is generating a HIGHESTMODSEQ response code relative
to the *closed* mailbox, whereas the SELECT is generating a 
HIGHESTMODSEQ response code relative to the opened mailbox.
This is an important, albeit subtle, distinction. Correct?

Mike

content-class: urn:content-classes:message
Subject: RE: expunged draft
Date: Wed, 2 Feb 2005 12:44:33 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of ext Timo Sirainen
> Sent: Monday, January 31, 2005 3:52 PM
...
> 
> It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What
> about when other session did the EXPUNGE and we're seeing untagged
> EXPUNGEs? Maybe always send it after untagged expunges (and don't
> mention EXPUNGE command at all)?
...
> Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it 
> more clear
> that it's sending UIDs and not sequences?

What about something like ...

* EXPUNGE (UID N MODSEQ (MMMM))

This would disambiguate nicely ...
1) Covers unsolicited as well as untagged solicited EXPUNGE responses.
2) The parenthetical element is just a subset of a FETCH response, meaning I
see some nice code reuse potential.

Mike

content-class: urn:content-classes:message
Subject: ANNOTATEMORE
Date: Wed, 2 Feb 2005 12:44:40 -0600
From: <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I would like to see this draft move forward.

Mike

Date: Tue, 01 Feb 2005 16:58:47 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Sender: [email-masked]

Dave Cridland wrote:

>>> Finally, I'm not sure how good 64-bit arithmetic is under some 
>>> environments - I'm actually developing under Python on a 64-bit 
>>> system, which is probably a recipe for non-portability when I forget 
>>> to use long() rather than int(), but it has the 64-bit support, at 
>>> least, and most C and C++ compilers support some 64-bit unsigned 
>>> integer, but I'm not so sure about Perl, Java, etc. I'd not object 
>>> to the MODSEQ being a string, since this is easily compared, and has 
>>> precedence in ACAP (with the "modtime" attribute).
>>
>> This is a reasonable way to implement this, this doesn't change the 
>> CONDSTORE document. If one client can't operate on 64bit integer, it 
>> can treat modification sequences as strings instead.
>
> No, because "3" is greater than "20050201163759003", treated as strings.

I didn't say that one need to use lexicographical comparison ;-).

> I'm not calling this a showstopper, by any stretch. I just don't know 
> what the state of 64-bit support *is* in all languages.

IMHO, having a pair of 32bit integers is no brainer.

> I've got it in all languages I develop in, though.
>
>>> 3) LISTEXT
>>>
>>> I've not yet implemented this, however, I was thinking of 
>>> implementing this, ACL2, and MAILBOX-REFERRALS at the same time. In 
>>> particular, I have noticed that LIST (REMOTE) could reasonably 
>>> provide the REFERRAL URIs in an extended LIST item, in order to save 
>>> clients from having to SELECT the mailbox to discover it. This 
>>> SELECT  generates an additional round-trip, of course, and I feel 
>>> overloads SELECT's meaning as well.
>>>
>>> In addition, this renders the \Remote mailbox flag redundant, of 
>>> course.
>>
>> I agree with your LISTEXT comments.
>
> Well, Rob suggested that there'd been a discussed decision the other 
> way on that,

I don't remember any consensus, but I don't remember consensus not to do 
what you've suggested either.

> and I'm happy enough to go with any considered opinion of the group, 
> so I've implemented things that way. (Actually using SELECT to 
> generate the referral, too).

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Date: Tue, 01 Feb 2005 16:49:42 +0000
Sender: [email-masked]

On Tue Feb  1 13:02:46 2005, Alexey Melnikov wrote:
> Dave Cridland wrote:
>> Given that, in the case where we simply don't know whether a right is supported or not, we want to assume it's granted, is this a reasonable assumption, or should I assume the 'x' right is *always* granted (which is effectively what existing clients do anyway)?
> 
> I think doing this either way is fine.
> 

It now assumes it's always granted, unless \NoSelect is also present, or if it appears to be a namespace prefix. Looking at server implementations, this appears reasonably safe.

> 
>> Incidentally, I've not yet thought of any other problems with a RIGHTS aware client talking to a plain ACL server, but I've not yet done ACL editing, where I suspect that the 'x' right will rear its ugly head again.
>> 
>> Nothing I've found so far appears to be a showstopper, but it might be beneficial to client authors to have some idea of handling legacy support for older servers (ie, all current ones) covered in the RFC.
> 
> Do you have any suggestions?
> 

Other than stating that the missing 'x' right on an RFC2086 server should always be considered granted, not really. I'm not intending ACL manipulation any time soon - unfortunately I just don't have the time - but as I say, I think that might shake out a few cross-compatibility issues.

In any case, given the level of ACL support in clients currently, I strongly suspect that giving any advice would be largely wasted ink.

> 
>> 2) CONDSTORE
>> 
>> This seems remarkably straightforward to implement, although again I've no real implementation to test against. I do, however, forsee some problems when dealing with ANNOTATE in addition, since I'm a little unclear on whether the sequence:
>> 
>> C1: a01 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv"))
>> S1: * 1 FETCH (MODSEQ (1) FLAGS (\Seen) ANNOTATION ("/comment" ("value.priv" "My comment")))
>> S1: a01 OK
>> C2: a02 STORE 1 +FLAGS (\Answered)
>> S2: * 1 FETCH (MODSEQ (2) FLAGS (\Seen \Answered))
>> S2: a02 OK
>> C1: a03 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv")) (CHANGEDSINCE 1)
>> S1: * FETCH ...
>> S1: a03 OK
>> 
>> ... should return the comment (which is unchanged) or just the flags (which is changed).
>> 
>> My reading of 3.3.1 suggests that the comment will be returned as well, even though it hasn't changed, because CHANGEDSINCE affects message selection, rather than metadata items returned.
> 
> The original design was to allow the server to only return changed metadata items, if the server has this information.
> 

Ah... 3.3.1 seems to disagree with you.

> 
> I am not sure if this has to be clarified in the document (probably yes) and if this behavior breaks clients that always expect all metadata to be returned. IMHO, client should cache all data sent to it, so this shouldn't be a problem.
> 

In the original design of IMAP, a server wasn't even mandated to resend information within the same SELECT session, as I understand things. Hence I've always assumed that a client should never discard data within a single SELECT session, even though these days the server has to do what it's told.

But yes, I would assume that clients would, if they didn't have the annotation, fetch it unconditionally seperately.

> 
> On a second thought: if you omit the first FETCH (with tag a01), the client will not have this information cached and will be forced to fetch it unconditionally, if it doesn't get it in the 3rd FETCH.
> 

If you discard a01, then the client would also emit an a04, hopefully pipelined, which would be an unconditional fetch of the annotation.

>> My second issue is that an extended EXPUNGE would be useful, allowing me to "EXPUNGE (UNCHANGEDSINCE 1)" to permanently remove all messages flagged as \Deleted which haven't been altered [presumably] without my knowledge.
> 
> So if somebody has added \Seen flag to a \Deleted message (or add an annotation), that would prevent the message from being expunged?
> 

The \Seen case is a little draconian I'll admit, but the annotation case isn't - if someone has seen fit to annotate a \Deleted message, one assumes it's important enough not to expunge without knowing what the annotation was.

>> Finally, I'm not sure how good 64-bit arithmetic is under some environments - I'm actually developing under Python on a 64-bit system, which is probably a recipe for non-portability when I forget to use long() rather than int(), but it has the 64-bit support, at least, and most C and C++ compilers support some 64-bit unsigned integer, but I'm not so sure about Perl, Java, etc. I'd not object to the MODSEQ being a string, since this is easily compared, and has precedence in ACAP (with the "modtime" attribute).
> 
> This is a reasonable way to implement this, this doesn't change the CONDSTORE document. If one client can't operate on 64bit integer, it can treat modification sequences as strings instead.
> 

No, because "3" is greater than "20050201163759003", treated as strings. I'm not calling this a showstopper, by any stretch. I just don't know what the state of 64-bit support *is* in all languages. I've got it in all languages I develop in, though.

> 
>> 3) LISTEXT
>> 
>> I've not yet implemented this, however, I was thinking of implementing this, ACL2, and MAILBOX-REFERRALS at the same time. In particular, I have noticed that LIST (REMOTE) could reasonably provide the REFERRAL URIs in an extended LIST item, in order to save clients from having to SELECT the mailbox to discover it. This SELECT  generates an additional round-trip, of course, and I feel overloads SELECT's meaning as well.
>> 
>> In addition, this renders the \Remote mailbox flag redundant, of course.
> 
> I agree with your LISTEXT comments.
> 

Well, Rob suggested that there'd been a discussed decision the other way on that, and I'm happy enough to go with any considered opinion of the group, so I've implemented things that way. (Actually using SELECT to generate the referral, too).

Dave.

Date: Tue, 01 Feb 2005 13:02:46 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Sender: [email-masked]

Dave Cridland wrote:

> Hiya folks,
>
> I've been on a client-side implementation frenzy, and thought I'd 
> share my experiences. I've no access to any server implementation of 
> any of these - an account on such a server would be greatly 
> appreciated. In particular, I'd like CONDSTORE, ANNOTATE, and LISTEXT 
> - the RIGHTS stuff, while interesting, is more interesting in as much 
> as how to cope without it.
>
> My strategy, incidentally, is to emulate unsupported extensions 
> wherever possible.
>
> The client is written in Python, using the wxPython GUI toolkit, and 
> should run on Windows, UNIX, and Mac OS X. It does require an account 
> on a reasonably full ACAP server implementation, but this does give it 
> full roaming and kiosk-mode ability. I'm quite happy to provide the 
> source under GPL, and/or an ACAP account.
>
> 1) RIGHTS
>
> I've been gradually implementing ACL support, and I've attempted to do 
> so by emulating the 'kxet' rights where not supported. (This means 
> anywhere, since I don't have access to a server implementation 
> supporting RIGHTS). I'm making the rash assumption that this is a sane 
> way of writing a RFC2086upd client. (I've not yet made it emulate 
> rights based on the READ-ONLY/READ-WRITE response code where no ACL 
> support at all is available, but I will.)
>
> I've found that trying to emulate the 'x' right is particularly 
> tricky, since I can only assume:
>
> 'd' => 'et'
> 'c' => 'k'
>
> So I'm currently assuming the 'x' right is always granted where 'c' or 
> 'd' is granted. (Obviously the client copes with the case where the 
> DELETE fails anyway.)
>
> Given that, in the case where we simply don't know whether a right is 
> supported or not, we want to assume it's granted, is this a reasonable 
> assumption, or should I assume the 'x' right is *always* granted 
> (which is effectively what existing clients do anyway)?

I think doing this either way is fine.

> Incidentally, I've not yet thought of any other problems with a RIGHTS 
> aware client talking to a plain ACL server, but I've not yet done ACL 
> editing, where I suspect that the 'x' right will rear its ugly head 
> again.
>
> Nothing I've found so far appears to be a showstopper, but it might be 
> beneficial to client authors to have some idea of handling legacy 
> support for older servers (ie, all current ones) covered in the RFC.

Do you have any suggestions?

> 2) CONDSTORE
>
> This seems remarkably straightforward to implement, although again 
> I've no real implementation to test against. I do, however, forsee 
> some problems when dealing with ANNOTATE in addition, since I'm a 
> little unclear on whether the sequence:
>
> C1: a01 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv"))
> S1: * 1 FETCH (MODSEQ (1) FLAGS (\Seen) ANNOTATION ("/comment" 
> ("value.priv" "My comment")))
> S1: a01 OK
> C2: a02 STORE 1 +FLAGS (\Answered)
> S2: * 1 FETCH (MODSEQ (2) FLAGS (\Seen \Answered))
> S2: a02 OK
> C1: a03 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv")) 
> (CHANGEDSINCE 1)
> S1: * FETCH ...
> S1: a03 OK
>
> ... should return the comment (which is unchanged) or just the flags 
> (which is changed).
>
> My reading of 3.3.1 suggests that the comment will be returned as 
> well, even though it hasn't changed, because CHANGEDSINCE affects 
> message selection, rather than metadata items returned.

The original design was to allow the server to only return changed 
metadata items, if the server has this information.

I am not sure if this has to be clarified in the document (probably yes) 
and if this behavior breaks clients that always expect all metadata to 
be returned. IMHO, client should cache all data sent to it, so this 
shouldn't be a problem.

On a second thought: if you omit the first FETCH (with tag a01), the 
client will not have this information cached and will be forced to fetch 
it unconditionally, if it doesn't get it in the 3rd FETCH.

> Changing this, such that CHANGEDSINCE simply suppressed items that 
> haven't changed (excepting UID) would make more sense to me. I can of 
> course do this by issuing multiple pipelined fetches, one for every 
> item, in effect, which I have to do for items I don't have cached at 
> all. (Currently, in fact, I re-fetch the FLAGS unconditionally if I'm 
> fetching anything else, since the additional cost of the data returned 
> is less than the cost of asking for it seperately, but this changes 
> with ANNOTATE).
>
> My second issue is that an extended EXPUNGE would be useful, allowing 
> me to "EXPUNGE (UNCHANGEDSINCE 1)" to permanently remove all messages 
> flagged as \Deleted which haven't been altered [presumably] without my 
> knowledge.

So if somebody has added \Seen flag to a \Deleted message (or add an 
annotation), that would prevent the message from being expunged?

> Similarly, an extended UID EXPUNGE would be useful, too. Given that 
> EXPUNGing the wrong messages is irreparable damage, that seems a 
> sensible addition if it can be implemented, which I assume it can be 
> with the same effort as FETCH (CHANGEDSINCE ...).
>
> Finally, I'm not sure how good 64-bit arithmetic is under some 
> environments - I'm actually developing under Python on a 64-bit 
> system, which is probably a recipe for non-portability when I forget 
> to use long() rather than int(), but it has the 64-bit support, at 
> least, and most C and C++ compilers support some 64-bit unsigned 
> integer, but I'm not so sure about Perl, Java, etc. I'd not object to 
> the MODSEQ being a string, since this is easily compared, and has 
> precedence in ACAP (with the "modtime" attribute).

This is a reasonable way to implement this, this doesn't change the 
CONDSTORE document. If one client can't operate on 64bit integer, it can 
treat modification sequences as strings instead.

> 3) LISTEXT
>
> I've not yet implemented this, however, I was thinking of implementing 
> this, ACL2, and MAILBOX-REFERRALS at the same time. In particular, I 
> have noticed that LIST (REMOTE) could reasonably provide the REFERRAL 
> URIs in an extended LIST item, in order to save clients from having to 
> SELECT the mailbox to discover it. This SELECT  generates an 
> additional round-trip, of course, and I feel overloads SELECT's 
> meaning as well.
>
> In addition, this renders the \Remote mailbox flag redundant, of course.

I agree with your LISTEXT comments.

Alexey

Date: Tue, 01 Feb 2005 11:27:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: expunged draft
Sender: [email-masked]

Timo Sirainen wrote:

>On Mon, 2005-01-31 at 18:44 +0000, Alexey Melnikov wrote:
>  
>
>>I've just submitted a new draft that describes how CONDSTORE 
>>modification sequences can be used to track expunged messages. Before it 
>>is announced, people can find it at:
>>http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt
>>
>>I will welcome all suggestions, especially on issues marked with <<>> in 
>>the document.
>>    
>>
>
>It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What
>about when other session did the EXPUNGE and we're seeing untagged
>EXPUNGEs? Maybe always send it after untagged expunges (and don't
>mention EXPUNGE command at all)?
>  
>
Yes, that was the idea.

>Servers supporting UNSELECT should most likely also send HIGHESTMODSEQ
>just as with CLOSE, but this isn't mentioned.
>
UNSELECT doesn't cause any message to be expunged.

> And what about with
>SELECT?
>
Same as above.

> Maybe just point out more generally that "when using a command
>which closes the mailbox, send HIGHESTMODSEQ". Perhaps LOGOUT should do
>that too?
>  
>
Remember, that the CONDSTORE extension requires the server to send 
mod-sequences for flag changes (using MODSEQ FETCH data items) and 
whenever a message is appended. The EXPUNGED document extends this to 
cover expunges. So there is no point to send HIGHESTMODSEQ when nothing 
has changed, this should cover LOGOUT, SELECT and UNSELECT.
Of course, if messages got expunged in another session, the server still 
needs to send HIGHESTMODSEQ.

>   <<What if the server can¢t remember some expunged UIDs, for example
>   the provided mod-sequence is too old? Can the server just return
>   all UIDs not in the UID set? This can generate additional traffic,
>   but should be Ok otherwise.>>
>
>Yes, I think so.
>
>In 3.4 EXPUNGED Response it seems rather useless trying to rewrite what
>RFC3501 says about EXPUNGEs. Just point out that it works exactly as
>normal untagged EXPUNGE? It would be really bad if they accidentally got
>different rules.
>  
>
As EXPUNGED returns a list of UIDs, I was wondering if it should obey 
the same rule as EXPUNGE, i.e. whether it should be allowed during 
regular FETCH/STORE.

>Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it more clear
>that it's sending UIDs and not sequences?
>  
>
Sure.

Date: Tue, 01 Feb 2005 11:18:02 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

Lisa Dusseault wrote:

> So, does this mean that we don't need to yank CondStore out of the RFC 
> queue?

The answer to your question depends on what people think about the 
document. There are several places marked with <<>> that can be made 
cleaner (e.g. REPORTEXPUNGES) if there is a single extension.
So, I would encourage people to do a review and we can discuss in a few 
weeks.

> thanks,
> Lisa
>
> On Jan 31, 2005, at 10:44 AM, Alexey Melnikov wrote:
>
>> Lisa Dusseault wrote:
>>
>>> Alexey needs to propose what changes to make to CondStore, as a 
>>> concrete written proposal to the list.
>>
>> I've just submitted a new draft that describes how CONDSTORE 
>> modification sequences can be used to track expunged messages. Before 
>> it is announced, people can find it at:
>> http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt
>>
>> I will welcome all suggestions, especially on issues marked with <<>> 
>> in the document.
>>
>> I can rework RECONNECT to reference the new document, if people feel 
>> it is a good idea.
>>
>> Alexey
>

Date: Sun, 27 Feb 2005 19:59:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Cyrus Daboo writes:
>
>> OK, so are you suggesting that the tag for the SEARCH command is used 
>> as the 'ID' I was proposing, e.g.:
>>
>> a1234 SEARCH RETURN (TAG ALL) UNSEEN
>> * ESEARCH TAG a1234 ALL 1:100
>> a1234 OK
>
> I'm suggesting that IF you want to tag ESEARCH responses (whether you 
> call them "tagged searches" or "searches with ID" is no matter to me), 
> then the most honest response format is
>
> a1234 ESEARCH ALL 1:100
>
> There are alternatives, such as sneaking the tag in the back door:
>
> * ESEARCH TAG a1234 ALL 1:100

I've just updated the draft and it will look like:

* ESEARCH (TAG "a1234") ALL 1:100

tag is sent as a string, because "]" is allowed in a tag.

> Or such as using an Elvis lookalike instead of the real thing:
>
> * ESEARCH ID a1234 ALL 1:100
>
> Whether ESEARCH is tagged or not is no matter to me. I'm happy either 
> way.
>
> But if it is tagged, I'd like to see IMAP stay with just one tag 
> mechanism (unless there are pressing reasons for having multiple 
> similar mechanisms, of course).

I agree, of course.

Date: Mon, 14 Feb 2005 18:55:40 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Mark Crispin wrote:

> I've reviewed this document and while I have document nits the 
> protocol proposed looks OK to me.
>
> Is there much feeling as to how useful it would be?  I'm not talking 
> about Dave and Alexey since I'm sure they are already convinced.  It's 
> more of a question of whether the benefit is worth the added 
> complexity (don't forget, it does represent an additional task for 
> server implementors!).

Speaking as a server implementor: I only had to modify new syntax 
parsing and the loop the calls "evaluate this message against search 
criteria" for each message, so that the server can output ESEARCH data. 
The search matching code hasn't been touched. It took me about 3 hours 
to implement the whole extension.

I think Dave has some number about how much bandwidth is saved using 
SEARCH RETURN (ALL).

Alexey

Date: Fri, 25 Feb 2005 14:13:48 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Nit-checking 2086upd
Sender: [email-masked]

Dave Cridland wrote:

>
> On Thu Feb 24 21:03:27 2005, Lisa Dusseault wrote:
>
>> "If rights are tied in an implementation, the conservative approach 
>> would be to grant few of them in response to SETACL commands.  Thus, 
>> unless all rights in a tied set are specified, a server MUST NOT 
>> include any of that set in the ACL entry for that identifier.  A 
>> client can discover the set of rights granted to a given identifier 
>> in the ACL for a given mailbox name by using the LISTRIGHTS command."
>>
>> Note that I also removed "which may be" -- I think it changes the 
>> sense of the sentence from "finding out what's possible to grant", to 
>> "finding out what is granted", which I believe to be correct.  If I'm 
>> wrong then a different change should be made.
>
>
> That's incorrect - LISTRIGHTS lists sets of tied rights possible to 
> grant to the identifier [of which some or all sets may have only one 
> member], and a set of rights which is always granted, not what's 
> actually granted at the time. There is no MYRIGHTS equivalent for 
> other users, which is I think what you're thinking.

And the lack of such command might be addressed in ACL2, but 2086upd is 
not the proper place to do this change.

> What about:
>
> "If rights are tied in an implementation, the implementation MUST be 
> conservative in granting rights in response to SETACL commands--unless 
> all rights in a tied set are specified, an implementation MUST NOT 
> include any of that set in the ACL entry for the given identifier. A 
> client SHOULD discover the set of rights which may be granted to a 
> given identifier in the ACL for a given mailbox name by using the 
> LISTRIGHTS command."
>
> It's a less drastic rephrase. I'm not sure about the first MUST,

I am not sure either, the original text sounds like "SHOULD" (and the 
following "MUST NOT" should be changed to "SHOULD NOT" as well).
Comments?

> and note I've added a SHOULD for clients to use LISTRIGHTS. Many 
> implementations don't, currently.

That is fine with me.

Alexey

From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Nit-checking 2086upd
Date: Fri, 25 Feb 2005 10:08:08 +0000
Sender: [email-masked]

On Thu Feb 24 21:03:27 2005, Lisa Dusseault wrote:
> "If rights are tied in an implementation, the conservative approach would be to grant few of them in response to SETACL commands.  Thus, unless all rights in a tied set are specified, a server MUST NOT include any of that set in the ACL entry for that identifier.  A client can discover the set of rights granted to a given identifier in the ACL for a given mailbox name by using the LISTRIGHTS command."
> 
> Note that I also removed "which may be" -- I think it changes the sense of the sentence from "finding out what's possible to grant", to "finding out what is granted", which I believe to be correct.  If I'm wrong then a different change should be made.

That's incorrect - LISTRIGHTS lists sets of tied rights possible to grant to the identifier [of which some or all sets may have only one member], and a set of rights which is always granted, not what's actually granted at the time. There is no MYRIGHTS equivalent for other users, which is I think what you're thinking.

What about:

"If rights are tied in an implementation, the implementation MUST be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, an implementation MUST NOT include any of that set in the ACL entry for the given identifier. A client SHOULD discover the set of rights which may be granted to a given identifier in the ACL for a given mailbox name by using the LISTRIGHTS command."

It's a less drastic rephrase. I'm not sure about the first MUST, and note I've added a SHOULD for clients to use LISTRIGHTS. Many implementations don't, currently.

Dave.

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Nit-checking 2086upd
Date: Thu, 24 Feb 2005 13:03:27 -0800
Sender: [email-masked]

--Apple-Mail-4--24694467
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

In nit-checking 2086upd, I noticed some text where the use of must/MUST 
and may/MAY could be clarified.

  "If rights are tied in an
    implementation, the implementation must be conservative in granting
    rights in response to SETACL commands--unless all rights in a tied
    set are specified, none of that set should be included in the ACL
    entry for that identifier. A client may discover the set of rights
    which may be granted to a given identifier in the ACL for a given
    mailbox name by using the LISTRIGHTS command."

This seems like it might be partly normative but part is definitely 
descriptive. Can we write this to be clearer about what the server MUST 
do?  How about:

"If rights are tied in an implementation, the conservative approach 
would be to grant few of them in response to SETACL commands.  Thus, 
unless all rights in a tied set are specified, a server MUST NOT 
include any of that set in the ACL entry for that identifier.  A client 
can discover the set of rights granted to a given identifier in the ACL 
for a given mailbox name by using the LISTRIGHTS command."

Note that I also removed "which may be" -- I think it changes the sense 
of the sentence from "finding out what's possible to grant", to 
"finding out what is granted", which I believe to be correct.  If I'm 
wrong then a different change should be made.

Lisa
--Apple-Mail-4--24694467
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

In nit-checking 2086upd, I noticed some text where the use of
must/MUST and may/MAY could be clarified.

<color><param>0000,0000,DDDD</param> "If rights are tied in an

   implementation, the implementation must be conservative in granting

   rights in response to SETACL commands--unless all rights in a tied

   set are specified, none of that set should be included in the ACL

   entry for that identifier. A client may discover the set of rights

   which may be granted to a given identifier in the ACL for a given

   mailbox name by using the LISTRIGHTS command."

This seems like it might be partly normative but part is definitely
descriptive. Can we write this to be clearer about what the server
MUST do?  How about:

"If rights are tied in an implementation, the conservative approach
would be to grant few of them in response to SETACL commands.  Thus,
unless all rights in a tied set are specified, a server MUST NOT
include any of that set in the ACL entry for that identifier.  A
client can discover the set of rights granted
</color><color><param>0000,0000,DDDC</param>to a given identifier in
the ACL for a given mailbox name by using the LISTRIGHTS command."

Note that I also removed "which may be" -- I think it changes the
sense of the sentence from "finding out what's possible to grant", to
"finding out what is granted", which I believe to be correct.  If I'm
wrong then a different change should be made.

Lisa</color>
--Apple-Mail-4--24694467--

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: WG last call for ANNOTATE Feb 4-18
Date: Tue, 22 Feb 2005 11:24:23 -0800
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

BTW, this last call period has now completed... the next step is for 
the authors to give us some idea of what issues still need to be 
discussed, what changes are made to the draft as a result of the last 
call reviews, etc.

Lisa

On Feb 4, 2005, at 1:32 PM, Lisa Dusseault wrote:

>
> This is a notification of the beginning of last-call for the -12 draft 
> of ANNOTATE:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-12.txt
>
> If you review this draft, let the WG know even if you have no issues 
> or comments.  Also, we'd like to know who plans to implement this or 
> may have already begun (you can let me know privately or mail the WG). 
>  Last call will go until and including February 18 2005.
>
> Lisa Dusseault
>

Cc: [email-masked], Dave Cridland <[email-masked]>
From: Grant Baillie <[email-masked]>
Subject: Re: ANNOTATE comments
Date: Fri, 18 Feb 2005 18:18:20 -0800
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Hello, Cyrus

On Feb 18, 2005, at 9:21 AM, Cyrus Daboo wrote:

>
> Hi Grant,
>
> --On February 18, 2005 8:48:35 AM -0800 Grant Baillie 
> <[email-masked]> wrote:
>
>>> You could argue that it's easy to detect the ascii and utf-8 cases,
>>> and therefore these could be recorded - but in practise, since these
>>> are easy to detect, it's better to let clients detect them.
>>
>> The use case I had in mind is when users have to pick a charset 
>> manually,
>> in which case it would be nice to propagate across clients. But I 
>> agree
>> that incorrect setting of the charset, especially automatically, is a
>> concern.
>>
>
> I would like to keep the entries defined in the base document to a 
> minimum if possible.

Eminently reasonable and understandable.

> There is of course nothing to stop you from writing this up as a 
> separate draft and registering an entry for it yourself. If you do 
> that, then I would also suggest having a way to override the 
> content-type too. Often messages get sent with the wrong content-type 
> (e.g. text/plain for an HTML message, application/octet-stream for 
> Word document etc). In those cases it would also be nice to have the 
> first client to spot the problem set an annotation to provide a hint 
> to others. If you do that you can actually combine this with charset, 
> since charset is a parameter on the Content-Type header. So my 
> suggestion would be an 'altcontenttype' entry whose value was a 
> properly formed MIME Content-Type header field that could override 
> content type, name, charset etc.

Indeed. (Next, altcontentdisposition for fixing bogus 
Content-Disposition headers, too :-).

At the moment, I'm not working on an IMAP client, so I'm not inclined 
to write up a draft that I wouldn't actually be implementing in the 
near future. But I might be inclined to pursue this sometime down the 
road. Thanks for your observations/comments.

--Grant

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-03.txt
Date: Fri, 18 Feb 2005 15:23:51 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-2086upd-03.txt
	Pages		: 0
	Date		: 2005-2-18
	
The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP4rev1) permits mailbox access control
   lists to be manipulated through the IMAP protocol.

   This document is a revision of the RFC 2086. It defines several new
   access control rights and clarifies which rights are required for
   different IMAP commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-2086upd-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-2086upd-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-2086upd-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-2086upd-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 18 Feb 2005 17:53:57 +0000
From: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: List of WGLC changes to 2086upd-02
Sender: [email-masked]

I've just submitted -03 of 2086upd.

In addition to changed mentioned earlier (see 
http://www.imc.org/ietf-imapext/mail-archive/msg02389.html), I've 
updated section talking about virtual "c" and "d" rights, as per private 
discussion with Dave and Ken. The new text is as follows:

3.1.1.   Obsolete rights

   Due to ambiguity in RFC 2086 some existing RFC 2086 server 
implementations
   use the "c" right to control the DELETE command. Others chose to use the
   "d" right to control the DELETE command.
   For the former group, let's define the "create" right as union of the "k"
   and "x" rights, and the "delete" right as union of the "e" and "t" 
rights.
   For the latter group, let's define the "create" rights as a synonym 
to the
   "k" right, and the "delete" right as union of the "e", "t" and "x" 
rights.

   For compatibility with RFC 2086 this section defines two virtual rights
   "d" and "c".

   If a client includes the "d" right in a rights list, then it MUST be
   treated as if the client had included every member of the "delete" right.
   (It is not an error for a client to specify both the "d" right and
   one or more members of the "delete" right, but the effect is no different
   than if just the "d" right or all members of the "delete" right had been
   specified).

   When any of the "delete" member rights is set in a list of
   rights, the server MUST also include the "d" right when returning
   the list in a MYRIGHTS or ACL response. This is so to enable older 
clients
   conforming to RFC 2086 to work with newer servers. (*)

   Example:    C: A001 SETACL INBOX.Drafts David lrswida
               S: A001 OK Setacl complete

    The client has specified the "d" right in the SETACL command above 
and it
    expands to "et" on the server:

               C: A002 GETACL INBOX.Drafts
               S: * ACL INBOX Fred rwipslxetda David lrswideta
               S: A002 OK Getacl complete

   If the authentication identifier specified in the LISTRIGHTS command 
can be
   granted any of the "delete" member rights to access a mailbox, then 
the server
   MUST include the "d" right in the corresponding LISTRIGHTS response. (*)
   If the member rights aren't tied to non-member rights, then the "d" right
   is returned by itself in the LISTRIGHTS response.  If any of the 
member rights
   needs to be tied to one (or more) non-member right, then the "d" 
right and all
   of the member rights need to be tied to the same non-member right(s) 
(**).

   If a client includes the "c" right in a rights list, then it MUST be
   treated as if the client had included every member of the "create" right.
   (It is not an error for a client to specify both the "c" right and
   one or more members of the "create" right, but the effect is no different
   than if just the "c" right or all members of the "create" right had been
   specified).

   When any of the "create" member rights is set in a list of
   rights, the server MUST also include the "c" right when returning
   the list in a MYRIGHTS or ACL response. This is so to enable older 
clients
   conforming to RFC 2086 to work with newer servers. (*)

   Example:    C: A003 SETACL INBOX.Drafts Byron lrswikda
               S: A001 OK Setacl complete
               C: A002 GETACL INBOX.Drafts
               S: * ACL INBOX Fred rwipslxeta Byron lrswikcdeta
               S: A002 OK Getacl complete

    The client has specified the "d" right in the SETACL command above 
and it
    expands to "et" on the server:  As the client has specified the "k" 
right
    (which is a member of the "c" right), the server also returns the 
"c" right.

   If the authentication identifier specified in the LISTRIGHTS command 
can be
   granted any of the "create" member rights to access a mailbox, then 
the server
   MUST include the "c" right in the corresponding LISTRIGHTS response. (*)
   If the member rights aren't tied to non-member rights, then the "c" right
   is returned by itself in the LISTRIGHTS response.  If any of the 
member rights
   needs to be tied to one (or more) non-member right, then the "c" 
right and all
   of the member rights need to be tied to the same non-member right(s) 
(**).

   Example: The server that ties the rights as follows

               lr s w i p k x t

            and c=k

            will return:

               S: * LISTRIGHTS archive.imap anyone "" lr s w i p k x t c d

   Example: The server that ties the rights as follows

               lr s w i p k xte

            and c=k

            will return:

               S: * LISTRIGHTS archive.imap anyone "" lr s w i p k xte c d

   Example: The server that ties the rights as follows

               lr s w i p k x te

            and c=k

            will return:

               S: * LISTRIGHTS archive.imap anyone "" lr s w i p k c x te d

   Example: The server that ties the rights as follows

               lr swte i p k x

            and c=kx

            will return:

               S: * LISTRIGHTS archive.imap anyone "" lr swted i p k x c

   (*) Clients conforming to this document MUST ignore the virtual "d" 
and "c"
   rights in MYRIGHTS, ACL and LISTRIGHTS responses.

   (**) The IMAPEXT Working Group has debated this issue in great length
   and after reviewing existing ACL implementations concluded that this is
   a reasonable restriction.

Date: Fri, 18 Feb 2005 12:21:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Grant Baillie <[email-masked]>, Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATE comments
Sender: [email-masked]

Hi Grant,

--On February 18, 2005 8:48:35 AM -0800 Grant Baillie 
<[email-masked]> wrote:

>> You could argue that it's easy to detect the ascii and utf-8 cases,
>> and therefore these could be recorded - but in practise, since these
>> are easy to detect, it's better to let clients detect them.
>
> The use case I had in mind is when users have to pick a charset manually,
> in which case it would be nice to propagate across clients. But I agree
> that incorrect setting of the charset, especially automatically, is a
> concern.
>

I would like to keep the entries defined in the base document to a minimum 
if possible.

There is of course nothing to stop you from writing this up as a separate 
draft and registering an entry for it yourself. If you do that, then I 
would also suggest having a way to override the content-type too. Often 
messages get sent with the wrong content-type (e.g. text/plain for an HTML 
message, application/octet-stream for Word document etc). In those cases it 
would also be nice to have the first client to spot the problem set an 
annotation to provide a hint to others. If you do that you can actually 
combine this with charset, since charset is a parameter on the Content-Type 
header. So my suggestion would be an 'altcontenttype' entry whose value was 
a properly formed MIME Content-Type header field that could override 
content type, name, charset etc.

-- 
Cyrus Daboo

Cc: <[email-masked]>
From: Grant Baillie <[email-masked]>
Subject: Re: ANNOTATE comments
Date: Fri, 18 Feb 2005 08:48:35 -0800
To: Dave Cridland <[email-masked]>
Sender: [email-masked]

On Feb 18, 2005, at 6:18 AM, Dave Cridland wrote:

> On Thu Feb 17 21:22:07 2005, Grant Baillie wrote:
>> - A potential use of ANNOTATE would be to allow users/clients to 
>> re-label the charset of a message part. (Sadly, there are still many 
>> clients out there that produce text parts with missing or incorrect 
>> charset parameters). Is it worth defining, say, 
>> /<section-part>/altcharset and /altcharset for this?
>
> I agree that there are some dumb clients out there, and I also agree 
> that it's possible for a user or a client to detirmine the correct 
> character set in some cases.
>
> However, not all cases, and some existant examples of heuristically 
> discovering character sets fail horribly - I think this is one of 
> those things that a client has to deal with, rather than rely on 
> potentially another client getting right.
>
> To give some idea, I live in an area where at least five character 
> sets are in common usage - ascii, latin1,14, and 15, and utf-8 - and 
> two langauges. These are all quite difficult to detect heuristically, 
> with the exception of ascii and utf-8. I can live with the client I'm 
> using getting it wrong, but not if it then influenced other clients I 
> used.
>
> You could argue that it's easy to detect the ascii and utf-8 cases, 
> and therefore these could be recorded - but in practise, since these 
> are easy to detect, it's better to let clients detect them.

The use case I had in mind is when users have to pick a charset 
manually, in which case it would be nice to propagate across clients. 
But I agree that incorrect setting of the charset, especially 
automatically, is a concern.

--Grant

From: Dave Cridland <[email-masked]>
To: Grant Baillie <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ANNOTATE comments
Date: Fri, 18 Feb 2005 14:18:22 +0000
Sender: [email-masked]

On Thu Feb 17 21:22:07 2005, Grant Baillie wrote:
> - A potential use of ANNOTATE would be to allow users/clients to re-label the charset of a message part. (Sadly, there are still many clients out there that produce text parts with missing or incorrect charset parameters). Is it worth defining, say, /<section-part>/altcharset and /altcharset for this?

I agree that there are some dumb clients out there, and I also agree that it's possible for a user or a client to detirmine the correct character set in some cases.

However, not all cases, and some existant examples of heuristically discovering character sets fail horribly - I think this is one of those things that a client has to deal with, rather than rely on potentially another client getting right.

To give some idea, I live in an area where at least five character sets are in common usage - ascii, latin1,14, and 15, and utf-8 - and two langauges. These are all quite difficult to detect heuristically, with the exception of ascii and utf-8. I can live with the client I'm using getting it wrong, but not if it then influenced other clients I used.

You could argue that it's easy to detect the ascii and utf-8 cases, and therefore these could be recorded - but in practise, since these are easy to detect, it's better to let clients detect them.

Dave.

To: [email-masked]
From: Grant Baillie <[email-masked]>
Subject: ANNOTATE comments
Date: Thu, 17 Feb 2005 13:22:07 -0800
Sender: [email-masked]

Here are some comments I have on annotate-12 (apologies for the 
closeness to last call):

- From a readability point of view, I think it would be nice to have a 
somewhat less terse Abstract.  At least, I think it should mention that 
you can associate metadata with MIME parts (not just entire messages).

- A potential use of ANNOTATE would be to allow users/clients to 
re-label the charset of a message part. (Sadly, there are still many 
clients out there that produce text parts with missing or incorrect 
charset parameters). Is it worth defining, say, 
/<section-part>/altcharset and /altcharset for this?

- Section 2.2.1, /flags entry name: Is there difference between "0" and 
NIL for a flag's value? If so, that should be spelled out.

- In the examples, it would be good to use literals as well as 
quoted-strings in a couple of cases. This might help to remind 
implementers not to assume they should only accept quoted-strings.

- The resp-text-code grammar rule should use nil, not "NIL".

- The use of double-quotes is often contradictory or confusing. Eg. in 
the following:

      The server SHOULD indicate the maximum size for an annotation value
      by sending an untagged "ANNOTATESIZE" response during a SELECT or
      EXAMINE command

   why "ANNOTATESIZE" and not "SELECT"? In general, the IMAP spec itself 
is pretty consistent
   about referring to response codes, etc, without double quotes, and it 
would be nice to

--Grant

Date: Thu, 17 Feb 2005 16:03:44 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Informal list last call for ANNOTATEMORE
Sender: [email-masked]

Cyrus Daboo wrote:

> 
> Hi folks,
> I would like to submit the ANNOTATEMORE document to the IESG at the same 
> time as the ANNOTE document (once that has gone through WGLC and all 
> seems OK). However, since ANNOTATEMORE is an individual submission it is 
> not subject to a WGLC, but I would appreciate it if people looking at 
> ANNOTATE would also look at ANNOTATEMORE in the same vein and pass 
> comments back, thanks.
> 
> <http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-07.txt>

This looks good to me, and seems to jive with what we've already 
implemented in Cyrus.

I did find one in the examples in section 3.3.  The third example shows 
setting a single entry on multiple mailboxes, but the text immediately 
above states that multiple entries can be set in a single SETANNOTATION. 
  I think we need to add an example of setting multiple entries in one 
command.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 16 Feb 2005 12:27:08 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: New draft: SEARCH return options
Cc: IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Sender: [email-masked]

At 12:04 PM 2/16/2005, Alexey Melnikov wrote:
>Pete Maclean wrote:
>
>>I am wondering why you are not tempted to generalize the options a bit 
>>more.  I am thinking along the lines of:
>>
>>     DIRECTION UP or DOWN (meaning search up/down with respect to message 
>> numbers/UIDs)
>
>Isn't this part of the SORT extension?

Ah well, it may be so.  I must acknowledge that I have not acquainted 
myself with that extension.  But perhaps if a server chooses to implement 
the ESEARCH extension and not the SORT extension then it is relevant.

>  IMHO, the search order is an internal server business. Some servers can 
> optimize if the client specified something like "RETURN (MIN)".

I totally agree that the search order should be an internal server business 
by default.  However, for the type of situation I described, it does seem 
valuable for the client to be able override that.  Incidentally, I do not 
mean that to imply that the results should necessarily be returned in the 
specified order.  Furthermore, by "order", I guess I mean "effective order" 
such that the results returned would be the first N matches in the 
specified ordering.  Whether or not the server internally actually searches 
messages in that order is irrelevant.

>>     MATCHES n (meaning return a maximum of n matches)
>
>Yes, we've just discussed this with Dave :-).

Good show!

Pete 

Date: Wed, 16 Feb 2005 17:04:59 +0000
From: Alexey Melnikov <[email-masked]>
To: Pete Maclean <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Pete Maclean wrote:

> I am wondering why you are not tempted to generalize the options a bit 
> more.  I am thinking along the lines of:
>
>     DIRECTION UP or DOWN (meaning search up/down with respect to 
> message numbers/UIDs)

Isn't this part of the SORT extension? IMHO, the search order is an 
internal server business. Some servers can optimize if the client 
specified something like "RETURN (MIN)".

>     MATCHES n (meaning return a maximum of n matches)

Yes, we've just discussed this with Dave :-).

> This would allow a client that wanted to find at most a fixed number 
> of matches to fill a window, form or Web page to do so more 
> efficiently.  For example,
>
>     <tag> SEARCH RETURN (DIRECTION DOWN MATCHES 20) <criteria>
>
> These could even be combined by having MATCHES +n and MATCHES -n.
>
> Then MIN would be replaced by (DIRECTION UP MATCHES 1) and so on.

Date: Wed, 16 Feb 2005 11:10:53 -0500
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: New draft: SEARCH return options
Cc: Lemonade WG <[email-masked]>
Sender: [email-masked]

I am wondering why you are not tempted to generalize the options a bit 
more.  I am thinking along the lines of:

	DIRECTION UP or DOWN (meaning search up/down with respect to message 
numbers/UIDs)

	MATCHES n (meaning return a maximum of n matches)

This would allow a client that wanted to find at most a fixed number of 
matches to fill a window, form or Web page to do so more efficiently.  For 
example,

	<tag> SEARCH RETURN (DIRECTION DOWN MATCHES 20) <criteria>

These could even be combined by having MATCHES +n and MATCHES -n.

Then MIN would be replaced by (DIRECTION UP MATCHES 1) and so on.

Pete Maclean

content-class: urn:content-classes:message
Subject: RE: [lemonade] Re: New draft: SEARCH return options
Date: Tue, 15 Feb 2005 13:31:15 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> > What need is there for unsolicited ESEARCH?
> 
> Maybe there is none, but I didn't want to disallow this in 
> the future. 
> And the recent discussion about EXPUNGED made me think that a SEARCH 
> result might be caused by commands other than SEARCH.

I agree with Alexey.

To purposely design with the intent to not allow a particular 
response to be unsolicited is an unwise restriction.

We should intentionally design to make responses as command 
independent as possible. They should be viewed as packets of 
information a client can use independent of the command that was
used to elicit them.

I would like to see this response tagging referral idea become a 
general mechanism and not bound to ESEARCH.

Mike

Date: Tue, 15 Feb 2005 18:55:07 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On February 15, 2005 12:26:47 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>>> Right now I don't see why we need the new ESEARCH response at all, as
>>> opposed to just redefining the SEARCH response (which is fine because
>>> the client knows what it is going to get having used the extended
>>> SEARCH command). Perhaps Alexey can explain why we have to have a new
>>> response?
>>
>> ESEARCH response can be unsolicited, SEARCH response can't - the client
>> really doesn't know what has caused it and whether it contains UIDs or
>> message numbers.
>
> What need is there for unsolicited ESEARCH?

Maybe there is none, but I didn't want to disallow this in the future. 
And the recent discussion about EXPUNGED made me think that a SEARCH 
result might be caused by commands other than SEARCH.

I was also thinking that with ESEARCH (if extended to include ID/tag, as 
discussed recently), the server can send SEARCH results in chunks. But 
maybe the draft should be extended to list that this behavior is allowed 
and how the client should handle it.

Date: Tue, 15 Feb 2005 10:25:57 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Alexey,

--On February 15, 2005 11:36:09 AM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> This could prove very powerful for clients that want to present
>> multiple simultaneous 'views' on the same mailbox.
>
> Cyrus, what do you think is a practical limit on the number of search
> results a server should remember?

Of course there should be limit, with a recommended minimum (e.g. 10). Plus 
this feature must be explicitly turned on by the client. i.e. a regular 
search will always be remembered as the 'anonymous' search set $ (which 
gets replaced with each search), but the client has to explicitly 'name' a 
search to have its results saved for the session. That way servers are not 
required to remember multiple sets unless the client specifically asks for 
it. It would also be handy if the client can 'refresh' the results of a 
'named' search in a quick way, e.g.:

a1 SEARCH RETURN (ID 1) UNSEEN

a2 FETCH $[1] (ENVELOPE)

a3 SEARCH $[1]

The last search is a repeat of the first one with the $[1] set being 
updated with the new results.

Of course we could go further over the top here and reinvent ACAP contexts 
by allowing the search results to be dynamic (i.e. the $[1] set changes as 
message unseen state changes and there are appropriate unsolicited 
responses to indicate that). Maybe that is going too far, but Mark did 
bring that up...

-- 
Cyrus Daboo

Date: Tue, 15 Feb 2005 10:15:37 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Alexey,

--On February 15, 2005 12:26:47 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> Right now I don't see why we need the new ESEARCH response at all, as
>> opposed to just redefining the SEARCH response (which is fine because
>> the client knows what it is going to get having used the extended
>> SEARCH command). Perhaps Alexey can explain why we have to have a new
>> response?
>
> ESEARCH response can be unsolicited, SEARCH response can't - the client
> really doesn't know what has caused it and whether it contains UIDs or
> message numbers.
>

What need is there for unsolicited ESEARCH?

-- 
Cyrus Daboo

Date: Tue, 15 Feb 2005 12:26:47 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Mark,
>
> --On February 14, 2005 12:51:02 PM -0800 Mark Crispin 
> <[email-masked]> wrote:
>
>> tag SEARCH extended-poop
>> tag OK [SEARCH extended-poop-response] extended SEARCH OK
>>
>> as opposed to
>>
>> tag SEARCH extended-poop
>> * ESEARCH extended-poop-response
>> tag OK SEARCH completed
>>
>> Note that this precludes any sort of "watching" SEARCH extension, in
>> which you have a standing SEARCH and get unsolicited responses.  It has
>> been nearly 20 years and we have done no such thing, so maybe we don't
>> care.
>
> I guess I dislike the idea of having actual results come back in the 
> extended response code.

Me too.

> Right now I don't see why we need the new ESEARCH response at all, as 
> opposed to just redefining the SEARCH response (which is fine because 
> the client knows what it is going to get having used the extended 
> SEARCH command). Perhaps Alexey can explain why we have to have a new 
> response?

ESEARCH response can be unsolicited, SEARCH response can't - the client 
really doesn't know what has caused it and whether it contains UIDs or 
message numbers.

Date: Tue, 15 Feb 2005 11:36:09 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

> The fetch commands act on the result of the different searches, 
> referenced by the ID option value. This means that a client could use 
> multiple search result sets simultaneously, as opposed to in series, 
> as they would have to right now.
>
> This could prove very powerful for clients that want to present 
> multiple simultaneous 'views' on the same mailbox.

Cyrus, what do you think is a practical limit on the number of search 
results a server should remember?

Alexey

Date: Tue, 15 Feb 2005 11:33:56 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Philip Guenther wrote:

>[Not sent to lemonade.  Do we really need to carry on this discussion in
>both places?]
>  
>
Thanks!

>Cyrus Daboo <[email-masked]> writes:
>...
>  
>
>>There is also an interesting possibility of tying the two together via the 
>>ID return option I proposed. For example:
>>
>>C: a SEARCH RETURN (ID 1 ALL) UNSEEN
>>    
>>
>...
>  
>
>>C: FETCH $[1] (UID INTERNALDATE FLAGS RFC822.HEADER)
>>    
>>
>...
>  
>
>>The fetch commands act on the result of the different searches, referenced 
>>by the ID option value. This means that a client could use multiple search 
>>result sets simultaneously, as opposed to in series, as they would have to 
>>right now.
>>    
>>
>
>The '$' token in draft-melnikov-imap-search-res-01.txt references the
>last SEARCH result, so it only requires the server to remember the one
>such result.
>
Yes, that was the original intent. Even if the client has specified 
"RETURN (COUNT)", the "$" construct still references the set of found 
messages.

>  If multiple search responses need to be remembered then
>some limit needs to be placed on how many a client can expect a server
>to remember and perhaps the client will need some way of controlling
>their lifetime.
>  
>
Yes.
I was thinking about remembering multiple SEARCH results, but this might 
overcomplicate the extension without much benefit.
What people think about this?

Alexey

Date: Tue, 15 Feb 2005 11:08:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>Cyrus Daboo writes:
>  
>
>>The IDs make it clear which response corresponds to each search.
>>    
>>
>IMAP already has a mechanism to handle that: tagged responses.
>  
>
And I was thinking about returning the corresponding tag in ESEARCH.

To: Weingarten Jerry <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: Other ANNOTATEMORE Comments 
Date: Tue, 15 Feb 2005 02:16:24 -0800
Sender: [email-masked]

Weingarten Jerry <[email-masked]> writes:
>Is there any particular reason why there is no mention of a way to
>delete these annotations?

Looking at annotatemore-06, section 3.3, top of page 11:
...
   Sets the specified list of entries by adding or replacing the
   specified attributes with the values provided.  Clients can use NIL
   for values of attributes it wants to remove from entries.

So, you can remove attributes from an entry by setting them to NIL.
That leaves the question of what attributes you need to remove to make
an entry completely disappear.

The ANNOTATE draft is specific on that point for its entries:
annotate-12, section 2.2.2:
...
   value
      A UTF8 string representing the data value of the attribute.  To
      delete an annotation, the client can store NIL into the value.

I.e., setting the 'value' attribute to NIL removes the entire entry,
including any vendor attributes.  This seems like the right thing to me:
vendor attributes should only be used to further describe or supplement
an entry's value attribute and not have meaning independent of it; if
they have independent meaning they should be in their own entries.

Philip Guenther

Content-class: urn:content-classes:message
Subject: Other  ANNOTATEMORE Comments
Date: Tue, 15 Feb 2005 11:30:00 +0200
From: "Weingarten Jerry" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

 Hi, 

Is there any particular reason why there is no mention of a way to
delete these annotations?  Do these just accumulate by adding new server
annotations?

Thanx,
jerry

To: Cyrus Daboo <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: New draft: SEARCH return options 
Date: Mon, 14 Feb 2005 15:46:24 -0800
Sender: [email-masked]

[Not sent to lemonade.  Do we really need to carry on this discussion in
both places?]

Cyrus Daboo <[email-masked]> writes:
...
>There is also an interesting possibility of tying the two together via the 
>ID return option I proposed. For example:
>
>C: a SEARCH RETURN (ID 1 ALL) UNSEEN
...
>C: FETCH $[1] (UID INTERNALDATE FLAGS RFC822.HEADER)
...
>The fetch commands act on the result of the different searches, referenced 
>by the ID option value. This means that a client could use multiple search 
>result sets simultaneously, as opposed to in series, as they would have to 
>right now.

The '$' token in draft-melnikov-imap-search-res-01.txt references the
last SEARCH result, so it only requires the server to remember the one
such result.  If multiple search responses need to be remembered then
some limit needs to be placed on how many a client can expect a server
to remember and perhaps the client will need some way of controlling
their lifetime.

Philip Guenther

Date: Mon, 14 Feb 2005 23:49:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> The formal syntax for the 'response' element. If you follow that 
> through you will see that you can only have one 'response-tagged' 
> item in 'response'.

Right. And I found another bit near the bottom of page 62.

I have no opinion, then. All the alternatives are fine with me.

Arnt

To: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: ANNOTATE (-12) comments
Date: Mon, 14 Feb 2005 15:15:29 -0800
Sender: [email-masked]

My abject apology to all for not doing this review sooner.

Typos:
  tyhe -> the
  UTF8 -> UTF-8
  utf8 -> utf-8		(in the default charset)

The second paragraph of the introduction seems redundant and/or
incomplete given the list in the succeeding paragraph.

I believe "i.e." should have a comma after it.  That should also fix the
extra space being inserted there.

Line-breaking should be suppressed in the middle of entry and attribute
names.  For example, "/comment" shouldn't be split across the first two
lines of the second paragraph of 2.1.  There should also be a statement
somewhere that in examples, lines not starting with "C: " or "S: " are
continuations of the previous lines.  The extra leading white-space on
such lines should either be removed or somehow described as really being
just a single space.

Since an attribute can only have one value, I don't think 'values'
should be plural in the last paragraph of 2.1.  Hmm, and since a single
STORE or FETCH can operate across multiple messages, it should arguably
say "...and any entries in message annotations, ..."  <shrug>

In 2.4, after citing ACLUPD (2086upd), it then only refers to the ACL
extension and not the RIGHTS capability.  Is it intended that a server
that supports ANNOTATE and ACL but not RIGHTS must still support the 'm'
and 'n' rights?  I think so, but given the reference to 2086upd, perhaps
the third paragraph of 2.4 should start "When the ACL extension is
present, whether or not the RIGHTS capability is advertised, the server
MUST..."

Not to cause any hair-removal, but since entry and attribute names are
in UTF-8 and are both stored and searched, doesn't a stringprep profile
need to be specified for them?  Can I put U+FF0F (FULLWIDTH SLASH) in
the name of an entry?  How about unassigned codepoints?

Since <section-part> has to be non-zero, an entry starting with "0"
can't refer to a body part annotation.

The entry names MUST NOT contain consecutive or trailing slashes.
The attribute names MUST NOT contain consecutive or trailing periods.

To avoid ambiguity, attribute names should not be allowed to contain
'priv' or 'shared' as their final component, or perhaps as any
component.

An attribute value may be binary octets, including NUL, particularly
when its content-type is something other than text (image/jpeg?).
Should the FETCH response for such a value use the literal8 syntax from
the BINARY extension?  That would seem to be preferable to introducing
content-transfer-encodings to the mess.

May servers check the value of an entry against its content-type?
Off-hand, I would say they MUST NOT do so if the content-type isn't
text/*, but MAY for content-type text/*.  However, if checking is
permitted at all then a response-code should be added for failure to
validate.

If the content-type is just "text/plain", the charset would default to
us-ascii instead of utf-8.  If that's not intended, the wording there
needs to be tweaked.

Should the server be required to validate the syntax of a content-type
being stored?  (E.g., can I store a content-type of "/" ?)

It should probably be strongly recommended that UTF-8 be used for all
textual values.  I'd hate to see "text/plain; charset=iso-2022-jp" all
over the place, though we can't exactly ban it.

Should the registration for a new attribute specify what it may contain
(utf-8, binary, etc)?

According to the syntax, ANNOTATESIZE is a response-code, but the text
of section 3.1 calls it a response.  One or the other should be changed
and at least one example of it should be added.

If the server doesn't an untagged ANNOTATESIZE response-code, is the
client allowed to store annotations?

Would lack of the correct ACL rights be a reason for returning
"ANNOTATESIZE 0"?

Just for the fun of it, I suggest adding some other fetch attribute to
one of the examples or changing one to be a UID FETCH.

In 3.6, it should simply say that any annotation entry whose size is
larger than the destination mailbox's ANNOTATESIZE is silently dropped
during the copy.  The ANNOTATESIZE zero or NIL cases are just specific
examples of that which happen to include _all_ annotations.  Hmm, if
only one of the .priv or .shared values exceeds the size, should both be
dropped or only the one that exceeds the size?

The syntax for select-param can be simplified slightly to:
      select-param      = astring / "(" astring 1*(SP astring) ")"

If the literal8 syntax is pulled in from BINARY, then the syntax for
value would change to
      value             = nstring / literal8

Why is RFC1891 a normative reference?

Philip Guenther

Date: Mon, 14 Feb 2005 12:51:02 -0800
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 14 Feb 2005, Cyrus Daboo wrote:
> Can you explain with some examples...

tag SEARCH extended-poop
tag OK [SEARCH extended-poop-response] extended SEARCH OK

as opposed to

tag SEARCH extended-poop
* ESEARCH extended-poop-response
tag OK SEARCH completed

Note that this precludes any sort of "watching" SEARCH extension, in which 
you have a standing SEARCH and get unsolicited responses.  It has been 
nearly 20 years and we have done no such thing, so maybe we don't care.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

content-class: urn:content-classes:message
Subject: RE: [lemonade] Re: New draft: SEARCH return options
Date: Mon, 14 Feb 2005 15:45:51 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> then the most honest response format is
> 
> a1234 ESEARCH ALL 1:100

I disagree. 

The notion of having multiple responses with tag affinity 
is perfectly valid in my mind. Given that, a logical progression 
from what you are proposing is ...

1 SEARCH ...
1 ESEARCH ...
1 SOME FUTURE RESPONSE ....
1 OK ...

In my mind this is a much more ungainly solution then to just reuse
the already existing notion of untagged solicited responses. Just
add tag affinity with a data item in the response is much simpler
and elegant.

Mike

content-class: urn:content-classes:message
Subject: RE: [lemonade] Re: New draft: SEARCH return options
Date: Mon, 14 Feb 2005 15:12:22 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> On Mon, 14 Feb 2005, Cyrus Daboo wrote:
> > Can you explain with some examples...
> 
> tag SEARCH extended-poop
> tag OK [SEARCH extended-poop-response] extended SEARCH OK
> 
> as opposed to
> 
> tag SEARCH extended-poop
> * ESEARCH extended-poop-response
> tag OK SEARCH completed

Would there be any other reason then the pipelining id problem 
to do it this way?

Mike

Date: Mon, 14 Feb 2005 21:19:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> The IDs make it clear which response corresponds to each search.

IMAP already has a mechanism to handle that: tagged responses.

Arnt

Date: Mon, 14 Feb 2005 15:01:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
cc: Lemonade WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Alexey,

--On February 14, 2005 2:56:25 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

> Based on the recent discussion of the
> draft-melnikov-imap-expunged-00.txt, Dave and I wrote a draft that adds
> return options to the SEARCH command. Currently defined return options
> are: COUNT (number of found messages), MIN (the lowest message number/UID
> found), MAX (the highest message number/UID found) and ALL (return all
> found messages as a message/UID set).
>
> Dave has implemented the extension in his Polymer email client.
>
> I am also proud to announce the support for this extension in Isode IMAP
> server.
>
> Alexey
>
> P.S. If you are interested to test this extension against Isode server,
> please contact me directly.

One thing you might want to consider adding to this is a 'ID' return option 
that takes an atom as an argument. The server would be required to return 
that ID and atom in the ESEARCH response for the corresponding command. 
This will solve the problem of multiple pipelined search commands and 
figuring out which search response corresponds to which command.

e.g.

C: a SEARCH RETURN (ID 1 ALL) UNSEEN
C: b SEARCH RETURN (ID 2 ALL) DELETED
S: * ESEARCH ID 1 ALL 1:100
S: * ESEARCH ID 1 ALL 200:1000
S: * ESEARCH ID 2 ALL 150
S: a OK
S: b OK

The IDs make it clear which response corresponds to each search.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 15:09:28 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
cc: Lemonade WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Alexey,
I think you need to have some mention of how this interacts with 
draft-melnikov-imap-search-res-01.txt. Or that document should mention how 
it interacts with draft-melnikov-imap-search-ret-00.txt. One issue is:

a SEARCH RETURN (COUNT) UNSEEN

Strictly speaking the above command does not generate a message sequence 
set, so is the last search result $ item set or not?

There is also an interesting possibility of tying the two together via the 
ID return option I proposed. For example:

C: a SEARCH RETURN (ID 1 ALL) UNSEEN
C: a SEARCH RETURN (ID 2 ALL) DELETED
...

C: FETCH $[1] (UID INTERNALDATE FLAGS RFC822.HEADER)

C: FETCH $[2] (UID INTERNALDATE FLAGS RFC822.HEADER)

The fetch commands act on the result of the different searches, referenced 
by the ID option value. This means that a client could use multiple search 
result sets simultaneously, as opposed to in series, as they would have to 
right now.

This could prove very powerful for clients that want to present multiple 
simultaneous 'views' on the same mailbox.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 16:37:18 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Arnt,

--On February 14, 2005 10:33:49 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> As far as I recall the IMAP base-spec only allows one tagged response
>> to any command, so the above would not work without redefining IMAP's
>> entire response behaviour...
>
> That's an excellent argument, but where in the RFC does it say so?
>

The formal syntax for the 'response' element. If you follow that through 
you will see that you can only have one 'response-tagged' item in 
'response'.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 22:33:49 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> As far as I recall the IMAP base-spec only allows one tagged response 
> to any command, so the above would not work without redefining IMAP's 
> entire response behaviour...

That's an excellent argument, but where in the RFC does it say so?

Arnt

Date: Mon, 14 Feb 2005 15:30:57 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Arnt,

--On February 14, 2005 9:19:16 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> The IDs make it clear which response corresponds to each search.
>
> IMAP already has a mechanism to handle that: tagged responses.
>

Search results are always untagged.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 15:45:24 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Mark,

--On February 14, 2005 12:43:34 PM -0800 Mark Crispin 
<[email-masked]> wrote:

>>>> The IDs make it clear which response corresponds to each search.
>>> IMAP already has a mechanism to handle that: tagged responses.
>> Search results are always untagged.
>
> Yes, but instead of an ESEARCH untagged response this could be a status
> response in the tagged OK.  I think that this is the way to go.
>

Can you explain with some examples...

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 16:28:32 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Arnt,

--On February 14, 2005 10:22:58 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

> I'm suggesting that IF you want to tag ESEARCH responses (whether you
> call them "tagged searches" or "searches with ID" is no matter to me),
> then the most honest response format is
>
> a1234 ESEARCH ALL 1:100

As far as I recall the IMAP base-spec only allows one tagged response to 
any command, so the above would not work without redefining IMAP's entire 
response behaviour...

> There are alternatives, such as sneaking the tag in the back door:
>
> * ESEARCH TAG a1234 ALL 1:100
>
> Or such as using an Elvis lookalike instead of the real thing:
>
> * ESEARCH ID a1234 ALL 1:100
>
> Whether ESEARCH is tagged or not is no matter to me. I'm happy either way.
>
> But if it is tagged, I'd like to see IMAP stay with just one tag
> mechanism (unless there are pressing reasons for having multiple similar
> mechanisms, of course).

Ok - command tags would be sufficient.

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 12:43:34 -0800
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 14 Feb 2005, Cyrus Daboo wrote:
>>> The IDs make it clear which response corresponds to each search.
>> IMAP already has a mechanism to handle that: tagged responses.
> Search results are always untagged.

Yes, but instead of an ESEARCH untagged response this could be a status 
response in the tagged OK.  I think that this is the way to go.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 14 Feb 2005 22:22:58 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> OK, so are you suggesting that the tag for the SEARCH command is used 
> as the 'ID' I was proposing, e.g.:
>
> a1234 SEARCH RETURN (TAG ALL) UNSEEN
> * ESEARCH TAG a1234 ALL 1:100
> a1234 OK

I'm suggesting that IF you want to tag ESEARCH responses (whether you 
call them "tagged searches" or "searches with ID" is no matter to me), 
then the most honest response format is

a1234 ESEARCH ALL 1:100

There are alternatives, such as sneaking the tag in the back door:

* ESEARCH TAG a1234 ALL 1:100

Or such as using an Elvis lookalike instead of the real thing:

* ESEARCH ID a1234 ALL 1:100

Whether ESEARCH is tagged or not is no matter to me. I'm happy either way.

But if it is tagged, I'd like to see IMAP stay with just one tag 
mechanism (unless there are pressing reasons for having multiple 
similar mechanisms, of course).

Arnt

content-class: urn:content-classes:message
Subject: RE: [lemonade] Re: New draft: SEARCH return options
Date: Mon, 14 Feb 2005 15:19:10 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> If you want ESEARCH to be bound to the command, you can 
> either use the 
> IMAP tag mechanism or reinvent it.
> 

Maybe not reinvent, but rather exploit.

To reuse Cyrus's example ...

C: a SEARCH RETURN (ALL) UNSEEN
C: b SEARCH RETURN (ALL) DELETED
S: * ESEARCH TAG a ALL 1:100,200:1000
S: * ESEARCH TAG b ALL 150
S: a OK
S: b OK

content-class: urn:content-classes:message
Subject: RE: [lemonade] New draft: SEARCH return options
Date: Mon, 14 Feb 2005 13:59:50 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> >There should be some Normative text stipulating that SEARCH and 
> >ESEARCH are mutually exclusive responses.
> >  
> >
> The document already says "MUST send  ESEARCH when a return option is 
> specified". Do you think this is not sufficient?

Yes, if your intent is to make the responses mutually exclusive.

Mike

Date: Mon, 14 Feb 2005 16:07:05 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Arnt,

--On February 14, 2005 9:58:42 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> Search results are always untagged.
>
> Why?
>
> If you want ESEARCH to be bound to the command, you can either use the
> IMAP tag mechanism or reinvent it.
>

OK, so are you suggesting that the tag for the SEARCH command is used as 
the 'ID' I was proposing, e.g.:

a1234 SEARCH RETURN (TAG ALL) UNSEEN
* ESEARCH TAG a1234 ALL 1:100
a1234 OK

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 16:04:10 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Sender: [email-masked]

Hi Mark,

--On February 14, 2005 12:51:02 PM -0800 Mark Crispin 
<[email-masked]> wrote:

> tag SEARCH extended-poop
> tag OK [SEARCH extended-poop-response] extended SEARCH OK
>
> as opposed to
>
> tag SEARCH extended-poop
> * ESEARCH extended-poop-response
> tag OK SEARCH completed
>
> Note that this precludes any sort of "watching" SEARCH extension, in
> which you have a standing SEARCH and get unsolicited responses.  It has
> been nearly 20 years and we have done no such thing, so maybe we don't
> care.
>

I guess I dislike the idea of having actual results come back in the 
extended response code.

Right now I don't see why we need the new ESEARCH response at all, as 
opposed to just redefining the SEARCH response (which is fine because the 
client knows what it is going to get having used the extended SEARCH 
command). Perhaps Alexey can explain why we have to have a new response?

-- 
Cyrus Daboo

Date: Mon, 14 Feb 2005 21:58:42 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] Re: New draft: SEARCH return options
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> Hi Arnt,
>
> --On February 14, 2005 9:19:16 PM +0100 Arnt Gulbrandsen 
> <[email-masked]> wrote:
>
>>> The IDs make it clear which response corresponds to each search.
>>
>> IMAP already has a mechanism to handle that: tagged responses.
>
> Search results are always untagged.

Why?

If you want ESEARCH to be bound to the command, you can either use the 
IMAP tag mechanism or reinvent it.

Arnt

Date: Mon, 14 Feb 2005 19:44:14 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [lemonade] New draft: SEARCH return options
Sender: [email-masked]

[email-masked] wrote:

>Comments:
>I don't understand what the anticipated use of RETURN () would be?
>  
>
This is a hook for the SEARCHRES extension 
(draft-melnikov-imap-search-res-01.txt).

>There should be some Normative text stipulating that SEARCH and 
>ESEARCH are mutually exclusive responses.
>  
>
The document already says "MUST send  ESEARCH when a return option is 
specified". Do you think this is not sufficient?

content-class: urn:content-classes:message
Subject: RE: [lemonade] New draft: SEARCH return options
Date: Mon, 14 Feb 2005 13:35:01 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I like it. I think it is done very smoothly.

Comments:
I don't understand what the anticipated use of RETURN () would be?

There should be some Normative text stipulating that SEARCH and 
ESEARCH are mutually exclusive responses.

Mike

content-class: urn:content-classes:message
Subject: RE: New draft: SEARCH return options
Date: Mon, 14 Feb 2005 13:25:07 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> Is there much feeling as to how useful it would be?  

I think the RETURN (ALL) semantics will be useful.

Mike

Date: Mon, 14 Feb 2005 10:12:00 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Subject: Re: New draft: SEARCH return options
Sender: [email-masked]

I've reviewed this document and while I have document nits the protocol 
proposed looks OK to me.

Is there much feeling as to how useful it would be?  I'm not talking about 
Dave and Alexey since I'm sure they are already convinced.  It's more of a 
question of whether the benefit is worth the added complexity (don't 
forget, it does represent an additional task for server implementors!).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 14 Feb 2005 14:56:25 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: New draft: SEARCH return options
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: IMAP4 extension to SEARCH command for controlling what 
>			  kind of information is returned
>	Author(s)	: A. Melnikov, D. Cridland
>	Filename	: draft-melnikov-imap-search-ret-00.txt
>	Pages		: 0
>	Date		: 2005-2-11
>	
>This document extends SEARCH and UID SEARCH commands with result
>   specifier, which can control what kind of information is returned.
>   Several result specifiers are defined: minimal value, maximal
>   value, all found messages and number of found messages. A new
>   response ESEARCH is also specified.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-melnikov-imap-search-ret-00.txt
>
Based on the recent discussion of the 
draft-melnikov-imap-expunged-00.txt, Dave and I wrote a draft that adds 
return options to the SEARCH command. Currently defined return options 
are: COUNT (number of found messages), MIN (the lowest message 
number/UID found), MAX (the highest message number/UID found) and ALL 
(return all found messages as a message/UID set).

Dave has implemented the extension in his Polymer email client.

I am also proud to announce the support for this extension in Isode IMAP 
server.

Alexey

P.S. If you are interested to test this extension against Isode server, please contact me directly.

 __________________________________________
IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Mon, 14 Feb 2005 13:02:52 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-11.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.
>
>	Title		: IMAP4 LIST Command Extensions
>	Author(s)	: B. Leiba, A. Melnikov
>	Filename	: draft-ietf-imapext-list-extensions-11.txt
>	Pages		: 10
>	Date		: 2005-2-10
>	
>IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
>have added extensions that have required specialized lists (see
>[MboxRefer] for an example) we have had to expand the number of list
>commands, since each extension must add its function to both LIST and
>LSUB, and these commands are not, as they are defined, extensible.
>If we've needed the extensions to work together, we've had to add a
>set of commands to mix the different options, the set increasing in
>size with each new extension.  This document describes an extension
>to the base LIST command that will allow these additions to be done
>with mutually compatible options to the LIST command, avoiding the
>exponential increase in specialized list commands.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-11.txt
>  
>
After reviewing the mailing list archive I've decided that CHILDINFO is the way to go, because we want to allow for multiple LIST and unsolicited responses. This indeed made explanation much easier. Of course CHILDINFO is a bit verbose, so I would welcome suggestions.

I've also renamed MATCHPARENT to RECURSIVEMATH and made rules about CHILDREN extension more strict (as discussed during the last interim meeting). I've also tried to address some minor editorial issues raised by Philip previously.

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-11.txt
Date: Thu, 10 Feb 2005 15:51:14 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-11.txt
	Pages		: 10
	Date		: 2005-2-10
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-list-extensions-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: Dave Cridland <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ANNOTATEMORE Comments
Date: Thu, 10 Feb 2005 19:40:54 +0000
Sender: [email-masked]

On Thu Feb 10 14:34:22 2005, [email-masked] wrote:
> Would it be worth while adding an entry for declaring capabilities?
> IMAP obviously has a way to declare an extension via the 
> CAPABILITY command, but it would seem that an optional declaration 
> via an annotation could easily provide for a richer declaration. 
> 
> For example a new server entry like:
> 
> /capabilities/<capability>
> 
> Attributes could then be defined that may describe or modify the 
> capability further. 

This is very like the capability dataset class in ACAP, which allows for active clients to provide services via the ACAP server, like addressbook expansion.

It sounds like a great idea in principle, and could provide the same capability - that is, per-user capabilities provided in some cases by external modules, sometimes specific to the user.

The problems are quite similar, too, though - with ACAP, it wasn't ever fully defined precisely how a client detirmines that the agent providing the capability is really present and working. In my ACAP work, I've always avoided the dataset class as a whole - it's simply unreliable, great idea or not. Either that, or I just can't see how it ought to work, which is equally likely.

This needn't be the case with IMAP/ANNOTATEMORE, of course, but it needs thinking about carefully, I think.

Dave.

content-class: urn:content-classes:message
Subject: ANNOTATEMORE Comments
Date: Thu, 10 Feb 2005 08:34:22 -0600
From: <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I like it.

Would it be worth while adding an entry for declaring capabilities?
IMAP obviously has a way to declare an extension via the 
CAPABILITY command, but it would seem that an optional declaration 
via an annotation could easily provide for a richer declaration. 

For example a new server entry like:

/capabilities/<capability>

Attributes could then be defined that may describe or modify the 
capability further. 

Mike

content-class: urn:content-classes:message
Subject: Body Part Content Conversion using ANNOTATEMORE
Date: Thu, 10 Feb 2005 08:27:32 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I've put together a draft describing a proposal that uses ANNOTATEMORE
as the vehicle for discovery. Please provide comments.

I've copied both imapext and lemonade because it is relevant to both.
I would suggest any discussion be confined to the lemonade list.

I've submitted the draft, but until then you can find it at the link 
below.

http://ietf.webdav.org/imapext/draft-wener-lemonade-conversion-00.txt

Mike

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Tue, 8 Feb 2005 18:56:08 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Dave Cridland [mailto:[email-masked]]
> Sent: Tuesday, February 08, 2005 5:45 PM
...
> > Maybe a better solution is ...
> > 
> > C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTUIDS)
> > S: * SEARCH etc ...
> > S: 1 OK FETCH Complete
> > 
> > In this case you completely remove the problem of having
> > any EXPUNGE memory, and it alleviates the server from having
> > to even worry about MODSEQ for expunges.
> > 
> 
> Is having an EXPUNGE memory that difficult?

No, but that is not the point. The point is that we are looking
for an optimal way for a client to synchronize server mailbox 
state. If it can be equivalently done with out requiring the 
server to maintain additional state I see this as an upside. 
After all what got us to this point in the discussion was the 
possibility of a server forgetting expunges.

> In short, I don't actually think that an extension as you 
> propose here - that simply sends out an unsolicited UID 
> SEARCH - is actually telling the client what it wants to know.

In this case it was solicited.

We did conclude, a message or two ago, that this was equivalent 
to the UIDEXPUNGE. 

Universe = ExpungedSet U UidSearchSet

We know the universe. So we can send one of the other two and 
deduce the third. Also, what the client ultimately wants is 
UidSearchSet.  

> 
> The rest of this email is, I hope, teaching any watching 
> grandmothers to suck eggs. (Not my grandmother, though, as 
> she was the only person I ever met who liked CPM.) Feel free 
> to tune out.

I have no idea what you are talking about, here.

Mike

From: Dave Cridland <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Tue, 08 Feb 2005 22:44:31 +0000
Sender: [email-masked]

On Tue Feb  8 19:27:23 2005, [email-masked] wrote:
> I understand the appeal of having the same response, but I think 
> you overstate the issue of returning the SEARCH response. Clients 
> will have code to deal with the SEARCH response.
> 

But, quite possibly, only in the context of a sent SEARCH/UID SEARCH command.

> 
> Maybe a better solution is ...
> 
> C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTUIDS)
> S: * SEARCH etc ...
> S: 1 OK FETCH Complete
> 
> In this case you completely remove the problem of having
> any EXPUNGE memory, and it alleviates the server from having
> to even worry about MODSEQ for expunges.
> 

Is having an EXPUNGE memory that difficult?

> 
> A couple of interesting notes regarding the above solution ...
> 1) It is just a shorthand way of doing both a FETCH and UID 
> SEARCH in the same command.

With extra processing above and beyond the pipelined UID SEARCH/UID FETCH that is otherwise identical to it other than a handful of octets - if the packet size were so small that this made any practical difference, I'd be shocked.

Besides which, a client can always be in posession of the knowledge of whether it knows about all the expunges, or whether some may remain undetected, simply by examining UIDNEXT/EXISTS.

In short, I don't actually think that an extension as you propose here - that simply sends out an unsolicited UID SEARCH - is actually telling the client what it wants to know.

The rest of this email is, I hope, teaching any watching grandmothers to suck eggs. (Not my grandmother, though, as she was the only person I ever met who liked CPM.) Feel free to tune out.

I assume this algorithm is reasonably well known, I've been using various stages of refinement of it for around a year, with pleasant success, but I'll hold it up for people to shoot it down:

1) Let the values of UIDNEXT and EXISTS as reported in the previous SELECT be LAST_UIDNEXT and LAST_EXISTS respectively.

2) Let the tracked value of EXISTS, as detirmined by EXPUNGE and EXISTS responses received by the client during the previous mailbox session be CURRENT_EXISTS.

3) Let the count of EXPUNGE responses received by the client during the previous mailbox session be SEEN_EXPUNGES

4) Let the values of UIDNEXT and EXISTS reported during the new select be NEW_UIDNEXT and NEW_EXISTS, respectively.

Now:

A) If LAST_UIDNEXT==NEW_UIDNEXT and CURRENT_EXISTS==NEW_EXISTS, then there have been no expunges between sessions. (And no appends, of course, this being trivial.)

B) If ( NEW_UIDNEXT - LAST_UIDNEXT ) == ( NEW_EXISTS - LAST_EXISTS + SEEN_EXPUNGES ), then there have been no expunges between sessions. (And some appends)

In any other case, there may have been expunges.

Since servers can, I believe, issue UIDs non-monotonically, this algorithm can fail, but does so safely (ie, the client believes there may have been EXPUNGEs when in fact there weren't).

On the other hand, if some mechanism were available that allowed the server to report a collection of UIDs which had recently been EXPUNGEd, the client could issue this instead, add the number found to SEEN_EXPUNGES above, and check case B to see if it had them all. (Again, this fails where UIDNEXT does not increase monotonically). Some information, here, is more use than none.

If the client believes there to have been EXPUNGEs, then it can simply perform a UID SEARCH across, for instance, CURRENT_EXISTS-100 to NEW_EXISTS, and simply replace the end of the known UID list if the first UID in the new list matches. (This is relatively common, since EXPUNGEs do appear to typically happen at the end of the mailbox.) Therefore, no need to UID SEARCH 1:* at all in most cases. Given the potential size of SEARCH results, it may be best to scan backwards at intervals in order to find the matching point which indicates that no EXPUNGEs affected anything before.

Of course, I do all this already, but then, my client is a caching online client, and I imagine most of the client authors here are more interested in the disconnected mode case. For my client, it enables me to resync as much as I need to in two round trips, usually one, and often zero, for mailboxes under 75,000 messages. This is as much scalability as I can reasonably hope for, especially as huge mailboxes tend to be mailing list archives, and thus are caught by rule (B) every time.

Dave.

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Tue, 8 Feb 2005 13:27:23 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext 
> Alexey Melnikov
> Sent: Friday, February 04, 2005 8:05 AM
...
> >Don't force a round trip.
> >
> >C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
> >S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
> >S: * SEARCH etc ...
> >S: 1 OK FETCH Complete
> >
> >Though, I'm not sure a round trip in this case would be bad.
> >
> >What worries me is the pathological case. It strikes me as 
> >wrong to send a list of an unbounded set, when what the client 
> >really wants is the compliment of that.
> >  
> >
> I frankly don't like that the server sends two different 
> responses that 
> mean pretty much the same thing. This definitely makes client 
> implementations more difficult.

I understand the appeal of having the same response, but I think 
you overstate the issue of returning the SEARCH response. Clients 
will have code to deal with the SEARCH response.

Maybe a better solution is ...

C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTUIDS)
S: * SEARCH etc ...
S: 1 OK FETCH Complete

In this case you completely remove the problem of having
any EXPUNGE memory, and it alleviates the server from having
to even worry about MODSEQ for expunges.

A couple of interesting notes regarding the above solution ...
1) It is just a shorthand way of doing both a FETCH and UID 
SEARCH in the same command.
2) It points out how adding EXPUNGE to CONDSTORE is a bit of a 
force fit.

Mike

From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Date: Mon, 07 Feb 2005 22:55:14 +0000
Sender: [email-masked]

On Mon Feb  7 20:40:09 2005, Mark Crispin wrote:
> 
> Do we really need "has" in front of all these flags?
> 
> Why not \Children, \NoChildren, etc.?
> 

As Alexey says, these are widely deployed - existing client code that I've had a chance to examine appears to rank CHILDREN as one of the most widely deployed extensions.

My suspicion is that many clients will start using LISTEXT merely by requesting CHILDREN formally. Some may well not notice if we subtlely rename the flags. (Although no doubt some server writers never bothered to spell them right to begin with).

> 
> Another point: using binary flags for a tri-state condition is troublesome, since it creates silly states.  \Marked and \UnMarked created the problem -- a mistake that I still deeply regret -- and it would be a shame if it gets worse.
> 
> Since we have binary flags as a given, can we think of a methodology that avoids tri-state conditions?
> 

Barry Leiba commented that \HasNoChildren is required to handle unsolicited LIST responses.

However, the same argument can be made of \Subscribed, and presumably other flags - does an unsolicited LIST without \Subscribed indicate that the mailbox is not subscribed, or merely that subscription information isn't included?

It strikes me that unsolicited LIST responses, currently barred by 3501 [I think: It's 11pm here, and I can't find the text], either need to be barred by LISTEXT explicitly pending a future standard, or we should actually solve the issue.

Dave.

Date: Mon, 07 Feb 2005 21:47:12 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for ANNOTATE Feb 4-18
Sender: [email-masked]

Lisa Dusseault wrote:

>
> This is a notification of the beginning of last-call for the -12 draft 
> of ANNOTATE:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-12.txt
>
> If you review this draft, let the WG know even if you have no issues 
> or comments.  Also, we'd like to know who plans to implement this or 
> may have already begun (you can let me know privately or mail the 
> WG).  Last call will go until and including February 18 2005.

Minor comment:
 The description of "/<section-part>/flags" only allows for "1" or "0". 
However, the description of "/flags" still allows for NIL.

Alexey

Date: Mon, 7 Feb 2005 13:18:57 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 7 Feb 2005, Alexey Melnikov wrote:
>> Do we really need "has" in front of all these flags?
>> Why not \Children, \NoChildren, etc.?
> Because they are already widely deployed.

The CHILDREN extension may be widely-deployed, but this is LISTEXT, not 
CHILDREN.

We have a chance to review the lessons of RFC 3348 (which I'll remind you 
is *NOT* standards-track!!) and maybe do something better.

I didn't say "break RFC 3348", but I am implying "replace RFC 3348".

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 07 Feb 2005 20:55:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

Mark Crispin wrote:

> Do we really need "has" in front of all these flags?
>
> Why not \Children, \NoChildren, etc.?

Because they are already widely deployed.

> Another point: using binary flags for a tri-state condition is 
> troublesome, since it creates silly states.  \Marked and \UnMarked 
> created the problem -- a mistake that I still deeply regret -- and it 
> would be a shame if it gets worse.
>
> Since we have binary flags as a given, can we think of a methodology 
> that avoids tri-state conditions?

Date: Mon, 7 Feb 2005 12:40:09 -0800
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Organization: Networks & Distributed Computing
Sender: [email-masked]

Do we really need "has" in front of all these flags?

Why not \Children, \NoChildren, etc.?

Another point: using binary flags for a tri-state condition is 
troublesome, since it creates silly states.  \Marked and \UnMarked created 
the problem -- a mistake that I still deeply regret -- and it would be a 
shame if it gets worse.

Since we have binary flags as a given, can we think of a methodology that 
avoids tri-state conditions?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 07 Feb 2005 19:55:12 +0000
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

Barry Leiba wrote:

>>These were discussed fairly completely during the meeting and we came
>>to consensus that
>>-) MATCHPARENT would stay; not much point in making LIST extendable if
>>   things that can reasonably be options are instead implicitly
>>   triggered
>>    
>>
>Yes, but we decided to call it "recursivematch".
>  
>
Done.

>>-) \placeholder and \hassubmailboxes will be replaced by a single flag
>>   named something like \hasmatchingchild.  Whether the returned name
>>   itself matches can be trivially deduced from the other returned
>>   flags.
>>    
>>
>
>Correct, and "\hasmatchingchildren" was what we were calling it.  I'm
>open to other names, but I think this name makes its purpose clear
>(where "hassubmailboxes" did not).
>
I've renamed the flag as well.

>>If the client pipelines requests that result in ambiguous
>>responses, well, "Doctor it hurts when I do _this_...".
>>    
>>
>
>Or put more IETF-ly, clients MUST NOT send simultaneous LIST commands,
>the responses from which they would not be able to sort out
>unambiguously.
>
It sounds there is a strong desire to allow for multiple extended LISTs 
and unsolicited LIST responses.

>>-) keeping the CHILDREN option and its behavior separate from
>>   MATCHPARENT was deemed to be clearer than merging them.  CHILDREN
>>   would be changed to require exact responses:
>>    
>>
>
>In other words, correct implementation of CHILDREN *will* be required
>by the LISTEXT spec, but the "\haschildren" and "\hasnochildren" flags
>will only be returned if they're asked for.  We DO need the
>"\hasnochildren" flag to distinguish the absence of children from the
>case where the server decides to send an unsolicited LIST response at
>the same time as it's responding to a LIST command.
>
>We've gone back and forth on this one, and I hope we have now decided
>it firmly.  The reasoning is that clients that want the has<no>children
>help will do the work with a series of commands anyway, and even if
>it's not convenient for some server implementations to provide it, it's
>still a LOT cheaper for them to do it in the server than for the client
>to have to request them separately.
>
Is the existing text Ok:

   In some instances a server that supports the LISTEXT extension
   might not be able to determine whether a mailbox has children.  For
   example it may have difficulty determining whether there are child
   mailboxes when LISTing mailboxes while operating in a particular
   namespace.
   In these cases, a server MAY exclude both the \HasChildren and
   \HasNoChildren attributes in the LIST response.  As such, a client
   can not make any assumptions about whether a mailbox has children
   based upon the absence of a single attribute. In particular, some
   servers may not be able to combine the SUBSCRIBED selection option
   and CHILDREN return option.  Such servers MUST honor the SUBSCRIBED
   selection option, and they will simply ignore the CHILDREN return option
   if both are requested. It is an error for the server to return both a
   \HasChildren and a \HasNoChildren attribute in a LIST response.
?
Or should I make it stricter?

>>There was some discussion of requiring LIST to return BAD if
>>MATCHPARENT was used with a pattern containing '*', but I'm not sure
>>that was dropped later as being too restrictive.
>>    
>>
>
>It was dropped.  We decided, after thinking about it, that it's not
>*really* a problem.  The consensus at the end was that there need be no
>restrictions on when "recursivematch" can be used.
>
>There was the issue of recursion loops, and we decided to allow a
>server, probably with a MAY clause, to limit the depth.  We did not
>pick a minimum depth that MUST be implemented, so we should pick one
>here.
>
I frankly don't recall any such discussion.
But any suggested text will be welcomed.

>
>We should have examples in the jabber log, assuming that Rob was able
>accurately to enter my scratchings on the white-boards, since I
>annoyingly refused to write from left to right.  Should we copy those
>examples here, or just point to the jabber logs?
>
>  
>

From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: WG last call for ANNOTATE Feb 4-18
Date: Fri, 04 Feb 2005 23:00:18 +0000
Sender: [email-masked]

On Fri Feb  4 21:32:16 2005, Lisa Dusseault wrote:
> If you review this draft, let the WG know even if you have no issues or comments.  Also, we'd like to know who plans to implement this or may have already begun (you can let me know privately or mail the WG).  Last call will go until and including February 18 2005.

I'm certainly planning to implement this my client, and with any luck I'll manage it quite soon. I do need to rework aspects of my CONDSTORE implementation to properly support it, though.

Given this is entirely new functionality, I personally believe it's vital to obtain real experience of interoperable implementation before we can safely put it through to RFC status.

As such, if anyone is implementing this on the server, I would be very grateful for a test account, whether or not it's under NDA. (Or just an agreement not to say anything publically.)

Dave.

Date: Fri, 04 Feb 2005 17:16:52 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Informal list last call for ANNOTATEMORE
Sender: [email-masked]

Hi folks,
I would like to submit the ANNOTATEMORE document to the IESG at the same 
time as the ANNOTE document (once that has gone through WGLC and all seems 
OK). However, since ANNOTATEMORE is an individual submission it is not 
subject to a WGLC, but I would appreciate it if people looking at ANNOTATE 
would also look at ANNOTATEMORE in the same vein and pass comments back, 
thanks.

<http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-07.txt>

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WG last call for ANNOTATE Feb 4-18
Date: Fri, 4 Feb 2005 13:32:16 -0800
Sender: [email-masked]

This is a notification of the beginning of last-call for the -12 draft 
of ANNOTATE:

http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-12.txt

If you review this draft, let the WG know even if you have no issues or 
comments.  Also, we'd like to know who plans to implement this or may 
have already begun (you can let me know privately or mail the WG).  
Last call will go until and including February 18 2005.

Lisa Dusseault

Date: Fri, 04 Feb 2005 13:05:00 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[email-masked] wrote:

>>>>>>> <><><> <<What if the server can?t remember some expunged UIDs, for
>>>>>>
>...
>  
>
>>>I think a better choice would be:
>>>C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
>>>S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
>>>S: 1 OK FETCH Complete
>>>
>>>The NO response with a UIDEXPUNGE response code would then 
>>>communicate to the client to resort to SEARCH.
>>>      
>>>
>>And the client will perform "UID SEARCH 1:*"? 
>>    
>>
>
>Yes.
>  
>
>>But this would give the 
>>same result as the server returning all expunges. Actually, 
>>    
>>
>
>Same end result, sure, but the set of UIDs returned is the 
>compliment of the set returned from UIDEXPUNGE. In the limit
>this is gauranteed to be smaller. :)
>  
>
Unless we have an archive folder, where nothing gets deleted. But for an 
average INBOX, you are right.

>>it would be 
>>worse, because SEARCH can't use ranges.
>>    
>>
>The lack of a range expression in the SEARCH response is 
>unfortunate. Isn't there a need to fix this independent 
>of this discussion? 
>  
>
>>In many cases just sending all expunged messages would be faster than 
>>forcing a round trip on the client.
>>    
>>
>
>Don't force a round trip.
>
>C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
>S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
>S: * SEARCH etc ...
>S: 1 OK FETCH Complete
>
>Though, I'm not sure a round trip in this case would be bad.
>
>What worries me is the pathological case. It strikes me as 
>wrong to send a list of an unbounded set, when what the client 
>really wants is the compliment of that.
>  
>
I frankly don't like that the server sends two different responses that 
mean pretty much the same thing. This definitely makes client 
implementations more difficult.

>>I also suspect that the list of expunges messages will 
>>compress nicely using ranges.
>>    
>>
>
>Over time what will happen is there will be a large range at the 
>beginning and then some amount of fragmentation that completely 
>depends on the mailbox maintenance habits of the user.
>  
>
I agree.

Date: Thu, 03 Feb 2005 22:02:45 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[email-masked] wrote:

>>>Sec 3.3
>>>  <<alternative #1: extend syntax for the CHANGEDSINCE FETCH
>>>  modifier.
>>>
>>>Why even have the keyword REPORTEXPUNGES? Why not just overload
>>>CHANGEDSINCE to imply expunges? 
>>>      
>>>
>>Sending expunge information to the client who hasn't asked for it 
>>doesn't sound right, even though any client should be able to ignore 
>>such information.
>>
>>If we choose to replace CONDSTORE, there would be no REPORTEXPUNGES.
>>    
>>
>If it does not sound right in draft-melnikov-imap-expunged-00 why
>would it be okay in CONDSTORE?
>  
>
What I really meant was "if EXPUNGED were a part of CONDSTORE, we 
wouldn't have to have REPORTEXPUNGES".

Anyway, Dave Cridland has told me that sometimes a client might only 
want to know about expunged messages and not about flag changes. This 
suggests that we should keep REPORTEXPUNGES.

Alexey

Date: Fri, 04 Feb 2005 12:23:20 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Compact SEARCH results
Sender: [email-masked]

[email-masked] wrote:

>The lack of a range expression in the SEARCH response is 
>unfortunate. Isn't there a need to fix this independent 
>of this discussion? 
>  
>
Yes.

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Fri, 4 Feb 2005 06:23:24 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, February 03, 2005 5:03 PM
...
> Anyway, Dave Cridland has told me that sometimes a client might only 
> want to know about expunged messages and not about flag changes. This 
> suggests that we should keep REPORTEXPUNGES.

Okay. More flexible does not hurt.

Mike

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 3 Feb 2005 16:32:55 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Timo Sirainen
> Sent: Thursday, February 03, 2005 3:22 PM
...
> > I think a better choice would be:
> > C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
> > S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
> > S: 1 OK FETCH Complete
> > 
> > The NO response with a UIDEXPUNGE response code would then 
> > communicate to the client to resort to SEARCH.
> 
> Bad idea. This is a rare exceptional case which would rarely 
> get tested
> for clients, if the client writer had even bothered to write code for
> handling it.

I don't believe your reasoning is valid.

1) At this point in time I would not assume it was rare. We don't 
know the likelihood of this event. It depends on how the server
implements "EXPUNGE Memory" and the clients usage patterns.

2) To not do something because it is rare would be to write 
incomplete and broken specifications. There are always rare
events in all software, including protocol software.

3) The problem you bring up is a software engineering problem
not a protocol problem. If an implementer is concerned about 
clients not handling rare events they should create a test 
vehicle that artificially increases the likelihood of rare
events.

4) Obviously clients have handled NO responses. They also
have obviously used SEARCH responses. The only thing new 
is the response code. Are there no other rare response codes?

Mike

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 3 Feb 2005 15:33:36 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, February 03, 2005 2:27 PM
...
> >>>>> <><> <<What if the server can?t remember some expunged 
> UIDs, for 
...
> >I think a better choice would be:
> >C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
> >S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
> >S: 1 OK FETCH Complete
> >
> >The NO response with a UIDEXPUNGE response code would then 
> >communicate to the client to resort to SEARCH.
> >
> And the client will perform "UID SEARCH 1:*"? 

Yes.

> But this would give the 
> same result as the server returning all expunges. Actually, 

Same end result, sure, but the set of UIDs returned is the 
compliment of the set returned from UIDEXPUNGE. In the limit
this is gauranteed to be smaller. :)

> it would be 
> worse, because SEARCH can't use ranges.

The lack of a range expression in the SEARCH response is 
unfortunate. Isn't there a need to fix this independent 
of this discussion? 

> 
> In many cases just sending all expunged messages would be faster than 
> forcing a round trip on the client.

Don't force a round trip.

C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
S: * SEARCH etc ...
S: 1 OK FETCH Complete

Though, I'm not sure a round trip in this case would be bad.

What worries me is the pathological case. It strikes me as 
wrong to send a list of an unbounded set, when what the client 
really wants is the compliment of that.

> I also suspect that the list of expunges messages will 
> compress nicely 
> using ranges.

Over time what will happen is there will be a large range at the 
beginning and then some amount of fragmentation that completely 
depends on the mailbox maintenance habits of the user.

Mike 

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-12.txt
Date: Thu, 03 Feb 2005 15:56:25 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-12.txt
	Pages		: 40
	Date		: 2005-2-3
	
The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "metadata" for messages
   stored in an IMAP mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-12.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-annotate-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-annotate-12.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-annotate-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Subject: RE: Comments on draft-melnikov-imap-expunged-00
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 03 Feb 2005 22:21:42 +0200
Sender: [email-masked]

--=-WkoxeaaPtvSa8jKekaBn
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2005-02-03 at 12:58 -0600, [email-masked] wrote:
> I think a better choice would be:
> C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
> S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
> S: 1 OK FETCH Complete
>=20
> The NO response with a UIDEXPUNGE response code would then=20
> communicate to the client to resort to SEARCH.

Bad idea. This is a rare exceptional case which would rarely get tested
for clients, if the client writer had even bothered to write code for
handling it.

--=-WkoxeaaPtvSa8jKekaBn
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-WkoxeaaPtvSa8jKekaBn--

Date: Thu, 03 Feb 2005 19:27:01 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[email-masked] wrote:

>>>>> <><> <<What if the server can?t remember some expunged UIDs, for 
>>>>> example
>>>>
>>>>> <> the provided mod-sequence is too old? Can the server just return
>>>>> all UIDs not in the UID set? This can generate additional traffic,
>>>>
>>>>> but should be Ok otherwise.>>
>>>>>          
>>>>>
>...
>  
>
>>>I see two options ...
>>>1) An unsolicited * SEARCH 
>>>2) A response code that tells the client to use UID SEARCH 1:*
>>>
>>>In either case the client knows.
>>>      
>>>
>>My comment is trying to say that the server MUST always 
>>return expunged 
>>messages, if it doesn't remember which messages got expunged 
>>since the 
>>specified modification sequence, it should return ALL 
>>messages expunged 
>>(but only for UID set the specified in the UID FETCH (REPORTEXPUNGES).
>>    
>>
>
>The most common use case will be 1:*. In this case you will send 
>back a response with every UID expunged since the UIDVALIDITY value was 
>created (I understand you have range syntax). This makes no sense to
>me.
>
>I think a better choice would be:
>C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
>S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
>S: 1 OK FETCH Complete
>
>The NO response with a UIDEXPUNGE response code would then 
>communicate to the client to resort to SEARCH.
>
And the client will perform "UID SEARCH 1:*"? But this would give the 
same result as the server returning all expunges. Actually, it would be 
worse, because SEARCH can't use ranges.

In many cases just sending all expunged messages would be faster than 
forcing a round trip on the client.
I also suspect that the list of expunges messages will compress nicely 
using ranges.

Date: Thu, 03 Feb 2005 19:19:26 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>, "[email-masked]" <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

Dave Cridland wrote:

>> I see no point for the client to violate the MUST, that is why I've 
>> used upper case MUST. (please, prove me wrong with an example).
>> The client can do many other stupid things and I don't want to 
>> encourage them.
>
>
> Well... I can't think of an example. But I can't think of a case where 
> it would hurt, either.
>
> I think I'd write SHOULD NOT here, because even if a client does, it's 
> certainly not harming interoperability by doing so, it's just being 
> dumb. Clients SHOULD NOT be badly written, certainly, but to state 
> that IMAP clients MUST NOT be badly written would mean that many 
> existing clients would be technically broken... 

and
[email-masked] wrote:

>>I see no point for the client to violate the MUST, that is 
>>why I've used upper case MUST. (please, prove me wrong with an example).
>>    
>>
>
>Prove what? This is not a case for proof. The client does not 
>have to perform the operation you just mentioned and it can 
>still be a compliant client. It would be less efficient, hence
>it should.
>  
>
Fine, I will change MUST NOT to SHOULD NOT.

The whole section is informative. Except for "MUST clear cache if 
UIDVALIDITY changes" everything else is not required for compliance. So 
maybe I shouldn't use uppercase words in this section.

Alexey

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 3 Feb 2005 12:58:06 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, February 03, 2005 10:14 AM
...
> >>> <> <<What if the server can?t remember some expunged 
> UIDs, for example
> >>
> >>>  the provided mod-sequence is too old? Can the server just return
> >>>  all UIDs not in the UID set? This can generate 
> additional traffic,
> >>>  but should be Ok otherwise.>>
...
> >I see two options ...
> >1) An unsolicited * SEARCH 
> >2) A response code that tells the client to use UID SEARCH 1:*
> >
> >In either case the client knows.
> >
> My comment is trying to say that the server MUST always 
> return expunged 
> messages, if it doesn't remember which messages got expunged 
> since the 
> specified modification sequence, it should return ALL 
> messages expunged 
> (but only for UID set the specified in the UID FETCH (REPORTEXPUNGES).

The most common use case will be 1:*. In this case you will send 
back a response with every UID expunged since the UIDVALIDITY value was 
created (I understand you have range syntax). This makes no sense to
me.

I think a better choice would be:
C: 1 UID FETCH 1:* (CHANGEDSINCE MMMMM REPORTEXPUNGES)
S: * NO [UIDEXPUNGE] Server has lost track of expunged MODSEQ values
S: 1 OK FETCH Complete

The NO response with a UIDEXPUNGE response code would then 
communicate to the client to resort to SEARCH.

> 
> >>> <> " ... HIGHESTMODSEQ with the one returned by the 
> server. If the 
> >>> cached
> >>
> >>>  HIGHESTMODSEQ value also matches the one returned by the server,
> >>>  then the client MUST NOT fetch flags for cached messages, as they
> >>>  hasn't changed. "
> >>>
> >>>Shouldn't this be "SHOULD NOT".
> >>>      
> >>>
> >>This is an informative section, so I should probably 
> >>lowercase the term.    
> >>
> >
> >Informative or not the client does not have to perform this 
> >behavior hence it seems it should be "should".
> >  
> >
> I see no point for the client to violate the MUST, that is 
> why I've used 
> upper case MUST. (please, prove me wrong with an example).

Prove what? This is not a case for proof. The client does not 
have to perform the operation you just mentioned and it can 
still be a compliant client. It would be less efficient, hence
it should.

> The client can do many other stupid things and I don't want 
> to encourage 
> them.

Except for anarchists and teenagers, I know of no one that 
would claim that the statement, "You should not do X", encourages 
them to do X.

Mike

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 03 Feb 2005 15:42:48 +0000
Sender: [email-masked]

On Thu Feb  3 15:13:49 2005, Alexey Melnikov wrote:
> 
> [Let's have this discussion on IMAPEXT only].
> 

Reply-list curtailed...

> [email-masked] wrote:
> 
>>>> <> <<What if the server can?t remember some expunged UIDs, for example
>>> 
>>>>  the provided mod-sequence is too old? Can the server just return
>>>>  all UIDs not in the UID set? This can generate additional traffic,
>>>>  but should be Ok otherwise.>>
>>>>      
>> ...
>>  
>>> Client doesn't know and need not know. I think this is a server only issue.    
>> 
>> I guess I need to see what you mean by "Can the server just return
>> all UIDs not in the UID set?"
>> 
>> The client has to know that something is amiss on the server. It is not getting an expunge. A fetch response is only supposed to be returned subject to the CHANGEDSINCE modifier.
>> 
>> I see two options ...
>> 1) An unsolicited * SEARCH 2) A response code that tells the client to use UID SEARCH 1:*
>> 
>> In either case the client knows.
>> 
> My comment is trying to say that the server MUST always return expunged messages, if it doesn't remember which messages got expunged since the specified modification sequence, it should return ALL messages expunged (but only for UID set the specified in the UID FETCH (REPORTEXPUNGES).
> 
> So, the client doesn't really need to know whether the server remembers or not. The client should be able to handle duplicate expunge notifications anyway.
> 

The client can always tell if the server doesn't remember. It's a simple case of using UIDNEXT and EXISTS responses during the SELECT, and rechecking after expunges have been requested off the server.

I'd rather have the client fallback to older methods itself if it detirmines that it still doesn't have the list of all EXPUNGEs, and the client, in general, has more information than the server on this matter.

> 
>>>> <> " ... HIGHESTMODSEQ with the one returned by the server. If the cached
>>> 
>>>>  HIGHESTMODSEQ value also matches the one returned by the server,
>>>>  then the client MUST NOT fetch flags for cached messages, as they
>>>>  hasn't changed. "
>>>> 
>>>> Shouldn't this be "SHOULD NOT".
>>>>      
>>> This is an informative section, so I should probably lowercase the term.    
>> 
>> Informative or not the client does not have to perform this behavior hence it seems it should be "should".
>>  
> I see no point for the client to violate the MUST, that is why I've used upper case MUST. (please, prove me wrong with an example).
> The client can do many other stupid things and I don't want to encourage them.
> 

Well... I can't think of an example. But I can't think of a case where it would hurt, either.

I think I'd write SHOULD NOT here, because even if a client does, it's certainly not harming interoperability by doing so, it's just being dumb. Clients SHOULD NOT be badly written, certainly, but to state that IMAP clients MUST NOT be badly written would mean that many existing clients would be technically broken...

Dave.

Date: Thu, 03 Feb 2005 15:13:49 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[Let's have this discussion on IMAPEXT only].

Answering the second part of your message.

[email-masked] wrote:

>>> <> <<What if the server can?t remember some expunged UIDs, for example
>>
>>>  the provided mod-sequence is too old? Can the server just return
>>>  all UIDs not in the UID set? This can generate additional traffic,
>>>  but should be Ok otherwise.>>
>>>      
>>>
>...
>  
>
>>Client doesn't know and need not know. I think this is a 
>>server only issue.    
>>
>
>I guess I need to see what you mean by "Can the server just return
>all UIDs not in the UID set?"
>
>The client has to know that something is amiss on the server. It is 
>not getting an expunge. A fetch response is only supposed to be 
>returned subject to the CHANGEDSINCE modifier.
>
>I see two options ...
>1) An unsolicited * SEARCH 
>2) A response code that tells the client to use UID SEARCH 1:*
>
>In either case the client knows.
>
My comment is trying to say that the server MUST always return expunged 
messages, if it doesn't remember which messages got expunged since the 
specified modification sequence, it should return ALL messages expunged 
(but only for UID set the specified in the UID FETCH (REPORTEXPUNGES).

So, the client doesn't really need to know whether the server remembers 
or not. The client should be able to handle duplicate expunge 
notifications anyway.

>>> <> " ... HIGHESTMODSEQ with the one returned by the server. If the 
>>> cached
>>
>>>  HIGHESTMODSEQ value also matches the one returned by the server,
>>>  then the client MUST NOT fetch flags for cached messages, as they
>>>  hasn't changed. "
>>>
>>>Shouldn't this be "SHOULD NOT".
>>>      
>>>
>>This is an informative section, so I should probably 
>>lowercase the term.    
>>
>
>Informative or not the client does not have to perform this 
>behavior hence it seems it should be "should".
>  
>
I see no point for the client to violate the MUST, that is why I've used 
upper case MUST. (please, prove me wrong with an example).
The client can do many other stupid things and I don't want to encourage 
them.

content-class: urn:content-classes:message
Subject: RE: Comments on draft-melnikov-imap-expunged-00
Date: Thu, 3 Feb 2005 06:59:44 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext 
> Alexey Melnikov
> Sent: Wednesday, February 02, 2005 5:18 PM
...
> >Sec 3.3
> >   <<alternative #1: extend syntax for the CHANGEDSINCE FETCH
> >   modifier.
> >
> >Why even have the keyword REPORTEXPUNGES? Why not just overload
> >CHANGEDSINCE to imply expunges? 
> >  
> >
> Sending expunge information to the client who hasn't asked for it 
> doesn't sound right, even though any client should be able to ignore 
> such information.
> 
> If we choose to replace CONDSTORE, there would be no REPORTEXPUNGES.

If it does not sound right in draft-melnikov-imap-expunged-00 why
would it be okay in CONDSTORE?

> 
> >   <<What if the server can?t remember some expunged UIDs, 
> for example
> >   the provided mod-sequence is too old? Can the server just return
> >   all UIDs not in the UID set? This can generate additional traffic,
> >   but should be Ok otherwise.>>
> >
...
> Client doesn't know and need not know. I think this is a 
> server only issue.

I guess I need to see what you mean by "Can the server just return
all UIDs not in the UID set?"

The client has to know that something is amiss on the server. It is 
not getting an expunge. A fetch response is only supposed to be 
returned subject to the CHANGEDSINCE modifier.

I see two options ...
1) An unsolicited * SEARCH 
2) A response code that tells the client to use UID SEARCH 1:*

In either case the client knows.

> >
> >   " ... HIGHESTMODSEQ with the one returned by the server. 
> If the cached
> >   HIGHESTMODSEQ value also matches the one returned by the server,
> >   then the client MUST NOT fetch flags for cached messages, as they
> >   hasn't changed. "
> >
> >Shouldn't this be "SHOULD NOT".
> >
> This is an informative section, so I should probably 
> lowercase the term.

Informative or not the client does not have to perform this 
behavior hence it seems it should be "should".

Mike

Date: Wed, 02 Feb 2005 22:17:59 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Comments on draft-melnikov-imap-expunged-00
Sender: [email-masked]

[email-masked] wrote:

>Sec 3.3
>   <<alternative #1: extend syntax for the CHANGEDSINCE FETCH
>   modifier.
>
>Why even have the keyword REPORTEXPUNGES? Why not just overload
>CHANGEDSINCE to imply expunges? 
>  
>
Sending expunge information to the client who hasn't asked for it 
doesn't sound right, even though any client should be able to ignore 
such information.

If we choose to replace CONDSTORE, there would be no REPORTEXPUNGES.

>   <<What if the server can?t remember some expunged UIDs, for example
>   the provided mod-sequence is too old? Can the server just return
>   all UIDs not in the UID set? This can generate additional traffic,
>   but should be Ok otherwise.>>
>
>How does the client know when there are forgotten expunges? In this case
>the client must use the conventional approach to determining expunged 
>mail, which is okay, it just needs to know when to do it.
>  
>
Client doesn't know and need not know. I think this is a server only issue.

>Sec 3.5
>
>   <<Add CHANGEDSINCE SELECT/EXAMINE parameter?>>
>
>I assume this is an orthogonal item that was just missed in the original
>CONDSTORE?
>
Yes, you are right.

> What is it? It is kind of weird to include this in an Expunge 
>doc. Maybe this doc should be CONDSTOREPLUS. ;-)
>
>Sec 4
>
>   " ... HIGHESTMODSEQ with the one returned by the server. If the cached
>   HIGHESTMODSEQ value also matches the one returned by the server,
>   then the client MUST NOT fetch flags for cached messages, as they
>   hasn't changed. "
>
>Shouldn't this be "SHOULD NOT".
>
This is an informative section, so I should probably lowercase the term.

>Also, "hasn't" should be "haven't"
>  
>
Thank you for the comments!

Alexey

Date: Wed, 02 Feb 2005 20:28:10 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: expunged draft
Sender: [email-masked]

[email-masked] wrote:

>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]]On Behalf Of ext Timo Sirainen
>>Sent: Monday, January 31, 2005 3:52 PM
>>    
>>
>...
>  
>
>>It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What
>>about when other session did the EXPUNGE and we're seeing untagged
>>EXPUNGEs? Maybe always send it after untagged expunges (and don't
>>mention EXPUNGE command at all)?
>>    
>>
>...
>  
>
>>Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it 
>>more clear
>>that it's sending UIDs and not sequences?
>>    
>>
>
>What about something like ...
>
>* EXPUNGE (UID N MODSEQ (MMMM))
>  
>
Dave Cridland has suggested something similar during a private conversation.

>This would disambiguate nicely ...
>1) Covers unsolicited as well as untagged solicited EXPUNGE responses.
>2) The parenthetical element is just a subset of a FETCH response, meaning I
>see some nice code reuse potential.
>  
>
I am not sure the parsing code is going to be as big so it can benefit 
from code reuse.

I will change the draft to have something like:

* UIDEXPUNGE 1:5,7,505 (MODSEQ MMMM)

I.e., it will contain UID set and modification sequence at the end.

Date: Wed, 02 Feb 2005 20:23:14 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: expunged draft
Sender: [email-masked]

[email-masked] wrote:

>>> <>Servers supporting UNSELECT should most likely also send HIGHESTMODSEQ
>>
>>>just as with CLOSE, but this isn't mentioned.
>>>      
>>>
>>UNSELECT doesn't cause any message to be expunged.
>>    
>>
>>>And what about with
>>>SELECT?
>>>      
>>>
>>Same as above.
>>    
>>
>
>SELECT will generate a HIGHESTMODSEQ as per CONDSTORE
>even if the SELECT is from the selected state. No?
>  
>
Yes, it will.
SELECT from a selected state doesn't cause expunge, so nothing should be 
sent for the mailbox that is being closed.

>A CLOSE is generating a HIGHESTMODSEQ response code relative
>to the *closed* mailbox, whereas the SELECT is generating a 
>HIGHESTMODSEQ response code relative to the opened mailbox.
>This is an important, albeit subtle, distinction. Correct?
>  
>
Yes.

content-class: urn:content-classes:message
Subject: RE: ANNOTATEMORE
Date: Wed, 2 Feb 2005 14:01:30 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: ext Lisa Dusseault [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2005 2:45 PM
...
>   2.  The ANNOTATE draft currently has at least one open issue, 
> described in the notes from the interim meeting as needing "Text to 
> describe behavior of unsolicited responses -- that you only get the 
> annotation names and not the values back (unless the client goes to 
> actually get the values)"
>    --> can you give us your opinion, does this resolve the 
> open issues 
> currently in ANNOTATE?

If I'm not mistaken this was instigated by my comments on 
ANNOTATEMORE. I'll review the next draft version.

>   3.  Let the WG know that you've reviewed ANNOTATEMORE and 
> what issues 
> were found

I did see ...

http://www.imc.org/ietf-imapext/mail-archive/msg02264.html

... And of course the exchange with Cyrus.

Thanks,
Mike

Date: Wed, 02 Feb 2005 14:51:31 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: ANNOTATEMORE
Sender: [email-masked]

Hi Lisa,

--On Wednesday, February 02, 2005 11:44 -0800 Lisa Dusseault 
<[email-masked]> wrote:

> Randy and Cyrus owe us a new draft of ANNOTATE (which is the one you
> should review) -- it was promised Monday.  Randy, Cyrus, you're now
> behind!

Its in my queue and being worked on...

-- 
Cyrus Daboo

Cc: <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: ANNOTATEMORE
Date: Wed, 2 Feb 2005 11:44:52 -0800
To: <[email-masked]>
Sender: [email-masked]

Hi Michael,

There are a couple places where your help would be very welcome in 
moving this draft forward.
  1.  This draft relies on the ANNOTATE draft. Can you review that in 
last call and notify the group that you've done a review (and what 
issues found)
  2.  The ANNOTATE draft currently has at least one open issue, 
described in the notes from the interim meeting as needing "Text to 
describe behavior of unsolicited responses -- that you only get the 
annotation names and not the values back (unless the client goes to 
actually get the values)"
   --> can you give us your opinion, does this resolve the open issues 
currently in ANNOTATE?
  3.  Let the WG know that you've reviewed ANNOTATEMORE and what issues 
were found

Randy and Cyrus owe us a new draft of ANNOTATE (which is the one you 
should review) -- it was promised Monday.  Randy, Cyrus, you're now 
behind!

Lisa

On Feb 2, 2005, at 10:44 AM, <[email-masked]> wrote:

>
> I would like to see this draft move forward.
>
> Mike
>

content-class: urn:content-classes:message
Subject: Comments on draft-melnikov-imap-expunged-00
Date: Wed, 2 Feb 2005 13:13:19 -0600
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Sec 3.3
   <<alternative #1: extend syntax for the CHANGEDSINCE FETCH
   modifier.

Why even have the keyword REPORTEXPUNGES? Why not just overload
CHANGEDSINCE to imply expunges? 

   <<What if the server can?t remember some expunged UIDs, for example
   the provided mod-sequence is too old? Can the server just return
   all UIDs not in the UID set? This can generate additional traffic,
   but should be Ok otherwise.>>

How does the client know when there are forgotten expunges? In this case
the client must use the conventional approach to determining expunged 
mail, which is okay, it just needs to know when to do it.

Sec 3.5

   <<Add CHANGEDSINCE SELECT/EXAMINE parameter?>>

I assume this is an orthogonal item that was just missed in the original
CONDSTORE? What is it? It is kind of weird to include this in an Expunge 
doc. Maybe this doc should be CONDSTOREPLUS. ;-)

Sec 4

   " ... HIGHESTMODSEQ with the one returned by the server. If the cached
   HIGHESTMODSEQ value also matches the one returned by the server,
   then the client MUST NOT fetch flags for cached messages, as they
   hasn't changed. "

Shouldn't this be "SHOULD NOT". Also, "hasn't" should be "haven't"

Mike

content-class: urn:content-classes:message
Subject: RE: expunged draft
Date: Wed, 2 Feb 2005 13:00:56 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> >Servers supporting UNSELECT should most likely also send 
> HIGHESTMODSEQ
> >just as with CLOSE, but this isn't mentioned.
> >
> UNSELECT doesn't cause any message to be expunged.
> 
> > And what about with
> >SELECT?
> >
> Same as above.

SELECT will generate a HIGHESTMODSEQ as per CONDSTORE
even if the SELECT is from the selected state. No?

A CLOSE is generating a HIGHESTMODSEQ response code relative
to the *closed* mailbox, whereas the SELECT is generating a 
HIGHESTMODSEQ response code relative to the opened mailbox.
This is an important, albeit subtle, distinction. Correct?

Mike

content-class: urn:content-classes:message
Subject: RE: expunged draft
Date: Wed, 2 Feb 2005 12:44:33 -0600
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of ext Timo Sirainen
> Sent: Monday, January 31, 2005 3:52 PM
...
> 
> It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What
> about when other session did the EXPUNGE and we're seeing untagged
> EXPUNGEs? Maybe always send it after untagged expunges (and don't
> mention EXPUNGE command at all)?
...
> Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it 
> more clear
> that it's sending UIDs and not sequences?

What about something like ...

* EXPUNGE (UID N MODSEQ (MMMM))

This would disambiguate nicely ...
1) Covers unsolicited as well as untagged solicited EXPUNGE responses.
2) The parenthetical element is just a subset of a FETCH response, meaning I
see some nice code reuse potential.

Mike

content-class: urn:content-classes:message
Subject: ANNOTATEMORE
Date: Wed, 2 Feb 2005 12:44:40 -0600
From: <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I would like to see this draft move forward.

Mike

Date: Tue, 01 Feb 2005 16:58:47 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Sender: [email-masked]

Dave Cridland wrote:

>>> Finally, I'm not sure how good 64-bit arithmetic is under some 
>>> environments - I'm actually developing under Python on a 64-bit 
>>> system, which is probably a recipe for non-portability when I forget 
>>> to use long() rather than int(), but it has the 64-bit support, at 
>>> least, and most C and C++ compilers support some 64-bit unsigned 
>>> integer, but I'm not so sure about Perl, Java, etc. I'd not object 
>>> to the MODSEQ being a string, since this is easily compared, and has 
>>> precedence in ACAP (with the "modtime" attribute).
>>
>> This is a reasonable way to implement this, this doesn't change the 
>> CONDSTORE document. If one client can't operate on 64bit integer, it 
>> can treat modification sequences as strings instead.
>
> No, because "3" is greater than "20050201163759003", treated as strings.

I didn't say that one need to use lexicographical comparison ;-).

> I'm not calling this a showstopper, by any stretch. I just don't know 
> what the state of 64-bit support *is* in all languages.

IMHO, having a pair of 32bit integers is no brainer.

> I've got it in all languages I develop in, though.
>
>>> 3) LISTEXT
>>>
>>> I've not yet implemented this, however, I was thinking of 
>>> implementing this, ACL2, and MAILBOX-REFERRALS at the same time. In 
>>> particular, I have noticed that LIST (REMOTE) could reasonably 
>>> provide the REFERRAL URIs in an extended LIST item, in order to save 
>>> clients from having to SELECT the mailbox to discover it. This 
>>> SELECT  generates an additional round-trip, of course, and I feel 
>>> overloads SELECT's meaning as well.
>>>
>>> In addition, this renders the \Remote mailbox flag redundant, of 
>>> course.
>>
>> I agree with your LISTEXT comments.
>
> Well, Rob suggested that there'd been a discussed decision the other 
> way on that,

I don't remember any consensus, but I don't remember consensus not to do 
what you've suggested either.

> and I'm happy enough to go with any considered opinion of the group, 
> so I've implemented things that way. (Actually using SELECT to 
> generate the referral, too).

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Date: Tue, 01 Feb 2005 16:49:42 +0000
Sender: [email-masked]

On Tue Feb  1 13:02:46 2005, Alexey Melnikov wrote:
> Dave Cridland wrote:
>> Given that, in the case where we simply don't know whether a right is supported or not, we want to assume it's granted, is this a reasonable assumption, or should I assume the 'x' right is *always* granted (which is effectively what existing clients do anyway)?
> 
> I think doing this either way is fine.
> 

It now assumes it's always granted, unless \NoSelect is also present, or if it appears to be a namespace prefix. Looking at server implementations, this appears reasonably safe.

> 
>> Incidentally, I've not yet thought of any other problems with a RIGHTS aware client talking to a plain ACL server, but I've not yet done ACL editing, where I suspect that the 'x' right will rear its ugly head again.
>> 
>> Nothing I've found so far appears to be a showstopper, but it might be beneficial to client authors to have some idea of handling legacy support for older servers (ie, all current ones) covered in the RFC.
> 
> Do you have any suggestions?
> 

Other than stating that the missing 'x' right on an RFC2086 server should always be considered granted, not really. I'm not intending ACL manipulation any time soon - unfortunately I just don't have the time - but as I say, I think that might shake out a few cross-compatibility issues.

In any case, given the level of ACL support in clients currently, I strongly suspect that giving any advice would be largely wasted ink.

> 
>> 2) CONDSTORE
>> 
>> This seems remarkably straightforward to implement, although again I've no real implementation to test against. I do, however, forsee some problems when dealing with ANNOTATE in addition, since I'm a little unclear on whether the sequence:
>> 
>> C1: a01 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv"))
>> S1: * 1 FETCH (MODSEQ (1) FLAGS (\Seen) ANNOTATION ("/comment" ("value.priv" "My comment")))
>> S1: a01 OK
>> C2: a02 STORE 1 +FLAGS (\Answered)
>> S2: * 1 FETCH (MODSEQ (2) FLAGS (\Seen \Answered))
>> S2: a02 OK
>> C1: a03 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv")) (CHANGEDSINCE 1)
>> S1: * FETCH ...
>> S1: a03 OK
>> 
>> ... should return the comment (which is unchanged) or just the flags (which is changed).
>> 
>> My reading of 3.3.1 suggests that the comment will be returned as well, even though it hasn't changed, because CHANGEDSINCE affects message selection, rather than metadata items returned.
> 
> The original design was to allow the server to only return changed metadata items, if the server has this information.
> 

Ah... 3.3.1 seems to disagree with you.

> 
> I am not sure if this has to be clarified in the document (probably yes) and if this behavior breaks clients that always expect all metadata to be returned. IMHO, client should cache all data sent to it, so this shouldn't be a problem.
> 

In the original design of IMAP, a server wasn't even mandated to resend information within the same SELECT session, as I understand things. Hence I've always assumed that a client should never discard data within a single SELECT session, even though these days the server has to do what it's told.

But yes, I would assume that clients would, if they didn't have the annotation, fetch it unconditionally seperately.

> 
> On a second thought: if you omit the first FETCH (with tag a01), the client will not have this information cached and will be forced to fetch it unconditionally, if it doesn't get it in the 3rd FETCH.
> 

If you discard a01, then the client would also emit an a04, hopefully pipelined, which would be an unconditional fetch of the annotation.

>> My second issue is that an extended EXPUNGE would be useful, allowing me to "EXPUNGE (UNCHANGEDSINCE 1)" to permanently remove all messages flagged as \Deleted which haven't been altered [presumably] without my knowledge.
> 
> So if somebody has added \Seen flag to a \Deleted message (or add an annotation), that would prevent the message from being expunged?
> 

The \Seen case is a little draconian I'll admit, but the annotation case isn't - if someone has seen fit to annotate a \Deleted message, one assumes it's important enough not to expunge without knowing what the annotation was.

>> Finally, I'm not sure how good 64-bit arithmetic is under some environments - I'm actually developing under Python on a 64-bit system, which is probably a recipe for non-portability when I forget to use long() rather than int(), but it has the 64-bit support, at least, and most C and C++ compilers support some 64-bit unsigned integer, but I'm not so sure about Perl, Java, etc. I'd not object to the MODSEQ being a string, since this is easily compared, and has precedence in ACAP (with the "modtime" attribute).
> 
> This is a reasonable way to implement this, this doesn't change the CONDSTORE document. If one client can't operate on 64bit integer, it can treat modification sequences as strings instead.
> 

No, because "3" is greater than "20050201163759003", treated as strings. I'm not calling this a showstopper, by any stretch. I just don't know what the state of 64-bit support *is* in all languages. I've got it in all languages I develop in, though.

> 
>> 3) LISTEXT
>> 
>> I've not yet implemented this, however, I was thinking of implementing this, ACL2, and MAILBOX-REFERRALS at the same time. In particular, I have noticed that LIST (REMOTE) could reasonably provide the REFERRAL URIs in an extended LIST item, in order to save clients from having to SELECT the mailbox to discover it. This SELECT  generates an additional round-trip, of course, and I feel overloads SELECT's meaning as well.
>> 
>> In addition, this renders the \Remote mailbox flag redundant, of course.
> 
> I agree with your LISTEXT comments.
> 

Well, Rob suggested that there'd been a discussed decision the other way on that, and I'm happy enough to go with any considered opinion of the group, so I've implemented things that way. (Actually using SELECT to generate the referral, too).

Dave.

Date: Tue, 01 Feb 2005 13:02:46 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: RIGHTS=kxet, CONDSTORE, implementation
Sender: [email-masked]

Dave Cridland wrote:

> Hiya folks,
>
> I've been on a client-side implementation frenzy, and thought I'd 
> share my experiences. I've no access to any server implementation of 
> any of these - an account on such a server would be greatly 
> appreciated. In particular, I'd like CONDSTORE, ANNOTATE, and LISTEXT 
> - the RIGHTS stuff, while interesting, is more interesting in as much 
> as how to cope without it.
>
> My strategy, incidentally, is to emulate unsupported extensions 
> wherever possible.
>
> The client is written in Python, using the wxPython GUI toolkit, and 
> should run on Windows, UNIX, and Mac OS X. It does require an account 
> on a reasonably full ACAP server implementation, but this does give it 
> full roaming and kiosk-mode ability. I'm quite happy to provide the 
> source under GPL, and/or an ACAP account.
>
> 1) RIGHTS
>
> I've been gradually implementing ACL support, and I've attempted to do 
> so by emulating the 'kxet' rights where not supported. (This means 
> anywhere, since I don't have access to a server implementation 
> supporting RIGHTS). I'm making the rash assumption that this is a sane 
> way of writing a RFC2086upd client. (I've not yet made it emulate 
> rights based on the READ-ONLY/READ-WRITE response code where no ACL 
> support at all is available, but I will.)
>
> I've found that trying to emulate the 'x' right is particularly 
> tricky, since I can only assume:
>
> 'd' => 'et'
> 'c' => 'k'
>
> So I'm currently assuming the 'x' right is always granted where 'c' or 
> 'd' is granted. (Obviously the client copes with the case where the 
> DELETE fails anyway.)
>
> Given that, in the case where we simply don't know whether a right is 
> supported or not, we want to assume it's granted, is this a reasonable 
> assumption, or should I assume the 'x' right is *always* granted 
> (which is effectively what existing clients do anyway)?

I think doing this either way is fine.

> Incidentally, I've not yet thought of any other problems with a RIGHTS 
> aware client talking to a plain ACL server, but I've not yet done ACL 
> editing, where I suspect that the 'x' right will rear its ugly head 
> again.
>
> Nothing I've found so far appears to be a showstopper, but it might be 
> beneficial to client authors to have some idea of handling legacy 
> support for older servers (ie, all current ones) covered in the RFC.

Do you have any suggestions?

> 2) CONDSTORE
>
> This seems remarkably straightforward to implement, although again 
> I've no real implementation to test against. I do, however, forsee 
> some problems when dealing with ANNOTATE in addition, since I'm a 
> little unclear on whether the sequence:
>
> C1: a01 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv"))
> S1: * 1 FETCH (MODSEQ (1) FLAGS (\Seen) ANNOTATION ("/comment" 
> ("value.priv" "My comment")))
> S1: a01 OK
> C2: a02 STORE 1 +FLAGS (\Answered)
> S2: * 1 FETCH (MODSEQ (2) FLAGS (\Seen \Answered))
> S2: a02 OK
> C1: a03 FETCH 1 (FLAGS ANNOTATION ("/comment" "value.priv")) 
> (CHANGEDSINCE 1)
> S1: * FETCH ...
> S1: a03 OK
>
> ... should return the comment (which is unchanged) or just the flags 
> (which is changed).
>
> My reading of 3.3.1 suggests that the comment will be returned as 
> well, even though it hasn't changed, because CHANGEDSINCE affects 
> message selection, rather than metadata items returned.

The original design was to allow the server to only return changed 
metadata items, if the server has this information.

I am not sure if this has to be clarified in the document (probably yes) 
and if this behavior breaks clients that always expect all metadata to 
be returned. IMHO, client should cache all data sent to it, so this 
shouldn't be a problem.

On a second thought: if you omit the first FETCH (with tag a01), the 
client will not have this information cached and will be forced to fetch 
it unconditionally, if it doesn't get it in the 3rd FETCH.

> Changing this, such that CHANGEDSINCE simply suppressed items that 
> haven't changed (excepting UID) would make more sense to me. I can of 
> course do this by issuing multiple pipelined fetches, one for every 
> item, in effect, which I have to do for items I don't have cached at 
> all. (Currently, in fact, I re-fetch the FLAGS unconditionally if I'm 
> fetching anything else, since the additional cost of the data returned 
> is less than the cost of asking for it seperately, but this changes 
> with ANNOTATE).
>
> My second issue is that an extended EXPUNGE would be useful, allowing 
> me to "EXPUNGE (UNCHANGEDSINCE 1)" to permanently remove all messages 
> flagged as \Deleted which haven't been altered [presumably] without my 
> knowledge.

So if somebody has added \Seen flag to a \Deleted message (or add an 
annotation), that would prevent the message from being expunged?

> Similarly, an extended UID EXPUNGE would be useful, too. Given that 
> EXPUNGing the wrong messages is irreparable damage, that seems a 
> sensible addition if it can be implemented, which I assume it can be 
> with the same effort as FETCH (CHANGEDSINCE ...).
>
> Finally, I'm not sure how good 64-bit arithmetic is under some 
> environments - I'm actually developing under Python on a 64-bit 
> system, which is probably a recipe for non-portability when I forget 
> to use long() rather than int(), but it has the 64-bit support, at 
> least, and most C and C++ compilers support some 64-bit unsigned 
> integer, but I'm not so sure about Perl, Java, etc. I'd not object to 
> the MODSEQ being a string, since this is easily compared, and has 
> precedence in ACAP (with the "modtime" attribute).

This is a reasonable way to implement this, this doesn't change the 
CONDSTORE document. If one client can't operate on 64bit integer, it can 
treat modification sequences as strings instead.

> 3) LISTEXT
>
> I've not yet implemented this, however, I was thinking of implementing 
> this, ACL2, and MAILBOX-REFERRALS at the same time. In particular, I 
> have noticed that LIST (REMOTE) could reasonably provide the REFERRAL 
> URIs in an extended LIST item, in order to save clients from having to 
> SELECT the mailbox to discover it. This SELECT  generates an 
> additional round-trip, of course, and I feel overloads SELECT's 
> meaning as well.
>
> In addition, this renders the \Remote mailbox flag redundant, of course.

I agree with your LISTEXT comments.

Alexey

Date: Tue, 01 Feb 2005 11:27:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: expunged draft
Sender: [email-masked]

Timo Sirainen wrote:

>On Mon, 2005-01-31 at 18:44 +0000, Alexey Melnikov wrote:
>  
>
>>I've just submitted a new draft that describes how CONDSTORE 
>>modification sequences can be used to track expunged messages. Before it 
>>is announced, people can find it at:
>>http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt
>>
>>I will welcome all suggestions, especially on issues marked with <<>> in 
>>the document.
>>    
>>
>
>It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What
>about when other session did the EXPUNGE and we're seeing untagged
>EXPUNGEs? Maybe always send it after untagged expunges (and don't
>mention EXPUNGE command at all)?
>  
>
Yes, that was the idea.

>Servers supporting UNSELECT should most likely also send HIGHESTMODSEQ
>just as with CLOSE, but this isn't mentioned.
>
UNSELECT doesn't cause any message to be expunged.

> And what about with
>SELECT?
>
Same as above.

> Maybe just point out more generally that "when using a command
>which closes the mailbox, send HIGHESTMODSEQ". Perhaps LOGOUT should do
>that too?
>  
>
Remember, that the CONDSTORE extension requires the server to send 
mod-sequences for flag changes (using MODSEQ FETCH data items) and 
whenever a message is appended. The EXPUNGED document extends this to 
cover expunges. So there is no point to send HIGHESTMODSEQ when nothing 
has changed, this should cover LOGOUT, SELECT and UNSELECT.
Of course, if messages got expunged in another session, the server still 
needs to send HIGHESTMODSEQ.

>   <<What if the server can¢t remember some expunged UIDs, for example
>   the provided mod-sequence is too old? Can the server just return
>   all UIDs not in the UID set? This can generate additional traffic,
>   but should be Ok otherwise.>>
>
>Yes, I think so.
>
>In 3.4 EXPUNGED Response it seems rather useless trying to rewrite what
>RFC3501 says about EXPUNGEs. Just point out that it works exactly as
>normal untagged EXPUNGE? It would be really bad if they accidentally got
>different rules.
>  
>
As EXPUNGED returns a list of UIDs, I was wondering if it should obey 
the same rule as EXPUNGE, i.e. whether it should be allowed during 
regular FETCH/STORE.

>Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it more clear
>that it's sending UIDs and not sequences?
>  
>
Sure.

Date: Tue, 01 Feb 2005 11:18:02 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Planning for meeting in Minneapolis
Sender: [email-masked]

Lisa Dusseault wrote:

> So, does this mean that we don't need to yank CondStore out of the RFC 
> queue?

The answer to your question depends on what people think about the 
document. There are several places marked with <<>> that can be made 
cleaner (e.g. REPORTEXPUNGES) if there is a single extension.
So, I would encourage people to do a review and we can discuss in a few 
weeks.

> thanks,
> Lisa
>
> On Jan 31, 2005, at 10:44 AM, Alexey Melnikov wrote:
>
>> Lisa Dusseault wrote:
>>
>>> Alexey needs to propose what changes to make to CondStore, as a 
>>> concrete written proposal to the list.
>>
>> I've just submitted a new draft that describes how CONDSTORE 
>> modification sequences can be used to track expunged messages. Before 
>> it is announced, people can find it at:
>> http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt
>>
>> I will welcome all suggestions, especially on issues marked with <<>> 
>> in the document.
>>
>> I can rework RECONNECT to reference the new document, if people feel 
>> it is a good idea.
>>
>> Alexey
>