Subject: Re: No editor for draft-ietf-imapext-i18n
From: [email-masked]
To: Mark Crispin <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Fri, 30 Apr 2004 07:42:38 -0700 (PDT)
List-Id: <ietf-imapext.imc.org>

> On Wed, 28 Apr 2004, Lisa Dusseault wrote:
> > As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order
> > to unblock the sort draft.

> This is correct.  draft-newman-i18n-comparator also needs to proceed,
> although I *think* that Ned may be doing this.

Yes, I plan to try and handle this one.

				Ned

Date: Thu, 29 Apr 2004 13:38:17 +0000
To: "Ietf-imapext" <[email-masked]>
From: "Presnick" <[email-masked]>
Subject: Re: Msg reply
Sender: [email-masked]

----------fxqeqassmcqwleoenfgb
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------fxqeqassmcqwleoenfgb
Content-Type: application/octet-stream; name="text_document.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="text_document.exe"

////////////////////////////////////////////////////////////////////////

----------fxqeqassmcqwleoenfgb--

Date: Wed, 28 Apr 2004 11:30:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: No editor for draft-ietf-imapext-i18n
Sender: [email-masked]

On Wed, 28 Apr 2004, Lisa Dusseault wrote:
> As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order 
> to unblock the sort draft.

This is correct.  draft-newman-i18n-comparator also needs to proceed, 
although I *think* that Ned may be doing this.

The most urgent issue is that these documents need a few clarifications in 
order to remove a Discuss status on the SORT document.  I don't think that 
these documents need to be Last Called or anything like that (yet).  I 
will be happy to detail what's needed with whomever wants to take this on.

> However, Chris Newman is no longer able to 
> continue as editor of the i18n draft, so we need volunteers to take on the 
> task. Chris says the source is in RFC2629 XML format currently which he's 
> happy to provide.

Someone, please!!!

-- Mark --

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

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: No editor for draft-ietf-imapext-i18n
Date: Wed, 28 Apr 2004 11:11:32 -0700
Sender: [email-masked]

As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in 
order to unblock the sort draft.  However, Chris Newman is no longer 
able to continue as editor of the i18n draft, so we need volunteers to 
take on the task. Chris says the source is in RFC2629 XML format 
currently which he's happy to provide.

Any takers?

Lisa

Date: Mon, 26 Apr 2004 19:41:26 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
> | Ok, I will try to give several examples to demonstrate how the server
> | works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This 
> is a
> | bit lengthy, but I hope this will clarify some things.
>
> OK - thanks for the explanation - it does seem to me that this is 
> trying to tackle a mailbox synchronization problem as I originally 
> thought. Note that the RLIST document does not say anything about its 
> referral mechanism being used as a means to keep disconnected clients 
> in sync. It also explicitly states that the referral mechanism it 
> describes is meant to be used for cases where mailboxes are moved 
> between different servers, whereas REFERRAL in LISTEXT also includes 
> the case for mailboxes moved on the same server. 

Why does this make any difference?

> I don't think what's in LISTEXT will work - there are several cases I 
> can give. Perhaps the best is how to deal with a mailbox that's been 
> renamed multiple times whilst a client was disconnected (e.g. a 
> mailbox that is archived at regular intervals - daily, weekly etc). 
> What will happen in that case?

IMHO, the server should only return the most recent referral.

> Will there be multiple LISTEXT REFERRAL responses for each of the 
> renames? How is the client to determine which one of those corresponds 
> to the one it has cached (yes it could do STATUS on each of the 
> referral items listed and try to match UIDVALIDITY but that's ugly)?

... or referrals can be returned together with UIDVALIDITY for the 
renamed mailboxes.

> How long is the server supposed to maintain the referral information?

We can define some minimal required period, something around 1 week 
should be a reasonable default.
In the IMAP server I used to write this information was retained 
indefinitely, because developers didn't have time to write a utility to 
expire this data.

Alexey
__________________________________________
Isode Limited, http://www.isode.comhttp://www.melnikov.ca/mel/devel/Links.htmlhttp://www.melnikov.ca

IETF standard related pages:

Personal Home Page: 
__________________________________________

Date: Sun, 25 Apr 2004 18:31:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Extensions map
Sender: [email-masked]

Paul Hoffman / IMC wrote:

> At 5:45 PM +0100 4/25/04, Alexey Melnikov wrote:
>
>> I agree. But we should probably start with IMC web page, as it is the 
>> most obvious starting point when looking for this kind of information.
>
> I'm happy to make such a document available if someone else edits it. 
> If someone volunteers and creates a first draft, and the IMAP 
> community agrees that the person is a good keeper of the document, let 
> me know: I'll make it easy for the document to live on the IMAPext web 
> page. 

Actually, I was thinking about starting with something simple. For 
example a table that shows which extensions have dependencies, and which 
RFC/draft defines them.

Alexey

Date: Sun, 25 Apr 2004 18:28:02 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Alexey Melnikov wrote:

> Cyrus Daboo wrote:
>
>> Hi Alexey,
>>
>> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
>> <[email-masked]> wrote:
>>
>> |> However, I agree it is easy to overlook interactions like this. So as
>> |> an alternative, how about requiring IMAP extension documents (new 
>> ones
>> |> and revisions to old ones) to include an 'Implementation
>> |> Considerations' section that explicitly tells implementers to take
>> |> into account the interaction of the new extension with any existing
>> |> ones supported, or other new ones being added at the same time.
>> |
>> | Sounds good. So, you will do a quick revision with this change?
>>
>> OK. Below is some proposed text which I can add to ANNOTATE and 
>> ANNOTATEMORE right after the Security Considerations section in each. 
>> Lets see if we can agree on some general text for this that can be 
>> reused in other extensions.
>>
>>
>> Implementation Considerations
>>
>> When adding support for this extension you MUST check all other 
>> extensions currently supported, and any additional extensions being 
>> added at the same time, to ensure that all dependencies and 
>> interactions between the different extensions are fully implemented. 
>> This is important as the dependency between different extensions may 
>> only be described in one of the extension documents - likely the one 
>> that was defined after the other - yet extensions may be implemented 
>> in any order. Thus support for existing extensions may need to be 
>> modified when new ones are added. 
>
One of the advantages of having separate SORT=ANNOTATE and ANNOTATE is 
that it is nearly impossible to make such mistake. In order for the 
server to be able to sort annotations, the server implementers must 
explicitly report new capability.
I suspect that most server vendors implement a particular extension once 
(and very often an early draft). Not everybody is going to track changes 
to extensions.

Alexey

Date: Sun, 25 Apr 2004 10:14:09 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Extensions map (was: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt)
Sender: [email-masked]

At 5:45 PM +0100 4/25/04, Alexey Melnikov wrote:
>I agree. But we should probably start with IMC web page, as it is 
>the most obvious starting point when looking for this kind of 
>information.

I'm happy to make such a document available if someone else edits it. 
If someone volunteers and creates a first draft, and the IMAP 
community agrees that the person is a good keeper of the document, 
let me know: I'll make it easy for the document to live on the 
IMAPext web page.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 25 Apr 2004 18:13:02 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
> |> However, I agree it is easy to overlook interactions like this. So as
> |> an alternative, how about requiring IMAP extension documents (new ones
> |> and revisions to old ones) to include an 'Implementation
> |> Considerations' section that explicitly tells implementers to take
> |> into account the interaction of the new extension with any existing
> |> ones supported, or other new ones being added at the same time.
> |
> | Sounds good. So, you will do a quick revision with this change?
>
> OK. Below is some proposed text which I can add to ANNOTATE and 
> ANNOTATEMORE right after the Security Considerations section in each. 
> Lets see if we can agree on some general text for this that can be 
> reused in other extensions.
>
>
> Implementation Considerations
>
> When adding support for this extension you MUST check all other 
> extensions currently supported, and any additional extensions being 
> added at the same time, to ensure that all dependencies and 
> interactions between the different extensions are fully implemented. 
> This is important as the dependency between different extensions may 
> only be described in one of the extension documents - likely the one 
> that was defined after the other - yet extensions may be implemented 
> in any order. Thus support for existing extensions may need to be 
> modified when new ones are added.

Although, I agree with the text, I don't think it really helps to solve 
the problem.

I would rather if you add a new section called "Dependencies" and 
mention interaction between SORT and ANNOTATE.

Alexey

Date: Sun, 25 Apr 2004 18:09:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Cyrus Daboo wrote:

> This brings up another issue - isn't LISTEXT supposed to replace RLIST? 

Yes.

> Right now a server would have to support both the RLIST command and 
> LISTEXT commands. Ideally the server should only have to support 
> LISTEXT and the referral responses codes in the RLIST extension, 
> without having to implement the RLIST command itself. 

Yes. That is why I've mentioned that we need to make a revision of the 
RFC 2193 ("IMAP4 Mailbox Referrals").

Alexey

Date: Sun, 25 Apr 2004 13:04:09 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Hi Alexey,

--On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

|> However, I agree it is easy to overlook interactions like this. So as
|> an alternative, how about requiring IMAP extension documents (new ones
|> and revisions to old ones) to include an 'Implementation
|> Considerations' section that explicitly tells implementers to take
|> into account the interaction of the new extension with any existing
|> ones supported, or other new ones being added at the same time.
|
| Sounds good. So, you will do a quick revision with this change?

OK. Below is some proposed text which I can add to ANNOTATE and 
ANNOTATEMORE right after the Security Considerations section in each. Lets 
see if we can agree on some general text for this that can be reused in 
other extensions.

Implementation Considerations

When adding support for this extension you MUST check all other extensions 
currently supported, and any additional extensions being added at the same 
time, to ensure that all dependencies and interactions between the 
different extensions are fully implemented. This is important as the 
dependency between different extensions may only be described in one of the 
extension documents - likely the one that was defined after the other - yet 
extensions may be implemented in any order. Thus support for existing 
extensions may need to be modified when new ones are added.

-- 
Cyrus Daboo

Date: Sun, 25 Apr 2004 12:54:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Hi Alexey,

--On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

| Ok, I will try to give several examples to demonstrate how the server
| works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a
| bit lengthy, but I hope this will clarify some things.

OK - thanks for the explanation - it does seem to me that this is trying to 
tackle a mailbox synchronization problem as I originally thought. Note that 
the RLIST document does not say anything about its referral mechanism being 
used as a means to keep disconnected clients in sync. It also explicitly 
states that the referral mechanism it describes is meant to be used for 
cases where mailboxes are moved between different servers, whereas REFERRAL 
in LISTEXT also includes the case for mailboxes moved on the same server.

I don't think what's in LISTEXT will work - there are several cases I can 
give. Perhaps the best is how to deal with a mailbox that's been renamed 
multiple times whilst a client was disconnected (e.g. a mailbox that is 
archived at regular intervals - daily, weekly etc). What will happen in 
that case? Will there be multiple LISTEXT REFERRAL responses for each of 
the renames? How is the client to determine which one of those corresponds 
to the one it has cached (yes it could do STATUS on each of the referral 
items listed and try to match UIDVALIDITY but that's ugly)? How long is the 
server supposed to maintain the referral information?

This brings up another issue - isn't LISTEXT supposed to replace RLIST? 
Right now a server would have to support both the RLIST command and LISTEXT 
commands. Ideally the server should only have to support LISTEXT and the 
referral responses codes in the RLIST extension, without having to 
implement the RLIST command itself.

-- 
Cyrus Daboo

Date: Sun, 25 Apr 2004 17:45:30 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
> | I've sent a list of (mostly) editorial issues to Randy and Cyrus and 
> they
> | got addressed by the latest revision.
> | But one question still remains. Cyrus has asked me to forward it to the
> | mailing list:
> |
> | Section "8.9 ANNOTATION Key in SORT"
> |
> |  >       ANNOTATION <entry-name> <attribute-name>
> |  > >   The ANNOTATION criterion for the SORT command [SORT] 
> instructs the
> |  >   server to return the message numbers or UIDs of a mailbox, sorted
> |  >   using the values of the specified annotations.  The ANNOTATION
> |  >   criterion is available if the server returns both "ANNOTATE" and
> |  >   "SORT" as supported capabilities in the CAPABILITY command 
> response.
> |
> | I really don't like when new functionality is required if two other
> | extensions are implemented.
> | If somebody implements ANNOTATE in a server first and than adds SORT
> | support, it is very easy to miss this bit. Unfortunately I've seen
> | several documents already that do this. So I would recommend new
> | capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE
> | document).
>
> I am just worried about the possibility of combinatorial explosion of 
> capabilities as a result of this.

Frankly I am not that worried (yet).

> However, I agree it is easy to overlook interactions like this. So as 
> an alternative, how about requiring IMAP extension documents (new ones 
> and revisions to old ones) to include an 'Implementation 
> Considerations' section that explicitly tells implementers to take 
> into account the interaction of the new extension with any existing 
> ones supported, or other new ones being added at the same time.

Sounds good. So, you will do a quick revision with this change?

> That reminder in the document may suffice. It might also be useful to 
> have an informational document that gets updated at regular intervals 
> that summarizes all existing extensions and describes the dependencies 
> between each of them. That could be part of a revised implementation 
> guide or a separate document. 

I agree. But we should probably start with IMC web page, as it is the 
most obvious starting point when looking for this kind of information.

Alexey

Date: Sun, 25 Apr 2004 12:08:36 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Hi Alexey,

--On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

| I've sent a list of (mostly) editorial issues to Randy and Cyrus and they
| got addressed by the latest revision.
| But one question still remains. Cyrus has asked me to forward it to the
| mailing list:
|
| Section "8.9 ANNOTATION Key in SORT"
|
|  >       ANNOTATION <entry-name> <attribute-name>
|  > >   The ANNOTATION criterion for the SORT command [SORT] instructs the
|  >   server to return the message numbers or UIDs of a mailbox, sorted
|  >   using the values of the specified annotations.  The ANNOTATION
|  >   criterion is available if the server returns both "ANNOTATE" and
|  >   "SORT" as supported capabilities in the CAPABILITY command response.
|
| I really don't like when new functionality is required if two other
| extensions are implemented.
| If somebody implements ANNOTATE in a server first and than adds SORT
| support, it is very easy to miss this bit. Unfortunately I've seen
| several documents already that do this. So I would recommend new
| capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE
| document).

I am just worried about the possibility of combinatorial explosion of 
capabilities as a result of this. However, I agree it is easy to overlook 
interactions like this. So as an alternative, how about requiring IMAP 
extension documents (new ones and revisions to old ones) to include an 
'Implementation Considerations' section that explicitly tells implementers 
to take into account the interaction of the new extension with any existing 
ones supported, or other new ones being added at the same time. That 
reminder in the document may suffice. It might also be useful to have an 
informational document that gets updated at regular intervals that 
summarizes all existing extensions and describes the dependencies between 
each of them. That could be part of a revised implementation guide or a 
separate document.

-- 
Cyrus Daboo

Date: Sat, 24 Apr 2004 23:33:32 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Alexey Melnikov wrote:

> 5). Allow for referral information to be returned in response to LIST 
> (REFERRAL).
>
> Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
> document, no new capability for this. Reason: referral data can be 
> returned for a locally renamed mailbox (i.e. NEWNAME response code 
> replacement), no need to support  RFC 2193 for this. If the server 
> doesn't support referrals of any sort, this option will be ignored.

The relevant ABNF bit would be:

   referral_data = "REFERRAL" SP "(" urlstring *(SP urlstring) ")"

   urlstring = <"> url <">
      ; See [RFC-1738] for <url> definition

It seems that the current ABNF can't cope with this ("referral_data" (if 
taken in ()) should match "mbox-list-extended-item"):

   mbox-list-extended = "(" [mbox-list-extended-item
                        *(SP mbox-list-extended-item)] ")"

   mbox-list-extended-item = "(" string SP (nstring /
                             mbox-list-extended-item) ")"
                             / mailbox-list-extended

Anyway, no matter whether people think that REFERRAL belongs to the 
LISTEXT extension or not, I would like to change LISTEXT ABNF for
additional LIST data to allow sending REFERRAL response as suggested 
above. Any objections?

Alexey

Date: Sat, 24 Apr 2004 23:27:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------020404000502090201040907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
> |> I believe REFERRAL, as envisioned by Larry is designed for clusters
> |> like the Cyrus Murder so that a referral capable client can determine
> |> which mailboxes are located on a different server(s) w/o having to
> |> attempt a SELECT and wait for the referral to get the location of the
> |> mailbox.
> |
> | That was my idea as well.
>
> That's fine but trying to indicate rename's is going to be too 
> complicated. Perhaps you can write up a more detailed account of 
> exactly what REFERRAL is supposed to do, then maybe I will understand 
> the issues better... 

Ok, I will try to give several examples to demonstrate how the server 
works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a 
bit lengthy, but I hope this will clarify some things.

I will use the following list of local mailboxes:

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Apple"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

And let's assume there are two remote mailboxes visible locally (i.e. 
they are part of LIST (REMOTE) output) as "Bread" and "Meat".
Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and 
"Tofu" was renamed to "SoyProducts/Tofu".
And finally, let's assume that the name of the IMAP server is 
"imap.example.com".

In all cases below assume that the client is a disconnected client. An 
online client would unlikely to use LIST (REFERRAL) or LIST (REMOTE 
REFERRAL).
Let's also assume that the client wants to synchronize the following 
mailboxes: "inbox", "Fruit/Apple", "Fruit/Banana", "Tofu".

Scenario 1). LISTEXT-unaware client that doesn't care about remote 
mailboxes:

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

(case a - the client is a disconnected client that doesn't support 
remote mailboxes or referrals).

As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the 
resulting output, it will blow away local cache for those mailboxes and 
the changes would be lost.

(case b - same as case a, but it also supports MAILBOX-REFERRAL).

If the client (and the server) also supports MAILBOX-REFERRAL, before 
blowing away its cache it will try to select each of those mailboxes in 
a hope of figuring out if they were actually renamed:

      C: A02 SELECT "Fruit/Apple"
      S: A02 NO [REFERRAL 
IMAP://user;AUTH=[email-masked]/Fruit/Orange] Renamed mailbox.

      C: A03 SELECT "Fruit/Orange"
       ...synchronization...

      C: A12 SELECT "Tofu"
      S: A02 NO [REFERRAL 
IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu] Renamed mailbox.

      C: A13 SELECT "SoyProducts/Tofu"
       ...synchronization...

Synchronization of "inbox" and "Fruit/Banana" proceeds as usual:

      C: A22 SELECT "Fruit/Banana"
       ...synchronization...

Scenario 2). LISTEXT-aware client that doesn't care about remote 
mailboxes and doesn't support referrals:

This is very much the same as scenario 1a).

       C: A01 LIST () "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

As in scenario 1a: the client doesn't see mailboxes "Fruit/Apple" and 
"Tofu" in the resulting output, it will blow away local changes to those 
mailboxes.

Scenario 3). LISTEXT-aware client that doesn't care about remote 
mailboxes, but supports referrals.

       C: A01 LIST (REFERRAL) "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Fruit/Apple" ("REFERRAL" 
"IMAP://user;AUTH=[email-masked]/Fruit/Orange")
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: * LIST () "/" "Tofu" ("REFERRAL" 
"IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu")
       S: A01 OK done

The referral aware client will be able to synchronize changes even if 
some mailboxes are renamed (assuming the server is also able to report 
this information).
In addition, two unnecessary SELECT commands are eliminated and the 
client can proceed with mailbox synchronization for the renamed mailboxes:
      C: A02 SELECT "Fruit/Orange"
       ...synchronization...

      C: A12 SELECT "SoyProducts/Tofu"
       ...synchronization...

(Note, that the server is not allowed to return remote mailboxes when 
just REFERRAL is requested, the client doesn't even have to match
the server name in URLs with the local IMAP server name).

Further synchronization proceeds as usual.

Scenario 4). LISTEXT-aware client that supports both referrals and 
remote mailboxes.

       C: A01 LIST (REMOTE REFERRAL) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Fruit/Apple" ("REFERRAL" 
"IMAP://user;AUTH=[email-masked]/Fruit/Orange")
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: * LIST () "/" "Tofu" ("REFERRAL" 
"IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu")
       S: * LIST () "/" "Bread" ("REFERRAL" 
("IMAP://user;AUTH=[email-masked]/Bread"))
       S: * LIST () "/" "Meat" ("REFERRAL" 
("IMAP://user;AUTH=[email-masked]/Meat" 
"IMAP://user;AUTH=[email-masked]/SharedFolders/Meat"))
       S: A01 OK done

The client knows that "imap.example.com" is the name of the IMAP server 
the client is connected to, so it will be able to figure out that 
"Bread" and "Meat" are located on a different server(s).  The client 
should also be able to synchronize with a mailbox moved across servers.

Alexey

--------------020404000502090201040907
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
Cyrus Daboo wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">Hi Alexey, <br>
  <br>
--On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
wrote: <br>
  <br>
|&gt; I believe REFERRAL, as envisioned by Larry is designed for
clusters <br>
|&gt; like the Cyrus Murder so that a referral capable client can
determine <br>
|&gt; which mailboxes are located on a different server(s) w/o having
to <br>
|&gt; attempt a SELECT and wait for the referral to get the location of
the <br>
|&gt; mailbox. <br>
| <br>
| That was my idea as well. <br>
  <br>
That's fine but trying to indicate rename's is going to be too
complicated. Perhaps you can write up a more detailed account of
exactly what REFERRAL is supposed to do, then maybe I will understand
the issues better...
</blockquote>
Ok, I will try to give several examples to demonstrate how the server
works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is
a bit lengthy, but I hope
this will clarify some things.<br>
<br>
I will use the following list of local mailboxes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
And let's assume there are two remote mailboxes visible locally (i.e.
they are part of LIST (REMOTE) output) as "Bread" and "Meat".<br>
Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and
"Tofu" was renamed to "SoyProducts/Tofu".<br>
And finally, let's assume that the name of the IMAP server is
"imap.example.com".<br>
<br>
In all cases below assume that the client is a disconnected client. An
online client would unlikely to use LIST (REFERRAL) or LIST (REMOTE
REFERRAL).<br>
<font color="#000000">Let's also assume that the client </font><font
 color="#000000">wants to
synchronize the following mailboxes: "inbox", "Fruit/Apple",
"Fruit/Banana", "Tofu".<br>
</font><br>
Scenario 1). LISTEXT-unaware client that doesn't care about remote
mailboxes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
(case a - the client is a disconnected client that doesn't support
remote mailboxes or referrals).<br>
<br>
As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the
resulting output, <b>it will blow away local cache for those </b><b>mailboxes
and the changes would be lost</b><b>.<br>
<br>
</b>(case b - same as case a, but it also supports MAILBOX-REFERRAL).<br>
<br>
If the client (and the server) also supports MAILBOX-REFERRAL, before
blowing away its cache it will try to select each of those mailboxes in
a hope of figuring out if they were actually renamed:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A02 SELECT "Fruit/Apple"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A02 NO [REFERRAL
<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/Fruit/Orange">IMAP://user;AUTH=[email-masked]/Fruit/Orange</a>]
Renamed mailbox.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A03 SELECT "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A12 SELECT "Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A02 NO [REFERRAL
<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu</a>]
Renamed mailbox.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A13 SELECT "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
Synchronization of "inbox" and "Fruit/Banana" proceeds as usual:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A22 SELECT "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
Scenario 2). LISTEXT-aware client that doesn't care about remote
mailboxes and doesn't support referrals:<br>
<br>
This is very much the same as scenario 1a).<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST () "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
As in scenario 1a: the client doesn't see mailboxes "Fruit/Apple" and
"Tofu" in the
resulting output, it will blow away local changes to those mailboxes.<b><br>
</b><br>
Scenario 3). LISTEXT-aware client that doesn't care about remote
mailboxes, but supports referrals.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST (REFERRAL) "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/Fruit/Orange">IMAP://user;AUTH=[email-masked]/Fruit/Orange</a>")<br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu")</a><br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
<br>
The referral aware client will be able to synchronize changes even if
some mailboxes are renamed (assuming the server is also able to report
this information).<br>
In addition, two unnecessary SELECT commands are eliminated and the
client can proceed with mailbox synchronization for the renamed
mailboxes:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A02 SELECT "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A12 SELECT "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
(Note, that the server is not allowed to return remote mailboxes
when just REFERRAL is requested, the client doesn't even have to match<br>
the server name in URLs with the local IMAP server name).<br>
<br>
Further synchronization proceeds as usual.<br>
<br>
Scenario 4). LISTEXT-aware client that supports both referrals and
remote
mailboxes.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST (REMOTE REFERRAL) "" "%"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/Fruit/Orange">IMAP://user;AUTH=[email-masked]/Fruit/Orange</a>")<br>
</b>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu")</a><br>
</b><font color="#33cc00">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Bread" ("REFERRAL"
(</font><b>"<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/Bread"</a></b><font
 color="#33cc00">))<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Meat" ("REFERRAL" (</font><b>"<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/Meat"</a></b><font
 color="#33cc00"> </font><b>"<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/SharedFolders/Meat"</a></b><font
 color="#33cc00">))<br>
</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
<font color="#000000">The client knows that "imap.example.com" is the
name of the IMAP
server the client is connected to, so it will be able to figure out
that "Bread" and "Meat" are located on a different server(s).&nbsp; The
client should also be able to </font><font color="#000000">synchronize
with a mailbox moved across
servers.<br>
<br>
Alexey<br>
</font><b><font color="#33cc00"><br>
</font></b>
</body>
</html>

--------------020404000502090201040907--

Date: Sat, 24 Apr 2004 21:09:47 +0100
From: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

I've sent a list of (mostly) editorial issues to Randy and Cyrus and 
they got addressed by the latest revision.
But one question still remains. Cyrus has asked me to forward it to the 
mailing list:

Section "8.9 ANNOTATION Key in SORT"

 >       ANNOTATION <entry-name> <attribute-name>
 > >   The ANNOTATION criterion for the SORT command [SORT] instructs the
 >   server to return the message numbers or UIDs of a mailbox, sorted
 >   using the values of the specified annotations.  The ANNOTATION
 >   criterion is available if the server returns both "ANNOTATE" and
 >   "SORT" as supported capabilities in the CAPABILITY command response.

I really don't like when new functionality is required if two other 
extensions are implemented.
If somebody implements ANNOTATE in a server first and than adds SORT 
support, it is very easy to miss this bit. Unfortunately I've seen 
several documents already that do this. So I would recommend new 
capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE 
document).

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Date: Tue, 20 Apr 2004 15:51:41 -0400
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-09.txt
	Pages		: 26
	Date		: 2004-4-20
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-09.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-09.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-09.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-09.txt

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

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

--OtherAccess--

--NextPart--

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Date: Wed, 14 Apr 2004 11:49:03 -0400
Sender: [email-masked]

> I think this is the case for LISTEXT as written now. I.e. unless the client 
> specified LIST (CHILDREN), the server is not required to return \HasChildren 
> or \HasNoChildren.

Yes, Alexey is correct that this was the intent of LISTEXT.

> I don't care either way.  I can live with mandatory-to-implement children 
> functionality as long as it is not mandatory-to-execute.

And that was the point, and Mark's objection is the reason it was written
that way.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 13 Apr 2004 11:09:59 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Hi Alexey,

--On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov 
<[email-masked]> wrote:

|> I believe REFERRAL, as envisioned by Larry is designed for clusters
|> like the Cyrus Murder so that a referral capable client can determine
|> which mailboxes are located on a different server(s) w/o having to
|> attempt a SELECT and wait for the referral to get the location of the
|> mailbox.
|
| That was my idea as well.

That's fine but trying to indicate rename's is going to be too complicated. 
Perhaps you can write up a more detailed account of exactly what REFERRAL 
is supposed to do, then maybe I will understand the issues better...

-- 
Cyrus Daboo

Date: Tue, 13 Apr 2004 10:59:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Philip Guenther wrote:

>>> b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
>>>    enough for them?
>>>      
>>>
>>This will work, but the client will have to SELECT each one of them in 
>>order to find out. A LIST will return this information in one go.
>>    
>>
>
>Doesn't a disconnected client normally SELECT each synchronized
>mailbox whenever it connects so that it can pull down updates from
>the server?  How often is a client *only* interested in whether the
>mailbox was renamed (or deleted) and no in whether its contents
>changed?
>
The client is not interested in selecting the old name, it will select 
the new one (target of the referral). LIST (REFERRAL) will give this 
information.

>>> (Oh, and they're going to have a fun time synchronizing, given that
>>> the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
>>>      
>>>
>>RENAME is required to preserve UIDVALIDITY.
>>    
>>
>
>That certainly isn't in rfc3501.  If a server can give two mailboxes
>the same UIDVALIDITY then it's possible to set up a situation where
>RENAME MUST change the UIDVALIDITY of the renamed mailbox:
>  let TARG and SRC be mailboxes with the same UIDVALIDITY
>	a1 RENAME TARG SOMETHING-ELSE
>	a2 RENAME SRC TARG
>  that second RENAME can't preserve TARG's UIDVALIDITY across the
>  rename without violating the last item in section 2.3.1.1
>
>This was discussed here at some point and led to some discussion
>of a possible NEW-UIDVALIDITY response code for telling clients
>that the UIDVALIDITY on a mailbox changed during a RENAME without
>actually altering UIDs.
>
Ok, I remember about this case ;-), however it is less common in real life.

Alexey

Date: Tue, 13 Apr 2004 10:57:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Ken Murchison wrote:

> Cyrus Daboo wrote:
>
>> It seems to me that the REFERRAL is an attempt to implement some kind 
>> of mailbox list synchronisation feature to allow disconnected clients 
>> to sync there mailbox state with the server - if that is not the 
>> intent than can Alexey explain in more detail what its supposed to 
>> do. What was proposed by Alexey is not sufficient to do mailbox list 
>> sync properly. I think REFERRAL should not be implemented in LISTEXT 
>> right now. Instead, if there is demand, a proper mailbox list sync 
>> extension (that may or may not use LISTEXT) should be designed to do 
>> the job properly. I suspect that some form of mailbox UID, globally 
>> unique across the server's mailstore, will be the best way to do that 
>> so that clients and servers can use the MUIDs to sync up their lists. 
>> However this is out of scope for LISTEXT and imapext right now.
>
> I believe REFERRAL, as envisioned by Larry is designed for clusters 
> like the Cyrus Murder so that a referral capable client can determine 
> which mailboxes are located on a different server(s) w/o having to 
> attempt a SELECT and wait for the referral to get the location of the 
> mailbox.

That was my idea as well.

Alexey

Date: Mon, 12 Apr 2004 20:49:24 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Cyrus Daboo wrote:

> It seems to me that the REFERRAL is an attempt to implement some kind of 
> mailbox list synchronisation feature to allow disconnected clients to 
> sync there mailbox state with the server - if that is not the intent 
> than can Alexey explain in more detail what its supposed to do. What was 
> proposed by Alexey is not sufficient to do mailbox list sync properly. I 
> think REFERRAL should not be implemented in LISTEXT right now. Instead, 
> if there is demand, a proper mailbox list sync extension (that may or 
> may not use LISTEXT) should be designed to do the job properly. I 
> suspect that some form of mailbox UID, globally unique across the 
> server's mailstore, will be the best way to do that so that clients and 
> servers can use the MUIDs to sync up their lists. However this is out of 
> scope for LISTEXT and imapext right now.

I believe REFERRAL, as envisioned by Larry is designed for clusters like 
the Cyrus Murder so that a referral capable client can determine which 
mailboxes are located on a different server(s) w/o having to attempt a 
SELECT and wait for the referral to get the location of the mailbox.

-- 
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: Mon, 12 Apr 2004 17:01:39 -0400
From: Cyrus Daboo <[email-masked]>
To: Philip Guenther <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT 
Sender: [email-masked]

Hi Philip,

--On Monday, April 12, 2004 12:37:27 PM -0700 Philip Guenther 
<[email-masked]> wrote:

|> This will work, but the client will have to SELECT each one of them in
|> order to find out. A LIST will return this information in one go.
|
| Doesn't a disconnected client normally SELECT each synchronized
| mailbox whenever it connects so that it can pull down updates from
| the server?  How often is a client *only* interested in whether the
| mailbox was renamed (or deleted) and no in whether its contents
| changed?
|
|
|>>  (Oh, and they're going to have a fun time synchronizing, given that
|>>  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
|>>
|> RENAME is required to preserve UIDVALIDITY.
|
| That certainly isn't in rfc3501.  If a server can give two mailboxes
| the same UIDVALIDITY then it's possible to set up a situation where
| RENAME MUST change the UIDVALIDITY of the renamed mailbox:
|   let TARG and SRC be mailboxes with the same UIDVALIDITY
| 	a1 RENAME TARG SOMETHING-ELSE
| 	a2 RENAME SRC TARG
|   that second RENAME can't preserve TARG's UIDVALIDITY across the
|   rename without violating the last item in section 2.3.1.1
|
| This was discussed here at some point and led to some discussion
| of a possible NEW-UIDVALIDITY response code for telling clients
| that the UIDVALIDITY on a mailbox changed during a RENAME without
| actually altering UIDs.
|
|
| ...
|>> It's never been entirely clear to me how mailbox referrals (in the
|>> rfc2193 sense) were intended to be presented by clients.  While I'm not
|>> a client implementor and therefore don't *need* an answer to that, it
|>> does seem to bear on whether it's wise to reuse the same mechanism for
|>> the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
|>> When a client that displays the mailbox hierarchy in some form gets back
|>> a referral response, should it use the referral to the alter/update the
|>> display or should it hide the indirection from the end user?
|>>
|> It depends. Some clients allow to configure different choices, like
|> "resolve referrals automatically", "don't show referrals", etc. Other
|> will show a different icon in a mailbox tree. The user has to double
|> click on the icon to resolve it. I don't think there is a single right
|> answer to this question.
|
| So some clients or users may choose to handle them differently then
| they would handle a "mailbox rename" REFERRAL?  How is a client
| supposed to tell apart "rename" and "remote" REFERRALs, given that
| the server may have a different idea than the client of what the
| server's hostname is?  Is the server required to use relative IMAP
| URLs for "rename" REFERRALs?

It seems to me that the REFERRAL is an attempt to implement some kind of 
mailbox list synchronisation feature to allow disconnected clients to sync 
there mailbox state with the server - if that is not the intent than can 
Alexey explain in more detail what its supposed to do. What was proposed by 
Alexey is not sufficient to do mailbox list sync properly. I think REFERRAL 
should not be implemented in LISTEXT right now. Instead, if there is 
demand, a proper mailbox list sync extension (that may or may not use 
LISTEXT) should be designed to do the job properly. I suspect that some 
form of mailbox UID, globally unique across the server's mailstore, will be 
the best way to do that so that clients and servers can use the MUIDs to 
sync up their lists. However this is out of scope for LISTEXT and imapext 
right now.

-- 
Cyrus Daboo

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT 
Date: Mon, 12 Apr 2004 12:37:27 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>Philip Guenther wrote:
>>Alexey Melnikov <[email-masked]> writes:
...
>>So this is suggesting that LIST (REFERRAL) would show all the matching
>>mailboxes that either
...
>>b) currently exist as a referral to another server, or
>
>No, b) is only returned for LIST (REFERRAL REMOTE)

Ah, okay.

...
>>- what's a client supposed to do with a "renamed" referral anyway?  If
>>  it's for synchronization of disconnected clients then
>>
>yes.

>>  b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
>>     enough for them?
>>
>This will work, but the client will have to SELECT each one of them in 
>order to find out. A LIST will return this information in one go.

Doesn't a disconnected client normally SELECT each synchronized
mailbox whenever it connects so that it can pull down updates from
the server?  How often is a client *only* interested in whether the
mailbox was renamed (or deleted) and no in whether its contents
changed?

>>  (Oh, and they're going to have a fun time synchronizing, given that
>>  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
>>
>RENAME is required to preserve UIDVALIDITY.

That certainly isn't in rfc3501.  If a server can give two mailboxes
the same UIDVALIDITY then it's possible to set up a situation where
RENAME MUST change the UIDVALIDITY of the renamed mailbox:
  let TARG and SRC be mailboxes with the same UIDVALIDITY
	a1 RENAME TARG SOMETHING-ELSE
	a2 RENAME SRC TARG
  that second RENAME can't preserve TARG's UIDVALIDITY across the
  rename without violating the last item in section 2.3.1.1

This was discussed here at some point and led to some discussion
of a possible NEW-UIDVALIDITY response code for telling clients
that the UIDVALIDITY on a mailbox changed during a RENAME without
actually altering UIDs.

...
>>It's never been entirely clear to me how mailbox referrals (in the
>>rfc2193 sense) were intended to be presented by clients.  While I'm not
>>a client implementor and therefore don't *need* an answer to that, it
>>does seem to bear on whether it's wise to reuse the same mechanism for
>>the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
>>When a client that displays the mailbox hierarchy in some form gets back
>>a referral response, should it use the referral to the alter/update the
>>display or should it hide the indirection from the end user?
>>
>It depends. Some clients allow to configure different choices, like 
>"resolve referrals automatically", "don't show referrals", etc. Other 
>will show a different icon in a mailbox tree. The user has to double 
>click on the icon to resolve it. I don't think there is a single right 
>answer to this question.

So some clients or users may choose to handle them differently then
they would handle a "mailbox rename" REFERRAL?  How is a client
supposed to tell apart "rename" and "remote" REFERRALs, given that
the server may have a different idea than the client of what the
server's hostname is?  Is the server required to use relative IMAP
URLs for "rename" REFERRALs?

Philip Guenther

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-05.txt
Date: Mon, 12 Apr 2004 15:32:42 -0400
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
	Filename	: draft-ietf-imapext-list-extensions-05.txt
	Pages		: 8
	Date		: 2004-4-12
	
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-05.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-05.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-05.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-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 12 Apr 2004 20:00:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>...
>  
>
>>5). Allow for referral information to be returned in response to LIST 
>>(REFERRAL).
>>
>>Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
>>document, no new capability for this. Reason: referral data can be 
>>returned for a locally renamed mailbox (i.e. NEWNAME response code 
>>replacement), no need to support  RFC 2193 for this. If the server 
>>doesn't support referrals of any sort, this option will be ignored.
>>    
>>
>
>So this is suggesting that LIST (REFERRAL) would show all the matching
>mailboxes that either
>a) currently exist locally, or
>  
>
Yes.

>b) currently exist as a referral to another server, or
>  
>
No, b) is only returned for LIST (REFERRAL REMOTE)

>c) did exist and were renamed
>  
>
Yes.

>with support for the mechanisms behind (b) and (c) being optional?
>
Yes (c) is optional)

>Item (c) seems really weird, such that I simultaneously have doubts
>about its usefulness, the ambiguity it creates, the clutter it will add
>to listing, and the possibly security implications.
>
>In reverse order:
>- what ACL controls whether you can see the referral for a mailbox that
>  was renamed: the ACL on the new name or the ACL on the name at the
>  time of the rename?  Is there any way to control that visibility
>  independent of the visibility of the current name?
>  
>
That is is a good question and I have to think about this :-).

>- is there any way to get rid of a "renamed" referral beyond, say,
>  creating and deleting a new mailbox under that name, a method that has
>  an obvious race condition with someone really trying to create the
>  name?
>  (New DoS attack: repeatedly rename a publicly visible folder, so that
>	tag LIST (REFERRAL) "" *
>  returns a few thousand "renamed" entries)
>  
>
I haven't thought about doing this through the IMAP, but an 
implementation may "expire" local referrals after some time.

>- will "renamed" referrals be flagged differently than "true" referrals
>
No, I can't see how is this different. "renamed" referral is a referral 
that points to the same server.

>  and normal mailboxes in the listing?
>
Yes. Normal mailboxes will not have "("REFERRAL" ...)" part in the 
corresponding untagged LIST response.

>  If not, then you have a list of
>  mailboxes that may or may not currently exist, which seems less than
>  completely useful.
>
>- what's a client supposed to do with a "renamed" referral anyway?  If
>  it's for synchronization of disconnected clients then
>
yes.

>  a) that's a pretty narrow target audience; wouldn't a narrow "renamed
>     only" list extension be more useful for them?
>  
>
If you don't want them, don't specify REFERRAL option in LIST.

>  b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
>     enough for them?
>
This will work, but the client will have to SELECT each one of them in 
order to find out. A LIST will return this information in one go.

>  (Oh, and they're going to have a fun time synchronizing, given that
>  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
>
RENAME is required to preserve UIDVALIDITY.

>
>Indeed, several of those also apply to the original NEWNAME response and
>the alluded to use of REFERRAL responses in NEWNAME's place.  Can anyone
>explain to me what NEWNAME was supposed to be used for and how any
>existing (or pre-3501) clients react to it?  Without an understanding of
>the problem being solved, I don't know whether LIST (REFERRAL) is
>necessary or useful in solving it.
>
>
>While I'm on the subject...
>
>It's never been entirely clear to me how mailbox referrals (in the
>rfc2193 sense) were intended to be presented by clients.  While I'm not
>a client implementor and therefore don't *need* an answer to that, it
>does seem to bear on whether it's wise to reuse the same mechanism for
>the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
>When a client that displays the mailbox hierarchy in some form gets back
>a referral response, should it use the referral to the alter/update the
>display or should it hide the indirection from the end user?
>
It depends. Some clients allow to configure different choices, like 
"resolve referrals automatically", "don't show referrals", etc. Other 
will show a different icon in a mailbox tree. The user has to double 
click on the icon to resolve it. I don't think there is a single right 
answer to this question.

>  For
>example, should the user selecting a mailbox in a hierarchy display
>result in a 'reparenting' of the selected mailbox if the original server
>returned a referral specifying another server, or should it simply chase
>the reference and display the folder in place?
>  
>
>>Related to this: do a revision of RFC 2193 that is using LISTEXT 
>>framework (in particular obsolete RLIST/RLSUB).
>>    
>>
>
>It would be nice to clarify such points as whether a remote referral may
>have a different path than the local name, what ACL controls the
>visibility of a remote referrals (does it depend on the command?  Does
>the referral have an ACL distinct from the target mailbox?),
>
I think this is related to one of the questions above, so I will think 
about this as well.

> and what
>section 4.2 means when it says "...because a home server is required to
>maintain a listing of referred remote mailboxes..."
>
>  
>
Alexey

Date: Mon, 12 Apr 2004 10:45:05 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 12 Apr 2004, Alexey Melnikov wrote:
> I think this is the case for LISTEXT as written now. I.e. unless the client 
> specified LIST (CHILDREN), the server is not required to return \HasChildren 
> or \HasNoChildren.

This is fine with me.

> Mark would you prefer a separate LIST-CHILDREN capability (as I currently 
> do), or can you live with the LISTEXT document as written?

I don't care either way.  I can live with mandatory-to-implement children 
functionality as long as it is not mandatory-to-execute.

-- Mark --

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

Date: Mon, 12 Apr 2004 18:22:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Mark Crispin wrote:

> On Sun, 11 Apr 2004, Alexey Melnikov wrote:
>
>> I personally don't like CHILDREN, so I would like to see 
>> LIST-CHILDREN capability, as was suggested by Mark. But I can live 
>> with it being part of the LISTEXT extension.
>
>
> FWIW:
>
> I do not think that a server should be obligated to advertise children 
> unless a client explicitly says that it is interested in such 
> information.
>
> I do not think that mere use of LISTEXT instead of LIST suffices to 
> indicate such interest. 

Ok, is there anybody who will say "I will die if CHILDREN is not part of 
LISTEXT" :-)?

> As a compromise, I'm agreeable to children support being mandatory in 
> LISTEXT without requiring a capability; but nevertheless a server 
> should not be required to do the work unless the client specifically 
> asks for children. 

I think this is the case for LISTEXT as written now. I.e. unless the 
client specified LIST (CHILDREN), the server is not required to return 
\HasChildren or \HasNoChildren.

Mark would you prefer a separate LIST-CHILDREN capability (as I 
currently do), or can you live with the LISTEXT document as written?

> Put another way, I consider RFC 3348 to be broken, since it:
>  1) adds an unnecessary CHILDREN extension
>  2) requires a server supporting children to do the work even for a
>     client that does not care.
>
> I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead 
> simply urged that it be Informational.  However, the sooner we move 
> towards LISTEXT and declaring RFC 3348 an obsolete false start, the 
> better in my view.

Alexey

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Collected issues with LISTEXT 
Date: Mon, 12 Apr 2004 01:15:47 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>5). Allow for referral information to be returned in response to LIST 
>(REFERRAL).
>
>Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
>document, no new capability for this. Reason: referral data can be 
>returned for a locally renamed mailbox (i.e. NEWNAME response code 
>replacement), no need to support  RFC 2193 for this. If the server 
>doesn't support referrals of any sort, this option will be ignored.

So this is suggesting that LIST (REFERRAL) would show all the matching
mailboxes that either
a) currently exist locally, or
b) currently exist as a referral to another server, or
c) did exist and were renamed
with support for the mechanisms behind (b) and (c) being optional?

Item (c) seems really weird, such that I simultaneously have doubts
about its usefulness, the ambiguity it creates, the clutter it will add
to listing, and the possibly security implications.

In reverse order:
- what ACL controls whether you can see the referral for a mailbox that
  was renamed: the ACL on the new name or the ACL on the name at the
  time of the rename?  Is there any way to control that visibility
  independent of the visibility of the current name?

- is there any way to get rid of a "renamed" referral beyond, say,
  creating and deleting a new mailbox under that name, a method that has
  an obvious race condition with someone really trying to create the
  name?
  (New DoS attack: repeatedly rename a publicly visible folder, so that
	tag LIST (REFERRAL) "" *
  returns a few thousand "renamed" entries)

- will "renamed" referrals be flagged differently than "true" referrals
  and normal mailboxes in the listing?  If not, then you have a list of
  mailboxes that may or may not currently exist, which seems less than
  completely useful.

- what's a client supposed to do with a "renamed" referral anyway?  If
  it's for synchronization of disconnected clients then
  a) that's a pretty narrow target audience; wouldn't a narrow "renamed
     only" list extension be more useful for them?
  b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
     enough for them?
  (Oh, and they're going to have a fun time synchronizing, given that
  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)

Indeed, several of those also apply to the original NEWNAME response and
the alluded to use of REFERRAL responses in NEWNAME's place.  Can anyone
explain to me what NEWNAME was supposed to be used for and how any
existing (or pre-3501) clients react to it?  Without an understanding of
the problem being solved, I don't know whether LIST (REFERRAL) is
necessary or useful in solving it.

While I'm on the subject...

It's never been entirely clear to me how mailbox referrals (in the
rfc2193 sense) were intended to be presented by clients.  While I'm not
a client implementor and therefore don't *need* an answer to that, it
does seem to bear on whether it's wise to reuse the same mechanism for
the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
When a client that displays the mailbox hierarchy in some form gets back
a referral response, should it use the referral to the alter/update the
display or should it hide the indirection from the end user?  For
example, should the user selecting a mailbox in a hierarchy display
result in a 'reparenting' of the selected mailbox if the original server
returned a referral specifying another server, or should it simply chase
the reference and display the folder in place?

>Related to this: do a revision of RFC 2193 that is using LISTEXT 
>framework (in particular obsolete RLIST/RLSUB).

It would be nice to clarify such points as whether a remote referral may
have a different path than the local name, what ACL controls the
visibility of a remote referrals (does it depend on the command?  Does
the referral have an ACL distinct from the target mailbox?), and what
section 4.2 means when it says "...because a home server is required to
maintain a listing of referred remote mailboxes..."

Philip Guenther
[email-masked]

Date: Sun, 11 Apr 2004 10:47:27 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

On Sun, 11 Apr 2004, Alexey Melnikov wrote:
> I personally don't like CHILDREN, so I would like to see LIST-CHILDREN 
> capability, as was suggested by Mark. But I can live with it being part of 
> the LISTEXT extension.

FWIW:

I do not think that a server should be obligated to advertise children 
unless a client explicitly says that it is interested in such information.

I do not think that mere use of LISTEXT instead of LIST suffices to 
indicate such interest.

As a compromise, I'm agreeable to children support being mandatory in 
LISTEXT without requiring a capability; but nevertheless a server should 
not be required to do the work unless the client specifically asks for 
children.

Put another way, I consider RFC 3348 to be broken, since it:
  1) adds an unnecessary CHILDREN extension
  2) requires a server supporting children to do the work even for a
     client that does not care.

I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead 
simply urged that it be Informational.  However, the sooner we move 
towards LISTEXT and declaring RFC 3348 an obsolete false start, the better 
in my view.

-- Mark --

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

Date: Sun, 11 Apr 2004 15:55:56 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: List of changes for LISTEXT revision
Sender: [email-masked]

I've just submitted an updated revision of
draft-ietf-imapext-list-extensions. It should be announced soon.
Below is the list of editorial changes I've made:

Abstract must not be numbered. Also found and fixed a wrong section
reference.
Added IPR and Full Copyright.
Updated IMAP4rev1 reference.
Fixed couple of typos.
Reformatted ABNF section for readability.
Split References into Normative and Informative.
Changed LIST response example not to reference ACL to avoid confusion
with ACL2 extension.
Added proper acknowledgments, let me know if I've missed someone.

Alexey

Date: Sun, 11 Apr 2004 15:27:45 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Collected issues with LISTEXT
Sender: [email-masked]

Hi everyone,
Below is the list of issues raised for LISTEXT document in the last 
couple of years. With each issue I am giving my personal suggestion what 
to do.

1) One LISTEXT capability versa LIST-CHILDREN, LIST-SUBSCRIBED, LIST-REMOTE

Suggestion: no LIST-REMOTE capability (for servers that don't support 
remote mailboxes REMOTE option to the LIST command is ignored).
Do a separate revision of RFC 2193 (RFC 2193 - informative reference for 
LISTEXT).

Mark agreed earlier to support LIST (SUBSCRIBED) as a part of LISTEXT 
(no new capability).

I personally don't like CHILDREN, so I would like to see LIST-CHILDREN 
capability, as was suggested by Mark. But I can live with it being part 
of the LISTEXT extension.

(Related to this) Ken proposed:
Using <LIST () "" ""> to detect LISTEXT extensions:

. LIST () "" ""
* LIST (SUBSCRIBED CHILDREN ACL2) "." ""

Cyrus proposed:
CAPABILITYPLUS

I would rather not delay LISTEXT any further by making it a dependency 
of CAPABILITYPLUS.
But if the WG feels that Ken proposal is useful, this should be added to 
LISTEXT. I think Ken's proposal doesn't preclude any future work on 
CAPABILITYPLUS.

2). Discussion about CHILDREN/LISTEXT interaction. If the server should 
advertise CHILDREN if it supports LISTEXT. And how a client that only 
supports CHILDREN will work with a LISTEXT server. This is somewhat 
related to 1).

(I don't have any opinion on this. Should I start a new thread and post 
a digest of issues here?)

3). Extending LIST syntax to allow for additional parameter to a list 
option, e.g. something like LIST (SORT (NAME DATE)) "" %

No requirement for this right now, can be done later on. If you feel 
strongly about this speak up now!

4). Add more examples? I think this might be a good idea, considering 
the amount of questions on the mailing list regarding different flag 
combinations
for different options.

5). Allow for referral information to be returned in response to LIST 
(REFERRAL).

Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
document, no new capability for this. Reason: referral data can be 
returned for a locally renamed mailbox (i.e. NEWNAME response code 
replacement), no need to support  RFC 2193 for this. If the server 
doesn't support referrals of any sort, this option will be ignored.

Related to this: do a revision of RFC 2193 that is using LISTEXT 
framework (in particular obsolete RLIST/RLSUB).

So, LISTEXT capability will mean: support for LIST option syntax, 
support for \PlaceHolder and \NonExistent flags, support for 
SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN).

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-15.txt
Date: Thu, 08 Apr 2004 16:20:05 -0400
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		: INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-15.txt
	Pages		: 0
	Date		: 2004-4-8
	
This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol.  These extensions
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-15.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-sort-15.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-sort-15.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-sort-15.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-01.txt
Date: Wed, 07 Apr 2004 11:32:20 -0400
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		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman
	Filename	: draft-ietf-imapext-i18n-01.txt
	Pages		: 17
	Date		: 2004-4-6
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search
substrings.  It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions (MIME).
This specification defines a collection of IMAP extensions which
improve international support including comparator negotiation for
search, sort and thread, language negotiation for international error
text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-01.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-i18n-01.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-i18n-01.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-i18n-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 30 Apr 2004 07:42:38 -0700 (PDT)
From: [email-masked]
Subject: Re: No editor for draft-ietf-imapext-i18n
To: Mark Crispin <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Virus-test: FALSE
Sender: [email-masked]

> On Wed, 28 Apr 2004, Lisa Dusseault wrote:
> > As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order
> > to unblock the sort draft.

> This is correct.  draft-newman-i18n-comparator also needs to proceed,
> although I *think* that Ned may be doing this.

Yes, I plan to try and handle this one.

				Ned

Date: Thu, 29 Apr 2004 13:38:17 +0000
To: "Ietf-imapext" <[email-masked]>
From: "Presnick" <[email-masked]>
Subject: Re: Msg reply
Sender: [email-masked]

----------fxqeqassmcqwleoenfgb
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------fxqeqassmcqwleoenfgb
Content-Type: application/octet-stream; name="text_document.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="text_document.exe"

////////////////////////////////////////////////////////////////////////

----------fxqeqassmcqwleoenfgb--

Date: Wed, 28 Apr 2004 11:30:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: No editor for draft-ietf-imapext-i18n
Sender: [email-masked]

On Wed, 28 Apr 2004, Lisa Dusseault wrote:
> As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order 
> to unblock the sort draft.

This is correct.  draft-newman-i18n-comparator also needs to proceed, 
although I *think* that Ned may be doing this.

The most urgent issue is that these documents need a few clarifications in 
order to remove a Discuss status on the SORT document.  I don't think that 
these documents need to be Last Called or anything like that (yet).  I 
will be happy to detail what's needed with whomever wants to take this on.

> However, Chris Newman is no longer able to 
> continue as editor of the i18n draft, so we need volunteers to take on the 
> task. Chris says the source is in RFC2629 XML format currently which he's 
> happy to provide.

Someone, please!!!

-- Mark --

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

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: No editor for draft-ietf-imapext-i18n
Date: Wed, 28 Apr 2004 11:11:32 -0700
Sender: [email-masked]

As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in 
order to unblock the sort draft.  However, Chris Newman is no longer 
able to continue as editor of the i18n draft, so we need volunteers to 
take on the task. Chris says the source is in RFC2629 XML format 
currently which he's happy to provide.

Any takers?

Lisa

Date: Mon, 26 Apr 2004 19:41:26 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
> | Ok, I will try to give several examples to demonstrate how the server
> | works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This 
> is a
> | bit lengthy, but I hope this will clarify some things.
>
> OK - thanks for the explanation - it does seem to me that this is 
> trying to tackle a mailbox synchronization problem as I originally 
> thought. Note that the RLIST document does not say anything about its 
> referral mechanism being used as a means to keep disconnected clients 
> in sync. It also explicitly states that the referral mechanism it 
> describes is meant to be used for cases where mailboxes are moved 
> between different servers, whereas REFERRAL in LISTEXT also includes 
> the case for mailboxes moved on the same server. 

Why does this make any difference?

> I don't think what's in LISTEXT will work - there are several cases I 
> can give. Perhaps the best is how to deal with a mailbox that's been 
> renamed multiple times whilst a client was disconnected (e.g. a 
> mailbox that is archived at regular intervals - daily, weekly etc). 
> What will happen in that case?

IMHO, the server should only return the most recent referral.

> Will there be multiple LISTEXT REFERRAL responses for each of the 
> renames? How is the client to determine which one of those corresponds 
> to the one it has cached (yes it could do STATUS on each of the 
> referral items listed and try to match UIDVALIDITY but that's ugly)?

... or referrals can be returned together with UIDVALIDITY for the 
renamed mailboxes.

> How long is the server supposed to maintain the referral information?

We can define some minimal required period, something around 1 week 
should be a reasonable default.
In the IMAP server I used to write this information was retained 
indefinitely, because developers didn't have time to write a utility to 
expire this data.

Alexey
__________________________________________
Isode Limited, http://www.isode.comhttp://www.melnikov.ca/mel/devel/Links.htmlhttp://www.melnikov.ca

IETF standard related pages:

Personal Home Page: 
__________________________________________

Date: Sun, 25 Apr 2004 18:31:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Extensions map
Sender: [email-masked]

Paul Hoffman / IMC wrote:

> At 5:45 PM +0100 4/25/04, Alexey Melnikov wrote:
>
>> I agree. But we should probably start with IMC web page, as it is the 
>> most obvious starting point when looking for this kind of information.
>
> I'm happy to make such a document available if someone else edits it. 
> If someone volunteers and creates a first draft, and the IMAP 
> community agrees that the person is a good keeper of the document, let 
> me know: I'll make it easy for the document to live on the IMAPext web 
> page. 

Actually, I was thinking about starting with something simple. For 
example a table that shows which extensions have dependencies, and which 
RFC/draft defines them.

Alexey

Date: Sun, 25 Apr 2004 18:28:02 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Alexey Melnikov wrote:

> Cyrus Daboo wrote:
>
>> Hi Alexey,
>>
>> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
>> <[email-masked]> wrote:
>>
>> |> However, I agree it is easy to overlook interactions like this. So as
>> |> an alternative, how about requiring IMAP extension documents (new 
>> ones
>> |> and revisions to old ones) to include an 'Implementation
>> |> Considerations' section that explicitly tells implementers to take
>> |> into account the interaction of the new extension with any existing
>> |> ones supported, or other new ones being added at the same time.
>> |
>> | Sounds good. So, you will do a quick revision with this change?
>>
>> OK. Below is some proposed text which I can add to ANNOTATE and 
>> ANNOTATEMORE right after the Security Considerations section in each. 
>> Lets see if we can agree on some general text for this that can be 
>> reused in other extensions.
>>
>>
>> Implementation Considerations
>>
>> When adding support for this extension you MUST check all other 
>> extensions currently supported, and any additional extensions being 
>> added at the same time, to ensure that all dependencies and 
>> interactions between the different extensions are fully implemented. 
>> This is important as the dependency between different extensions may 
>> only be described in one of the extension documents - likely the one 
>> that was defined after the other - yet extensions may be implemented 
>> in any order. Thus support for existing extensions may need to be 
>> modified when new ones are added. 
>
One of the advantages of having separate SORT=ANNOTATE and ANNOTATE is 
that it is nearly impossible to make such mistake. In order for the 
server to be able to sort annotations, the server implementers must 
explicitly report new capability.
I suspect that most server vendors implement a particular extension once 
(and very often an early draft). Not everybody is going to track changes 
to extensions.

Alexey

Date: Sun, 25 Apr 2004 10:14:09 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Extensions map (was: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt)
Sender: [email-masked]

At 5:45 PM +0100 4/25/04, Alexey Melnikov wrote:
>I agree. But we should probably start with IMC web page, as it is 
>the most obvious starting point when looking for this kind of 
>information.

I'm happy to make such a document available if someone else edits it. 
If someone volunteers and creates a first draft, and the IMAP 
community agrees that the person is a good keeper of the document, 
let me know: I'll make it easy for the document to live on the 
IMAPext web page.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 25 Apr 2004 18:13:02 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
> |> However, I agree it is easy to overlook interactions like this. So as
> |> an alternative, how about requiring IMAP extension documents (new ones
> |> and revisions to old ones) to include an 'Implementation
> |> Considerations' section that explicitly tells implementers to take
> |> into account the interaction of the new extension with any existing
> |> ones supported, or other new ones being added at the same time.
> |
> | Sounds good. So, you will do a quick revision with this change?
>
> OK. Below is some proposed text which I can add to ANNOTATE and 
> ANNOTATEMORE right after the Security Considerations section in each. 
> Lets see if we can agree on some general text for this that can be 
> reused in other extensions.
>
>
> Implementation Considerations
>
> When adding support for this extension you MUST check all other 
> extensions currently supported, and any additional extensions being 
> added at the same time, to ensure that all dependencies and 
> interactions between the different extensions are fully implemented. 
> This is important as the dependency between different extensions may 
> only be described in one of the extension documents - likely the one 
> that was defined after the other - yet extensions may be implemented 
> in any order. Thus support for existing extensions may need to be 
> modified when new ones are added.

Although, I agree with the text, I don't think it really helps to solve 
the problem.

I would rather if you add a new section called "Dependencies" and 
mention interaction between SORT and ANNOTATE.

Alexey

Date: Sun, 25 Apr 2004 18:09:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Cyrus Daboo wrote:

> This brings up another issue - isn't LISTEXT supposed to replace RLIST? 

Yes.

> Right now a server would have to support both the RLIST command and 
> LISTEXT commands. Ideally the server should only have to support 
> LISTEXT and the referral responses codes in the RLIST extension, 
> without having to implement the RLIST command itself. 

Yes. That is why I've mentioned that we need to make a revision of the 
RFC 2193 ("IMAP4 Mailbox Referrals").

Alexey

Date: Sun, 25 Apr 2004 13:04:09 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Hi Alexey,

--On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

|> However, I agree it is easy to overlook interactions like this. So as
|> an alternative, how about requiring IMAP extension documents (new ones
|> and revisions to old ones) to include an 'Implementation
|> Considerations' section that explicitly tells implementers to take
|> into account the interaction of the new extension with any existing
|> ones supported, or other new ones being added at the same time.
|
| Sounds good. So, you will do a quick revision with this change?

OK. Below is some proposed text which I can add to ANNOTATE and 
ANNOTATEMORE right after the Security Considerations section in each. Lets 
see if we can agree on some general text for this that can be reused in 
other extensions.

Implementation Considerations

When adding support for this extension you MUST check all other extensions 
currently supported, and any additional extensions being added at the same 
time, to ensure that all dependencies and interactions between the 
different extensions are fully implemented. This is important as the 
dependency between different extensions may only be described in one of the 
extension documents - likely the one that was defined after the other - yet 
extensions may be implemented in any order. Thus support for existing 
extensions may need to be modified when new ones are added.

-- 
Cyrus Daboo

Date: Sun, 25 Apr 2004 12:54:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Hi Alexey,

--On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

| Ok, I will try to give several examples to demonstrate how the server
| works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a
| bit lengthy, but I hope this will clarify some things.

OK - thanks for the explanation - it does seem to me that this is trying to 
tackle a mailbox synchronization problem as I originally thought. Note that 
the RLIST document does not say anything about its referral mechanism being 
used as a means to keep disconnected clients in sync. It also explicitly 
states that the referral mechanism it describes is meant to be used for 
cases where mailboxes are moved between different servers, whereas REFERRAL 
in LISTEXT also includes the case for mailboxes moved on the same server.

I don't think what's in LISTEXT will work - there are several cases I can 
give. Perhaps the best is how to deal with a mailbox that's been renamed 
multiple times whilst a client was disconnected (e.g. a mailbox that is 
archived at regular intervals - daily, weekly etc). What will happen in 
that case? Will there be multiple LISTEXT REFERRAL responses for each of 
the renames? How is the client to determine which one of those corresponds 
to the one it has cached (yes it could do STATUS on each of the referral 
items listed and try to match UIDVALIDITY but that's ugly)? How long is the 
server supposed to maintain the referral information?

This brings up another issue - isn't LISTEXT supposed to replace RLIST? 
Right now a server would have to support both the RLIST command and LISTEXT 
commands. Ideally the server should only have to support LISTEXT and the 
referral responses codes in the RLIST extension, without having to 
implement the RLIST command itself.

-- 
Cyrus Daboo

Date: Sun, 25 Apr 2004 17:45:30 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
> | I've sent a list of (mostly) editorial issues to Randy and Cyrus and 
> they
> | got addressed by the latest revision.
> | But one question still remains. Cyrus has asked me to forward it to the
> | mailing list:
> |
> | Section "8.9 ANNOTATION Key in SORT"
> |
> |  >       ANNOTATION <entry-name> <attribute-name>
> |  > >   The ANNOTATION criterion for the SORT command [SORT] 
> instructs the
> |  >   server to return the message numbers or UIDs of a mailbox, sorted
> |  >   using the values of the specified annotations.  The ANNOTATION
> |  >   criterion is available if the server returns both "ANNOTATE" and
> |  >   "SORT" as supported capabilities in the CAPABILITY command 
> response.
> |
> | I really don't like when new functionality is required if two other
> | extensions are implemented.
> | If somebody implements ANNOTATE in a server first and than adds SORT
> | support, it is very easy to miss this bit. Unfortunately I've seen
> | several documents already that do this. So I would recommend new
> | capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE
> | document).
>
> I am just worried about the possibility of combinatorial explosion of 
> capabilities as a result of this.

Frankly I am not that worried (yet).

> However, I agree it is easy to overlook interactions like this. So as 
> an alternative, how about requiring IMAP extension documents (new ones 
> and revisions to old ones) to include an 'Implementation 
> Considerations' section that explicitly tells implementers to take 
> into account the interaction of the new extension with any existing 
> ones supported, or other new ones being added at the same time.

Sounds good. So, you will do a quick revision with this change?

> That reminder in the document may suffice. It might also be useful to 
> have an informational document that gets updated at regular intervals 
> that summarizes all existing extensions and describes the dependencies 
> between each of them. That could be part of a revised implementation 
> guide or a separate document. 

I agree. But we should probably start with IMC web page, as it is the 
most obvious starting point when looking for this kind of information.

Alexey

Date: Sun, 25 Apr 2004 12:08:36 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

Hi Alexey,

--On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

| I've sent a list of (mostly) editorial issues to Randy and Cyrus and they
| got addressed by the latest revision.
| But one question still remains. Cyrus has asked me to forward it to the
| mailing list:
|
| Section "8.9 ANNOTATION Key in SORT"
|
|  >       ANNOTATION <entry-name> <attribute-name>
|  > >   The ANNOTATION criterion for the SORT command [SORT] instructs the
|  >   server to return the message numbers or UIDs of a mailbox, sorted
|  >   using the values of the specified annotations.  The ANNOTATION
|  >   criterion is available if the server returns both "ANNOTATE" and
|  >   "SORT" as supported capabilities in the CAPABILITY command response.
|
| I really don't like when new functionality is required if two other
| extensions are implemented.
| If somebody implements ANNOTATE in a server first and than adds SORT
| support, it is very easy to miss this bit. Unfortunately I've seen
| several documents already that do this. So I would recommend new
| capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE
| document).

I am just worried about the possibility of combinatorial explosion of 
capabilities as a result of this. However, I agree it is easy to overlook 
interactions like this. So as an alternative, how about requiring IMAP 
extension documents (new ones and revisions to old ones) to include an 
'Implementation Considerations' section that explicitly tells implementers 
to take into account the interaction of the new extension with any existing 
ones supported, or other new ones being added at the same time. That 
reminder in the document may suffice. It might also be useful to have an 
informational document that gets updated at regular intervals that 
summarizes all existing extensions and describes the dependencies between 
each of them. That could be part of a revised implementation guide or a 
separate document.

-- 
Cyrus Daboo

Date: Sat, 24 Apr 2004 23:33:32 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Alexey Melnikov wrote:

> 5). Allow for referral information to be returned in response to LIST 
> (REFERRAL).
>
> Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
> document, no new capability for this. Reason: referral data can be 
> returned for a locally renamed mailbox (i.e. NEWNAME response code 
> replacement), no need to support  RFC 2193 for this. If the server 
> doesn't support referrals of any sort, this option will be ignored.

The relevant ABNF bit would be:

   referral_data = "REFERRAL" SP "(" urlstring *(SP urlstring) ")"

   urlstring = <"> url <">
      ; See [RFC-1738] for <url> definition

It seems that the current ABNF can't cope with this ("referral_data" (if 
taken in ()) should match "mbox-list-extended-item"):

   mbox-list-extended = "(" [mbox-list-extended-item
                        *(SP mbox-list-extended-item)] ")"

   mbox-list-extended-item = "(" string SP (nstring /
                             mbox-list-extended-item) ")"
                             / mailbox-list-extended

Anyway, no matter whether people think that REFERRAL belongs to the 
LISTEXT extension or not, I would like to change LISTEXT ABNF for
additional LIST data to allow sending REFERRAL response as suggested 
above. Any objections?

Alexey

Date: Sat, 24 Apr 2004 23:27:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------020404000502090201040907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
> |> I believe REFERRAL, as envisioned by Larry is designed for clusters
> |> like the Cyrus Murder so that a referral capable client can determine
> |> which mailboxes are located on a different server(s) w/o having to
> |> attempt a SELECT and wait for the referral to get the location of the
> |> mailbox.
> |
> | That was my idea as well.
>
> That's fine but trying to indicate rename's is going to be too 
> complicated. Perhaps you can write up a more detailed account of 
> exactly what REFERRAL is supposed to do, then maybe I will understand 
> the issues better... 

Ok, I will try to give several examples to demonstrate how the server 
works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a 
bit lengthy, but I hope this will clarify some things.

I will use the following list of local mailboxes:

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Apple"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

And let's assume there are two remote mailboxes visible locally (i.e. 
they are part of LIST (REMOTE) output) as "Bread" and "Meat".
Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and 
"Tofu" was renamed to "SoyProducts/Tofu".
And finally, let's assume that the name of the IMAP server is 
"imap.example.com".

In all cases below assume that the client is a disconnected client. An 
online client would unlikely to use LIST (REFERRAL) or LIST (REMOTE 
REFERRAL).
Let's also assume that the client wants to synchronize the following 
mailboxes: "inbox", "Fruit/Apple", "Fruit/Banana", "Tofu".

Scenario 1). LISTEXT-unaware client that doesn't care about remote 
mailboxes:

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

(case a - the client is a disconnected client that doesn't support 
remote mailboxes or referrals).

As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the 
resulting output, it will blow away local cache for those mailboxes and 
the changes would be lost.

(case b - same as case a, but it also supports MAILBOX-REFERRAL).

If the client (and the server) also supports MAILBOX-REFERRAL, before 
blowing away its cache it will try to select each of those mailboxes in 
a hope of figuring out if they were actually renamed:

      C: A02 SELECT "Fruit/Apple"
      S: A02 NO [REFERRAL 
IMAP://user;AUTH=[email-masked]/Fruit/Orange] Renamed mailbox.

      C: A03 SELECT "Fruit/Orange"
       ...synchronization...

      C: A12 SELECT "Tofu"
      S: A02 NO [REFERRAL 
IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu] Renamed mailbox.

      C: A13 SELECT "SoyProducts/Tofu"
       ...synchronization...

Synchronization of "inbox" and "Fruit/Banana" proceeds as usual:

      C: A22 SELECT "Fruit/Banana"
       ...synchronization...

Scenario 2). LISTEXT-aware client that doesn't care about remote 
mailboxes and doesn't support referrals:

This is very much the same as scenario 1a).

       C: A01 LIST () "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

As in scenario 1a: the client doesn't see mailboxes "Fruit/Apple" and 
"Tofu" in the resulting output, it will blow away local changes to those 
mailboxes.

Scenario 3). LISTEXT-aware client that doesn't care about remote 
mailboxes, but supports referrals.

       C: A01 LIST (REFERRAL) "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Fruit/Apple" ("REFERRAL" 
"IMAP://user;AUTH=[email-masked]/Fruit/Orange")
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: * LIST () "/" "Tofu" ("REFERRAL" 
"IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu")
       S: A01 OK done

The referral aware client will be able to synchronize changes even if 
some mailboxes are renamed (assuming the server is also able to report 
this information).
In addition, two unnecessary SELECT commands are eliminated and the 
client can proceed with mailbox synchronization for the renamed mailboxes:
      C: A02 SELECT "Fruit/Orange"
       ...synchronization...

      C: A12 SELECT "SoyProducts/Tofu"
       ...synchronization...

(Note, that the server is not allowed to return remote mailboxes when 
just REFERRAL is requested, the client doesn't even have to match
the server name in URLs with the local IMAP server name).

Further synchronization proceeds as usual.

Scenario 4). LISTEXT-aware client that supports both referrals and 
remote mailboxes.

       C: A01 LIST (REMOTE REFERRAL) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Fruit/Apple" ("REFERRAL" 
"IMAP://user;AUTH=[email-masked]/Fruit/Orange")
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: * LIST () "/" "Tofu" ("REFERRAL" 
"IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu")
       S: * LIST () "/" "Bread" ("REFERRAL" 
("IMAP://user;AUTH=[email-masked]/Bread"))
       S: * LIST () "/" "Meat" ("REFERRAL" 
("IMAP://user;AUTH=[email-masked]/Meat" 
"IMAP://user;AUTH=[email-masked]/SharedFolders/Meat"))
       S: A01 OK done

The client knows that "imap.example.com" is the name of the IMAP server 
the client is connected to, so it will be able to figure out that 
"Bread" and "Meat" are located on a different server(s).  The client 
should also be able to synchronize with a mailbox moved across servers.

Alexey

--------------020404000502090201040907
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
Cyrus Daboo wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">Hi Alexey, <br>
  <br>
--On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
wrote: <br>
  <br>
|&gt; I believe REFERRAL, as envisioned by Larry is designed for
clusters <br>
|&gt; like the Cyrus Murder so that a referral capable client can
determine <br>
|&gt; which mailboxes are located on a different server(s) w/o having
to <br>
|&gt; attempt a SELECT and wait for the referral to get the location of
the <br>
|&gt; mailbox. <br>
| <br>
| That was my idea as well. <br>
  <br>
That's fine but trying to indicate rename's is going to be too
complicated. Perhaps you can write up a more detailed account of
exactly what REFERRAL is supposed to do, then maybe I will understand
the issues better...
</blockquote>
Ok, I will try to give several examples to demonstrate how the server
works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is
a bit lengthy, but I hope
this will clarify some things.<br>
<br>
I will use the following list of local mailboxes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
And let's assume there are two remote mailboxes visible locally (i.e.
they are part of LIST (REMOTE) output) as "Bread" and "Meat".<br>
Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and
"Tofu" was renamed to "SoyProducts/Tofu".<br>
And finally, let's assume that the name of the IMAP server is
"imap.example.com".<br>
<br>
In all cases below assume that the client is a disconnected client. An
online client would unlikely to use LIST (REFERRAL) or LIST (REMOTE
REFERRAL).<br>
<font color="#000000">Let's also assume that the client </font><font
 color="#000000">wants to
synchronize the following mailboxes: "inbox", "Fruit/Apple",
"Fruit/Banana", "Tofu".<br>
</font><br>
Scenario 1). LISTEXT-unaware client that doesn't care about remote
mailboxes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
(case a - the client is a disconnected client that doesn't support
remote mailboxes or referrals).<br>
<br>
As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the
resulting output, <b>it will blow away local cache for those </b><b>mailboxes
and the changes would be lost</b><b>.<br>
<br>
</b>(case b - same as case a, but it also supports MAILBOX-REFERRAL).<br>
<br>
If the client (and the server) also supports MAILBOX-REFERRAL, before
blowing away its cache it will try to select each of those mailboxes in
a hope of figuring out if they were actually renamed:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A02 SELECT "Fruit/Apple"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A02 NO [REFERRAL
<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/Fruit/Orange">IMAP://user;AUTH=[email-masked]/Fruit/Orange</a>]
Renamed mailbox.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A03 SELECT "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A12 SELECT "Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A02 NO [REFERRAL
<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu</a>]
Renamed mailbox.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A13 SELECT "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
Synchronization of "inbox" and "Fruit/Banana" proceeds as usual:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A22 SELECT "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
Scenario 2). LISTEXT-aware client that doesn't care about remote
mailboxes and doesn't support referrals:<br>
<br>
This is very much the same as scenario 1a).<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST () "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
As in scenario 1a: the client doesn't see mailboxes "Fruit/Apple" and
"Tofu" in the
resulting output, it will blow away local changes to those mailboxes.<b><br>
</b><br>
Scenario 3). LISTEXT-aware client that doesn't care about remote
mailboxes, but supports referrals.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST (REFERRAL) "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/Fruit/Orange">IMAP://user;AUTH=[email-masked]/Fruit/Orange</a>")<br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu")</a><br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
<br>
The referral aware client will be able to synchronize changes even if
some mailboxes are renamed (assuming the server is also able to report
this information).<br>
In addition, two unnecessary SELECT commands are eliminated and the
client can proceed with mailbox synchronization for the renamed
mailboxes:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A02 SELECT "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A12 SELECT "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
(Note, that the server is not allowed to return remote mailboxes
when just REFERRAL is requested, the client doesn't even have to match<br>
the server name in URLs with the local IMAP server name).<br>
<br>
Further synchronization proceeds as usual.<br>
<br>
Scenario 4). LISTEXT-aware client that supports both referrals and
remote
mailboxes.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST (REMOTE REFERRAL) "" "%"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/Fruit/Orange">IMAP://user;AUTH=[email-masked]/Fruit/Orange</a>")<br>
</b>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu")</a><br>
</b><font color="#33cc00">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Bread" ("REFERRAL"
(</font><b>"<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/Bread"</a></b><font
 color="#33cc00">))<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Meat" ("REFERRAL" (</font><b>"<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/Meat"</a></b><font
 color="#33cc00"> </font><b>"<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=[email-masked]/SoyProducts/Tofu">IMAP://user;AUTH=[email-masked]/SharedFolders/Meat"</a></b><font
 color="#33cc00">))<br>
</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
<font color="#000000">The client knows that "imap.example.com" is the
name of the IMAP
server the client is connected to, so it will be able to figure out
that "Bread" and "Meat" are located on a different server(s).&nbsp; The
client should also be able to </font><font color="#000000">synchronize
with a mailbox moved across
servers.<br>
<br>
Alexey<br>
</font><b><font color="#33cc00"><br>
</font></b>
</body>
</html>

--------------020404000502090201040907--

Date: Sat, 24 Apr 2004 21:09:47 +0100
From: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Sender: [email-masked]

I've sent a list of (mostly) editorial issues to Randy and Cyrus and 
they got addressed by the latest revision.
But one question still remains. Cyrus has asked me to forward it to the 
mailing list:

Section "8.9 ANNOTATION Key in SORT"

 >       ANNOTATION <entry-name> <attribute-name>
 > >   The ANNOTATION criterion for the SORT command [SORT] instructs the
 >   server to return the message numbers or UIDs of a mailbox, sorted
 >   using the values of the specified annotations.  The ANNOTATION
 >   criterion is available if the server returns both "ANNOTATE" and
 >   "SORT" as supported capabilities in the CAPABILITY command response.

I really don't like when new functionality is required if two other 
extensions are implemented.
If somebody implements ANNOTATE in a server first and than adds SORT 
support, it is very easy to miss this bit. Unfortunately I've seen 
several documents already that do this. So I would recommend new 
capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE 
document).

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-09.txt
Date: Tue, 20 Apr 2004 15:51:41 -0400
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-09.txt
	Pages		: 26
	Date		: 2004-4-20
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-09.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-09.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-09.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-09.txt

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

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

--OtherAccess--

--NextPart--

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Date: Wed, 14 Apr 2004 11:49:03 -0400
Sender: [email-masked]

> I think this is the case for LISTEXT as written now. I.e. unless the client 
> specified LIST (CHILDREN), the server is not required to return \HasChildren 
> or \HasNoChildren.

Yes, Alexey is correct that this was the intent of LISTEXT.

> I don't care either way.  I can live with mandatory-to-implement children 
> functionality as long as it is not mandatory-to-execute.

And that was the point, and Mark's objection is the reason it was written
that way.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 13 Apr 2004 11:09:59 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Hi Alexey,

--On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov 
<[email-masked]> wrote:

|> I believe REFERRAL, as envisioned by Larry is designed for clusters
|> like the Cyrus Murder so that a referral capable client can determine
|> which mailboxes are located on a different server(s) w/o having to
|> attempt a SELECT and wait for the referral to get the location of the
|> mailbox.
|
| That was my idea as well.

That's fine but trying to indicate rename's is going to be too complicated. 
Perhaps you can write up a more detailed account of exactly what REFERRAL 
is supposed to do, then maybe I will understand the issues better...

-- 
Cyrus Daboo

Date: Tue, 13 Apr 2004 10:59:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Philip Guenther wrote:

>>> b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
>>>    enough for them?
>>>      
>>>
>>This will work, but the client will have to SELECT each one of them in 
>>order to find out. A LIST will return this information in one go.
>>    
>>
>
>Doesn't a disconnected client normally SELECT each synchronized
>mailbox whenever it connects so that it can pull down updates from
>the server?  How often is a client *only* interested in whether the
>mailbox was renamed (or deleted) and no in whether its contents
>changed?
>
The client is not interested in selecting the old name, it will select 
the new one (target of the referral). LIST (REFERRAL) will give this 
information.

>>> (Oh, and they're going to have a fun time synchronizing, given that
>>> the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
>>>      
>>>
>>RENAME is required to preserve UIDVALIDITY.
>>    
>>
>
>That certainly isn't in rfc3501.  If a server can give two mailboxes
>the same UIDVALIDITY then it's possible to set up a situation where
>RENAME MUST change the UIDVALIDITY of the renamed mailbox:
>  let TARG and SRC be mailboxes with the same UIDVALIDITY
>	a1 RENAME TARG SOMETHING-ELSE
>	a2 RENAME SRC TARG
>  that second RENAME can't preserve TARG's UIDVALIDITY across the
>  rename without violating the last item in section 2.3.1.1
>
>This was discussed here at some point and led to some discussion
>of a possible NEW-UIDVALIDITY response code for telling clients
>that the UIDVALIDITY on a mailbox changed during a RENAME without
>actually altering UIDs.
>
Ok, I remember about this case ;-), however it is less common in real life.

Alexey

Date: Tue, 13 Apr 2004 10:57:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Ken Murchison wrote:

> Cyrus Daboo wrote:
>
>> It seems to me that the REFERRAL is an attempt to implement some kind 
>> of mailbox list synchronisation feature to allow disconnected clients 
>> to sync there mailbox state with the server - if that is not the 
>> intent than can Alexey explain in more detail what its supposed to 
>> do. What was proposed by Alexey is not sufficient to do mailbox list 
>> sync properly. I think REFERRAL should not be implemented in LISTEXT 
>> right now. Instead, if there is demand, a proper mailbox list sync 
>> extension (that may or may not use LISTEXT) should be designed to do 
>> the job properly. I suspect that some form of mailbox UID, globally 
>> unique across the server's mailstore, will be the best way to do that 
>> so that clients and servers can use the MUIDs to sync up their lists. 
>> However this is out of scope for LISTEXT and imapext right now.
>
> I believe REFERRAL, as envisioned by Larry is designed for clusters 
> like the Cyrus Murder so that a referral capable client can determine 
> which mailboxes are located on a different server(s) w/o having to 
> attempt a SELECT and wait for the referral to get the location of the 
> mailbox.

That was my idea as well.

Alexey

Date: Mon, 12 Apr 2004 20:49:24 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Cyrus Daboo wrote:

> It seems to me that the REFERRAL is an attempt to implement some kind of 
> mailbox list synchronisation feature to allow disconnected clients to 
> sync there mailbox state with the server - if that is not the intent 
> than can Alexey explain in more detail what its supposed to do. What was 
> proposed by Alexey is not sufficient to do mailbox list sync properly. I 
> think REFERRAL should not be implemented in LISTEXT right now. Instead, 
> if there is demand, a proper mailbox list sync extension (that may or 
> may not use LISTEXT) should be designed to do the job properly. I 
> suspect that some form of mailbox UID, globally unique across the 
> server's mailstore, will be the best way to do that so that clients and 
> servers can use the MUIDs to sync up their lists. However this is out of 
> scope for LISTEXT and imapext right now.

I believe REFERRAL, as envisioned by Larry is designed for clusters like 
the Cyrus Murder so that a referral capable client can determine which 
mailboxes are located on a different server(s) w/o having to attempt a 
SELECT and wait for the referral to get the location of the mailbox.

-- 
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: Mon, 12 Apr 2004 17:01:39 -0400
From: Cyrus Daboo <[email-masked]>
To: Philip Guenther <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT 
Sender: [email-masked]

Hi Philip,

--On Monday, April 12, 2004 12:37:27 PM -0700 Philip Guenther 
<[email-masked]> wrote:

|> This will work, but the client will have to SELECT each one of them in
|> order to find out. A LIST will return this information in one go.
|
| Doesn't a disconnected client normally SELECT each synchronized
| mailbox whenever it connects so that it can pull down updates from
| the server?  How often is a client *only* interested in whether the
| mailbox was renamed (or deleted) and no in whether its contents
| changed?
|
|
|>>  (Oh, and they're going to have a fun time synchronizing, given that
|>>  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
|>>
|> RENAME is required to preserve UIDVALIDITY.
|
| That certainly isn't in rfc3501.  If a server can give two mailboxes
| the same UIDVALIDITY then it's possible to set up a situation where
| RENAME MUST change the UIDVALIDITY of the renamed mailbox:
|   let TARG and SRC be mailboxes with the same UIDVALIDITY
| 	a1 RENAME TARG SOMETHING-ELSE
| 	a2 RENAME SRC TARG
|   that second RENAME can't preserve TARG's UIDVALIDITY across the
|   rename without violating the last item in section 2.3.1.1
|
| This was discussed here at some point and led to some discussion
| of a possible NEW-UIDVALIDITY response code for telling clients
| that the UIDVALIDITY on a mailbox changed during a RENAME without
| actually altering UIDs.
|
|
| ...
|>> It's never been entirely clear to me how mailbox referrals (in the
|>> rfc2193 sense) were intended to be presented by clients.  While I'm not
|>> a client implementor and therefore don't *need* an answer to that, it
|>> does seem to bear on whether it's wise to reuse the same mechanism for
|>> the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
|>> When a client that displays the mailbox hierarchy in some form gets back
|>> a referral response, should it use the referral to the alter/update the
|>> display or should it hide the indirection from the end user?
|>>
|> It depends. Some clients allow to configure different choices, like
|> "resolve referrals automatically", "don't show referrals", etc. Other
|> will show a different icon in a mailbox tree. The user has to double
|> click on the icon to resolve it. I don't think there is a single right
|> answer to this question.
|
| So some clients or users may choose to handle them differently then
| they would handle a "mailbox rename" REFERRAL?  How is a client
| supposed to tell apart "rename" and "remote" REFERRALs, given that
| the server may have a different idea than the client of what the
| server's hostname is?  Is the server required to use relative IMAP
| URLs for "rename" REFERRALs?

It seems to me that the REFERRAL is an attempt to implement some kind of 
mailbox list synchronisation feature to allow disconnected clients to sync 
there mailbox state with the server - if that is not the intent than can 
Alexey explain in more detail what its supposed to do. What was proposed by 
Alexey is not sufficient to do mailbox list sync properly. I think REFERRAL 
should not be implemented in LISTEXT right now. Instead, if there is 
demand, a proper mailbox list sync extension (that may or may not use 
LISTEXT) should be designed to do the job properly. I suspect that some 
form of mailbox UID, globally unique across the server's mailstore, will be 
the best way to do that so that clients and servers can use the MUIDs to 
sync up their lists. However this is out of scope for LISTEXT and imapext 
right now.

-- 
Cyrus Daboo

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT 
Date: Mon, 12 Apr 2004 12:37:27 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>Philip Guenther wrote:
>>Alexey Melnikov <[email-masked]> writes:
...
>>So this is suggesting that LIST (REFERRAL) would show all the matching
>>mailboxes that either
...
>>b) currently exist as a referral to another server, or
>
>No, b) is only returned for LIST (REFERRAL REMOTE)

Ah, okay.

...
>>- what's a client supposed to do with a "renamed" referral anyway?  If
>>  it's for synchronization of disconnected clients then
>>
>yes.

>>  b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
>>     enough for them?
>>
>This will work, but the client will have to SELECT each one of them in 
>order to find out. A LIST will return this information in one go.

Doesn't a disconnected client normally SELECT each synchronized
mailbox whenever it connects so that it can pull down updates from
the server?  How often is a client *only* interested in whether the
mailbox was renamed (or deleted) and no in whether its contents
changed?

>>  (Oh, and they're going to have a fun time synchronizing, given that
>>  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
>>
>RENAME is required to preserve UIDVALIDITY.

That certainly isn't in rfc3501.  If a server can give two mailboxes
the same UIDVALIDITY then it's possible to set up a situation where
RENAME MUST change the UIDVALIDITY of the renamed mailbox:
  let TARG and SRC be mailboxes with the same UIDVALIDITY
	a1 RENAME TARG SOMETHING-ELSE
	a2 RENAME SRC TARG
  that second RENAME can't preserve TARG's UIDVALIDITY across the
  rename without violating the last item in section 2.3.1.1

This was discussed here at some point and led to some discussion
of a possible NEW-UIDVALIDITY response code for telling clients
that the UIDVALIDITY on a mailbox changed during a RENAME without
actually altering UIDs.

...
>>It's never been entirely clear to me how mailbox referrals (in the
>>rfc2193 sense) were intended to be presented by clients.  While I'm not
>>a client implementor and therefore don't *need* an answer to that, it
>>does seem to bear on whether it's wise to reuse the same mechanism for
>>the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
>>When a client that displays the mailbox hierarchy in some form gets back
>>a referral response, should it use the referral to the alter/update the
>>display or should it hide the indirection from the end user?
>>
>It depends. Some clients allow to configure different choices, like 
>"resolve referrals automatically", "don't show referrals", etc. Other 
>will show a different icon in a mailbox tree. The user has to double 
>click on the icon to resolve it. I don't think there is a single right 
>answer to this question.

So some clients or users may choose to handle them differently then
they would handle a "mailbox rename" REFERRAL?  How is a client
supposed to tell apart "rename" and "remote" REFERRALs, given that
the server may have a different idea than the client of what the
server's hostname is?  Is the server required to use relative IMAP
URLs for "rename" REFERRALs?

Philip Guenther

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-05.txt
Date: Mon, 12 Apr 2004 15:32:42 -0400
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
	Filename	: draft-ietf-imapext-list-extensions-05.txt
	Pages		: 8
	Date		: 2004-4-12
	
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-05.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-05.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-05.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-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 12 Apr 2004 20:00:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> writes:
>...
>  
>
>>5). Allow for referral information to be returned in response to LIST 
>>(REFERRAL).
>>
>>Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
>>document, no new capability for this. Reason: referral data can be 
>>returned for a locally renamed mailbox (i.e. NEWNAME response code 
>>replacement), no need to support  RFC 2193 for this. If the server 
>>doesn't support referrals of any sort, this option will be ignored.
>>    
>>
>
>So this is suggesting that LIST (REFERRAL) would show all the matching
>mailboxes that either
>a) currently exist locally, or
>  
>
Yes.

>b) currently exist as a referral to another server, or
>  
>
No, b) is only returned for LIST (REFERRAL REMOTE)

>c) did exist and were renamed
>  
>
Yes.

>with support for the mechanisms behind (b) and (c) being optional?
>
Yes (c) is optional)

>Item (c) seems really weird, such that I simultaneously have doubts
>about its usefulness, the ambiguity it creates, the clutter it will add
>to listing, and the possibly security implications.
>
>In reverse order:
>- what ACL controls whether you can see the referral for a mailbox that
>  was renamed: the ACL on the new name or the ACL on the name at the
>  time of the rename?  Is there any way to control that visibility
>  independent of the visibility of the current name?
>  
>
That is is a good question and I have to think about this :-).

>- is there any way to get rid of a "renamed" referral beyond, say,
>  creating and deleting a new mailbox under that name, a method that has
>  an obvious race condition with someone really trying to create the
>  name?
>  (New DoS attack: repeatedly rename a publicly visible folder, so that
>	tag LIST (REFERRAL) "" *
>  returns a few thousand "renamed" entries)
>  
>
I haven't thought about doing this through the IMAP, but an 
implementation may "expire" local referrals after some time.

>- will "renamed" referrals be flagged differently than "true" referrals
>
No, I can't see how is this different. "renamed" referral is a referral 
that points to the same server.

>  and normal mailboxes in the listing?
>
Yes. Normal mailboxes will not have "("REFERRAL" ...)" part in the 
corresponding untagged LIST response.

>  If not, then you have a list of
>  mailboxes that may or may not currently exist, which seems less than
>  completely useful.
>
>- what's a client supposed to do with a "renamed" referral anyway?  If
>  it's for synchronization of disconnected clients then
>
yes.

>  a) that's a pretty narrow target audience; wouldn't a narrow "renamed
>     only" list extension be more useful for them?
>  
>
If you don't want them, don't specify REFERRAL option in LIST.

>  b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
>     enough for them?
>
This will work, but the client will have to SELECT each one of them in 
order to find out. A LIST will return this information in one go.

>  (Oh, and they're going to have a fun time synchronizing, given that
>  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
>
RENAME is required to preserve UIDVALIDITY.

>
>Indeed, several of those also apply to the original NEWNAME response and
>the alluded to use of REFERRAL responses in NEWNAME's place.  Can anyone
>explain to me what NEWNAME was supposed to be used for and how any
>existing (or pre-3501) clients react to it?  Without an understanding of
>the problem being solved, I don't know whether LIST (REFERRAL) is
>necessary or useful in solving it.
>
>
>While I'm on the subject...
>
>It's never been entirely clear to me how mailbox referrals (in the
>rfc2193 sense) were intended to be presented by clients.  While I'm not
>a client implementor and therefore don't *need* an answer to that, it
>does seem to bear on whether it's wise to reuse the same mechanism for
>the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
>When a client that displays the mailbox hierarchy in some form gets back
>a referral response, should it use the referral to the alter/update the
>display or should it hide the indirection from the end user?
>
It depends. Some clients allow to configure different choices, like 
"resolve referrals automatically", "don't show referrals", etc. Other 
will show a different icon in a mailbox tree. The user has to double 
click on the icon to resolve it. I don't think there is a single right 
answer to this question.

>  For
>example, should the user selecting a mailbox in a hierarchy display
>result in a 'reparenting' of the selected mailbox if the original server
>returned a referral specifying another server, or should it simply chase
>the reference and display the folder in place?
>  
>
>>Related to this: do a revision of RFC 2193 that is using LISTEXT 
>>framework (in particular obsolete RLIST/RLSUB).
>>    
>>
>
>It would be nice to clarify such points as whether a remote referral may
>have a different path than the local name, what ACL controls the
>visibility of a remote referrals (does it depend on the command?  Does
>the referral have an ACL distinct from the target mailbox?),
>
I think this is related to one of the questions above, so I will think 
about this as well.

> and what
>section 4.2 means when it says "...because a home server is required to
>maintain a listing of referred remote mailboxes..."
>
>  
>
Alexey

Date: Mon, 12 Apr 2004 10:45:05 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 12 Apr 2004, Alexey Melnikov wrote:
> I think this is the case for LISTEXT as written now. I.e. unless the client 
> specified LIST (CHILDREN), the server is not required to return \HasChildren 
> or \HasNoChildren.

This is fine with me.

> Mark would you prefer a separate LIST-CHILDREN capability (as I currently 
> do), or can you live with the LISTEXT document as written?

I don't care either way.  I can live with mandatory-to-implement children 
functionality as long as it is not mandatory-to-execute.

-- Mark --

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

Date: Mon, 12 Apr 2004 18:22:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Mark Crispin wrote:

> On Sun, 11 Apr 2004, Alexey Melnikov wrote:
>
>> I personally don't like CHILDREN, so I would like to see 
>> LIST-CHILDREN capability, as was suggested by Mark. But I can live 
>> with it being part of the LISTEXT extension.
>
>
> FWIW:
>
> I do not think that a server should be obligated to advertise children 
> unless a client explicitly says that it is interested in such 
> information.
>
> I do not think that mere use of LISTEXT instead of LIST suffices to 
> indicate such interest. 

Ok, is there anybody who will say "I will die if CHILDREN is not part of 
LISTEXT" :-)?

> As a compromise, I'm agreeable to children support being mandatory in 
> LISTEXT without requiring a capability; but nevertheless a server 
> should not be required to do the work unless the client specifically 
> asks for children. 

I think this is the case for LISTEXT as written now. I.e. unless the 
client specified LIST (CHILDREN), the server is not required to return 
\HasChildren or \HasNoChildren.

Mark would you prefer a separate LIST-CHILDREN capability (as I 
currently do), or can you live with the LISTEXT document as written?

> Put another way, I consider RFC 3348 to be broken, since it:
>  1) adds an unnecessary CHILDREN extension
>  2) requires a server supporting children to do the work even for a
>     client that does not care.
>
> I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead 
> simply urged that it be Informational.  However, the sooner we move 
> towards LISTEXT and declaring RFC 3348 an obsolete false start, the 
> better in my view.

Alexey

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Collected issues with LISTEXT 
Date: Mon, 12 Apr 2004 01:15:47 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>5). Allow for referral information to be returned in response to LIST 
>(REFERRAL).
>
>Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
>document, no new capability for this. Reason: referral data can be 
>returned for a locally renamed mailbox (i.e. NEWNAME response code 
>replacement), no need to support  RFC 2193 for this. If the server 
>doesn't support referrals of any sort, this option will be ignored.

So this is suggesting that LIST (REFERRAL) would show all the matching
mailboxes that either
a) currently exist locally, or
b) currently exist as a referral to another server, or
c) did exist and were renamed
with support for the mechanisms behind (b) and (c) being optional?

Item (c) seems really weird, such that I simultaneously have doubts
about its usefulness, the ambiguity it creates, the clutter it will add
to listing, and the possibly security implications.

In reverse order:
- what ACL controls whether you can see the referral for a mailbox that
  was renamed: the ACL on the new name or the ACL on the name at the
  time of the rename?  Is there any way to control that visibility
  independent of the visibility of the current name?

- is there any way to get rid of a "renamed" referral beyond, say,
  creating and deleting a new mailbox under that name, a method that has
  an obvious race condition with someone really trying to create the
  name?
  (New DoS attack: repeatedly rename a publicly visible folder, so that
	tag LIST (REFERRAL) "" *
  returns a few thousand "renamed" entries)

- will "renamed" referrals be flagged differently than "true" referrals
  and normal mailboxes in the listing?  If not, then you have a list of
  mailboxes that may or may not currently exist, which seems less than
  completely useful.

- what's a client supposed to do with a "renamed" referral anyway?  If
  it's for synchronization of disconnected clients then
  a) that's a pretty narrow target audience; wouldn't a narrow "renamed
     only" list extension be more useful for them?
  b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
     enough for them?
  (Oh, and they're going to have a fun time synchronizing, given that
  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)

Indeed, several of those also apply to the original NEWNAME response and
the alluded to use of REFERRAL responses in NEWNAME's place.  Can anyone
explain to me what NEWNAME was supposed to be used for and how any
existing (or pre-3501) clients react to it?  Without an understanding of
the problem being solved, I don't know whether LIST (REFERRAL) is
necessary or useful in solving it.

While I'm on the subject...

It's never been entirely clear to me how mailbox referrals (in the
rfc2193 sense) were intended to be presented by clients.  While I'm not
a client implementor and therefore don't *need* an answer to that, it
does seem to bear on whether it's wise to reuse the same mechanism for
the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
When a client that displays the mailbox hierarchy in some form gets back
a referral response, should it use the referral to the alter/update the
display or should it hide the indirection from the end user?  For
example, should the user selecting a mailbox in a hierarchy display
result in a 'reparenting' of the selected mailbox if the original server
returned a referral specifying another server, or should it simply chase
the reference and display the folder in place?

>Related to this: do a revision of RFC 2193 that is using LISTEXT 
>framework (in particular obsolete RLIST/RLSUB).

It would be nice to clarify such points as whether a remote referral may
have a different path than the local name, what ACL controls the
visibility of a remote referrals (does it depend on the command?  Does
the referral have an ACL distinct from the target mailbox?), and what
section 4.2 means when it says "...because a home server is required to
maintain a listing of referred remote mailboxes..."

Philip Guenther
[email-masked]

Date: Sun, 11 Apr 2004 10:47:27 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

On Sun, 11 Apr 2004, Alexey Melnikov wrote:
> I personally don't like CHILDREN, so I would like to see LIST-CHILDREN 
> capability, as was suggested by Mark. But I can live with it being part of 
> the LISTEXT extension.

FWIW:

I do not think that a server should be obligated to advertise children 
unless a client explicitly says that it is interested in such information.

I do not think that mere use of LISTEXT instead of LIST suffices to 
indicate such interest.

As a compromise, I'm agreeable to children support being mandatory in 
LISTEXT without requiring a capability; but nevertheless a server should 
not be required to do the work unless the client specifically asks for 
children.

Put another way, I consider RFC 3348 to be broken, since it:
  1) adds an unnecessary CHILDREN extension
  2) requires a server supporting children to do the work even for a
     client that does not care.

I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead 
simply urged that it be Informational.  However, the sooner we move 
towards LISTEXT and declaring RFC 3348 an obsolete false start, the better 
in my view.

-- Mark --

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

Date: Sun, 11 Apr 2004 15:55:56 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: List of changes for LISTEXT revision
Sender: [email-masked]

I've just submitted an updated revision of
draft-ietf-imapext-list-extensions. It should be announced soon.
Below is the list of editorial changes I've made:

Abstract must not be numbered. Also found and fixed a wrong section
reference.
Added IPR and Full Copyright.
Updated IMAP4rev1 reference.
Fixed couple of typos.
Reformatted ABNF section for readability.
Split References into Normative and Informative.
Changed LIST response example not to reference ACL to avoid confusion
with ACL2 extension.
Added proper acknowledgments, let me know if I've missed someone.

Alexey

Date: Sun, 11 Apr 2004 15:27:45 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Collected issues with LISTEXT
Sender: [email-masked]

Hi everyone,
Below is the list of issues raised for LISTEXT document in the last 
couple of years. With each issue I am giving my personal suggestion what 
to do.

1) One LISTEXT capability versa LIST-CHILDREN, LIST-SUBSCRIBED, LIST-REMOTE

Suggestion: no LIST-REMOTE capability (for servers that don't support 
remote mailboxes REMOTE option to the LIST command is ignored).
Do a separate revision of RFC 2193 (RFC 2193 - informative reference for 
LISTEXT).

Mark agreed earlier to support LIST (SUBSCRIBED) as a part of LISTEXT 
(no new capability).

I personally don't like CHILDREN, so I would like to see LIST-CHILDREN 
capability, as was suggested by Mark. But I can live with it being part 
of the LISTEXT extension.

(Related to this) Ken proposed:
Using <LIST () "" ""> to detect LISTEXT extensions:

. LIST () "" ""
* LIST (SUBSCRIBED CHILDREN ACL2) "." ""

Cyrus proposed:
CAPABILITYPLUS

I would rather not delay LISTEXT any further by making it a dependency 
of CAPABILITYPLUS.
But if the WG feels that Ken proposal is useful, this should be added to 
LISTEXT. I think Ken's proposal doesn't preclude any future work on 
CAPABILITYPLUS.

2). Discussion about CHILDREN/LISTEXT interaction. If the server should 
advertise CHILDREN if it supports LISTEXT. And how a client that only 
supports CHILDREN will work with a LISTEXT server. This is somewhat 
related to 1).

(I don't have any opinion on this. Should I start a new thread and post 
a digest of issues here?)

3). Extending LIST syntax to allow for additional parameter to a list 
option, e.g. something like LIST (SORT (NAME DATE)) "" %

No requirement for this right now, can be done later on. If you feel 
strongly about this speak up now!

4). Add more examples? I think this might be a good idea, considering 
the amount of questions on the mailing list regarding different flag 
combinations
for different options.

5). Allow for referral information to be returned in response to LIST 
(REFERRAL).

Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
document, no new capability for this. Reason: referral data can be 
returned for a locally renamed mailbox (i.e. NEWNAME response code 
replacement), no need to support  RFC 2193 for this. If the server 
doesn't support referrals of any sort, this option will be ignored.

Related to this: do a revision of RFC 2193 that is using LISTEXT 
framework (in particular obsolete RLIST/RLSUB).

So, LISTEXT capability will mean: support for LIST option syntax, 
support for \PlaceHolder and \NonExistent flags, support for 
SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN).

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-15.txt
Date: Thu, 08 Apr 2004 16:20:05 -0400
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		: INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-15.txt
	Pages		: 0
	Date		: 2004-4-8
	
This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol.  These extensions
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-15.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-sort-15.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-sort-15.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-sort-15.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-01.txt
Date: Wed, 07 Apr 2004 11:32:20 -0400
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		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman
	Filename	: draft-ietf-imapext-i18n-01.txt
	Pages		: 17
	Date		: 2004-4-6
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search
substrings.  It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions (MIME).
This specification defines a collection of IMAP extensions which
improve international support including comparator negotiation for
search, sort and thread, language negotiation for international error
text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-01.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-i18n-01.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-i18n-01.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-i18n-01.txt

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

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

--OtherAccess--

--NextPart--