Subject: Re: Abusing subscriptions
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Date: Tue, 31 May 2005 10:10:11 -0700
List-Id: <ietf-imapext.imc.org>

On Tue, 31 May 2005, Rob Siemborski wrote:
> On 5/31/05, Mark Crispin <[email-masked]> wrote:
>> It isn't abuse to subscribe, say, all your mailboxes which receive
>> incoming mail so that you have a subset list to scan closer for new mail,
>> ignoring all the mailboxes with old archived mail.  That's the general
>> notion of what subscriptions are intended to do (and specifically
>> newsgroups).
> If the client does this automatically, without asking the user, when
> the user didn't intend for this to happen, it still seems pretty
> abusive.

I agree.

I would argue, though, that a client wouldn't know what mailboxes "receive 
incoming mail" unless told so by the user; and that the abuse is the 
presumption on the part of the client that it knows without being told.

-- Mark --

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

Date: Tue, 31 May 2005 09:09:32 -0700
From: Rob Siemborski <[email-masked]>
Reply-To: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: Abusing subscriptions
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/31/05, Mark Crispin <[email-masked]> wrote:
> It isn't abuse to subscribe, say, all your mailboxes which receive
> incoming mail so that you have a subset list to scan closer for new mail,
> ignoring all the mailboxes with old archived mail.  That's the general
> notion of what subscriptions are intended to do (and specifically
> newsgroups).

If the client does this automatically, without asking the user, when
the user didn't intend for this to happen, it still seems pretty
abusive.

-Rob

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

Date: Tue, 31 May 2005 09:01:33 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Abusing subscriptions
Sender: [email-masked]

On Tue, 31 May 2005, Arnt Gulbrandsen wrote:
>> Yes.  Recursively LISTing all mailbox names and automatically
>> subscribing every single name that comes back is an abuse of
>> subscriptions,
>> What purpose can possibly be served by recursively LISTing all names
>> and then SUBSCRIBEing?
> I agree that that's abuse, as would silently unsubscribing all
> subscribed names be. Both of those remove all information from the
> subscription list.
> Is that all you mean by abuse?

Yes.  There are, unfortunately, commonly used clients that do this.  It's 
been an ongoing problem for many years.  [Even worse, there are clients 
which, having done this, then does an LSUB and then LISTs each name 
individually.]

It isn't abuse to subscribe, say, all your mailboxes which receive 
incoming mail so that you have a subset list to scan closer for new mail, 
ignoring all the mailboxes with old archived mail.  That's the general 
notion of what subscriptions are intended to do (and specifically 
newsgroups).

-- Mark --

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

Date: Tue, 31 May 2005 08:56:15 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Abusing subscriptions
Sender: [email-masked]

On Tue, 31 May 2005, Mark Crispin wrote:
> What purpose can possibly be served by recursively LISTing all names and then 
> SUBSCRIBEing?

In a similar vein -

If you buy a magazine at the store, does this mean that the store should 
automatically subscribe you to that magazine and all other magazines that 
the store sells?

If you try some new browser, should that browser add all URLs that you 
type in or click to your Windows Address (IE bookmarks), and initiate a 
spider to hunt out other possible URLs to add?

If you connect to an anonymous FTP server, should the FTP client 
automatically download all files on the server?

I hope that the answer for the above is all "of course not"!

How, then, is it reasonable for a client to abuse subscriptions in a 
similar way?  Why is a static LSUB list, which is documented not to 
reflect what is actually on the server, better than the list from LIST?

So maybe subscriptions have another purpose.  What happens if an IMAP 
server exports newsgroups?  Wouldn't it be nice if the server kept track 
of your subscribed newsgroups instead requiring a .newsrc file on each 
client?

-- Mark --

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

Date: Tue, 31 May 2005 17:53:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Abusing subscriptions
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> Yes.  Recursively LISTing all mailbox names and automatically 
> subscribing every single name that comes back is an abuse of 
> subscriptions,
...
> What purpose can possibly be served by recursively LISTing all names 
> and then SUBSCRIBEing?

I agree that that's abuse, as would silently unsubscribing all 
subscribed names be. Both of those remove all information from the 
subscription list.

Is that all you mean by abuse?

Arnt

Date: Tue, 31 May 2005 08:33:42 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Abusing subscriptions
Sender: [email-masked]

On Tue, 31 May 2005, Arnt Gulbrandsen wrote:
> Mark Crispin writes:
>> Unfortunately, you can't use the IMAP "subscribe" feature to identify these 
>> mailboxes, because of certain poorly-written clients which abuse 
>> subscriptions.
> Abuse? How?

Yes.  Recursively LISTing all mailbox names and automatically subscribing 
every single name that comes back is an abuse of subscriptions, just as 
recursively LISTing all mailbox names and doing a STATUS of every single 
name is an abuse of the server.

The fact that hundreds, thousands, tens of thousands, ... of commands are 
being done by this is a clue that this is not the right thing to do.

> I don't actually see any text about how one is meant to use subscriptions.

There's no text that says that, the first time you run a client, the 
client shouldn't unilaterally download all messages in all mailboxes into 
a client-proprietary format, and then expunge the messages from the 
server.  That doesn't change the fact that this is abuse, and would 
probably seriously aggrieve someone who runs a client just to try it.

There's no text that says that you shouldn't rename all of HKLM in the 
Windows registry.

The world is full of things that are not explicitly stated, but are 
nonetheless implicit.  One of these implicit concepts is that software 
should not make far-ranging changes to shared state, especially not 
without the consent of the user.

Another of these implicit concepts is that, if you are not certain of the 
purpose of something, you shouldn't use it until you ascertain that 
purpose.

What purpose can possibly be served by recursively LISTing all names and 
then SUBSCRIBEing?

I shudder at the notion that without explicit instructions to the 
contrary, it's right and proper to do anything; and if something bad 
happens, it's the fault of the instructions and not the abuser's lack of 
common sense or refusal to do research.  Do we really need to have 
detailed usage instructions on a box of toothpicks?

-- Mark --

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

Date: Tue, 31 May 2005 10:52:05 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Abusing subscriptions
Sender: [email-masked]

Mark Crispin writes:
> Unfortunately, you can't use the IMAP "subscribe" feature to identify 
> these mailboxes, because of certain poorly-written clients which 
> abuse subscriptions.

Abuse? How?

I don't actually see any text about how one is meant to use subscriptions.

Arnt

Date: Tue, 31 May 2005 09:27:30 +0100
From: "Simon Tyler" <[email-masked]>
Subject: Re: IMAP4 List Command Extensions
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a MIME-encapsulated message

--==_08273053102768/PD.gordano.com==_
Content-Type: multipart/alternative; boundary="==_08273053102769/PD.gordano.com==_"

--==_08273053102769/PD.gordano.com==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 =20
Indeed the protocol should consider a wide variety of implementations. Such=
 as one which has no large overhead in obtaining the extra information I=
 was proposing. Our client will clearly backdown to using a STATUS command=
 should the extended LIST response not be found.=20
 =20
I fully understand all the issues, that is why I felt it was a reasonable=
 extension - servers which have issues returning the UID information in=
 short timescales would obviously not choose to add in such an extension.=
 Those that can obtain the information could do so.=20
 =20
Simon=20

---- Message from mailto:<[email-masked] Mark Crispin=
 <[email-masked]> at 31-May-2005 00:47:28 ------=20

I'm not sure if I was unclear in my previous message.  The point that I=20
attempted to make is that if you wish your client to interoperate with=20
multiple servers, you can not assume that UIDVALIDITY/UIDNEXT can be=20
obtained quickly.

It is an important characteristic of well-designed Internet protocol=20
implementations that they consider a wide variety of other=20
implementations.  This means, among other things, that you have to=20
consider the limitations in other implementations even if your own=20
implementation does not have that implementation.

One very large vendor is often heavily criticized because its software=
 has=20
many non-standard extensions that are implied to be part of the standard.=20
Then, when competing software does not work due to it not having these=20
non-standard extensions, the implication is that the competitor's=
 software=20
is broken.  This has led to ill feelings, and some of these problems have=20
even been offered as evidence of illegal behavior by that vendor.

It is therefore of critical importance that your software work well with=20
implementations that meet the basic compliance requirements without any=20
extensions.

As you may have noticed, STATUS does not accept a wildcard.  There is a=20
reason for this; and that reason was not stupidity on the part of the=20
protocol designer.  Please note the following text in RFC 3501, section=20
6.3.10:

       Unlike the LIST command, the STATUS command is not guaranteed to
       be fast in its response.  Under certain circumstances, it can be
       quite slow.  In some implementations, the server is obliged to
       open the mailbox read-only internally to obtain certain status
       information.  Also unlike the LIST command, the STATUS command
       does not accept wildcards.

The entire design of the STATUS command was to make a client implementor=20
think "hmm, it does not scale to do a LIST followed by a STATUS of each=20
individual name, I need to think of alternative strategies."

The bottom line is that you need to think of alternative strategies in=20
order to produce a quality IMAP client and not an "also-ran".

On Tue, 31 May 2005, Simon Tyler wrote:
> Whilst I understand that some servers may take a significant length of=20
> time to retrieve the UIDVALIDITY\UIDNEXT values others do not have this=20
> restriction. It also remains a fact that many IMAP clients will do a=20
> STATUS for each and every mailbox so for those clients it would be an=20
> improvement if this information could (optionally) be included in the=20
> LIST response.
>
> In our testing adding this sort sort of feature to the client and=
 server=20
> dramatically improved the synchronisation speed - the cost to our=
 server=20
> of getting the UIDVALIDATY\UIDNEXT being almost nothing.
>
> Simon
>
>
> ---- Message from mailto:<[email-masked] Mark Crispin=
 <[email-masked]> at 31-May-2005 00:17:08 ------
> On Tue, 31 May 2005, Simon Tyler wrote:
>> A typical client will do a
>> LIST to obtain the list of folders and then later do a STATUS on each
>> folder to get information such as the UIDVALIDITY. The cost of doing
>> this is suprisingly high (about 200ms in general) caused simply by
>> general network latency.
>
> The cost of doing this can be even higher than just that.
>
> There is no guarantee that a mail store can return the UIDVALIDITY or
> UIDNEXT in a trivial amount of time.  A LIST that returns those values
> could easily take some number of seconds per mailbox returned.  That LIST
> command returning UIDVALIDITY/UIDNEXT could take hours to complete!

-- Mark --

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

--==_08273053102769/PD.gordano.com==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style><!-- P{ margin-top:0;margin-bottom:0;} //=
 --></style></head><body><P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Indeed the protocol should consider a wide=
 variety of implementations. Such as one which has no large overhead in=
 obtaining the extra information I was proposing. Our client will clearly=
 backdown to using a STATUS command should the extended LIST response not=
 be found.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>I fully understand all the issues, that is=
 why I felt it was a reasonable extension - servers which have issues=
 returning the UID information in short timescales would obviously not=
 choose to add in such an extension. Those that can obtain the information=
 could do so.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Simon</P>
<P><BR>---- Message from <A href=3D"mailto:<[email-masked]">Mark=
 Crispin &lt;[email-masked]&gt;</A> at 31-May-2005 00:47:28=
 ------</P>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:=
 #000000 2px solid">I'm not sure if I was unclear in my previous message.=
 &nbsp;The point that I <BR>attempted to make is that if you wish your=
 client to interoperate with <BR>multiple servers, you can not assume that=
 UIDVALIDITY/UIDNEXT can be <BR>obtained quickly.<BR><BR>It is an important=
 characteristic of well-designed Internet protocol <BR>implementations that=
 they consider a wide variety of other <BR>implementations. &nbsp;This=
 means, among other things, that you have to <BR>consider the limitations=
 in other implementations even if your own <BR>implementation does not have=
 that implementation.<BR><BR>One very large vendor is often heavily=
 criticized because its software has <BR>many non-standard extensions that=
 are implied to be part of the standard. <BR>Then, when competing software=
 does not work due to it not having these <BR>non-standard extensions, the=
 implication is that the competitor's software <BR>is broken. &nbsp;This=
 has led to ill feelings, and some of these problems have <BR>even been=
 offered as evidence of illegal behavior by that vendor.<BR><BR>It is=
 therefore of critical importance that your software work well with=
 <BR>implementations that meet the basic compliance requirements without=
 any <BR>extensions.<BR><BR>As you may have noticed, STATUS does not accept=
 a wildcard. &nbsp;There is a <BR>reason for this; and that reason was not=
 stupidity on the part of the <BR>protocol designer. &nbsp;Please note the=
 following text in RFC 3501, section=
 <BR>6.3.10:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Unlike the=
 LIST command, the STATUS command is not guaranteed=
 to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be fast in its response.=
 &nbsp;Under certain circumstances, it can=
 be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;quite slow. &nbsp;In some=
 implementations, the server is obliged=
 to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;open the mailbox read-only=
 internally to obtain certain=
 status<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;information.=
 &nbsp;Also unlike the LIST command, the STATUS=
 command<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;does not accept=
 wildcards.<BR><BR>The entire design of the STATUS command was to make a=
 client implementor <BR>think "hmm, it does not scale to do a LIST followed=
 by a STATUS of each <BR>individual name, I need to think of alternative=
 strategies."<BR><BR>The bottom line is that you need to think of=
 alternative strategies in <BR>order to produce a quality IMAP client and=
 not an "also-ran".<BR><BR>On Tue, 31 May 2005, Simon Tyler wrote:<BR>&gt;=
 Whilst I understand that some servers may take a significant length of=
 <BR>&gt; time to retrieve the UIDVALIDITY\UIDNEXT values others do not=
 have this <BR>&gt; restriction. It also remains a fact that many IMAP=
 clients will do a <BR>&gt; STATUS for each and every mailbox so for those=
 clients it would be an <BR>&gt; improvement if this information could=
 (optionally) be included in the <BR>&gt; LIST response.<BR>&gt;<BR>&gt; In=
 our testing adding this sort sort of feature to the client and server=
 <BR>&gt; dramatically improved the synchronisation speed - the cost to our=
 server <BR>&gt; of getting the UIDVALIDATY\UIDNEXT being almost=
 nothing.<BR>&gt;<BR>&gt; Simon<BR>&gt;<BR>&gt;<BR>&gt; ---- Message from=
 mailto:&lt;[email-masked] Mark Crispin=
 &lt;[email-masked]&gt; at 31-May-2005 00:17:08 ------<BR>&gt; On=
 Tue, 31 May 2005, Simon Tyler wrote:<BR>&gt;&gt; A typical client will do=
 a<BR>&gt;&gt; LIST to obtain the list of folders and then later do a=
 STATUS on each<BR>&gt;&gt; folder to get information such as the=
 UIDVALIDITY. The cost of doing<BR>&gt;&gt; this is suprisingly high (about=
 200ms in general) caused simply by<BR>&gt;&gt; general network=
 latency.<BR>&gt;<BR>&gt; The cost of doing this can be even higher than=
 just that.<BR>&gt;<BR>&gt; There is no guarantee that a mail store can=
 return the UIDVALIDITY or<BR>&gt; UIDNEXT in a trivial amount of time.=
 &nbsp;A LIST that returns those values<BR>&gt; could easily take some=
 number of seconds per mailbox returned. &nbsp;That LIST<BR>&gt; command=
 returning UIDVALIDITY/UIDNEXT could take hours to complete!<BR><BR>-- Mark=
 --<BR><BR>http://staff.washington.edu/mrc<BR>Science does not emerge from=
 voting, party politics, or public debate.<BR>Si vis pacem, para=
 bellum.<BR><BR><BR></BLOCKQUOTE></FONT></body></html>

--==_08273053102769/PD.gordano.com==_--
--==_08273053102768/PD.gordano.com==_--

Date: Tue, 31 May 2005 07:52:23 +0000
From: Pawel Salek <[email-masked]>
Subject: Re: IMAP4 List Command Extensions
To: Simon Tyler <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On 05/31/2005 09:36:31 AM, Simon Tyler wrote:
> 
> 
> Whilst I understand that some servers may take a significant length  
> of time to retrieve the UIDVALIDITY\UIDNEXT values others do not have
> this restriction. It also remains a fact that many IMAP clients will
> do a STATUS for each and every mailbox so for those clients it would
> be an improvement if this information could (optionally) be included
> in the LIST response.
> 
> In our testing adding this sort sort of feature to the client and
> server dramatically improved the synchronisation speed - the cost to
> our server of getting the UIDVALIDATY\UIDNEXT being almost nothing.

If you really *insist* on fetching UIDVALIDITY, have you considered  
simply pipelining STATUS requests? This would reduce the latency as  
well and no standard change or a new extension would be required.  
Observe Mark's comments about STATUS performance remain valid: binding  
your  users to IMAP servers with specific behavior defeats the entire  
idea of standards and interoperability. I do not know good imap clients  
that unconditionally do STATUS on all the folders - and I probably  
would not like to use them either.

Pawel

> ---- Message from mailto:<[email-masked] Mark Crispin
> <[email-masked]> at 31-May-2005 00:17:08 ------
> 
> On Tue, 31 May 2005, Simon Tyler wrote:
> > A typical client will do a
> > LIST to obtain the list of folders and then later do a STATUS on
> each
> > folder to get information such as the UIDVALIDITY. The cost of doing
> 
> > this is suprisingly high (about 200ms in general) caused simply by
> > general network latency.
> 
> The cost of doing this can be even higher than just that.
> 
>  There is no guarantee that a mail store can return the UIDVALIDITY  
> or   UIDNEXT in a trivial amount of time.  A LIST that returns those   
> values   could easily take some number of seconds per mailbox  
> returned.  That  LIST  command returning UIDVALIDITY/UIDNEXT could  
> take hours to complete!

Date: Tue, 31 May 2005 00:47:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Simon Tyler <[email-masked]>
cc: [email-masked]
Subject: Re: IMAP4 List Command Extensions
Sender: [email-masked]

I'm not sure if I was unclear in my previous message.  The point that I 
attempted to make is that if you wish your client to interoperate with 
multiple servers, you can not assume that UIDVALIDITY/UIDNEXT can be 
obtained quickly.

It is an important characteristic of well-designed Internet protocol 
implementations that they consider a wide variety of other 
implementations.  This means, among other things, that you have to 
consider the limitations in other implementations even if your own 
implementation does not have that implementation.

One very large vendor is often heavily criticized because its software has 
many non-standard extensions that are implied to be part of the standard. 
Then, when competing software does not work due to it not having these 
non-standard extensions, the implication is that the competitor's software 
is broken.  This has led to ill feelings, and some of these problems have 
even been offered as evidence of illegal behavior by that vendor.

It is therefore of critical importance that your software work well with 
implementations that meet the basic compliance requirements without any 
extensions.

As you may have noticed, STATUS does not accept a wildcard.  There is a 
reason for this; and that reason was not stupidity on the part of the 
protocol designer.  Please note the following text in RFC 3501, section 
6.3.10:

       Unlike the LIST command, the STATUS command is not guaranteed to
       be fast in its response.  Under certain circumstances, it can be
       quite slow.  In some implementations, the server is obliged to
       open the mailbox read-only internally to obtain certain status
       information.  Also unlike the LIST command, the STATUS command
       does not accept wildcards.

The entire design of the STATUS command was to make a client implementor 
think "hmm, it does not scale to do a LIST followed by a STATUS of each 
individual name, I need to think of alternative strategies."

The bottom line is that you need to think of alternative strategies in 
order to produce a quality IMAP client and not an "also-ran".

On Tue, 31 May 2005, Simon Tyler wrote:
> Whilst I understand that some servers may take a significant length of 
> time to retrieve the UIDVALIDITY\UIDNEXT values others do not have this 
> restriction. It also remains a fact that many IMAP clients will do a 
> STATUS for each and every mailbox so for those clients it would be an 
> improvement if this information could (optionally) be included in the 
> LIST response.
>
> In our testing adding this sort sort of feature to the client and server 
> dramatically improved the synchronisation speed - the cost to our server 
> of getting the UIDVALIDATY\UIDNEXT being almost nothing.
>
> Simon
>
>
> ---- Message from mailto:<[email-masked] Mark Crispin <[email-masked]> at 31-May-2005 00:17:08 ------
> On Tue, 31 May 2005, Simon Tyler wrote:
>> A typical client will do a
>> LIST to obtain the list of folders and then later do a STATUS on each
>> folder to get information such as the UIDVALIDITY. The cost of doing
>> this is suprisingly high (about 200ms in general) caused simply by
>> general network latency.
>
> The cost of doing this can be even higher than just that.
>
> There is no guarantee that a mail store can return the UIDVALIDITY or
> UIDNEXT in a trivial amount of time.  A LIST that returns those values
> could easily take some number of seconds per mailbox returned.  That LIST
> command returning UIDVALIDITY/UIDNEXT could take hours to complete!

-- Mark --

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

Date: Tue, 31 May 2005 08:36:31 +0100
From: "Simon Tyler" <[email-masked]>
Subject: Re: IMAP4 List Command Extensions
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a MIME-encapsulated message

--==_07363109302704/PD.gordano.com==_
Content-Type: multipart/alternative; boundary="==_07363109302705/PD.gordano.com==_"

--==_07363109302705/PD.gordano.com==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 =20
Whilst I understand that some servers may take a significant length of time=
 to retrieve the UIDVALIDITY\UIDNEXT values others do not have this=
 restriction. It also remains a fact that many IMAP clients will do a=
 STATUS for each and every mailbox so for those clients it would be an=
 improvement if this information could (optionally) be included in the LIST=
 response.=20
 =20
In our testing adding this sort sort of feature to the client and server=
 dramatically improved the synchronisation speed - the cost to our server=
 of getting the UIDVALIDATY\UIDNEXT being almost nothing.=20
 =20
Simon=20
 =20

---- Message from mailto:<[email-masked] Mark Crispin=
 <[email-masked]> at 31-May-2005 00:17:08 ------=20

On Tue, 31 May 2005, Simon Tyler wrote:
> A typical client will do a=20
> LIST to obtain the list of folders and then later do a STATUS on each=20
> folder to get information such as the UIDVALIDITY. The cost of doing=20
> this is suprisingly high (about 200ms in general) caused simply by=20
> general network latency.

The cost of doing this can be even higher than just that.

There is no guarantee that a mail store can return the UIDVALIDITY or=20
UIDNEXT in a trivial amount of time.  A LIST that returns those values=20
could easily take some number of seconds per mailbox returned.  That LIST=20
command returning UIDVALIDITY/UIDNEXT could take hours to complete!

--==_07363109302705/PD.gordano.com==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style><!-- P{ margin-top:0;margin-bottom:0;} //=
 --></style></head><body><P>&nbsp;</P>
<P>Whilst I understand that some servers may take a significant length of=
 time to retrieve the UIDVALIDITY\UIDNEXT values others do not have this=
 restriction. It also remains a fact that many IMAP clients will do a=
 STATUS for each and every mailbox so for those clients it would be an=
 improvement if this information could (optionally) be included in the LIST=
 response.</P>
<P>&nbsp;</P>
<P>In our testing adding this sort sort of feature to the client and server=
 dramatically improved the synchronisation speed&nbsp;- the cost to our=
 server of getting the UIDVALIDATY\UIDNEXT being almost nothing.</P>
<P>&nbsp;</P>
<P>Simon</P>
<P>&nbsp;</P>
<P><FONT face=3DArial size=3D2><BR>---- Message from <A=
 href=3D"mailto:<[email-masked]">Mark Crispin=
 &lt;[email-masked]&gt;</A> at 31-May-2005 00:17:08 ------</P>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:=
 #000000 2px solid">On Tue, 31 May 2005, Simon Tyler wrote:<BR>&gt; A=
 typical client will do a <BR>&gt; LIST to obtain the list of folders and=
 then later do a STATUS on each <BR>&gt; folder to get information such as=
 the UIDVALIDITY. The cost of doing <BR>&gt; this is suprisingly high=
 (about 200ms in general) caused simply by <BR>&gt; general network=
 latency.<BR><BR>The cost of doing this can be even higher than just=
 that.<BR><BR>There is no guarantee that a mail store can return the=
 UIDVALIDITY or <BR>UIDNEXT in a trivial amount of time. &nbsp;A LIST that=
 returns those values <BR>could easily take some number of seconds per=
 mailbox returned. &nbsp;That LIST <BR>command returning=
 UIDVALIDITY/UIDNEXT could take hours to=
 complete!<BR><BR><BR></BLOCKQUOTE></FONT></body></html>

--==_07363109302705/PD.gordano.com==_--
--==_07363109302704/PD.gordano.com==_--

Date: Tue, 31 May 2005 00:17:08 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Simon Tyler <[email-masked]>
cc: [email-masked]
Subject: Re: IMAP4 List Command Extensions
Sender: [email-masked]

On Tue, 31 May 2005, Simon Tyler wrote:
> A typical client will do a 
> LIST to obtain the list of folders and then later do a STATUS on each 
> folder to get information such as the UIDVALIDITY. The cost of doing 
> this is suprisingly high (about 200ms in general) caused simply by 
> general network latency.

The cost of doing this can be even higher than just that.

There is no guarantee that a mail store can return the UIDVALIDITY or 
UIDNEXT in a trivial amount of time.  A LIST that returns those values 
could easily take some number of seconds per mailbox returned.  That LIST 
command returning UIDVALIDITY/UIDNEXT could take hours to complete!

Put another way, if your client requires that all remote mailboxes be 
synchronized in this way, you will find that it simply will not work in 
many environments.  You need to address the problem in another way.

Fortunately, it is generally not necessary to synchronize *all* mailboxes 
automatically.  Only a small number of mailboxes need to do this, while 
most other mailboxes are archives.  So, if you maintain a list of the 
small number of mailboxes you need to synchronize automatically, you can 
ignore those that do not need this.

Unfortunately, you can't use the IMAP "subscribe" feature to identify 
these mailboxes, because of certain poorly-written clients which abuse 
subscriptions.

-- Mark --

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

Date: Tue, 31 May 2005 08:06:27 +0100
From: "Simon Tyler" <[email-masked]>
Subject: IMAP4 List Command Extensions
To: <[email-masked]>
Sender: [email-masked]

This is a MIME-encapsulated message

--==_07062779602641/PD.gordano.com==_
Content-Type: multipart/alternative; boundary="==_07062779602642/PD.gordano.com==_"

--==_07062779602642/PD.gordano.com==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
 =20
Hi,=20
 =20
I was just reading your LIST Command Extensions Internet draft and have a=
 suggestion for some additions.=20
 =20
The company I work for (Gordano Ltd - http://www.gordano.com/=
 www.gordano.com) is in the process of writing our own IMAP client=
 transport to be used with our extsing IMAP server. We have noticed some=
 issues with the LIST response in particular. A typical client will do a=
 LIST to obtain the list of folders and then later do a STATUS on each=
 folder to get information such as the UIDVALIDITY. The cost of doing this=
 is suprisingly high (about 200ms in general) caused simply by general=
 network latency. If you are synchronising a large number of folders then=
 this quickly adds up.=20
 =20
We have added in a custom LIST response extension whereby the LIST response=
 includes additional information we require -UNDVALIDITY and UIDNEXT. In a=
 typical "no changes" case this vastly reduces the time a client is able to=
 sync in.=20
 =20
e.g.=20
 =20
S: * LIST (UIDVALIDITY 99999 UIDNEXT 99999) "/" "folder"=20
 =20
Clearly this could be extended to include all the STATUS fields. Similarly=
 the LIST comand itself could be extended to request the fields it=
 requires.=20
 =20
This is not ideal from our perspective - although we would like customers=
 of our client transport to also use our server, this is not always the=
 case and hence we would like to stick to established (or at least=
 proposed) standards. Would you consider adding into your draft such an=
 extension?=20
 =20
Simon

--==_07062779602642/PD.gordano.com==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style><!-- P{ margin-top:0;margin-bottom:0;} //=
 --></style></head><body><FONT face=3DArial size=3D2>
<P><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Hi,</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>I was just reading your LIST Command=
 Extensions Internet draft and have a suggestion for some=
 additions.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>The company I work for (Gordano Ltd - <A=
 href=3D"http://www.gordano.com/" target=3D_blank>www.gordano.com</A>) is=
 in the process of writing our own IMAP client transport to be used with=
 our extsing IMAP server. We have noticed some issues with the LIST=
 response in particular. A typical client will do a LIST to obtain the list=
 of folders and then later do a STATUS on each folder to get information=
 such as the UIDVALIDITY. The cost of doing this is suprisingly=
 high&nbsp;(about&nbsp;200ms&nbsp;in general)&nbsp;caused simply by general=
 network latency. If you are synchronising a large number of folders then=
 this quickly adds up.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>We have added in a custom LIST response=
 extension whereby the LIST response includes additional information we=
 require -UNDVALIDITY and UIDNEXT. In a typical "no changes" case this=
 vastly reduces the time a client is able to sync in.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>e.g.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>S:&nbsp;* LIST (UIDVALIDITY 99999 UIDNEXT=
 99999) "/" "folder"</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Clearly this could be extended to include=
 all the STATUS fields. Similarly the LIST comand itself could be extended=
 to request the fields it requires.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>This is not ideal from our perspective -=
 although we would like customers of our client transport to also use our=
 server, this is not always the case and hence we would like to stick to=
 established (or at least proposed) standards. Would you consider adding=
 into your draft such an extension?</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Simon</FONT></P><BR><BR></FONT></body></html>

--==_07062779602642/PD.gordano.com==_--
--==_07062779602641/PD.gordano.com==_--

Date: Thu, 26 May 2005 21:21:08 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-2086upd-06
Sender: [email-masked]

Ken Murchison wrote:

> The table in section 5 lists the APPEND command twice.  I assume that 
> the second instance should be COPY instead of APPEND, since the former 
> requires the selected state.

Good catch.
Fixed in my copy.

Date: Thu, 26 May 2005 16:09:07 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: draft-ietf-imapext-2086upd-06
Sender: [email-masked]

The table in section 5 lists the APPEND command twice.  I assume that 
the second instance should be COPY instead of APPEND, since the former 
requires the selected state.

-- 
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: Thu, 26 May 2005 14:48:47 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: revision -04 to rfc2359bis
Sender: [email-masked]

Mark Crispin wrote:
> On Wed, 25 May 2005, Arnt Gulbrandsen wrote:
> 
>> Change (4) apparently affects COPYUID, which means that previously 
>> acceptable server code for COPY breaks:
>> printf( "%s OK [COPYUID %d %d:%d]\r\n", tag, validity, first, 
>> first+last-1 );
> 
> 
> OK, you've convinced me.  Draft -04 (attached) revokes change 4 and 
> alters the following explanation to the prohibitory text for APPENDUID:
>          This is because a client which does not support [MULTIAPPEND]
>          expects only a single UID and not a UID set.
> 
> Are we done now?

Hum.

-- 
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: Thu, 26 May 2005 12:24:41 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: revision -04 to rfc2359bis
Cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> Are we done now?

Hum from me.

And I'm still amazed at the speed of this.

Arnt

Date: Wed, 25 May 2005 17:50:53 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Cyrus Daboo <[email-masked]>
Subject: revision -04 to rfc2359bis
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-172342576-1117068653=:25491
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 25 May 2005, Arnt Gulbrandsen wrote:
> Change (4) apparently affects 
> COPYUID, which means that previously acceptable server code for COPY breaks:
> printf( "%s OK [COPYUID %d %d:%d]\r\n", tag, validity, first, first+last-1 );

OK, you've convinced me.  Draft -04 (attached) revokes change 4 and alters 
the following explanation to the prohibitory text for APPENDUID:
          This is because a client which does not support [MULTIAPPEND]
          expects only a single UID and not a UID set.

Are we done now?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-172342576-1117068653=:25491
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-04.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-04.txt

---1903383771-172342576-1117068653=:25491--

Date: Wed, 25 May 2005 14:47:47 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-crispin-imap-rfc2359bis-03.txt
Cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> --On May 24, 2005 4:18:13 PM -0700 Mark Crispin 
> <[email-masked]> wrote:
>> I'd like to get either a hum of concensus or a snarl of objection on 
>> this point.  Thanks.
>
> hum of approval from me.

Not from me, although I won't snarl either. Change (4) apparently 
affects COPYUID, which means that previously acceptable server code for 
COPY breaks:

printf( "%s OK [COPYUID %d %d:%d]\r\n", tag, validity, first, first+last-1 );

Change (4) seems superfluous anyway.

Little short on sleep today. Maybe I'm wrong?

Arnt

Date: Wed, 25 May 2005 08:38:15 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: draft-crispin-imap-rfc2359bis-03.txt
Sender: [email-masked]

Hi Mark,

--On May 24, 2005 4:18:13 PM -0700 Mark Crispin <[email-masked]> 
wrote:

>> I've uploaded draft -03 (and it's attached here).  I may have
>> overstepped my  boundaries by prohibiting all UID set ranges in which
>> the two values are  equal -- are there any objections to my having done
>> this?  This only applies  when both UIDPLUS and MULTIAPPEND are in
>> effect.
>
> I'd like to get either a hum of concensus or a snarl of objection on this
> point.  Thanks.

hum of approval from me.

-- 
Cyrus Daboo

Date: Wed, 25 May 2005 12:18:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-crispin-imap-rfc2359bis-03.txt
Sender: [email-masked]

Mark Crispin wrote:

> It was pointed out to me that it is possible for a server to send 
> "[APPENDUID 432 123:123]" as a response to a single APPEND, which 
> would confuse a client which doesn't implement RFC 3502.  This is 
> actually a problem introduced by the combination of RFC 2359 and RFC 
> 3502.
>
> I also observed that it used the RFC 2060 term "message set", which was
> replaced with "sequence set" in RFC 3501.  What's worse, "message set" 
> was used to refer to both RFC 3501 sequence sets and to the new 
> uid-set rule introduced in this document.
>
> I've uploaded draft -03 (and it's attached here).  I may have 
> overstepped my boundaries by prohibiting all UID set ranges in which 
> the two values are equal -- are there any objections to my having done 
> this?  This only applies when both UIDPLUS and MULTIAPPEND are in effect.

These changes are fine with me, as I've fixed "[COPYUID 12345 5:5]" in 
my server ;-).

Date: Tue, 24 May 2005 16:18:13 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-crispin-imap-rfc2359bis-03.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 May 2005, Mark Crispin wrote:
> I've uploaded draft -03 (and it's attached here).  I may have overstepped my 
> boundaries by prohibiting all UID set ranges in which the two values are 
> equal -- are there any objections to my having done this?  This only applies 
> when both UIDPLUS and MULTIAPPEND are in effect.

I'd like to get either a hum of concensus or a snarl of objection on this 
point.  Thanks.

-- Mark --

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

Date: Tue, 24 May 2005 16:08:04 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: draft-crispin-imap-rfc2359bis-03.txt
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-2009146749-1116976084=:13471
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

It was pointed out to me that it is possible for a server to send 
"[APPENDUID 432 123:123]" as a response to a single APPEND, which would 
confuse a client which doesn't implement RFC 3502.  This is actually a 
problem introduced by the combination of RFC 2359 and RFC 3502.

I also observed that it used the RFC 2060 term "message set", which was
replaced with "sequence set" in RFC 3501.  What's worse, "message set" was 
used to refer to both RFC 3501 sequence sets and to the new uid-set rule 
introduced in this document.

I've uploaded draft -03 (and it's attached here).  I may have overstepped 
my boundaries by prohibiting all UID set ranges in which the two values 
are equal -- are there any objections to my having done this?  This only 
applies when both UIDPLUS and MULTIAPPEND are in effect.

Here are the changes:

1) Add the following definition of UID set to the conventions:

    A "UID set" is similar to the [IMAP] sequence set; however, the "*"
    value for sequence number is not permitted.

2) Change all occurances of "message set" to "sequence set" or "UID set"
    as appropriate.

3) Expand the APPENDUID text in the MULTIAPPEND case to clarify that
    123:123 is prohibited:

       If the server also supports the [MULTIAPPEND] extension, and if
       multiple messages were appended in the APPEND command, then the
       second value is a UID set containing the UIDs assigned to
       the appended messages, in the order they were transmitted in the
       APPEND command.  This UID set may not contain extraneous
       UIDs or the symbol "*".

          Note: the UID set form of the APPENDUID response code MUST
          NOT be used if only a single message was appended.  In
          particular, a server MUST NOT send a range such as 123:123.

4) Same as (3), for the formal syntax of uid-range and the MULTIAPPEND
    extension to the formal syntax for append-uid:

    uid-range       = (uniqueid ":" uniqueid)
                      ; two non-equal uniqueid values and all
                      ; values between these two regards of order.
                      ; Example: 2:4 and 4:2 are equivalent.
                      ; These values MUST NOT be equal; e.g. 2:2
                      ; is not permitted.

    Servers which support [MULTIAPPEND] will have the following extension
    to the above rules:

    append-uid      =/ uid-set
                      ; only if multiple messages appended

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-2009146749-1116976084=:13471
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-03.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-03.txt

---1903383771-2009146749-1116976084=:13471--

Date: Tue, 24 May 2005 15:21:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: asking for last call on rfc2359bis document
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 May 2005, Arnt Gulbrandsen wrote:
> One example: IIRC there's nothing in base IMAP that requires the client to 
> parse sequence-set. For this reason, if 2359 hadn't made the issue moot, I 
> would have preferred COPYUID to use "nz-number *(SP nz-number)" like SEARCH 
> does.

IMHO, this is OK.  If the client supports 2359, it has to be able to parse 
sequence-set; if it doesn't, then the default
 	atom [SP 1*<any TEXT-CHAR except "]">]
rule in resp-text-code will ensure that the client doesn't get perturbed 
by any unsolicited APPENDUID/COPYUID.

If we could take a time machine and fix it, I would have insisted that 
APPENDUID and COPYUID be untagged responses instead of resp-text-code, and 
have an APPENDUID and COPYUID command to trigger those responses.  That's 
actually what I wanted, but I lost the battle and decided not to fight it 
further.

-- Mark --

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

Date: Tue, 24 May 2005 17:02:10 +0100
Subject: Re: asking for last call on rfc2359bis document
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Mark Crispin <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Tue May 24 12:05:42 2005, Arnt Gulbrandsen wrote:
> One example: IIRC there's nothing in base IMAP that requires the 
> client to parse sequence-set. For this reason, if 2359 hadn't made 
> the issue moot, I would have preferred COPYUID to use "nz-number 
> *(SP nz-number)" like SEARCH does.

Funnily enough, Alexey used almost the exact reverse argument to 
convince me that using set syntax was better for ESEARCH.

Anyway, I'm glad you raised this issue, as we cannot possibly let a 
draft go through without a pointless long-winded argument. :-)

In this case, copying multiple messages is very commonly copying a 
contiguous range - the most common example being the "sweep" of 
messages currently in the INBOX. This is more likely the more 
messages are copied, I suspect.

This in turn strongly suggests that sequence-set will be lower 
bandwidth - it is always lower or same bandwidth in any case. (It 
actually tends to be lower when it really is a sequence set, rather 
than a UID set, of course).

Moreover, set syntax is a valuable addition to a client's parser, as 
the lower bandwidth requirements inevitably mean less resource usage, 
and I strongly suspect that set syntax compresses better than a 
traditional text-based compression algorithm (perhaps one in the TLS 
layer) due to domain knowledge for the data involved.

Right, pointless argument over, RFC2359bis can go through to last 
call with a clean consience. :-)

Seriously, it all looks fine to me.

Dave.

Date: Tue, 24 May 2005 13:05:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: asking for last call on rfc2359bis document
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 24 May 2005, Arnt Gulbrandsen wrote:
>> Seriously, I like it. There's nothing I dislike that's fixable.
>
> Well, is there something that you dislike?

A couple of things, but 2359 has cast them in stone.

One example: IIRC there's nothing in base IMAP that requires the client 
to parse sequence-set. For this reason, if 2359 hadn't made the issue 
moot, I would have preferred COPYUID to use "nz-number *(SP nz-number)" 
like SEARCH does.

> This looks like a "let sleeping dogs lie" condition to me... :-)

I can certainly see the sense in that.

Arnt

Date: Tue, 24 May 2005 02:58:01 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: asking for last call on rfc2359bis document
Sender: [email-masked]

On Tue, 24 May 2005, Arnt Gulbrandsen wrote:
> Seriously, I like it. There's nothing I dislike that's fixable.

Well, is there something that you dislike?

> Although... how about adding a note that client authors SHOULD NOT send * in 
> the UID EXPUNGE commands?

I'm not sure why this would be needed.  I agree that "UID EXPUNGE *" does 
not seem to me to be particularly useful, with the possible exception of 
"UID EXPUNGE 1:*".  It's certainly dangerous.

On the other hand, RFC 2359 allowed it, so it can't be removed.  What's 
more, I don't want to have a situation, 5-10 years from now, of someone 
asking "why did you say such a stupid thing" and demanding an update to 
the document.

This looks like a "let sleeping dogs lie" condition to me... :-)

-- Mark --

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

Date: Tue, 24 May 2005 10:31:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: asking for last call on rfc2359bis document
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> I believe that the -02 draft of the rfc2359bis document addresses all 
> the comments that I have received so far:
>   ftp://ftp.ietf.org/internet-drafts/draft-crispin-imap-rfc2359bis-02.txt
> and consequently I think that work on it is finished.
>
> Please give it one last review, and if all is well I'll ask our 
> esteemed AD to bring it up to the IESG.  Thanks!

I am amazed, I am astonished. IMAP drafts just aren't supposed to move 
so quickly ;)

Seriously, I like it. There's nothing I dislike that's fixable.

Although... how about adding a note that client authors SHOULD NOT send 
* in the UID EXPUNGE commands?

Arnt

Date: Mon, 23 May 2005 15:45:21 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: asking for last call on rfc2359bis document
Organization: Networks & Distributed Computing
Sender: [email-masked]

I believe that the -02 draft of the rfc2359bis document addresses all the 
comments that I have received so far:
   ftp://ftp.ietf.org/internet-drafts/draft-crispin-imap-rfc2359bis-02.txt
and consequently I think that work on it is finished.

Please give it one last review, and if all is well I'll ask our esteemed 
AD to bring it up to the IESG.  Thanks!

-- Mark --

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

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'IMAP4 ACL extension' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Mon, 23 May 2005 17:33:11 -0400
Sender: [email-masked]

The IESG has received a request from the Internet Message Access Protocol 
Extension WG to consider the following document:

- 'IMAP4 ACL extension '
   <draft-ietf-imapext-2086upd-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-06-06.

This document is known to not pass IDNits checking.  That will be
corrected before IESG evaluation.  Other AD evaluation comments are
visible in the ID Tracker.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-06.txt

Date: Sun, 22 May 2005 16:06:57 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: rfc2086upd nit
Sender: [email-masked]

Alexey Melnikov wrote:

> Mark Crispin wrote:
>
>> The statement:
>>
>>    Except as noted otherwise, all alphabetic characters are
>>    case-insensitive.  The use of upper or lower case characters to
>>    define token strings is for editorial clarity only.  Implementations
>>    MUST accept these strings in a case-insensitive fashion.
>>
>> in the Formal Syntax is redundant.  RFC 2234 already requires this, 
>> and the RFC 3501 Formal Syntax emphasizes this point and others which 
>> are of equal importance.
>
> IMHO, this is one of those rules which is easy to forget (I've made 
> such mistake with IMAP keywords once).

Just to emphasize this I've changed capitalization in several examples.

Date: Sun, 22 May 2005 16:01:31 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Mark Crispin <[email-masked]>
Subject: Re: rfc2086upd nit
Sender: [email-masked]

Mark Crispin wrote:

> The statement:
>
>    Except as noted otherwise, all alphabetic characters are
>    case-insensitive.  The use of upper or lower case characters to
>    define token strings is for editorial clarity only.  Implementations
>    MUST accept these strings in a case-insensitive fashion.
>
> in the Formal Syntax is redundant.  RFC 2234 already requires this, 
> and the RFC 3501 Formal Syntax emphasizes this point and others which 
> are of equal importance.

IMHO, this is one of those rules which is easy to forget (I've made such 
mistake with IMAP keywords once).

> I recommend either omitting this paragraph entirely, or duplicating 
> all of the text that appears in the RFC 3501 Formal Syntax 
> introduction.  I think that the first of these choices is better.

Does anybody else has an opinion on that?

Alexey

Date: Fri, 20 May 2005 13:31:23 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: rfc2086upd nit
Organization: Networks & Distributed Computing
Sender: [email-masked]

The statement:

    Except as noted otherwise, all alphabetic characters are
    case-insensitive.  The use of upper or lower case characters to
    define token strings is for editorial clarity only.  Implementations
    MUST accept these strings in a case-insensitive fashion.

in the Formal Syntax is redundant.  RFC 2234 already requires this, and 
the RFC 3501 Formal Syntax emphasizes this point and others which are of 
equal importance.

I recommend either omitting this paragraph entirely, or duplicating all of 
the text that appears in the RFC 3501 Formal Syntax introduction.  I think 
that the first of these choices is better.

-- Mark --

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

Date: Fri, 20 May 2005 12:46:42 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: updated (-01) rfc2359bis
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-1035889917-1116618402=:14865
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

OK, I think that I have addressed your nits and those sent to me in 
private email by a few other people in draft -02 which I've just sent to 
the I-D repository.

It's attached to this message too.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-1035889917-1116618402=:14865
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-02.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-02.txt

---1903383771-1035889917-1116618402=:14865--

From: "Scott Hollenbeck" <[email-masked]>
To: "'Pete Resnick'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Fri, 20 May 2005 15:39:28 -0400
Sender: [email-masked]

> That said: If you are willing to go ahead with the Last Call 
> as-is, great. If you still insist on the changes before 
> issuing the Last Call, let us know and obviously the WG will 
> have Alexey make the changes and submit the new document in 
> the next day or two. In the meanwhile I will start the 
> process discussion (starting with the IETF Chair, up to and 
> including appeal). In either case, let us know one final time 
> how you want to proceed.

Pete and I had a chat by phone to talk through next steps.  I agree that my
review did not uncover any significant issues with the protocol itself, so I
have agreed to issue the last call once an "in progress" update is
available.  Pete and I have agreed that some of the issues may be left for
discussion with the community.  The unresolved issues and remaining
questions will be identified in the review request sent to the community.
Edits, including IDNits corrections, will be made in parallel with the last
call.

We believe this is a reasonable compromise.  Anyone who believes otherwise
should speak now.

-Scott-

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-06.txt
Date: Fri, 20 May 2005 15:38:17 -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 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-2086upd-06.txt
	Pages		: 0
	Date		: 2005-5-20
	
The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP) permits mailbox access control
   lists to be retrieved and manipulated through the IMAP protocol.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Fri, 20 May 2005 14:37:10 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: updated (-01) rfc2359bis
Sender: [email-masked]

Hi Mark,
Some formal syntax nits, plus one possible security issue:

--On Thursday, May 19, 2005 14:35 -0700 Mark Crispin 
<[email-masked]> wrote:

> Please review.  I'm hoping that there are no objections to this update
> and we can get through a quick last-call and submission to the IESG as
> reflecting WG concensus.

Can you please add the new capability string explicitly to the Formal 
Syntax:

  capability  =/  "UIDPLUS"

'nz_number' should be 'nz-number'.

For consistency I would suggest replacing the underscores in the resp_* 
syntax elements with dashes.

Also, the new response codes should be shown as properly extending the IMAP 
syntax, and should include UIDNOTSTICKY which is currently not defined:

  response-text-code  =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"

'uid-number' (used in 'uid-range' definition) is not defined anywhere. 
Shouldn't it be 'uniqueid'?

Security issue: it is possible to have a mailbox with permissions set so 
that a user can write to it (i.e. do COPY or APPEND) but cannot read it 
(i.e. SELECT/EXAMINE) - this would be something like a 'drop-box' In such 
cases shouldn't the COPYUID and APPENDUID responses be suppressed to avoid 
exposing information that the user would not otherwise be able to access?

-- 
Cyrus Daboo

From: [email-masked]
Cc: Scott Hollenbeck <[email-masked]>, [email-masked]
Date: Fri, 20 May 2005 10:53:02 -0700 (PDT)
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
To: Pete Resnick <[email-masked]>
Sender: [email-masked]

> On 5/19/05 at 7:39 PM -0400, Scott Hollenbeck wrote:

> >Clarification of the extension model being used (the ABNF import
> >discussion) is not an editorial issue.  It's directly related to the
> >normative reference to RFC 2234.

> There is no technical issue with regard to reference to RFC 2234. The
> ABNF in the document is correct and is correctly used as per that
> specification. The only question is whether:

>     Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>     Non-terminals referenced but not defined below are as defined by
>     [IMAP4].

> is clear. (Specifically, whether the word "modified" is correct and
> whether it is better to reference "IMAP4" or "IMAP".) None of this is
> technical in nature. There is no technical interpretation of the
> document that could be confused whether or not these corrections are
> made. (That an ABNF validator must be used in a particular way is not
> germane to the technical correctness of this specification. The only
> "normative reference" to 2234 is that you won't be able to figure out
> the syntax without also reading and understanding 2234.) The change
> requested is only an editorial objection to the clarity of a comment.

I agree 100%.

> >Whether or not this document updates 3501 is not an editorial issue.

> The contents of an "Updates" header in an RFC are subject to:

> ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt

> That seems to me very much an editorial issue. Whether this document
> is technically correct does not depend on the contents of that
> particular field in the RFC template. At most, the current text of
> "<<3501?>>" indicates that the editor was not sure whether this
> qualified as an update under those instructions. (My read of the
> instructions is that it does qualify as an update.)

I concur with this assessment, however, in the final analysis, the
determination of what constitutes an update is properly something the IESG
needs to decide.

> No technical
> review of this document will be in any way changed if that text is
> changed. It is editorial only.

> >The issue of "MAY" vs. "may" vs. a synonym is not an editorial
> >issue.  It's directly related to the normative reference to RFC 2119.

> Neither of the examples you pointed out make one iota of difference
> in the technical interpretation of the document. And it certainly has
> nothing to do with the 2119 reference: In neither case is a
> capitalized imperative used in a way that it shouldn't. In neither
> case would the use of an imperative change the *technical*
> interpretation of the text. This is strictly an editorial objection,
> that use of the non-imperative English word "may" is an inconsistent
> usage, especially in places where the imperatives are used.

Agreed as well.

> And I am fully aware that we have now spent two days on this already.
> But this is now an "in principle" discussion that I would like
> resolved, other than its effect on this particular document. My
> contention is that the IESG should not be requiring editorial and
> stylistic flubs to be cleaned up prior to Last Call. It's an utter
> waste of the IESG's time and unnecessarily delays the documents
> progression. The IESG is free to make stylistic and editorial
> comments to the editor, and these should be fixed before RFC
> publication to be sure. But to not clean these things up in parallel
> with the Last Call is IMO a problem with the review process that
> needs to be fixed. And at this point, I'm perfectly willing to make
> an appeal on this point (and obviously recuse myself from the IAB
> decision if it gets that far). But one way or the other, I'd like
> this particular process point clarified for the future.

I note in passing that a similar situation used to exist in regards to IESG
evaluations. An IESG member who found an editorial nit in a document either had
to file a DISCUSS for no good purpose or let the nit pass along with the very
real possibility that it would not get fixed prior to publication. (There were
several cases where this in fact happened, one sufficiently severe that a
revised version of a document had to be produced almost immediately.) 

The ability to create a set of nonblocking comments for the RFC Editor was
added to deal with this. I suggest that this mechanism is the appropriate one
to use to deal with all of these - editorial issues should be recorded
and dealt with either through opportunistic correction as part of a revised
version being published or by the RFC Editor.

I don't know whether the datatracker lets ADs add RFC Editor notes prior to a
ballot being created, but if not it should. (When I was an AD I used a
note-taking tool called Tinderbox to track these sorts of things, but that was
just me; it really should be incorporated into the overall workflow mechanism.)

> That said: If you are willing to go ahead with the Last Call as-is,
> great. If you still insist on the changes before issuing the Last
> Call, let us know and obviously the WG will have Alexey make the
> changes and submit the new document in the next day or two. In the
> meanwhile I will start the process discussion (starting with the IETF
> Chair, up to and including appeal). In either case, let us know one
> final time how you want to proceed.

Either way sounds like a good plan to me.

				Ned

Date: Fri, 20 May 2005 10:53:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Scott Hollenbeck <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

On Thu, 19 May 2005, Pete Resnick wrote:
> There is no technical issue with regard to reference to RFC 2234. The ABNF in 
> the document is correct and is correctly used as per that specification. The 
> only question is whether:
>   Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>   Non-terminals referenced but not defined below are as defined by
>   [IMAP4].
> is clear. (Specifically, whether the word "modified" is correct and whether 
> it is better to reference "IMAP4" or "IMAP".)

I now understand the problem.

Without arguing any of your other points, the "as modified by [IMAP4]" is 
wrong.  It's a remnant of something which is now moot.

The original text in RFC 2086 was "The following syntax specification uses 
the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] as 
modified by [IMAP4]."

RFC 2060 inherited ABNF from RFC 822.  RFC 2234 obviously did not exist 
when RFC 2060 was issued.  RFC 822 had a "#" construct which indicated 
tokens separated by one or more commas; for example,
 	#("a" / "b" / "c")
could parse
 	b,c,,,,a

RFC 2060 modified the "#" construct so that it indicated tokens separated 
by one (and only one!) space; for example:
 	#("a" / "b" / "c")
could parse
 	b c a

RFC 2234 abolished the "#" construct entirely.  In modern times, the way 
that you would do the RFC 822 style "#" is with (assuming a definition of 
abc = "a" / "b" / "c"):
 	abc *(1*(0x2c) abc)
and the way that you would do the RFC 2060 style "#" is with
 	abc *(SP abc)

As both RFC 822 and RFC 2060 are obsolete, and that the current [IMAP] 
specification (RFC 3501) does not modify ABNF in any way, the text "as 
modified by [IMAP4]" is superfluous and should be removed.

-- Mark --

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

Date: Thu, 19 May 2005 17:50:08 -0700
To: "Scott Hollenbeck" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Cc: <[email-masked]>
Sender: [email-masked]

On 5/19/05 at 7:39 PM -0400, Scott Hollenbeck wrote:

>Clarification of the extension model being used (the ABNF import 
>discussion) is not an editorial issue.  It's directly related to the 
>normative reference to RFC 2234.

There is no technical issue with regard to reference to RFC 2234. The 
ABNF in the document is correct and is correctly used as per that 
specification. The only question is whether:

    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
    Non-terminals referenced but not defined below are as defined by
    [IMAP4].

is clear. (Specifically, whether the word "modified" is correct and 
whether it is better to reference "IMAP4" or "IMAP".) None of this is 
technical in nature. There is no technical interpretation of the 
document that could be confused whether or not these corrections are 
made. (That an ABNF validator must be used in a particular way is not 
germane to the technical correctness of this specification. The only 
"normative reference" to 2234 is that you won't be able to figure out 
the syntax without also reading and understanding 2234.) The change 
requested is only an editorial objection to the clarity of a comment.

>Whether or not this document updates 3501 is not an editorial issue.

The contents of an "Updates" header in an RFC are subject to:

ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt

That seems to me very much an editorial issue. Whether this document 
is technically correct does not depend on the contents of that 
particular field in the RFC template. At most, the current text of 
"<<3501?>>" indicates that the editor was not sure whether this 
qualified as an update under those instructions. (My read of the 
instructions is that it does qualify as an update.) No technical 
review of this document will be in any way changed if that text is 
changed. It is editorial only.

>The issue of "MAY" vs. "may" vs. a synonym is not an editorial 
>issue.  It's directly related to the normative reference to RFC 2119.

Neither of the examples you pointed out make one iota of difference 
in the technical interpretation of the document. And it certainly has 
nothing to do with the 2119 reference: In neither case is a 
capitalized imperative used in a way that it shouldn't. In neither 
case would the use of an imperative change the *technical* 
interpretation of the text. This is strictly an editorial objection, 
that use of the non-imperative English word "may" is an inconsistent 
usage, especially in places where the imperatives are used.

>So what now?  I want the document updated to address these three 
>issues at a minimum before I request a last call.

I would really like to insist that the Last Call be issued before 
another draft is done. I obviously have no objection to these (like 
the other editorial) changes being done as a post-Last-Call edit, as 
that can be run in parallel and will not be blocking the process from 
moving forward.

And I am fully aware that we have now spent two days on this already. 
But this is now an "in principle" discussion that I would like 
resolved, other than its effect on this particular document. My 
contention is that the IESG should not be requiring editorial and 
stylistic flubs to be cleaned up prior to Last Call. It's an utter 
waste of the IESG's time and unnecessarily delays the documents 
progression. The IESG is free to make stylistic and editorial 
comments to the editor, and these should be fixed before RFC 
publication to be sure. But to not clean these things up in parallel 
with the Last Call is IMO a problem with the review process that 
needs to be fixed. And at this point, I'm perfectly willing to make 
an appeal on this point (and obviously recuse myself from the IAB 
decision if it gets that far). But one way or the other, I'd like 
this particular process point clarified for the future.

That said: If you are willing to go ahead with the Last Call as-is, 
great. If you still insist on the changes before issuing the Last 
Call, let us know and obviously the WG will have Alexey make the 
changes and submit the new document in the next day or two. In the 
meanwhile I will start the process discussion (starting with the IETF 
Chair, up to and including appeal). In either case, let us know one 
final time how you want to proceed.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 20 May 2005 16:38:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: "'Pete Resnick'" <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>>However, this, like the other comments Scott made, is strictly 
>>editorial. None of these things change the technical meaning of the 
>>spec and should not be required to be changed before IETF last call. 
>>I really do not want to see the IETF last call delayed waiting for 
>>another ID. I would like this one last called.
>>    
>>
>
>Most of the comments I provided were indeed editorial in nature.  Except for
>these:
>
>Clarification of the extension model being used (the ABNF import discussion)
>is not an editorial issue.  It's directly related to the normative reference
>to RFC 2234.  Note: The IESG recently approved a replacement for 2234,
>draft-crocker-abnf-rfc2234bis.  It's in the RFC Editor queue.  The reference
>might need to be updated, but we can leave that for later.
>  
>
Ok.

>Whether or not this document updates 3501 is not an editorial issue.  That
>question should be removed before the community is asked to review the
>document.
>  
>
I agree.

>The issue of "MAY" vs. "may" vs. a synonym is not an editorial issue.  It's
>directly related to the normative reference to RFC 2119.
>  
>
Sure.

>So what now?  I want the document updated to address these three issues at a
>minimum before I request a last call.
>
I suggest that I submit a new revision right now which can be Last 
Called. While this is being done I will fix ID nits.

>  The others can slide for now, but
>they will have to be addressed before I bring the document to the IESG for
>review -- wrap 'em up with whatever else might come out of the last call.
>IDnits issues can wait until after last call, too, but they will need to be
>addressed before IESG evaluation.
>  
>
Ok.

Date: Thu, 19 May 2005 18:49:24 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: updated (-01) rfc2359bis 
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 19 May 2005, Philip Guenther wrote:
> Hmm, the syntax for UID EXPUNGE no longer permits '*' in the uid-set.

Good catch.  That's unintentional, and a bug.  Although I agree with you 
that "*" is a remarkably bad thing to use with UID EXPUNGE, it was 
permitted in RFC 2359 and should in the update since otherwise it's an 
incompatible change.

I'll change the uid-expunge rule to use sequence-set instead of uid-set in 
draft -02.

Thanks!

-- Mark --

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

To: Mark Crispin <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: updated (-01) rfc2359bis 
Date: Thu, 19 May 2005 18:43:59 -0700
Sender: [email-masked]

Mark Crispin <[email-masked]> writes:
>Please review.  I'm hoping that there are no objections to this update and 
>we can get through a quick last-call and submission to the IESG as 
>reflecting WG concensus.

Hmm, the syntax for UID EXPUNGE no longer permits '*' in the uid-set.
While this makes sense given the purpose of the command, it should be
mentioned as a change somewhere.  (Is a server that accepts '*'
non-compliant or does it just become a GIGO case?)

Philip Guenther

From: "Scott Hollenbeck" <[email-masked]>
To: "'Pete Resnick'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Thu, 19 May 2005 19:39:17 -0400
Sender: [email-masked]

> However, this, like the other comments Scott made, is strictly 
> editorial. None of these things change the technical meaning of the 
> spec and should not be required to be changed before IETF last call. 
> I really do not want to see the IETF last call delayed waiting for 
> another ID. I would like this one last called.

Most of the comments I provided were indeed editorial in nature.  Except for
these:

Clarification of the extension model being used (the ABNF import discussion)
is not an editorial issue.  It's directly related to the normative reference
to RFC 2234.  Note: The IESG recently approved a replacement for 2234,
draft-crocker-abnf-rfc2234bis.  It's in the RFC Editor queue.  The reference
might need to be updated, but we can leave that for later.

Whether or not this document updates 3501 is not an editorial issue.  That
question should be removed before the community is asked to review the
document.

The issue of "MAY" vs. "may" vs. a synonym is not an editorial issue.  It's
directly related to the normative reference to RFC 2119.

So what now?  I want the document updated to address these three issues at a
minimum before I request a last call.  The others can slide for now, but
they will have to be addressed before I bring the document to the IESG for
review -- wrap 'em up with whatever else might come out of the last call.
IDnits issues can wait until after last call, too, but they will need to be
addressed before IESG evaluation.

-Scott-

Date: Thu, 19 May 2005 15:51:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Organization: Networks & Distributed Computing
Sender: [email-masked]

[Resending this message to the list as it got misdirected...]

On Mon, 16 May 2005, Dave Cridland wrote:
> My immediate thought is that Message-Id is intended to serve this kind of 
> purpose already, and any technical argument against it must also be 
> applicable to any new header.

The arguments, such as they were, were IMHO spurious; the claim was that 
it was too easy to have false matches.

> In addition, a new header wouldn't be in 
> ENVELOPE.

I don't think that this is necessary or desirable.  Since the primary 
purpose is for synchronization/location, I would think that you'd use 
SEARCH to locate it before fetching any envelopes.

> A possibly better solution might be to provide message-id search criteria 
> support.

Already in IMAP: SEARCH HEADER Message-ID text

-- Mark --

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

Date: Thu, 19 May 2005 14:35:27 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: updated (-01) rfc2359bis
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-1329043306-1116538527=:30530
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Based on the comments I've received, I've updated my proposed rfc2359bis 
document on the I-D repository.  A copy is attached to this message.

Please review.  I'm hoping that there are no objections to this update and 
we can get through a quick last-call and submission to the IESG as 
reflecting WG concensus.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-1329043306-1116538527=:30530
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-01.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-01.txt

---1903383771-1329043306-1116538527=:30530--

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Meeting in Paris
Date: Thu, 19 May 2005 10:35:14 -0700
Sender: [email-masked]

I think we should have an IMAPEXT meeting in Paris to push documents 
forward and twist peoples' arms into doing reviews.  I'll schedule one 
and start collecting agenda items.  Document editors, please let me 
know if you can make it and what to discuss for your drafts.

Lisa

Date: Thu, 19 May 2005 10:01:24 -0400
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: RFC 2359bis
Sender: [email-masked]

Mark,

A couple of comments.

    The added facilities of the features in UIDPLUS are optimizations;
    clients can provide the same functionality, albeit less efficiently,
    by using facilities in the base protocol.

I am being extremely, perhaps even pathologically, nitpicking here but I 
question whether this is strictly true.  Suppose that two client sessions 
APPEND single identical messages to a mailbox more or less at the same 
time.  In such a case, there is likely to be nothing exposed through IMAP 
that can distinguish the two messages other than their UIDs.  Now, one 
might say that if the messages are identical it hardly matters if a client 
cannot reliably identify the one that it appended.  But suppose further 
that each client chooses to immediately delete its newly appended 
message.  If, using discovery, each client happens to identify the same 
copy of the message as its own then a copy of the message could be 
unintentionally left behind.

There is an extraneous word ("is") in the line:

       a message either does not have the \Deleted flag set or is has a

Pete Maclean

At 08:50 PM 5/18/2005, Mark Crispin wrote:
>As promised, I have written my proposed revision to RFC 2359.  I've sent 
>it to the I-D respository, but attached is a copy if you want to get an 
>early look.
>
>I think that I have addressed all of Alexey's concerns (and I hope Alexey 
>will point out if I haven't).  Please note that this is a first draft and 
>so will probably need some editorial revision.
>
>-- Mark --
>
>http://staff.washington.edu/mrc
>Science does not emerge from voting, party politics, or public debate.
>Si vis pacem, para bellum.
>

Date: Thu, 19 May 2005 09:52:53 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked], Scott Hollenbeck <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Hi Pete,

--On May 19, 2005 6:29:12 AM -0700 Pete Resnick <[email-masked]> 
wrote:

> The purpose here is not to be clear to people who want to validate ABNF;
> they are not the audience for this document. The purpose here is to be
> clear to people who want to implement IMAP using the ABNF. If this needs
> fixing, perhaps the language I used in the CATENATE document would be
> useful:
>
>     The following syntax specification uses the Augmented Backus-Naur
>     Form (ABNF) [7] notation.  Elements not defined here can be found in
>     the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
>     [8] specifications.
>
> However, this, like the other comments Scott made, is strictly editorial.
> None of these things change the technical meaning of the spec and should
> not be required to be changed before IETF last call. I really do not want
> to see the IETF last call delayed waiting for another ID. I would like
> this one last called.

One thing to bear in mind with the CATENATE description - the ordering of 
'import' of ABNF from IMAP [1] and IMAP ABNF [8] is important. Yes it 
should be obvious that definitions IMAP ABNF replace those in IMAP, but 
maybe this should be explicit. As an example, here is what I had in 
ANNOTATE:

   Non-terminals referenced but not defined below are as defined by
   [RFC3501] with the new definitions in [ABNFEXT] superceding those in
   [RFC3501].

Combining this with your's:

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) [7] notation.  Elements not defined here can be found in
    the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
    [8] specifications, with the new definitions in IMAP ABNF [8] 
superceding
    those in IMAP [1].

I agree with you that this is only an editorial change and should not 
affect last call status.

-- 
Cyrus Daboo

Date: Thu, 19 May 2005 06:29:12 -0700
To: Lisa Dusseault <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Cc: Mark Crispin <[email-masked]>, [email-masked], Scott Hollenbeck <[email-masked]>
Sender: [email-masked]

On 5/18/05 at 3:54 PM -0700, Lisa Dusseault wrote:

>Seems to me that the text
>
>    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>    Non-terminals referenced but not defined below are as defined by
>    [IMAP4].
>
>is slightly misleading if not incorrect, because as Philip points 
>out IMAP4 doesn't modify ABNF itself.

Fair enough. However:

>The paragraph could be clearer for people who want to validate the 
>ABNF.  It could read:
>
>    Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
>    defined in [IMAP4].  The IMAP4 ABNF should be imported first before
>    attempting to validate these rules.

The purpose here is not to be clear to people who want to validate 
ABNF; they are not the audience for this document. The purpose here 
is to be clear to people who want to implement IMAP using the ABNF. 
If this needs fixing, perhaps the language I used in the CATENATE 
document would be useful:

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) [7] notation.  Elements not defined here can be found in
    the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
    [8] specifications.

However, this, like the other comments Scott made, is strictly 
editorial. None of these things change the technical meaning of the 
spec and should not be required to be changed before IETF last call. 
I really do not want to see the IETF last call delayed waiting for 
another ID. I would like this one last called.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

Date: Thu, 19 May 2005 06:23:01 -0700
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Cc: Scott Hollenbeck <[email-masked]>, [email-masked]
Sender: [email-masked]

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Thu, 19 May 2005 07:41:16 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 10:30 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> On Wed, 18 May 2005, Scott Hollenbeck wrote:
> >> In particular, I fail to understand how the ABNF parsing can
> >> be done any other way than starting with the ABNF from the
> >> base specification and then following with the ABNF from
> >> whatever specification is extending the base specification.
> > I've identified the sequence of improperly combined ABNF 
> rules that can
> > cause parser failure.  I agree that the sequence you 
> described above is what
> > MUST happen to ensure that the combined ABNF is valid.  
> I've been trying to
> > say that I don't believe that the text makes this sequence clear.
> 
> OK, I think I'm starting to understand.  So the ABNF is fine, and the 
> text introducing the ABNF is broken.  Correct?

Correct.  My original suggestion to change the ABNF was mistaken.

-Scott-

Date: Thu, 19 May 2005 11:31:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>, "'Pete Resnick'" <[email-masked]>
CC: [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>>-----Original Message-----
>>From: Pete Resnick [mailto:[email-masked]] 
>>Sent: Wednesday, May 18, 2005 5:25 PM
>>To: Scott Hollenbeck
>>Cc: 'Mark Crispin'; [email-masked]
>>Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
>>
>>On 5/17/05 at 6:11 PM -0400, Scott Hollenbeck wrote:
>>
>>    
>>
>>>>On Tue, 17 May 2005, Scott Hollenbeck wrote:
>>>>        
>>>>
>>>>>I'd prefer to see an ABNF comment like this if you want to do 
>>>>>something like that:
>>>>>;;capability     = <defined in [IMAP]>
>>>>>This makes it clear that a parser shouldn't try to parse the 
>>>>>incomplete rule.
>>>>>          
>>>>>
>>>>If this is done, will you then be content with the =/ definitions?
>>>>        
>>>>
>>>Yes.  I now understand the intent and believe that a little bit of 
>>>explicit clarification is all that's needed to help others avoid the 
>>>mistake I made in trying to parse the ABNF by itself.
>>>      
>>>
>>Scott, I've got to say that I really object to this 
>>silliness. There is *no* ambiguity whatsoever if you are 
>>implementing an IMAP client or server because you *must* 
>>implement 3501. This is only a problem if you are a blind 
>>reader who is not doing an implementation. The "=/" is 
>>perfectly clear that you're going to have to look for the 
>>original terminal elsewhere.
>>
>>Alexey, I would ask that you not make this change.
>>    
>>
>
>Sorry, Pete, but I disagree completely that this is silliness.  The complete
>ABNF specification will be invalid if not constructed by merging rules with
>those in 3501 in a very particular way.  The method needed to form a valid,
>complete ABNF specification is NOT clear in the draft as written.  For
>example:
>
>;; from 2086upd
>capability      =/ rights-capa
>;; from 3501
>capability      = ("AUTH=" auth-type) / atom
>
>will not parse.  The rules MUST be combined in this order:
>
>;; from 3501
>capability      = ("AUTH=" auth-type) / atom
>;; from 2086upd
>capability      =/ rights-capa
>
>Be clear now or be clear later.  I can guarantee that this situation will be
>(and has been) noted by other reviewers.
>  
>
I have not changed "=/" to "=", but I've added a clarifying statement 
about productions defined in RFC 3501.

Date: Wed, 18 May 2005 19:29:32 -0700
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Scott Hollenbeck wrote:
>> In particular, I fail to understand how the ABNF parsing can
>> be done any other way than starting with the ABNF from the
>> base specification and then following with the ABNF from
>> whatever specification is extending the base specification.
> I've identified the sequence of improperly combined ABNF rules that can
> cause parser failure.  I agree that the sequence you described above is what
> MUST happen to ensure that the combined ABNF is valid.  I've been trying to
> say that I don't believe that the text makes this sequence clear.

OK, I think I'm starting to understand.  So the ABNF is fine, and the 
text introducing the ABNF is broken.  Correct?

> By the way, this reminds of something else: I think that what I said
> yesterday about this document updating 3501 is incorrect.  I originally
> thought that the ABNF was intended to replace parts of what's in 3501, but
> as a result of this discussion I now understand that I was mistaken.  If
> someone can implement 3501 without being required to consult this spec then
> there's no update involved?

I agree that this document does not update 3501.  As with other IMAP 
extensions documents, this document extends the protocol described in 3501 
with optional facilities, which can be disregarded by an implementor of 
3501 who is not interested in those facilities.

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 22:15:37 -0400
Sender: [email-masked]

> In particular, I fail to understand how the ABNF parsing can 
> be done any other way than starting with the ABNF from the 
> base specification and then following with the ABNF from 
> whatever specification is extending the base specification.

I've identified the sequence of improperly combined ABNF rules that can
cause parser failure.  I agree that the sequence you described above is what
MUST happen to ensure that the combined ABNF is valid.  I've been trying to
say that I don't believe that the text makes this sequence clear.

By the way, this reminds of something else: I think that what I said
yesterday about this document updating 3501 is incorrect.  I originally
thought that the ABNF was intended to replace parts of what's in 3501, but
as a result of this discussion I now understand that I was mistaken.  If
someone can implement 3501 without being required to consult this spec then
there's no update involved?

-Scott-

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>, "'Lisa Dusseault'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 22:15:37 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 7:00 PM
> To: Lisa Dusseault
> Cc: [email-masked]; Scott Hollenbeck
> Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> On Wed, 18 May 2005, Lisa Dusseault wrote:
> >   Formal syntax is defined using ABNF [ABNF], extending the 
> ABNF rules
> >   defined in [IMAP4].  The IMAP4 ABNF should be imported 
> first before
> >   attempting to validate these rules.
> 
> If this is what this was all about, then I have no objection. 
>  The discussion so far suggests that it's something else, 
> hence my continued confusion.

This is what I've been trying to describe.  Sorry if that hasn't been clear.

-Scott-

Date: Wed, 18 May 2005 17:50:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: RFC 2359bis
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-1054626394-1116463832=:14801
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

As promised, I have written my proposed revision to RFC 2359.  I've sent 
it to the I-D respository, but attached is a copy if you want to get an 
early look.

I think that I have addressed all of Alexey's concerns (and I hope Alexey 
will point out if I haven't).  Please note that this is a first draft and 
so will probably need some editorial revision.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-1054626394-1116463832=:14801
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-00.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-00.txt

---1903383771-1054626394-1116463832=:14801--

Date: Wed, 18 May 2005 16:00:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: [email-masked], Scott Hollenbeck <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Lisa Dusseault wrote:
>   Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
>   defined in [IMAP4].  The IMAP4 ABNF should be imported first before
>   attempting to validate these rules.

If this is what this was all about, then I have no objection.  The 
discussion so far suggests that it's something else, hence my continued 
confusion.

-- Mark --

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

Date: Wed, 18 May 2005 15:57:31 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Scott Hollenbeck wrote:
> The problem is that you can't just paste the ABNF from the two documents
> together to produce a syntactically valid ABNF spec.  The rules from the
> extension MUST appear after the rules from 3501 to produce ABNF that can be
> processed without error by a validating parser because of the way that
> incremental construction works.

I fail to comprehend the distinction that is being made here.

In particular, I fail to understand how the ABNF parsing can be done any 
other way than starting with the ABNF from the base specification and then 
following with the ABNF from whatever specification is extending the base 
specification.

I may be the stupidest person in the world, but I suspect that I am not 
alone in being bewildered as to what the problem may be.

-- Mark --

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

Cc: [email-masked], Scott Hollenbeck <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 15:54:09 -0700
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

Seems to me that the text

    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
    Non-terminals referenced but not defined below are as defined by
    [IMAP4].

is slightly misleading if not incorrect, because as Philip points out 
IMAP4 doesn't modify ABNF itself.  It isn't obvious to me that 
'capability' is a non-terminal though I suppose it might be.  The 
paragraph could be clearer for people who want to validate the ABNF.  
It could read:

    Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
    defined in [IMAP4].  The IMAP4 ABNF should be imported first before
    attempting to validate these rules.

We could work around this without changing the doc by introducing it to 
the IESG along with the explanation in email but if we're changing the 
draft for a few nits we might as well include this one.

Alexey, BTW -- Ekr has a perl script that will generate a TOC from text 
if I understand correctly.  I was hoping a TOC wasn't required and that 
the line lengths could be fixed after IESG review but they can also be 
fixed now.

Lisa

On May 18, 2005, at 3:30 PM, Mark Crispin wrote:

>
> On Wed, 18 May 2005, Scott Hollenbeck wrote:
>> I am NOT suggesting that the rules be duplicated.  What I am 
>> referring to is
>> Pete's assertion that an implementer is going to have to combine the 
>> rules
>> etc. from 3501 (I'm paraphrasing here, OK?) and this document to 
>> obtain a
>> complete ABNF spec.  I agree with that.  My assertion is that when 
>> forming
>> that combination the order of the rules is significant if you're using
>> incremental construction.
>
> I guess that I still don't understand what the problem is.
>
> With any IMAP extension specification, you start with the rules in 
> [IMAP] (currently 3501) and then add the rules from the extension.  So 
> the rule defining "capability" will always appear before the rule 
> extending "capability", because "capability" is defined in [IMAP] and 
> extended in the extension.
>
> This is also the case with the MULTIAPPEND extension (3502), which 
> actually replaced a rule of [IMAP].
>
> If the problem is simply that you feel that it's unclear that [IMAP]'s 
> rules are incorporated as a prefix to the rules in the document, then 
> please suggest preferable broilerplate for that text.
>
> I have the feeling that we're all arguing loudly for the same thing, 
> but not understanding each other.  I think that what raised hackles is 
> the notion that 2086upd had to duplicate the "capability" rule rather 
> than inherit it from [IMAP].
>
> So, could we please try again, with a clearer statement of what is 
> needed?
> I'm still confused as to what was the original problem.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 18:47:05 -0400
Sender: [email-masked]

> So, could we please try again, with a clearer statement of 
> what is needed?
> I'm still confused as to what was the original problem.

The ABNF comment that we talked about yesterday, or the text just offered by
Philip Guenther, would be fine.

The problem is that you can't just paste the ABNF from the two documents
together to produce a syntactically valid ABNF spec.  The rules from the
extension MUST appear after the rules from 3501 to produce ABNF that can be
processed without error by a validating parser because of the way that
incremental construction works.

I *know* I'm being picky, but if 2234 is being cited as a normative
reference we can't ignore the parts we don't like.

-Scott-

From: [email-masked]
Cc: Scott Hollenbeck <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 18 May 2005 15:00:51 -0700 (PDT)
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
To: Pete Resnick <[email-masked]>
Sender: [email-masked]

> On 5/17/05 at 6:11 PM -0400, Scott Hollenbeck wrote:

> >>On Tue, 17 May 2005, Scott Hollenbeck wrote:
> >>>I'd prefer to see an ABNF comment like this if you want to do
> >>>something like that:
> >>>;;capability     = <defined in [IMAP]>
> >>>This makes it clear that a parser shouldn't try to parse the
> >>>incomplete rule.
> >>
> >>If this is done, will you then be content with the =/ definitions?
> >
> >Yes.  I now understand the intent and believe that a little bit of
> >explicit clarification is all that's needed to help others avoid the
> >mistake I made in trying to parse the ABNF by itself.

And here I was thinking I was the only one who had this reaction... and
keeping silent. Thanks Pete for posting this.

> Scott, I've got to say that I really object to this silliness. There
> is *no* ambiguity whatsoever if you are implementing an IMAP client
> or server because you *must* implement 3501. This is only a problem
> if you are a blind reader who is not doing an implementation. The
> "=/" is perfectly clear that you're going to have to look for the
> original terminal elsewhere.

Exactly so. We need to focus on changes that actually improve our protocols or
which make them easier to implement. And IMO this doesn't qualify.

Rigorous, repeated checking of ABNF is fine and dandy, but it has to take into 
account that ABNF rulesets routinely inherit productions from other documents.
If this cannot be taken into account the checking is causing more problems than
it solves. In my experience at least ABNF errors detectable by an automatic
checker have not been a signficant source of implementation issues. (Sadly, the
same cannot be said for cases where the ABNF parses fine but nevertheless was
broken in some way.)

> Alexey, I would ask that you not make this change.

At one level really don't care about whether or not this particular change gets
made. It's a small matter.

But the problem is that there are now so many of these small matters, each
masquerading as something important, that they are collectively causing real
damage to the overall process by causing frustration and introducing delays.

We now spend precious time discussing things like whether or not the
grammar for ABNF itself should support the ability to bind a comment to 
a particular ABNF rule. Or whether or not the ABNF grammar should specify
a multiplicity of line terminators instead of the canonical CRLF. Or whether
or not the LTRU group should extend the concept of a charset label to include
script tags. (Thankfully, this last got shut down, but before a bunch of
time was wasted on it.) And so on. These are just off the top of my head; I'm
sure I could come up with many other, and probably better, examples.

I don't have a suggestion for how to eliminate improvement suggestions whose
cost outweighs the benefits. And failing that, the only thing I know to do is
to push back on this stuff. As such, I'm with Pete in asking for this change
not to be made.

				Ned

Date: Wed, 18 May 2005 15:30:13 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Scott Hollenbeck wrote:
> I am NOT suggesting that the rules be duplicated.  What I am referring to is
> Pete's assertion that an implementer is going to have to combine the rules
> etc. from 3501 (I'm paraphrasing here, OK?) and this document to obtain a
> complete ABNF spec.  I agree with that.  My assertion is that when forming
> that combination the order of the rules is significant if you're using
> incremental construction.

I guess that I still don't understand what the problem is.

With any IMAP extension specification, you start with the rules in [IMAP] 
(currently 3501) and then add the rules from the extension.  So the rule 
defining "capability" will always appear before the rule extending 
"capability", because "capability" is defined in [IMAP] and extended in 
the extension.

This is also the case with the MULTIAPPEND extension (3502), which 
actually replaced a rule of [IMAP].

If the problem is simply that you feel that it's unclear that [IMAP]'s 
rules are incorporated as a prefix to the rules in the document, then 
please suggest preferable broilerplate for that text.

I have the feeling that we're all arguing loudly for the same thing, but 
not understanding each other.  I think that what raised hackles is the 
notion that 2086upd had to duplicate the "capability" rule rather than 
inherit it from [IMAP].

So, could we please try again, with a clearer statement of what is needed?
I'm still confused as to what was the original problem.

-- Mark --

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

From: Philip Guenther <[email-masked]>
To: Scott Hollenbeck <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd 
Date: Wed, 18 May 2005 15:22:18 -0700
Sender: [email-masked]

I wrote:
...
>(Come to think of it, I'm not sure what "as modified by [IMAP4]" was
>supposed to mean, as [IMAP] doesn't 'modify' the rules of ABNF.)

Looking backwards, I strongly suspect this originated from when RFC
2060 was the IMAP base spec, as it *did* modify the BNF syntax rules
from those in straight RFC 822.  Now that [IMAP4] is RFC 3501 and
ABNF is used without modification, I think that IMAP extensions
should drop the "as modified by" text.

Philip Guenther

From: "Scott Hollenbeck" <[email-masked]>
To: "'Philip Guenther'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd 
Date: Wed, 18 May 2005 18:14:37 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Philip Guenther [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 6:07 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd 
> 
> Scott Hollenbeck <[email-masked]> writes:
> >>Pete Resnick writes:
> ...
> >> Scott, I've got to say that I really object to this 
> silliness. There 
> >> is *no* ambiguity whatsoever if you are implementing an 
> IMAP client 
> >> or server because you *must* implement 3501. This is only 
> a problem 
> >> if you are a blind reader who is not doing an implementation. The 
> >> "=/" is perfectly clear that you're going to have to look for the 
> >> original terminal elsewhere.
> >
> >Sorry, Pete, but I disagree completely that this is silliness.  The 
> >complete ABNF specification will be invalid if not constructed by 
> >merging rules with those in 3501 in a very particular way.  
> The method 
> >needed to form a valid, complete ABNF specification is NOT 
> clear in the 
> >draft as written.  For
> >example:
> ...
> 
> The first paragraph of the Formal Syntax section reads;
>    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>    Non-terminals referenced but not defined below are as defined by
>    [IMAP4].
> 
> 
> Would it be sufficient to change that to something like:
>    Formal syntax is defined using ABNF [ABNF] as an extension to
>    the syntax in section 9 of [IMAP].
> or maybe
>    Formal syntax is defined using ABNF [ABNF], extending the rules
>    in section 9 of [IMAP].

We talked about this possibility yesterday.  I'd be OK with either text like
this or a comment in the ABNF itself, and I believe I can defend both to
future reviwers if need be.

-Scott-

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 18:10:23 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 5:54 PM
> To: Scott Hollenbeck
> Cc: 'Pete Resnick'; [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> On Wed, 18 May 2005, Scott Hollenbeck wrote:
> > ;; from 2086upd
> > capability      =/ rights-capa
> > ;; from 3501
> > capability      = ("AUTH=" auth-type) / atom
> > will not parse.  The rules MUST be combined in this order:
> > ;; from 3501
> > capability      = ("AUTH=" auth-type) / atom
> > ;; from 2086upd
> > capability      =/ rights-capa
> 
> 
> Now I am confused.
> 
> Are you really saying that ABNF can not have any forward 
> references?  If so, I vehemently object.  ABNF rules should 
> be in alphabetical order, so that mere mortals can find it.
> 
> If not, then it is completely unambiguous to state:
> 
>  	capability      =/ rights-capa
> 
>  	capability      = ("AUTH=" auth-type) / atom
> 
> because =/ is effectively a forward reference.
> 
> 
> I don't terribly mind having
> 
>  	capability      = <<defined in [IMAP]>>
> 
> if that makes the IESG happy, but I most certainly object to 
> duplicating the definition of an [IMAP] rules a different 
> document.  That will break if [IMAP] ever changes the 
> definition of the rule.

Mark, please read section 3.3 of RRC 2234.  It describes the order of the
rules when using incremental construction.  ABNF is what it is.

I am NOT suggesting that the rules be duplicated.  What I am referring to is
Pete's assertion that an implementer is going to have to combine the rules
etc. from 3501 (I'm paraphrasing here, OK?) and this document to obtain a
complete ABNF spec.  I agree with that.  My assertion is that when forming
that combination the order of the rules is significant if you're using
incremental construction.

I've tested this using Bill Fenner's ABNF parser.  It supports my claim.

Look, if you all want to push back I'll gladly ask the rest of the IESG to
comment.  They'll eventually have to look anyway, and as I said, we can
either be clear now or we can be clear later.  I believe that adding a
comment as I described earlier will address an issue that has been raised by
other reviewers for other documents that use ABNF in the same way.

-Scott-

To: Scott Hollenbeck <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd 
Date: Wed, 18 May 2005 15:07:22 -0700
Sender: [email-masked]

Scott Hollenbeck <[email-masked]> writes:
>>Pete Resnick writes:
...
>> Scott, I've got to say that I really object to this 
>> silliness. There is *no* ambiguity whatsoever if you are 
>> implementing an IMAP client or server because you *must* 
>> implement 3501. This is only a problem if you are a blind 
>> reader who is not doing an implementation. The "=/" is 
>> perfectly clear that you're going to have to look for the 
>> original terminal elsewhere.
>
>Sorry, Pete, but I disagree completely that this is silliness.  The complete
>ABNF specification will be invalid if not constructed by merging rules with
>those in 3501 in a very particular way.  The method needed to form a valid,
>complete ABNF specification is NOT clear in the draft as written.  For
>example:
...

The first paragraph of the Formal Syntax section reads;
   Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
   Non-terminals referenced but not defined below are as defined by
   [IMAP4].

Would it be sufficient to change that to something like:
   Formal syntax is defined using ABNF [ABNF] as an extension to
   the syntax in section 9 of [IMAP].
or maybe
   Formal syntax is defined using ABNF [ABNF], extending the rules
   in section 9 of [IMAP].

(Come to think of it, I'm not sure what "as modified by [IMAP4]" was
supposed to mean, as [IMAP] doesn't 'modify' the rules of ABNF.)

Philip Guenther

Date: Wed, 18 May 2005 14:54:06 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: "'Pete Resnick'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Scott Hollenbeck wrote:
> ;; from 2086upd
> capability      =/ rights-capa
> ;; from 3501
> capability      = ("AUTH=" auth-type) / atom
> will not parse.  The rules MUST be combined in this order:
> ;; from 3501
> capability      = ("AUTH=" auth-type) / atom
> ;; from 2086upd
> capability      =/ rights-capa

Now I am confused.

Are you really saying that ABNF can not have any forward references?  If 
so, I vehemently object.  ABNF rules should be in alphabetical order, so 
that mere mortals can find it.

If not, then it is completely unambiguous to state:

 	capability      =/ rights-capa

 	capability      = ("AUTH=" auth-type) / atom

because =/ is effectively a forward reference.

I don't terribly mind having

 	capability      = <<defined in [IMAP]>>

if that makes the IESG happy, but I most certainly object to duplicating 
the definition of an [IMAP] rules a different document.  That will break 
if [IMAP] ever changes the definition of the rule.

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Pete Resnick'" <[email-masked]>
Cc: "'Mark Crispin'" <[email-masked]>, <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 17:39:58 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Pete Resnick [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 5:25 PM
> To: Scott Hollenbeck
> Cc: 'Mark Crispin'; [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> On 5/17/05 at 6:11 PM -0400, Scott Hollenbeck wrote:
> 
> >>On Tue, 17 May 2005, Scott Hollenbeck wrote:
> >>>I'd prefer to see an ABNF comment like this if you want to do 
> >>>something like that:
> >>>;;capability     = <defined in [IMAP]>
> >>>This makes it clear that a parser shouldn't try to parse the 
> >>>incomplete rule.
> >>
> >>If this is done, will you then be content with the =/ definitions?
> >
> >Yes.  I now understand the intent and believe that a little bit of 
> >explicit clarification is all that's needed to help others avoid the 
> >mistake I made in trying to parse the ABNF by itself.
> 
> Scott, I've got to say that I really object to this 
> silliness. There is *no* ambiguity whatsoever if you are 
> implementing an IMAP client or server because you *must* 
> implement 3501. This is only a problem if you are a blind 
> reader who is not doing an implementation. The "=/" is 
> perfectly clear that you're going to have to look for the 
> original terminal elsewhere.
> 
> Alexey, I would ask that you not make this change.

Sorry, Pete, but I disagree completely that this is silliness.  The complete
ABNF specification will be invalid if not constructed by merging rules with
those in 3501 in a very particular way.  The method needed to form a valid,
complete ABNF specification is NOT clear in the draft as written.  For
example:

;; from 2086upd
capability      =/ rights-capa
;; from 3501
capability      = ("AUTH=" auth-type) / atom

will not parse.  The rules MUST be combined in this order:

;; from 3501
capability      = ("AUTH=" auth-type) / atom
;; from 2086upd
capability      =/ rights-capa

Be clear now or be clear later.  I can guarantee that this situation will be
(and has been) noted by other reviewers.

-Scott-

Date: Wed, 18 May 2005 14:25:29 -0700
To: "Scott Hollenbeck" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Cc: "'Mark Crispin'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 5/17/05 at 6:11 PM -0400, Scott Hollenbeck wrote:

>>On Tue, 17 May 2005, Scott Hollenbeck wrote:
>>>I'd prefer to see an ABNF comment like this if you want to do 
>>>something like that:
>>>;;capability     = <defined in [IMAP]>
>>>This makes it clear that a parser shouldn't try to parse the 
>>>incomplete rule.
>>
>>If this is done, will you then be content with the =/ definitions?
>
>Yes.  I now understand the intent and believe that a little bit of 
>explicit clarification is all that's needed to help others avoid the 
>mistake I made in trying to parse the ABNF by itself.

Scott, I've got to say that I really object to this silliness. There 
is *no* ambiguity whatsoever if you are implementing an IMAP client 
or server because you *must* implement 3501. This is only a problem 
if you are a blind reader who is not doing an implementation. The 
"=/" is perfectly clear that you're going to have to look for the 
original terminal elsewhere.

Alexey, I would ask that you not make this change.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

Date: Wed, 18 May 2005 11:09:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

On Wed, 18 May 2005, Alexey Melnikov wrote:
> If one has a server that doesn't support persistent UIDs, what is exactly the 
> point of implementing UID EXPUNGE? Such server should instead extend EXPUNGE 
> to accept message set (which is arguable fixes a deficiency in EXPUNGE).

That's a good question.  Fortunately, there's an equally good answer.

Allowing a message sequence set in EXPUNGE opens up complex message 
sequence synchronization problems.  This is something that has proven 
problematic enough with the existing protocol without adding such a 
dangerous command.

Even though the mail store doesn't have persistent UIDs, they are 
generally persistant in the session and thus UID EXPUNGE does not have 
these problems.

Also, UID EXPUNGE can be streamed.

-- Mark --

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

Date: Wed, 18 May 2005 11:05:42 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

On Wed, 18 May 2005, Alexey Melnikov wrote:
>>> I also want a big note saying that if the server can't *ever* return a 
>>> correct APPENDUID/COPYUID, than it must not advertise support for UIDPLUS.
>>> (Some text about multiple mailstores when some of them don't support 
>>> persistent UIDs might be appropriate as well.)
>> I don't think that we can do this; such a statement would be unenforcable.
> I know, that is why it should be a "note".

"MUST" is inconsistant with being a "note".

I agree with encouraging APPENDUID/COPYUID, but I believe that is all that 
we should do.  In any case, UID EXPUNGE should not be held hostage.

> What I meant was "the code was never written to do APPENDUID/COPYUID", as 
> opposed to the server is not configured with a mailstore that supports 
> APPENDUID/COPYUID.

As a practical matter, it makes no difference to the client.  Therefore, 
it does not belong in a protocol specification.  It may be appropriate for 
an "IMAP Implementation Recommendations" document.

> Well, a server that recognizes UID EXPUNGE and always returns NO, plus never 
> returns COPYUID/APPENDUID would also be compliant with rfc2359bis.

That's arguable.  I don't think that a server should refuse UID EXPUNGE 
with a NO if it allows EXPUNGE.

I think that we can make that be a requirement.  If we do that, then "UID 
EXPUNGE always returns NO" would not be in compliance with rfc2359bis.

The rationale is that the UIDPLUS capability advertises that a useful 
implementation of UID EXPUNGE is present.  It doesn't really advertise 
APPENDUID/COPYUID because those are responses, not commands; either they 
come back or they don't come back.

-- Mark --

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

Date: Wed, 18 May 2005 18:39:24 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> It was a terrible mistake to bundle UID EXPUNGE with 
> APPENDUID/COPYUID. The intent was to pressure servers to implement 
> APPENDUID/COPYUID.  This backfired; clients can't rely upon being able 
> to use UID EXPUNGE because multiple servers implementations do not 
> have it.

If one has a server that doesn't support persistent UIDs, what is 
exactly the point of implementing UID EXPUNGE? Such server should 
instead extend EXPUNGE to accept message set (which is arguable fixes a 
deficiency in EXPUNGE).

Date: Wed, 18 May 2005 18:34:11 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 18 May 2005, Alexey Melnikov wrote:
>
>> I also want a big note saying that if the server can't *ever* return 
>> a correct APPENDUID/COPYUID, than it must not advertise support for 
>> UIDPLUS.
>> (Some text about multiple mailstores when some of them don't support 
>> persistent UIDs might be appropriate as well.)
>
> I don't think that we can do this; such a statement would be unenforcable.

I know, that is why it should be a "note".

> It has never worked in the past to use MUST/MUST NOT to enforce a 
> quality of implementation issue, especially when there are legitimate 
> reasons to violate the preferred behavior.
>
> Just what is "can't *ever*"?  Think about that.  Suppose the site' 
> mail store is entirely one without sticky UIDs.  The server software 
> is completely capable of doing UID EXPUNGE, and if a better mail store 
> is installed it could do APPENDUID/COPYUID.

What I meant was "the code was never written to do APPENDUID/COPYUID", 
as opposed to the server is not configured with a mailstore that 
supports APPENDUID/COPYUID.

> What you're saying, in effect, is that the server has to somehow check 
> to see if there is no other mail store other than the crippled one, 
> and if so it has to disable the UID EXPUNGE command and not advertise 
> UIDPLUS.

Well, that would be welcomed, but actually not what I was talking about.

>> This is basically to prevent lazy implementations which assume that 
>> implementing UID EXPUNGE and violating "SHOULD return 
>> APPENDUID/COPYUID" should be sufficient to be compliant.
>
> Although I sympathize with your intentions, I'm on the opposite side 
> from you on this.
>
> There are different standards for "compliant" and "fully implement"; 
> and "compliant" does not always mean "useful".
>
> In my opinion, a server which advertises UIDPLUS, implements UID 
> EXPUNGE, but never returns APPENDUID/COPYUID (and makes not attempt to 
> do so) is fully compliant with rfc2359bis.  I also contend that RFC 
> 2359 does not explicitly state that it is mandatory to return 
> APPENDUID/COPYUID.

Well, a server that recognizes UID EXPUNGE and always returns NO, plus 
never returns COPYUID/APPENDUID would also be compliant with rfc2359bis.

> On the other hand, such a server does not fully implement rfc2359bis.

Date: Wed, 18 May 2005 10:14:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

On Wed, 18 May 2005, Alexey Melnikov wrote:
> I also want a big note saying that if the server can't *ever* return a 
> correct APPENDUID/COPYUID, than it must not advertise support for UIDPLUS.
> (Some text about multiple mailstores when some of them don't support 
> persistent UIDs might be appropriate as well.)

I don't think that we can do this; such a statement would be unenforcable. 
It has never worked in the past to use MUST/MUST NOT to enforce a quality 
of implementation issue, especially when there are legitimate reasons to 
violate the preferred behavior.

Just what is "can't *ever*"?  Think about that.  Suppose the site' mail 
store is entirely one without sticky UIDs.  The server software is 
completely capable of doing UID EXPUNGE, and if a better mail store is 
installed it could do APPENDUID/COPYUID.

What you're saying, in effect, is that the server has to somehow check to 
see if there is no other mail store other than the crippled one, and if so 
it has to disable the UID EXPUNGE command and not advertise UIDPLUS.

> This is basically to prevent lazy implementations which assume that 
> implementing UID EXPUNGE and violating "SHOULD return APPENDUID/COPYUID" 
> should be sufficient to be compliant.

Although I sympathize with your intentions, I'm on the opposite side from 
you on this.

There are different standards for "compliant" and "fully implement"; and 
"compliant" does not always mean "useful".

In my opinion, a server which advertises UIDPLUS, implements UID EXPUNGE, 
but never returns APPENDUID/COPYUID (and makes not attempt to do so) is 
fully compliant with rfc2359bis.  I also contend that RFC 2359 does not 
explicitly state that it is mandatory to return APPENDUID/COPYUID.

On the other hand, such a server does not fully implement rfc2359bis.

It was a terrible mistake to bundle UID EXPUNGE with APPENDUID/COPYUID. 
The intent was to pressure servers to implement APPENDUID/COPYUID.  This 
backfired; clients can't rely upon being able to use UID EXPUNGE because 
multiple servers implementations do not have it.

-- Mark --

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

Date: Wed, 18 May 2005 17:36:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> On Tue, 17 May 2005, Alexey Melnikov wrote:
>
>>> It is also ambiguous as to whether a server which does not support 
>>> UID EXPUNGE may send APPENDUID/COPYUID response codes.
>>
>> I frankly can't see why implementing UID EXPUNGE might be difficult, 
>> but I don't see a reason why not.
>
> Agreed on both points.
>
>>> The alternate interpretation, that UIDPLUS covers the response codes,
>>
>> Which was always my interpretation.
>
> I agree that this is the most likely current interpretation.  I think 
> that this interpretation is wrong, because...:
>
>>> necessitates that, in the case of a mail store that does not have 
>>> sticky UIDs (that is, UIDVALIDITY changes at each SELECT), the 
>>> server issue false (but plausible-seeming) information in an 
>>> APPENDUID/COPYUID response code.
>>
>> Or the server can omit the response code entirely and any correctly 
>> written IMAP client should handle that properly.
>
> I agree that this is desirable and should be the goal, but that is not 
> what RFC 2359 implies by tying UIDPLUS to the response codes.
>
>>> I can not believe that the intent of RFC 2359 is that a server send 
>>> a complete fabrication in the case of a server which supports 
>>> multiple mail stores, only some of which have sticky UIDs.
>>
>> Omitting the response code seems better than returning fake information.
>
> I agree, which is why I want to update RFC 2359 so that:
>
> (1) The UIDPLUS capability only covers the UID EXPUNGE command.
>
> (2) ALL servers SHOULD issue APPENDUID/COPYUID responses, regardless of
>     whether or not they offer UIDPLUS.

If this means that RFC 2359 update "updates RFC 3501", than this is fine 
with me.

> (3) If a server can not issue a correct APPENDUID/COPYUID response 
> because
>     of server implementation or mail store limitation, then it MUST NOT
>     issue a APPENDUID/COPYUID with fake information.  Instead, it would
>     just omit APPENDUID/COPYUID in the response.

I also want a big note saying that if the server can't *ever* return a 
correct APPENDUID/COPYUID, than it must not advertise support for UIDPLUS.
(Some text about multiple mailstores when some of them don't support 
persistent UIDs might be appropriate as well.)
This is basically to prevent lazy implementations which assume that 
implementing UID EXPUNGE and violating "SHOULD return APPENDUID/COPYUID" 
should be sufficient to be compliant.

> I believe that RFC 2359 is correctly interpreted as saying:
>
> (a) The UIDPLUS capability covers both the UID EXPUNGE command and the
>     APPENDUID/COPYUID responses.
>
> (b) Servers which do not advertise UIDPLUS MUST NOT issue
>     APPENDUID/COPYUID responses, and servers which advertise UIDPLUS MUST
>     issue APPENDUID/COPYUID responses.
>
> (b) If a server which advertises UIDPLUS can not issue a correct
>     APPENDUID/COPYUID response because of a mail store limitation beyond
>     control of the server implementation, then it MUST issue a
>     APPENDUID/COPYUID with fake information.
>
> I consider (a) - (c) to be undesirable.  Consequently, I believe that 
> RFC 2359 should be revised to be updated as per (1) - (3) above.
>
> Is there a hum of concensus on this issue?  Or, alternatively, a snarl 
> of rejection?

Hum, assuming you agree with the 2 points mentioned above.

Date: Wed, 18 May 2005 12:09:56 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> 
> On Tue, 17 May 2005, Alexey Melnikov wrote:
> 
>>> It is also ambiguous as to whether a server which does not support 
>>> UID EXPUNGE may send APPENDUID/COPYUID response codes.
>>
>> I frankly can't see why implementing UID EXPUNGE might be difficult, 
>> but I don't see a reason why not.
> 
> 
> Agreed on both points.
> 
>>> The alternate interpretation, that UIDPLUS covers the response codes,
>>
>> Which was always my interpretation.
> 
> 
> I agree that this is the most likely current interpretation.  I think 
> that this interpretation is wrong, because...:
> 
>>> necessitates that, in the case of a mail store that does not have 
>>> sticky UIDs (that is, UIDVALIDITY changes at each SELECT), the server 
>>> issue false (but plausible-seeming) information in an 
>>> APPENDUID/COPYUID response code.
>>
>> Or the server can omit the response code entirely and any correctly 
>> written IMAP client should handle that properly.
> 
> 
> I agree that this is desirable and should be the goal, but that is not 
> what RFC 2359 implies by tying UIDPLUS to the response codes.
> 
>>> I can not believe that the intent of RFC 2359 is that a server send a 
>>> complete fabrication in the case of a server which supports multiple 
>>> mail stores, only some of which have sticky UIDs.
>>
>> Omitting the response code seems better than returning fake information.
> 
> 
> I agree, which is why I want to update RFC 2359 so that:
> 
> (1) The UIDPLUS capability only covers the UID EXPUNGE command.
> 
> (2) ALL servers SHOULD issue APPENDUID/COPYUID responses, regardless of
>     whether or not they offer UIDPLUS.
> 
> (3) If a server can not issue a correct APPENDUID/COPYUID response because
>     of server implementation or mail store limitation, then it MUST NOT
>     issue a APPENDUID/COPYUID with fake information.  Instead, it would
>     just omit APPENDUID/COPYUID in the response.

Humming...

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

Date: Wed, 18 May 2005 13:16:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>>Well, RFC 2234 section 3.3 allows for "=/". So this suggest 
>>that the parser doesn't recognize all constructs in RFC 2234.
>>    
>>
>
>It recognizes the construct all right.  The I-D isn't using it correctly.
>You MUST have an initial rule identified before you can use the "=/"
>construct, like this:
>
>ruleset = alt1 / alt2
>ruleset =/ alt3
>ruleset =/ alt4 / alt5
>
>You haven't specified the initial rule.  The parser is thus absolutely
>correct.
>  
>
Ok, I see your point now.

>If the idea is that the initial rule MUST be imported from 3501 to make this
>syntactically valid ABNF then you should make that perfectly clear, perhaps
>by adding an ABNF comment before the new alternative rules.
>  
>
Yes, will do.

Date: Tue, 17 May 2005 16:27:57 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 17 May 2005, Alexey Melnikov wrote:
>> Frankly I would rather see servers properly support APPENDUID and COPYUID.
> Me too. Should a next revision of IMAP even happen, I would prefer that 
> UIDPLUS (UID EXPUNGE and the response codes) be included in the base spec.

Please note that there are mail stores in which it is impossible to 
accomplish correct APPENDUID/COPYUID.  This means that either the server 
must generate fake information, or the option must persist for the server 
to omit APPENDUID/COPYUID.

>> So an alternative would be to introduce a new argument to APPEND and COPY 
>> that would be the clients explicit request to get APPENDUID and COPYUID 
>> back, and it would be made clear that the client should only use that 
>> argument when it really wants that data, and would otherwise fallback to 
>> some other way (likely more costly) to identify the copies/appended 
>> messages.
> This addition might be fine, but it will need a new capability string, or 
> existing clients which expect automatic COPYUID/APPENDUID will not work with 
> such servers. You also need to convince client implementors to update their 
> code.

I agree that this would have been desirable, and it was a terrible mistake 
not to have done it in RFC 2359.  I tried to prevent the mistake, but lost 
that battle.

I agree that it is too late to undo that mistake now.

However, we should undo the other mistakes, which essentially have the 
effect of creating a requirement that servers which allow UID EXPUNGE (and 
also APPENDUID/COPYUID with some mail stores) generate fake 
APPENDUID/COPYUID data for mail stores which can not support it.

-- Mark --

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

Date: Tue, 17 May 2005 16:23:35 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 17 May 2005, Alexey Melnikov wrote:
>> It is also ambiguous as to whether a server which does not support UID 
>> EXPUNGE may send APPENDUID/COPYUID response codes.
> I frankly can't see why implementing UID EXPUNGE might be difficult, but I 
> don't see a reason why not.

Agreed on both points.

>> The alternate interpretation, that UIDPLUS covers the response codes,
> Which was always my interpretation.

I agree that this is the most likely current interpretation.  I think that 
this interpretation is wrong, because...:

>> necessitates that, in the case of a mail store that does not have sticky 
>> UIDs (that is, UIDVALIDITY changes at each SELECT), the server issue false 
>> (but plausible-seeming) information in an APPENDUID/COPYUID response code.
> Or the server can omit the response code entirely and any correctly written 
> IMAP client should handle that properly.

I agree that this is desirable and should be the goal, but that is not 
what RFC 2359 implies by tying UIDPLUS to the response codes.

>> I can not believe that the intent of RFC 2359 is that a server send a 
>> complete fabrication in the case of a server which supports multiple mail 
>> stores, only some of which have sticky UIDs.
> Omitting the response code seems better than returning fake information.

I agree, which is why I want to update RFC 2359 so that:

(1) The UIDPLUS capability only covers the UID EXPUNGE command.

(2) ALL servers SHOULD issue APPENDUID/COPYUID responses, regardless of
     whether or not they offer UIDPLUS.

(3) If a server can not issue a correct APPENDUID/COPYUID response because
     of server implementation or mail store limitation, then it MUST NOT
     issue a APPENDUID/COPYUID with fake information.  Instead, it would
     just omit APPENDUID/COPYUID in the response.

I believe that RFC 2359 is correctly interpreted as saying:

(a) The UIDPLUS capability covers both the UID EXPUNGE command and the
     APPENDUID/COPYUID responses.

(b) Servers which do not advertise UIDPLUS MUST NOT issue
     APPENDUID/COPYUID responses, and servers which advertise UIDPLUS MUST
     issue APPENDUID/COPYUID responses.

(b) If a server which advertises UIDPLUS can not issue a correct
     APPENDUID/COPYUID response because of a mail store limitation beyond
     control of the server implementation, then it MUST issue a
     APPENDUID/COPYUID with fake information.

I consider (a) - (c) to be undesirable.  Consequently, I believe that RFC 
2359 should be revised to be updated as per (1) - (3) above.

Is there a hum of concensus on this issue?  Or, alternatively, a snarl of 
rejection?

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 18:11:34 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 4:11 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> On Tue, 17 May 2005, Scott Hollenbeck wrote:
> > I'd prefer to see an ABNF comment like this if you want to do 
> > something like
> > that:
> > ;;capability     = <defined in [IMAP]>
> > This makes it clear that a parser shouldn't try to parse the 
> > incomplete rule.
> 
> If this is done, will you then be content with the =/ definitions?

Yes.  I now understand the intent and believe that a little bit of explicit
clarification is all that's needed to help others avoid the mistake I made
in trying to parse the ABNF by itself.

-Scott-

Date: Tue, 17 May 2005 13:11:28 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 17 May 2005, Scott Hollenbeck wrote:
> I'd prefer to see an ABNF comment like this if you want to do something like
> that:
> ;;capability     = <defined in [IMAP]>
> This makes it clear that a parser shouldn't try to parse the incomplete
> rule.

If this is done, will you then be content with the =/ definitions?

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 15:39:56 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 3:28 PM
> To: Scott Hollenbeck
> Cc: 'Cyrus Daboo'; [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> Would it work to have the rule as a meta-variable, e.g.
> 
> capability     = <defined in [IMAP]>

I'd prefer to see an ABNF comment like this if you want to do something like
that:

;;capability     = <defined in [IMAP]>

This makes it clear that a parser shouldn't try to parse the incomplete
rule.

-Scott-

Date: Tue, 17 May 2005 12:28:07 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: "'Cyrus Daboo'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

Would it work to have the rule as a meta-variable, e.g.

capability     = <defined in [IMAP]>

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>
Cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 15:24:20 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Cyrus Daboo [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 2:56 PM
> To: Scott Hollenbeck; 'Alexey Melnikov'
> Cc: 'Lisa Dusseault'; [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> Hi Scott,
> 
> --On Tuesday, May 17, 2005 14:39 -0400 Scott Hollenbeck 
> <[email-masked]> wrote:
> 
> > If the idea is that the initial rule MUST be imported from 
> 3501 to make
> > this syntactically valid ABNF then you should make that 
> perfectly clear,
> > perhaps by adding an ABNF comment before the new alternative rules.
> 
> The first paragraph of the Formal Syntax section already states that:
> 
> 
> >    Formal syntax is defined using ABNF [ABNF] as modified 
> by [IMAP4].
> >    Non-terminals referenced but not defined below are as defined by
> >    [IMAP4].

Experience tells me that this will not be enough to warn someone.  If the
defs cause a parser to spit out a syntax error (and they do) I think a
little more text to explain why would be helpful.

> If this is no longer sufficient then it will require changes 
> to pretty much 
> all the IMAP extension documents as they all use something 
> similar. If 
> that's going to be the case then it might be worth defining a 
> new document 
> construct that lists the 'imported' formal syntax elements in 
> a manner that 
> can be parsed by ABNF checker tools.

That would be nice, but that's an ABNF weakness that we can't solve at the
moment.  I think the doc thus needs to make the needed fix more obvious.

Terminals are easy: a parser says "not defined", you say "oh, let me look in
3501", it's there, done.  The problem with this rule situation is that the
ABNF itself is structurally incomplete and parsers don't know how to import
rules to fix the problem.  Text in a comment to let people know that they
need to copy rules from 3501 to make the ABNF spec syntactically complete
would help.

On the other hand, one could also add a little more to the [IMAP4] reference
sentence. It might help to explicitly note that the ABNF is NOT intended to
stand on its own and that it MUST only be considered in union with the rules
and terminals from 3501 to be complete.

I'm poking at this because the RFC Editor is now using automated tools to
check ABNF, XML Schemas, etc.  They'll see the same syntax error I did if
they try to parse the ABNF in isolation.  It'll thus help eliminate a
possible bump later on if we can be a little more clear now.

-Scott-

Date: Tue, 17 May 2005 14:55:43 -0400
From: Cyrus Daboo <[email-masked]>
To: Scott Hollenbeck <[email-masked]>, "'Alexey Melnikov'" <[email-masked]>
cc: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Hi Scott,

--On Tuesday, May 17, 2005 14:39 -0400 Scott Hollenbeck 
<[email-masked]> wrote:

> If the idea is that the initial rule MUST be imported from 3501 to make
> this syntactically valid ABNF then you should make that perfectly clear,
> perhaps by adding an ABNF comment before the new alternative rules.

The first paragraph of the Formal Syntax section already states that:

>    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>    Non-terminals referenced but not defined below are as defined by
>    [IMAP4].

If this is no longer sufficient then it will require changes to pretty much 
all the IMAP extension documents as they all use something similar. If 
that's going to be the case then it might be worth defining a new document 
construct that lists the 'imported' formal syntax elements in a manner that 
can be parsed by ABNF checker tools.

-- 
Cyrus Daboo

From: "Scott Hollenbeck" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 14:39:22 -0400
Importance: Normal
Sender: [email-masked]

> Well, RFC 2234 section 3.3 allows for "=/". So this suggest 
> that the parser doesn't recognize all constructs in RFC 2234.

It recognizes the construct all right.  The I-D isn't using it correctly.
You MUST have an initial rule identified before you can use the "=/"
construct, like this:

ruleset = alt1 / alt2
ruleset =/ alt3
ruleset =/ alt4 / alt5

You haven't specified the initial rule.  The parser is thus absolutely
correct.

If the idea is that the initial rule MUST be imported from 3501 to make this
syntactically valid ABNF then you should make that perfectly clear, perhaps
by adding an ABNF comment before the new alternative rules.

-Scott-

Date: Tue, 17 May 2005 19:27:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>>Section 6.2 describes under what conditions servers 
>>supporting the ACL 
>>extension should return READ-WRITE or READ-ONLY response 
>>codes defined 
>>in RFC 3501. I thought that this meant that the draft updated 
>>3501, but 
>>I wasn't quite sure. Please advise.
>>    
>>
>I believe it updates 3501, especially as things relate to the ABNF.  More on
>that below.
>  
>
Ok.

>>> <>- Please remove what looks like a reference to RFC 3501 
>>> ("IMAP4rev1") from
>>
>>>the abstract, or maybe just identify the acronym as "IMAP".
>>>      
>>>
>>Is the following Ok?:
>>   The ACL (Access Control List) extension (RFC 2086) of the Internet
>>   Message Access Protocol (IMAP) permits ...
>>    
>>
>
>This looks better.
>
>[snip]
>  
>
>>> <>- Section 3, 7th paragraph: "A client may determine". Again, is 
>>> this "may"
>>
>>>supposed to be in lower case letters?
>>>      
>>>
>>The sentence is:
>>   A client may determine the set of rights granted to the logged-in 
>>user for a given mailbox name by using the MYRIGHTS
>>   command.
>>
>>The MYRIGHTS command is the only way to determine rights of the 
>>logged-in user, there is no implementation choice here.
>>So I don't think this "may" should be capitalized.
>>    
>>
>
>I think you'd be better off using a word other than "may", such as "can".
>People get confused when mixing upper and lower case forms of the 2119
>directives.  Even the IESG argues about it.  I think you'd be better off
>using the upper case form where appropriate, and synonyms like "can" to
>replace the lower case forms where no directive is intended.
>  
>
I've changed this to "can". Thanks.

>[snip]
>  
>
>>>Section 8: two minor ABNF errors:
>>>
>>>capability   =/ rights-capa
>>>command-auth =/ setacl / deleteacl / getacl / listrights / myrights
>>>
>>>should be:
>>>
>>>capability   = rights-capa
>>>command-auth = setacl / deleteacl / getacl / listrights / myrights
>>>      
>>>
>>The "capability" and "command-auth" productions are defined 
>>in RFC 3501, 
>>this document is extending them, so I think "=/" is more appropriate.
>>    
>>
>
>Here's the problem with that: the ABNF as currently written won't parse
>because you appear to have introduced a syntax error.  Try running it
>through here to see what I mean:
>
>http://irg.attlabs.net/~fenner/abnf.cgi
>
>("Bill" is Bill Fenner, one of the other IESG members.)
>  
>
Well, RFC 2234 section 3.3 allows for "=/". So this suggest that the parser doesn't recognize all constructs in RFC 2234.

>If the idea is to extend a definition from 3501, you can copy the ABNF
>terminals that are being extended from 3501 and add the new values here.
>That way we have syntactically complete ABNF that passes automated
>validation AND it makes the answer to the "does this update 3501?"
>
Most of the IMAP extensions extend ABNF in RFC 3501, but none of the 
published RFCs list them as "updating" RFC 3501. That is why I've hesitated.

> question
>very obvious.  Don't worry about the SP terminal et al. -- there's already
>text in the document to explain that missing terminals can be found in 3501,
>and I confirmed that they're truly there.
>  
>

Date: Tue, 17 May 2005 11:24:12 -0700
From: Rob Siemborski <[email-masked]>
Reply-To: Rob Siemborski <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Cc: Alexey Melnikov <[email-masked]>, Lisa Dusseault <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/17/05, Scott Hollenbeck <[email-masked]> wrote:
> If the idea is to extend a definition from 3501, you can copy the ABNF
> terminals that are being extended from 3501 and add the new values here.
> That way we have syntactically complete ABNF that passes automated
> validation AND it makes the answer to the "does this update 3501?" question
> very obvious.  Don't worry about the SP terminal et al. -- there's already
> text in the document to explain that missing terminals can be found in 3501,
> and I confirmed that they're truly there.

But what if another specification updates these terminals - which
happens all the time with CAPABILITY.  Then you have to depend on all
the documents that preceed the one you're trying to implement.  This
seems far less extensible than just referring to the definition in
RFC3501.

-Rob

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

From: "Scott Hollenbeck" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 14:16:16 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 2:03 PM
> To: Scott Hollenbeck
> Cc: 'Lisa Dusseault'; [email-masked]
> Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> Scott Hollenbeck wrote:
> 
> >Lisa Dusseault has asked me to bring 
> draft-ietf-imapext-2086upd to the IESG
> >for review.  Before I can do that, I have to review the 
> document myself and
> >I need to request an IETF last call.  Here are my review comments and
> >questions:
> >
> >- What does "Updates: <<3501?>>" mean in the first page 
> headers?  Does this
> >document update RFC 3501 or not?
> >  
> >
> Section 6.2 describes under what conditions servers 
> supporting the ACL 
> extension should return READ-WRITE or READ-ONLY response 
> codes defined 
> in RFC 3501. I thought that this meant that the draft updated 
> 3501, but 
> I wasn't quite sure. Please advise.

I believe it updates 3501, especially as things relate to the ABNF.  More on
that below.

> >- Please remove what looks like a reference to RFC 3501 
> ("IMAP4rev1") from
> >the abstract, or maybe just identify the acronym as "IMAP".
> >  
> >
> Is the following Ok?:
>    The ACL (Access Control List) extension (RFC 2086) of the Internet
>    Message Access Protocol (IMAP) permits ...

This looks better.

[snip]

> >- Section 3, 7th paragraph: "A client may determine".  
> Again, is this "may"
> >supposed to be in lower case letters?
> >
> The sentence is:
>    A client may determine the set of rights granted to the logged-in 
> user for a given mailbox name by using the MYRIGHTS
>    command.
> 
> The MYRIGHTS command is the only way to determine rights of the 
> logged-in user, there is no implementation choice here.
> So I don't think this "may" should be capitalized.

I think you'd be better off using a word other than "may", such as "can".
People get confused when mixing upper and lower case forms of the 2119
directives.  Even the IESG argues about it.  I think you'd be better off
using the upper case form where appropriate, and synonyms like "can" to
replace the lower case forms where no directive is intended.

[snip]

> >Section 8: two minor ABNF errors:
> >
> >capability   =/ rights-capa
> >command-auth =/ setacl / deleteacl / getacl / listrights / myrights
> >
> >should be:
> >
> >capability   = rights-capa
> >command-auth = setacl / deleteacl / getacl / listrights / myrights
> >  
> >
> The "capability" and "command-auth" productions are defined 
> in RFC 3501, 
> this document is extending them, so I think "=/" is more appropriate.

Here's the problem with that: the ABNF as currently written won't parse
because you appear to have introduced a syntax error.  Try running it
through here to see what I mean:

http://irg.attlabs.net/~fenner/abnf.cgi

("Bill" is Bill Fenner, one of the other IESG members.)

If the idea is to extend a definition from 3501, you can copy the ABNF
terminals that are being extended from 3501 and add the new values here.
That way we have syntactically complete ABNF that passes automated
validation AND it makes the answer to the "does this update 3501?" question
very obvious.  Don't worry about the SP terminal et al. -- there's already
text in the document to explain that missing terminals can be found in 3501,
and I confirmed that they're truly there.

-Scott-

Date: Tue, 17 May 2005 19:02:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>Lisa Dusseault has asked me to bring draft-ietf-imapext-2086upd to the IESG
>for review.  Before I can do that, I have to review the document myself and
>I need to request an IETF last call.  Here are my review comments and
>questions:
>
>- What does "Updates: <<3501?>>" mean in the first page headers?  Does this
>document update RFC 3501 or not?
>  
>
Section 6.2 describes under what conditions servers supporting the ACL 
extension should return READ-WRITE or READ-ONLY response codes defined 
in RFC 3501. I thought that this meant that the draft updated 3501, but 
I wasn't quite sure. Please advise.

>- Please remove what looks like a reference to RFC 3501 ("IMAP4rev1") from
>the abstract, or maybe just identify the acronym as "IMAP".
>  
>
Is the following Ok?:
   The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP) permits ...

Or do you suggest to change this to:

   The ACL (Access Control List) extension (RFC 2086) of the IMAP
   permits ...

?

>- Editorial nit, Abstract and Section 2: s/the RFC 2086/RFC 2086/
>  
>
Fixed.

>- A Table of Contents is needed.  Other formatting errors found using the ID
>nits tool [1] should also be corrected.
>
>- Section 3, 6th paragraph, 1st sentence: "An implementation MAY tie rights
>together or may".  Is this second "may" supposed to be in lower case
>letters?
>  
>
I don't think so, fixed.

>- Section 3, 7th paragraph: "A client may determine".  Again, is this "may"
>supposed to be in lower case letters?
>
The sentence is:
   A client may determine the set of rights granted to the logged-in 
user for a given mailbox name by using the MYRIGHTS
   command.

The MYRIGHTS command is the only way to determine rights of the 
logged-in user, there is no implementation choice here.
So I don't think this "may" should be capitalized.

>  I won't call out any more, but let's
>consider this an open question for any other 2119 keywords that appear in
>both upper and lower case letters.  Consistency is a good thing.
>
>Section 4, first paragraph: s/that have an identifier/that has an
>identifier/
>  
>
Fixed, thanks.

>Section 8: two minor ABNF errors:
>
>capability   =/ rights-capa
>command-auth =/ setacl / deleteacl / getacl / listrights / myrights
>
>should be:
>
>capability   = rights-capa
>command-auth = setacl / deleteacl / getacl / listrights / myrights
>  
>
The "capability" and "command-auth" productions are defined in RFC 3501, 
this document is extending them, so I think "=/" is more appropriate.

>(change "=/" to "=")
>
>Let's talk about these.  An update is likely required before I can bring
>this to last call because I don't want to last call a document with known
>ABNF syntax errors or spec ambiguities.
>
>-Scott-
>
>[1]
>http://ietf.levkowetz.com/tools/idnits/idnits.pyht
>  
>

Date: Tue, 17 May 2005 10:53:19 -0700
From: Rob Siemborski <[email-masked]>
Reply-To: Rob Siemborski <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Cc: Lisa Dusseault <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/17/05, Scott Hollenbeck <[email-masked]> wrote:
> capability   =/ rights-capa
> command-auth =/ setacl / deleteacl / getacl / listrights / myrights
> 
> should be:
> 
> capability   = rights-capa
> command-auth = setacl / deleteacl / getacl / listrights / myrights
> 
> (change "=/" to "=")
> 
> Let's talk about these.  An update is likely required before I can bring
> this to last call because I don't want to last call a document with known
> ABNF syntax errors or spec ambiguities.

Isn't this ABNF correct, since it is extending terminals defined in
RFC3501?  Perhaps that needs to be clarified.

-Rob

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

From: "Scott Hollenbeck" <[email-masked]>
To: "'Lisa Dusseault'" <[email-masked]>
Cc: [email-masked]
Subject: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 13:32:53 -0400
Importance: Normal
Sender: [email-masked]

Lisa Dusseault has asked me to bring draft-ietf-imapext-2086upd to the IESG
for review.  Before I can do that, I have to review the document myself and
I need to request an IETF last call.  Here are my review comments and
questions:

- What does "Updates: <<3501?>>" mean in the first page headers?  Does this
document update RFC 3501 or not?

- Please remove what looks like a reference to RFC 3501 ("IMAP4rev1") from
the abstract, or maybe just identify the acronym as "IMAP".

- Editorial nit, Abstract and Section 2: s/the RFC 2086/RFC 2086/

- A Table of Contents is needed.  Other formatting errors found using the ID
nits tool [1] should also be corrected.

- Section 3, 6th paragraph, 1st sentence: "An implementation MAY tie rights
together or may".  Is this second "may" supposed to be in lower case
letters?

- Section 3, 7th paragraph: "A client may determine".  Again, is this "may"
supposed to be in lower case letters?  I won't call out any more, but let's
consider this an open question for any other 2119 keywords that appear in
both upper and lower case letters.  Consistency is a good thing.

Section 4, first paragraph: s/that have an identifier/that has an
identifier/

Section 8: two minor ABNF errors:

capability   =/ rights-capa
command-auth =/ setacl / deleteacl / getacl / listrights / myrights

should be:

capability   = rights-capa
command-auth = setacl / deleteacl / getacl / listrights / myrights

(change "=/" to "=")

Let's talk about these.  An update is likely required before I can bring
this to last call because I don't want to last call a document with known
ABNF syntax errors or spec ambiguities.

-Scott-

[1]
http://ietf.levkowetz.com/tools/idnits/idnits.pyht

Date: Tue, 17 May 2005 17:43:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Mark,
>
> --On May 16, 2005 1:44:06 PM -0700 Mark Crispin 
> <[email-masked]> wrote:
>
>> The silence has been deafening in response to my comments about the
>> UIDPLUS specification.  Should I assume that this means that I should
>> undertake updating RFC 2359 to resolve the ambiguities that I mentioned?
>
> I checked my implementation and it does not rely on COPYUID and 
> APPENDUID even when the UIDPLUS capability is present. Of course it 
> only uses UID EXPUNGE when UIDPLUS is present. So the changes you 
> propose would not be a problem for me - obviously I can't say whether 
> others that use COPYUID/APPENDUID are in the same boat.

Mozilla/Thunderbird use COPYUID/APPENDUID. Probably others as well.

>> Also, what do people think about recommending a standard header for
>> clients to write into the header for non-UIDPLUS servers or mail stores?
>> It looks like SUN has X-SGMT-Synchronization-Tag.
>
> That's only relevant for APPENDs of course and not COPY.
>
> Frankly I would rather see servers properly support APPENDUID and COPYUID.

Me too. Should a next revision of IMAP even happen, I would prefer that 
UIDPLUS (UID EXPUNGE and the response codes) be included in the base spec.

> I realise that the main argument against it is that it is time 
> consuming to determine it, and having to do it for every COPY or 
> APPEND command is a waste, especially if the client is not using that 
> info anyway.

For some servers like Cyrus and Isode Mbox the APPENDUID/COPYUID 
information is always available, so they might as well return it all the 
time.

> So an alternative would be to introduce a new argument to APPEND and 
> COPY that would be the clients explicit request to get APPENDUID and 
> COPYUID back, and it would be made clear that the client should only 
> use that argument when it really wants that data, and would otherwise 
> fallback to some other way (likely more costly) to identify the 
> copies/appended messages.

This addition might be fine, but it will need a new capability string, 
or existing clients which expect automatic COPYUID/APPENDUID will not 
work with such servers. You also need to convince client implementors to 
update their code.

Alexey

Date: Tue, 17 May 2005 15:35:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> RFC 2359 needs to clarify that the UIDPLUS extension indicates that 
> the UID EXPUNGE extension is present, and does not necessarily 
> indicate the APPENDUID and COPYUID response codes.
>
> As presently constituted, RFC 2359 is ambiguous as to whether 
> APPENDUID and COPYUID are mandatory responses for a UIDPLUS server.

> It is also ambiguous as to whether a server which does not support UID 
> EXPUNGE may send APPENDUID/COPYUID response codes.

I frankly can't see why implementing UID EXPUNGE might be difficult, but 
I don't see a reason why not.

> I recommend that RFC 2359 be updated as follows:
>
> . clarify that the UIDPLUS extension refers to the UID EXPUNGE command.
>
> . recommend that servers SHOULD issue APPENDUID/COPYUID response codes.
>
>
> The alternate interpretation, that UIDPLUS covers the response codes,

Which was always my interpretation.

> necessitates that, in the case of a mail store that does not have 
> sticky UIDs (that is, UIDVALIDITY changes at each SELECT), the server 
> issue false (but plausible-seeming) information in an 
> APPENDUID/COPYUID response code.

Or the server can omit the response code entirely and any correctly 
written IMAP client should handle that properly.

> I can not believe that the intent of RFC 2359 is that a server send a 
> complete fabrication in the case of a server which supports multiple 
> mail stores, only some of which have sticky UIDs.

Omitting the response code seems better than returning fake information.

Date: Mon, 16 May 2005 14:27:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 16 May 2005, Cyrus Daboo wrote:
>> Also, what do people think about recommending a standard header for
>> clients to write into the header for non-UIDPLUS servers or mail stores?
>> It looks like SUN has X-SGMT-Synchronization-Tag.
> That's only relevant for APPENDs of course and not COPY.

True; although we *could* create a standard header that works with both 
APPEND and COPY, and is not vulnerable to possible UID instability. 
Personally, I think that a standard header to search is technically 
superior to UIDPLUS.

> Frankly I would rather see servers properly support APPENDUID and COPYUID. I 
> realise that the main argument against it is that it is time consuming to 
> determine it, and having to do it for every COPY or APPEND command is a 
> waste, especially if the client is not using that info anyway.

That's one reason.  There's another: the mail store may not support it. 
If the mail store does not support sticky UIDs (that is, UIDVALIDITY is 
different each time), there's nothing the server can do.

> So an alternative would be to introduce a new argument to APPEND and 
> COPY that would be the clients explicit request to get APPENDUID and 
> COPYUID back, and it would be made clear that the client should only use 
> that argument when it really wants that data, and would otherwise 
> fallback to some other way (likely more costly) to identify the 
> copies/appended messages.

I asked for this years ago when UIDPLUS was first proposed.  UIDPLUS (and 
the pre-LISTEXT CHILDREN extension) stand out as being wrongly designed to 
require work on the server even when the client does not request it.

-- Mark --

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

Date: Mon, 16 May 2005 17:19:40 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Sender: [email-masked]

Hi Mark,

--On May 16, 2005 1:44:06 PM -0700 Mark Crispin <[email-masked]> 
wrote:

> The silence has been deafening in response to my comments about the
> UIDPLUS specification.  Should I assume that this means that I should
> undertake updating RFC 2359 to resolve the ambiguities that I mentioned?

I checked my implementation and it does not rely on COPYUID and APPENDUID 
even when the UIDPLUS capability is present. Of course it only uses UID 
EXPUNGE when UIDPLUS is present. So the changes you propose would not be a 
problem for me - obviously I can't say whether others that use 
COPYUID/APPENDUID are in the same boat.

> Also, what do people think about recommending a standard header for
> clients to write into the header for non-UIDPLUS servers or mail stores?
> It looks like SUN has X-SGMT-Synchronization-Tag.

That's only relevant for APPENDs of course and not COPY.

Frankly I would rather see servers properly support APPENDUID and COPYUID. 
I realise that the main argument against it is that it is time consuming to 
determine it, and having to do it for every COPY or APPEND command is a 
waste, especially if the client is not using that info anyway.

So an alternative would be to introduce a new argument to APPEND and COPY 
that would be the clients explicit request to get APPENDUID and COPYUID 
back, and it would be made clear that the client should only use that 
argument when it really wants that data, and would otherwise fallback to 
some other way (likely more costly) to identify the copies/appended 
messages.

-- 
Cyrus Daboo

Date: Mon, 16 May 2005 13:44:06 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: UIDPLUS comments?
Organization: Networks & Distributed Computing
Sender: [email-masked]

The silence has been deafening in response to my comments about the 
UIDPLUS specification.  Should I assume that this means that I should 
undertake updating RFC 2359 to resolve the ambiguities that I mentioned?

Also, what do people think about recommending a standard header for 
clients to write into the header for non-UIDPLUS servers or mail stores? 
It looks like SUN has X-SGMT-Synchronization-Tag.

-- Mark --

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-13.txt
Date: Mon, 16 May 2005 15:40:39 -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, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-13.txt
	Pages		: 38
	Date		: 2005-5-16
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists 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-13.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-13.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-13.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-13.txt

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

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

--OtherAccess--

--NextPart--

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WG Last Call of LISTEXT draft 13
Date: Mon, 16 May 2005 11:23:50 -0700
Sender: [email-masked]

I call your attention to this draft:

http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
-13.txt

That link doesn't yet work but Barry did post the 13 draft to the list  
today: http://www.imc.org/ietf-imapext/mail-archive/msg02601.html

This document is the framework for much of the syntax we're doing in  
other IMAPEXT tasks and is being referenced by other documents already,  
so it's important that it gets a good review.  I'll be expecting  
several people to review the complete draft or to review changes from a  
version they've reviewed before.  If you review it at all, or plan to  
implement, or have any opinion about standardizing this document, send  
mail to the WG list or at least to me.

Last call will go until EOD, May 31.

Lisa

Date: Mon, 16 May 2005 13:23:38 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
cc: Lisa Dusseault <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-13
Sender: [email-masked]

--==========92EB6F57300CB3B266C8==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Alexey pointed out that the capability "LISTEXT" is currently used by
several inconsistent programs.  The I-D editor also complained that I
was following the obsolete RFC 3667 IP statement instead of the new RFC
3978 one (who can keep track of all these changes, even with xml2rfc to
help?), so they wouldn't publish it as it was anyway.  I've sent the
attached update, which specifies "LIST-EXTENDED" as the capability
string.

Barry

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

--==========92EB6F57300CB3B266C8==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-imapext-list-extensions-13.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-13.txt"; size=67058

IMAP Extensions Working Group                                   B. =
Leiba
Internet-Draft                           IBM T.J. Watson Research =
Center
Updates: 2193 (if approved)                                  A. =
Melnikov
Obsoletes: 3348 (if approved)                              Isode =
Limited
Expires: November 17, 2005                                  May 16, =
2005

                     IMAP4 LIST Command Extensions
                 draft-ietf-imapext-list-extensions-13

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists 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

Leiba & Melnikov        Expires November 17, 2005               [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   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.

Note

   A revised version of this draft document will be submitted to the =
RFC
   editor as an Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked].

   This document obsoletes RFC 3348 and updates RFC 2193.

Table of Contents

   1.  Conventions used in this document  . . . . . . . . . . . . . .  =
3

   2.  Introduction and overview  . . . . . . . . . . . . . . . . . .  =
4

   3.  Extended LIST Command  . . . . . . . . . . . . . . . . . . . .  =
6
   3.1 General principles for returning LIST responses  . . . . . . . =
10
   3.2 Additional requirements on LIST-EXTENDED clients . . . . . . . =
11
   3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . =
11

   4.  The CHILDREN return Option . . . . . . . . . . . . . . . . . . =
14

   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . =
16

   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . =
26

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . =
29

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . =
30
   8.1 Guidelines for IANA  . . . . . . . . . . . . . . . . . . . . . =
30
   8.2 Registration procedure and Change control  . . . . . . . . . . =
30
   8.3 Registration template for LIST-EXTENDED options  . . . . . . . =
31
   8.4 Initial LIST-EXTENDED option registrations . . . . . . . . . . =
32
   8.5 Registration template for LIST-EXTENDED extended data item . . =
34
   8.6 Initial LIST-EXTENDED extended data item registrations . . . . =
35

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
36

   10. Normative References . . . . . . . . . . . . . . . . . . . . . =
36

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
36

       Intellectual Property and Copyright Statements . . . . . . . . =
38

Leiba & Melnikov        Expires November 17, 2005               [Page =
2]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

1.  Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Kwds].

   The term "canonical LIST pattern" refers to the canonical pattern
   constructed internally by the server from the reference and mailbox
   name arguments (Section 6.3.8 of [IMAP4]).  The [IMAP4] LIST command
   returns only mailboxes that match the canonical LIST pattern.

   Other terms are introduced where they are referenced for the first
   time.

Leiba & Melnikov        Expires November 17, 2005               [Page =
3]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

2.  Introduction and overview

   The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:

   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");

   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");

   3.  if the LIST command has more than 2 parameters ("LIST return
       options");

   Otherwise the original syntax is used.

   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB =
commands
   described in [MBRef].  We are also defining the mechanism to request
   extended mailbox information, such as is described in the "Child
   Mailbox Extension" [CMbox].  The base LSUB command is not deprecated
   by this extension; rather, this extension adds a way to obtain
   subscription information with more options, with those server
   implementations that support it.  Clients that simply need a list of
   subscribed mailboxes, as provided by the LSUB command, SHOULD
   continue to use that command.

   This document defines an IMAP4 extension that is identified by the
   capability string "LIST-EXTENDED".  The LIST-EXTENDED extension =
makes
   the following changes to the IMAP4 protocol, which are described in
   more detail in Section 3 and Section 4:

   a.  defines new syntax for LIST command options.

   b.  extends LIST to allow for multiple mailbox patterns.

   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and
       RECURSIVEMATCH.

   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.

   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".

Leiba & Melnikov        Expires November 17, 2005               [Page =
4]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   f.  adds CHILDINFO extended data item.

Leiba & Melnikov        Expires November 17, 2005               [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

3.  Extended LIST Command

   This extension updates the syntax of the LIST command to allow for
   multiple mailbox patterns to be specified, if they are enclosed in
   parantheses.  A mailbox name match a list of mailbox patterns if it
   matches at least one mailbox pattern.  Note that if a mailbox name
   matches multiple mailbox patterns from the list, the server should
   return only a single LIST response.

   Note that the non-extended LIST command is required to treat an =
empty
   ("" string) mailbox name argument as a special request to return the
   hierarchy delimiter and the root name of the name given in the
   reference parameter (as per [IMAP4]).  However ANY extended LIST
   command (extended in any of 3 ways specified in Section 2, or any
   combination of therof) MUST NOT treat the empty mailbox name as such
   special request and any regular processing described in this =
document
   applies.  In particular, if an extended LIST command has multiple
   mailbox names and one (or more) of them is the empty string, the
   empty string MUST be ignored for the purpose of matching.

   Some servers might restrict which patterns are allowed in a LIST
   command.  If a server doesn't accept a particular pattern, it MUST
   silently ignore it.

   The LIST command syntax is also extended in two additional ways: by
   adding a parenthesized list of command options between the command
   name and the reference name (LIST selection options) and an optional
   list of options at the end that control what kind of information
   should be returned (LIST return options).  See the formal syntax in
   Section 6 for specific details.

   A LIST selection option tells the server which mailbox names should
   be selected by the LIST operation.  The server should return
   information about all mailbox names that match any of the "canonical
   LIST pattern" (as described above) and satisfy additional selection
   criteria (if any) specified by the LIST selection options.  Let's
   call any such mailbox name a "matched mailbox name".  When multiple
   selection options are specified, the server MUST return information
   about mailbox names that satisfy every selection option, unless a
   description of a particular specified option prescribes special
   rules.  An example of an option prescribing special rules is the
   RECURSIVEMATCH selection option described later in this section.  We
   will use the term "selection criteria" when referring collectively =
to
   all selection options specified in a LIST command.

   A LIST return option controls which information is returned for each
   matched mailbox name.  Note that return options MUST NOT cause the
   server to report information about additional mailbox names.  If the

Leiba & Melnikov        Expires November 17, 2005               [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   client has not specified any return option, only information about
   attributes should be returned by the server.  (Of course the server
   is allowed to include any other information at will.)

   Both selection and return command options will be defined in this
   document and in approved extension documents; each option will be
   enabled by a capability string (one capability may enable multiple
   options), and a client MUST NOT send an option for which the server
   has not advertised support.  A server MUST respond to options it =
does
   not recognize with a BAD response.  The client SHOULD NOT specify =
any
   option more than once, however if the client does this, the server
   MUST act as if it received the option only once.  The order in which
   options are specified by the client is not significant.

   In general, each selection option except for RECURSIVEMATCH will =
have
   a corresponding return option.  The REMOTE selection option is an
   anomaly in this regard, and does not have a corresponding return
   option.  That is because it expands, rather than restricts, the set
   of mailboxes that are returned.  Future extensions to this
   specification should keep parallelism in mind, and define a pair of
   corresponding options.

   This extension is identified by the capability string "LIST-
   EXTENDED", and support for it is a prerequisite for any future
   extensions that require specialized forms of the LIST command.  Such
   extensions MUST refer to this document and MUST add their function
   through command options as described herein.  Note that extensions
   that don't require support for an extended LIST command, but use
   extended LIST responses (see below), don't need to advertise the
   "LIST-EXTENDED" capability string.

   This extension also defines extensions to the LIST response, =
allowing
   a series of extended fields at the end, a parenthesized list of
   tagged data (also referred to as "extended data item").  The first
   element of an extended field is a tag, which identifies type of the
   data.  Tags MUST be registered with IANA, as described in Section =
8.5
   of this document.  An example of such extended set might be

      ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample
      "text"))

   or...

      ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more
      text"))

Leiba & Melnikov        Expires November 17, 2005               [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   See the formal grammar, below, for the full syntactic details.  The
   server MUST NOT return any extended data item, unless the client has
   expressed its ability to support extended LIST responses, for =
example
   by using an extended LIST command.  The server MAY return data in =
the
   extended fields that was not solicited by the client.  The client
   MUST ignore all extended fields it doesn't recognize.

   The LIST-EXTENDED capability also defines several new mailbox
   attributes.

   The "\NonExistent" attribute indicates that a mailbox does not
   actually exist.  Note that this attribute is not meaningful by
   itself, as mailboxes that match the canonical LIST pattern but don't
   exist must not be returned unless one of the two conditions listed
   below is also satisfied:

   a.  the mailbox also satisfies the selection criteria (for example,
       its name is subscribed and the "SUBSCRIBED" selection option has
       been specified)

   b.  "RECURSIVEMATCH" has been specified, and the mailbox has at =
least
       one child mailbox that matches the LIST pattern and selection
       criteria.

   In practice this means that the "\NonExistent" attribute is usually
   returned with one or more of "\Subscribed", "\Remote" or the
   CHILDINFO extended data item (see their description below).

   The "\NonExistent" attribute implies "\NoSelect".  The =
"\NonExistent"
   attribute MUST be supported and MUST be accurately computed.

   The selection options defined in this specification are

   SUBSCRIBED - causes the LIST command to list subscribed names, =
rather
      than the existing mailboxes.  This will often be a subset of the
      actual mailboxes.  It's also possible for this list to contain =
the
      names of mailboxes that don't exist.  In any case, the list MUST
      include exactly those mailbox names that match the canonical list
      pattern and are subscribed to.  This option is intended to
      supplement the LSUB command.  Of particular note are the mailbox
      attributes as returned by this option, compared with what is
      returned by LSUB.  With the latter, the attributes returned may
      not reflect the actual attribute status on the mailbox name, and
      the \NoSelect attribute has a special meaning (it indicates that
      this mailbox is not, itself, subscribed, but that it has child
      mailboxes that are).  With the SUBSCRIBED selection option
      described here, the attributes are accurate, complete, and have =
no

Leiba & Melnikov        Expires November 17, 2005               [Page =
8]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

      special meanings.  "LSUB" and "LIST (SUBSCRIBED)" are, thus, not
      the same thing, and some servers must do significant extra work =
to
      respond to "LIST (SUBSCRIBED)".  Because of this, clients SHOULD
      continue to use "LSUB" unless they specifically want the
      additional information offered by "LIST (SUBSCRIBED)".

      This option defines a new mailbox attribute, "\Subscribed", that
      indicates that a mailbox name is subscribed to.  The =
"\Subscribed"
      attribute MUST be supported and MUST be accurately computed when
      the SUBSCRIBED selection option is specified.

      Note that the SUBSCRIBED selection option implies the SUBSCRIBED
      return option (see below).

   REMOTE - causes the LIST command to show remote mailboxes as well as
      local ones, as described in [MBRef].  This option is intended to
      replace the RLIST command and, in conjunction with the SUBSCRIBED
      selection option, the RLSUB command.

      This option defines a new mailbox attribute, "\Remote", that
      indicates that a mailbox is a remote mailbox.  The "\Remote"
      attribute MUST be accurately computed when the REMOTE option is
      specified.

      Note that a server implementation that doesn't support any remote
      mailboxes is compliant with this specification as long as it
      accepts and ignores the REMOTE selection option.  Note that if =
the
      server choses to ignore the REMOTE selection option, it still has
      to treat RECURSIVEMATCH REMOTE as a valid combination of =
selection
      options (see also the description of the RECURSIVEMATCH option
      below).

   RECURSIVEMATCH - this option forces the server to return information
      about parent mailboxes that don't match other selection options,
      but have some submailboxes that do.  Information about children =
is
      returned in the CHILDINFO extended data item, as described in
      Section 3.3.

      Note 1: In order for a parent mailbox to be returned, it still =
has
      to match the canonical LIST pattern.

      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.

      The RECURSIVEMATCH option MUST NOT occur as the only selection

Leiba & Melnikov        Expires November 17, 2005               [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

      option, as it only makes sense when other selection options are
      also used.  The server MUST return BAD tagged response in such
      case.

      Note that even if RECURSIVEMATCH option is specified, the client
      MUST still be able to handle a case when a CHILDINFO extended =
data
      item is returned and there are no submailboxes that meet the
      selection criteria of the given LIST command, as they can be
      deleted/renamed after the LIST response was sent, but before the
      client had a chance to access them.

   The return options defined in this specification are

   SUBSCRIBED - causes the LIST command to return subscription state =
for
      all matching mailbox names.  The "\Subscribed" attribute MUST be
      supported and MUST be accurately computed when the SUBSCRIBED
      return option is specified.  Further, all mailbox flags MUST be
      accurately computed (this differs from the behaviour of the LSUB
      command).

   CHILDREN - Requests mailbox child information as originally proposed
      in [CMbox].  See Section 4, below, for details.  This option MUST
      be supported by all servers.

3.1  General principles for returning LIST responses

   This section outlines several principles that can be used by server
   implementations of this document to decide if a LIST response should
   be returned, as well as how many responses and what kind of
   information they may contain.

   1.  Exactly one LIST response should be returned for each mailbox
       name which matches the canonical LIST pattern.  Server
       implementors must not assume that clients will be able to
       assemble mailbox attributes and other information returned in
       multiple LIST responses.

   2.  There are only two reasons for including a matching mailbox name
       in the responses to the LIST command (Note that the server is
       allowed to return unsolicited responses at any time.  Such
       responses are not governed by this rule):

       A.  the mailbox name also satisfies the selection criteria;

Leiba & Melnikov        Expires November 17, 2005              [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       B.  the mailbox name doesn't satisfy the selection criteria, but
           it has at least one child mailbox name that satisfies the
           selection criteria and that doesn't match the canonical LIST
           pattern.
           For more information on this case see the CHILDINFO extended
           data item described in Section 3.3.  Note that the CHILDINFO
           extended data item can only be returned when the
           RECURSIVEMATCH selection option is specified.

   3.  Attributes returned in the same LIST response must be treated
       additively.  For example the following response

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

       means that the "Fruit/Peach" mailbox doesn't exist, but it is
       subscribed.

3.2  Additional requirements on LIST-EXTENDED clients

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred
   from it.  For example, the client must treat presence of the
   \NoInferiors attribute as if the \HasNoChildren attribute was also
   sent by the server.

   The following table summarizes inference rules described in
   Section 3.

               +--------------------+-------------------+
               | returned attribute | implied attribute |
               +--------------------+-------------------+
               |    \NoInferiors    |   \HasNoChildren  |
               |                    |                   |
               |    \NonExistent    |     \NoSelect     |
               +--------------------+-------------------+

3.3  CHILDINFO extended data item

   The CHILDINFO extended data item MUST only be returned when the
   client has specified the RECURSIVEMATCH selection option.

   The CHILDINFO extended data item in a LIST response describes the
   selection criteria that has caused it to be returned and indicates

Leiba & Melnikov        Expires November 17, 2005              [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   that the mailbox has st least one child mailbox that matches the
   selection criteria.

   The LSUB command indicates this condition by using the "\NoSelect"
   attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   CHILDINFO extended data item is more general, in that it can be used
   with any extended set of selection criteria.

   The returned selection criteria allow the client to distinguish a
   solicited response from an unsolicited one, as well as to =
distinguish
   among solicited responses caused by multiple pipelined LIST commands
   that specify different criteria.

   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.

   Examples 8 and 10 in Section 5 demonstrate the difference between
   present CHILDINFO extended data item and the "\HasChildren"
   attribute.

   The following table summarizes interaction between the =
"\NonExistent"
   attribute and CHILDINFO (the first collumn describes if the parent
   mailbox exists):

   =
+----------------+----------------+----------------+----------------+
   |     exists     |    meets the   |   has a child  |    returned    =
|
   |                |    selection   | that meets the |  LIST-EXTENDED =
|
   |                |    criteria    |    selection   | attributes and =
|
   |                |                |    criteria    |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+
   |       no       |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       yes      |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       no       |       yes      |       no       |  (\NonExistent =
|
   |                |                |                |     <attr>)    =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       no       |    (<attr>)    =
|
   |                |                |                |                =
|
   |       no       |       no       |       yes      | (\NonExistent) =
|
   |                |                |                |   + CHILDINFO  =
|
   |                |                |                |                =
|

Leiba & Melnikov        Expires November 17, 2005              [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   |       yes      |       no       |       yes      | () + CHILDINFO =
|
   |                |                |                |                =
|
   |       no       |       yes      |       yes      |  (\NonExistent =
|
   |                |                |                |    <attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       yes      |   (<attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+

   where <attr> is one or more attributes that correspond to the
   selection criteria, for example for the SUBSCRIBED option the <attr>
   is \Subscribed.

Leiba & Melnikov        Expires November 17, 2005              [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

4.  The CHILDREN return Option

   The CHILDREN return option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [CMbox].  The CHILDREN
   return option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified.

   Many IMAP4 [IMAP4] clients present to the user a hierarchical view =
of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline =
hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.  When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.
   The CHILDREN return option provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST "" * or a LIST "" % for each mailbox name.  The
   CHILDREN return option defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren.
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN return option is provided to indicate that the
   client particularly wants this information.  If the CHILDREN return
   option is present, the server MUST return these attributes even if
   their computation is expensive.

   \HasChildren

        The presence of this attribute indicates that the mailbox has
        child mailboxes.  A server SHOULD NOT set this attribute if
        there are child mailboxes, and the user does not have
        permissions to access any of them.  In this case, =
\HasNoChildren
        SHOULD be used.  In many cases, however, a server may not be
        able to efficiently compute whether a user has access to all
        child mailboxes.  As such a client MUST be prepared to accept
        the \HasChildren attribute as a hint.  That is, a mailbox MAY =
be
        flagged with the \HasChildren attribute, but no child mailboxes
        will appear in the LIST response.

   \HasNoChildren

Leiba & Melnikov        Expires November 17, 2005              [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

        The presence of this attribute indicates that the mailbox has =
NO
        child mailboxes that are accessible to the currently
        authenticated user.

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

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.

Leiba & Melnikov        Expires November 17, 2005              [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

5.  Examples

   1:  The first example shows the complete local hierarchy that will =
be
       used for the other examples.

          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: * LIST () "/" "Vegetable/Corn"

          S: A01 OK done

   2:  In the next example, we'll see the subscribed mailboxes.  This =
is
       similar to, but not equivalent with, <LSUB "" "*">.  Note that
       the mailbox called "Fruit/Peach" is subscribed to, but does not
       actually exist (perhaps it was deleted while still subscribed).
       The "Fruit" mailbox is not subscribed to, but it has two
       subscribed children.  The "Vegetable" mailbox is subscribed and
       has two children, one of them is subscribed as well.

          C: A02 LIST (SUBSCRIBED) "" "*"

          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"

          S: * LIST (\Subscribed) "/" "Fruit/Banana"

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"

Leiba & Melnikov        Expires November 17, 2005              [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: A02 OK done

   3:  The next example shows the use of the CHILDREN option.  The
       client, without having to list the second level of hierarchy, =
now
       knows which of the top-level mailboxes have submailboxes
       (children) and which do not.  Note that it's not necessary for
       the server to return the \HasNoChildren attribute for the inbox,
       because the \NoInferiors attribute already implies that, and has
       a stronger meaning.

          C: A03 LIST () "" "%" RETURN (CHILDREN)

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST (\HasChildren) "/" "Fruit"

          S: * LIST (\HasNoChildren) "/" "Tofu"

          S: * LIST (\HasChildren) "/" "Vegetable"

          S: A03 OK done

   4:  In this example we see more mailboxes, which reside on another
       server to which we may obtain referrals.  This is similar to the
       command <RLIST "" "%">.  Note that in the case of the remote
       mailboxes, the server might or might not be able to include
       CHILDREN information; it includes it if it can, and omits it if
       it can't.

          C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST (\HasChildren) "/" "Fruit"

          S: * LIST (\HasNoChildren) "/" "Tofu"

          S: * LIST (\HasChildren) "/" "Vegetable"

          S: * LIST (\Remote) "/" "Bread"

Leiba & Melnikov        Expires November 17, 2005              [Page =
17]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\HasChildren \Remote) "/" "Meat"

          S: A04 OK done

   5:  The following example also requests the server to include
       mailboxes, which reside on another server.  The server returns
       information about all mailboxes which are subscribed.  This is
       similar to the command <RLSUB "" "%">.  We also see the use of
       two selection options.

          C: A05 LIST (REMOTE SUBSCRIBED) "" "*"

          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"

          S: * LIST (\Subscribed) "/" "Fruit/Banana"

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

          S: * LIST (\Subscribed) "/" "Vegetable"

          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"

          S: * LIST (\Remote \Subscribed) "/" "Bread"

          S: A05 OK done

   6:  The following example requests the server to include mailboxes,
       which reside on another server.  The server is requested to
       return subscription information for all returned mailboxes.  =
This
       is different from the example above.

       Note that the output of this command is not a superset of the
       output in the previous example, as it doesn't include LIST
       response for the non-existent "Fruit/Peach".

          C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)

          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"

          S: * LIST () "/" "Fruit"

Leiba & Melnikov        Expires November 17, 2005              [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST () "/" "Fruit/Apple"

          S: * LIST (\Subscribed) "/" "Fruit/Banana"

          S: * LIST () "/" "Tofu"

          S: * LIST (\Subscribed) "/" "Vegetable"

          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"

          S: * LIST () "/" "Vegetable/Corn"

          S: * LIST (\Remote \Subscribed) "/" "Bread"

          S: * LIST (\Remote) "/" "Meat"

          S: A06 OK done

   7:  In the following example the client has specified multiple
       mailbox patterns.  Note that this example doesn't use the =
mailbox
       hierarchy used in the previous examples.

          C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")

          S: * LIST () "/" "INBOX"

          S: * LIST (\NoInferiors) "/" "Drafts"

          S: * LIST () "/" "Sent/March2004"

          S: * LIST (\Marked) "/" "Sent/December2003"

          S: * LIST () "/" "Sent/August2004"

          S: BBB OK done

   8:  The following example demonstates the difference between
       \HasChildren attribute and CHILDINFO extended data item.

       Let's assume there is the following hierarchy:

Leiba & Melnikov        Expires November 17, 2005              [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          C: C01 LIST "" "*"

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST () "/" "Foo"

          S: * LIST () "/" "Foo/Bar"

          S: * LIST () "/" "Foo/Baz"

          S: * LIST () "/" "Moo"

          S: C01 OK done

       If the client asks RETURN (CHILDREN) it will get this:

          C: CA3 LIST "" "%" RETURN (CHILDREN)

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST (\HasChildren) "/" "Foo"

          S: * LIST (\HasNoChildren) "/" "Moo"

          S: CA3 OK done

       A) Let's also assume that the mailbox "Foo/Baz" is the only
       subscribed mailbox.  Then we get this result:

          C: C02 LIST (SUBSCRIBED) "" "*"

          S: * LIST (\Subscribed) "/" "Foo/Baz"

          S: C02 OK done

       Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
       will return no mailboxes (as the mailboxes "Moo", "Foo" and
       "Inbox" are NOT subscribed).  However, if the client issues =
this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"

Leiba & Melnikov        Expires November 17, 2005              [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))

          S: C04 OK done

       i.e. the mailbox "Foo" is not subscribed, but it has a child =
that
       is.

       A1) If the mailbox "Foo" had been subscribed instead, the last
       command would return this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"

          S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))

          S: C04 OK done

       or even this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"

          S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))

          S: C04 OK done

       A2) If we assume instead that the mailbox "Foo" is not part of
       the original hierarchy and is not subscribed, the last command
       will give this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"

          S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))

          S: C04 OK done

       B) Now, let's assume that no mailbox is subscribed.  In this =
case
       the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will =
return
       no responses, as there are no subscribed children (even though
       "Foo" has children).

Leiba & Melnikov        Expires November 17, 2005              [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       C) And finally, suppose that only the mailboxes "Foo" and "Moo"
       are subscribed.  In that case we see this result:

          C: LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)

          S: * LIST (\HasChildren \Subscribed) "/" "Foo"

          S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"

       (which means that the mailbox "Foo" has children, but none of
       them is subscribed).

   9:  The following example demonstrates that the CHILDINFO extended
       data item is returned whether children mailboxes match the
       canonical LIST pattern or not.

       Let's assume there is the following hierarchy:

          C: D01 LIST "" "*"

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST () "/" "foo2"

          S: * LIST () "/" "foo2/bar1"

          S: * LIST () "/" "foo2/bar2"

          S: * LIST () "/" "baz2"

          S: * LIST () "/" "baz2/bar2"

          S: * LIST () "/" "baz2/bar22"

          S: * LIST () "/" "baz2/bar222"

          S: * LIST () "/" "eps2"

          S: * LIST () "/" "eps2/mamba"

          S: * LIST () "/" "quux2/bar2"

Leiba & Melnikov        Expires November 17, 2005              [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: D01 OK done

       And that the following mailboxes are subscribed:

          C: D02 LIST (SUBSCRIBED) "" "*"

          S: * LIST (\Subscribed) "/" "foo2/bar1"

          S: * LIST (\Subscribed) "/" "foo2/bar2"

          S: * LIST (\Subscribed) "/" "baz2/bar2"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2"

          S: * LIST (\Subscribed) "/" "eps2/mamba"

          S: * LIST (\Subscribed) "/" "quux2/bar2"

          S: D02 OK done

       The client issues the following command first:

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"

          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "foo2/bar2"

          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "baz2/bar2"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))

Leiba & Melnikov        Expires November 17, 2005              [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\Subscribed) "/" "quux2/bar2"

          S: D03 OK done

       and the server may also include

          S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO"
          ("SUBSCRIBED")))

       The CHILDINFO extended data item is returned for mailboxes
       "foo2", "baz2" and "eps2", because all of them have subscribed
       children, even though for the mailbox "foo2" only one of the two
       subscribed children match the pattern, for the mailbox "baz2" =
all
       the subscribed children match the pattern and for the mailbox
       "eps2" none of the subscribed children match the pattern.

       Note that if the client issues

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"

          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "foo2/bar1"

          S: * LIST (\Subscribed) "/" "foo2/bar2"

          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "baz2/bar2"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "eps2/mamba"

          S: * LIST (\Subscribed) "/" "quux2/bar2"

          S: D03 OK done

Leiba & Melnikov        Expires November 17, 2005              [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
       have the CHILDINFO extended data item, even though this
       information is redundant and the client can determine it by
       itself.

   10: The following example shows usage of multiple mailbox patterns.
       It also demonstrates that the presence of the CHILDINFO extended
       data item doesn't necessarily imply \HasChildren.

          C: a1 LIST "" ("foo" "foo/*")

          S: * LIST () "/" foo

          S: a1 OK done

          C: a2 LIST (SUBSCRIBED) "" "foo/*"

          S: * LIST (\Subscribed \NonExistent) "/" foo/bar

          S: a2 OK done

          C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN
          (CHILDREN)

          S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
          ("SUBSCRIBED")))

          S: a3 OK done

Leiba & Melnikov        Expires November 17, 2005              [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

6.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].

   "vendor-token" is defined in [ACAP].  Note that this normative
   reference to ACAP is an issue in moving this spec forward, since =
ACAP
   will never move to Draft Standard.  The definitions of =
"vendor-token"
   and of the IANA registry must eventually go somewhere else, in a
   document that can be moved forward on the standards track.

   childinfo-extended-item =3D "CHILDINFO" SP "(" list-select-base-opt-
               quoted
               *( SP list-select-base-opt-quoted ) ")"
               ; Extended data item returned when the RECURSIVEMATCH
               ; selection option is specified.
               ; Note 1: the CHILDINFO tag can be returned
               ;  with and without surrounding quotes, as per
               ;  mbox-list-extended-item-tag production.
               ; Note 2: The selection options are returned quoted,
               ;  unlike their specification in the extended LIST
               ;  command.

   child-mbox-flag =3D "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

   eitem-standard-tag =3D atom
               ; a tag for extended list data defined in a Standard
               ; Track or Experimental RFC.

   eitem-vendor-tag =3D vendor-tag
               ; a vendor specific tag for extended list data

   list =3D      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
               [SP list-return-opts]

   list-select-opts =3D "(" [*(list-select-mod-opt SP) =
list-select-base-
               opt
               *(SP list-select-opt)] ")"
               ; list selection options, e.g.  REMOTE

Leiba & Melnikov        Expires November 17, 2005              [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   list-select-opt =3D list-select-mod-opt / list-select-base-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

   list-select-base-opt =3D "SUBSCRIBED" / "REMOTE" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted =3D <"> list-select-base-opt <">

   list-select-mod-opt =3D "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-return-opts =3D "RETURN" SP "(" [return-option *(SP return-
               option)] ")"
               ; list return options, e.g.  CHILDREN

   mailbox-list =3D "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]

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

   mbox-list-extended-item =3D "(" mbox-list-extended-item-data ")"

   mbox-list-extended-item-data =3D mbox-list-extended-item-tag SP
               nstring-list

   mbox-list-extended-item-tag =3D astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; or "eitem-standard-tag" ABNF productions.
               ; A tag registration template is described in this
               document
               ; in Section 8.5.

Leiba & Melnikov        Expires November 17, 2005              [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   mbox-list-oflag =3D child-mbox-flag / "\NonExistent" /
               / "\Subscribed" / "\Remote"

   mbox-or-pat =3D list-mailbox / patterns

   nstring-list =3D nstring /
               "(" [nstring-list *(SP nstring-list)] ")"
               ; a recursive list definition

   option-extension =3D option-vendor-tag / option-standard-tag

   option-vendor-tag =3D vendor-tag
               ; a vendor specific option

   option-standard-tag =3D atom
               ; an option defined in a Standard Track or
               ; Experimental RFC

   patterns =3D  "(" list-mailbox *(SP list-mailbox) ")"

   return-option =3D "SUBSCRIBED" / "CHILDREN" /
               option-extension

   vendor-tag =3D vendor-token "-" atom

Leiba & Melnikov        Expires November 17, 2005              [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

7.  Security Considerations

   This document describes syntactic changes to the specification of =
the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  =
They
   are described in [IMAP4] and [MBRef].

   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all =
child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access =
to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.  In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.

   The CHILDINFO extended data item has the same security =
considerations
   as the \HasChildren attribute described above.

Leiba & Melnikov        Expires November 17, 2005              [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

8.  IANA Considerations

8.1  Guidelines for IANA

   It is requested that IANA creates two new registries for LIST-
   EXTENDED options and LIST-EXTENDED response data.  The templates and
   the initial registrations are detailed below.

8.2  Registration procedure and Change control

   Registration of a LIST-EXTENDED option is done by filling in the
   template in Section 8.3 and sending it via electronic mail to
   [email-masked].  Registration of a LIST-EXTENDED extended data item =
is
   done by filling in the template in Section 8.5 and sending it via
   electronic mail to [email-masked].  IANA has the right to reject
   obviously bogus registrations, but will perform no review of claims
   made in the registration form.

   A LIST-EXTENDED option/extended data item name that starts with "V-"
   is reserved for vendor specific options/extended data items.  All
   options, whether they are vendor specific or global, should be
   registered with IANA.  If a LIST-EXTENDED extended data item is
   returned as a result of requesting a particular LIST-EXTENDED =
option,
   the name of the option SHOULD be used as the name of the LIST-
   EXTENDED extended data item.

   Each vendor specific options/extended data item MUST start with =
their
   vendor-token ("vendor prefix").  The vendor-token MUST be registered
   with IANA, using the [ACAP] vendor subtree registry.

   Standard LIST-EXTENDED option/extended data item names are case
   insensitive.  If the vendor prefix is omitted from a vendor specific
   LIST-EXTENDED option/extended data item name, the rest is case
   insensitive.  The vendor prefix itself is not case-sensitive, as it
   might contain non-ASCII characters.

   While the registration procedures do not require it, authors of =
LIST-
   EXTENDED options/extended data items are encouraged to seek =
community
   review and comment whenever that is feasible.  Authors may seek
   community review by posting a specification of their proposed
   mechanism as an Internet- Draft.  LIST-EXTENDED options/extended =
data
   items intended for widespread use should be standardized through the
   normal IETF process, when appropriate.

   Comments on registered LIST-EXTENDED options/extended response data
   should first be sent to the "owner" of the mechanism and/or to the
   IMAPEXT WG mailing list.  Submitters of comments may, after a
   reasonable attempt to contact the owner, request IANA to attach =
their

Leiba & Melnikov        Expires November 17, 2005              [Page =
30]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   comment to the registration itself.  If IANA approves of this, the
   comment will be made accessible in conjunction with the registration
   LIST-EXTENDED options/ extended response data itself.

   Once a LIST-EXTENDED registration has been published by IANA, the
   author may request a change to its definition.  The change request
   follows the same procedure as the registration request.

   The owner of a LIST-EXTENDED registration may pass responsibility =
for
   the registered option/extended data item to another person or agency
   by informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a LIST-EXTENDED option/
   extended data item.  The most common case of this will be to enable
   changes to be made to mechanisms where the author of the =
registration
   has died, moved out of contact or is otherwise unable to make =
changes
   that are important to the community.

   LIST-EXTENDED registrations may not be deleted; mechanisms which are
   no longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such LIST-EXTENDED options/
   extended data items will be clearly marked in the lists published by
   IANA.

   The IESG is considered to be the owner of all LIST-EXTENDED options/
   extended data items which are on the IETF standards track.

8.3  Registration template for LIST-EXTENDED options

   To: [email-masked]
   Subject: Registration of LIST-EXTENDED option X

   LIST-EXTENDED option name:

   LIST-EXTENDED option type: (One of SELECTION or RETURN)

   Implied return options(s), if the option type is SELECTION: (zero or
   more)

   LIST-EXTENDED option description:

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

Leiba & Melnikov        Expires November 17, 2005              [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Person and email address to contact for further information:

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.4  Initial LIST-EXTENDED option registrations

   It is requested that the LIST-EXTENDED option registry be populated
   with the following entries:

   1.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option SUBSCRIBED

       LIST-EXTENDED option name: SUBSCRIBED

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): SUBSCRIBED

       LIST-EXTENDED option description: Causes the LIST command to =
list
       subscribed mailboxes, rather than the actual mailboxes.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   2.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option REMOTE

       LIST-EXTENDED option name: REMOTE

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): (none)

       LIST-EXTENDED option description: causes the LIST command to
       return remote mailboxes as well as local ones, as described in

Leiba & Melnikov        Expires November 17, 2005              [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       RFC 2193.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   3.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option SUBSCRIBED

       LIST-EXTENDED option name: SUBSCRIBED

       LIST-EXTENDED option type: RETURN

       LIST-EXTENDED option description: Causes the LIST command to
       return subscription state.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   4.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH

       LIST-EXTENDED option name: RECURSIVEMATCH

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): (none)

       LIST-EXTENDED option description: Requests that CHILDINFO

Leiba & Melnikov        Expires November 17, 2005              [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       extended data item is to be returned.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   5.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option CHILDREN

       LIST-EXTENDED option name: CHILDREN

       LIST-EXTENDED option type: RETURN

       LIST-EXTENDED option description: Requests mailbox child
       information.

       Published specification : XXXX, Section 3 and Section 4.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

8.5  Registration template for LIST-EXTENDED extended data item

   To: [email-masked]
   Subject: Registration of X LIST-EXTENDED extended data item

   LIST-EXTENDED extended data item tag:

   LIST-EXTENDED extended data item description:

   Which LIST-EXTENDED option(s) (and their types) causes this extended
   data item to be returned (if any):

Leiba & Melnikov        Expires November 17, 2005              [Page =
34]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.6  Initial LIST-EXTENDED extended data item registrations

   It is requested that the LIST-EXTENDED extended data item registry =
be
   populated with the following entries:

   1.  To: [email-masked]
       Subject: Registration of CHILDINFO LIST-EXTENDED extended data
       item

       LIST-EXTENDED extended data item tag: CHILDINFO

       LIST-EXTENDED extended data item description: The CHILDINFO
       extended data item describes the selection criteria that has
       caused it to be returned and indicates that the mailbox has one
       or more child mailbox that match the selection criteria.

       Which LIST-EXTENDED option(s) (and their types) causes this
       extended data item to be returned (if any): RECURSIVEMATCH
       selection option

       Published specification : XXXX, Section 3.3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

Leiba & Melnikov        Expires November 17, 2005              [Page =
35]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

9.  Acknowledgements

   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in Section 4, is theirs.

   This document is the result of discussions on the IMAP4 and IMAPEXT
   mailing lists and is meant to reflect consensus of those groups.  In
   particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo
   Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt
   Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were
   active participants in those discussions or made suggestions to this
   document.

10.  Normative References

   [ABNF]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 2234, November 1997.

   [ACAP]   Newman, C. and J. Myers, "ACAP -- Application Configuration
            Access Protocol", RFC 2244, November 1997.

   [CMbox]  Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.

   [IMAP4]  Crispin, M., "Internet Message Access Protocol - Version
            4rev1", RFC 3501, March 2003.

   [Kwds]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", RFC 2119, March 1997.

   [MBRef]  Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
            September 1997.

Authors' Addresses

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532
   US

   Phone: +1 914 784 7941
   Email: [email-masked]

Leiba & Melnikov        Expires November 17, 2005              [Page =
36]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: [email-masked]
   URI:   http://www.melnikov.ca/

Leiba & Melnikov        Expires November 17, 2005              [Page =
37]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Leiba & Melnikov        Expires November 17, 2005              [Page =
38]
=0C

--==========92EB6F57300CB3B266C8==========--

Date: Mon, 16 May 2005 10:57:55 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
cc: Lisa Dusseault <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-13, ready for last call
Sender: [email-masked]

--==========3BDCC6310244676E312C==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I've just submitted the attached draft to the ID editor, and it's ready
for last call.  The only change between this and the -12 version is the
removal of the "comment on these things" notes, since there were no
comments asking for any changes.  I also removed a couple of
draft-specific things, so, for instance, the capability is now
"LISTEXT" instead of the draft placekeeper string.

I'm still not happy with all the aspects of example 9, but since no one
else had anything to say about it, it stays as is.

Lisa:  Go wild with it....

Barry

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

--==========3BDCC6310244676E312C==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-imapext-list-extensions-13.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-13.txt"; size=65554

IMAP Extensions Working Group                                   B. =
Leiba
Internet-Draft                           IBM T.J. Watson Research =
Center
Updates: 2193 (if approved)                                  A. =
Melnikov
Obsoletes: 3348 (if approved)                              Isode =
Limited
Expires: November 17, 2005                                  May 16, =
2005

                     IMAP4 LIST Command Extensions
                 draft-ietf-imapext-list-extensions-13

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists 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

Leiba & Melnikov        Expires November 17, 2005               [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   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.

Note

   A revised version of this draft document will be submitted to the =
RFC
   editor as an Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked].

   This document obsoletes RFC 3348 and updates RFC 2193.

Leiba & Melnikov        Expires November 17, 2005               [Page =
2]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

Table of Contents

   1.  Conventions used in this document  . . . . . . . . . . . . . .  =
4

   2.  Introduction and overview  . . . . . . . . . . . . . . . . . .  =
5

   3.  Extended LIST Command  . . . . . . . . . . . . . . . . . . . .  =
6
   3.1 General principles for returning LIST responses  . . . . . . . =
10
   3.2 Additional requirements on LISTEXT clients . . . . . . . . . . =
11
   3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . =
11

   4.  The CHILDREN return Option . . . . . . . . . . . . . . . . . . =
13

   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . =
15

   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . =
22

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . =
25

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . =
26
   8.1 Guidelines for IANA  . . . . . . . . . . . . . . . . . . . . . =
26
   8.2 Registration procedure and Change control  . . . . . . . . . . =
26
   8.3 Registration template for LISTEXT options  . . . . . . . . . . =
27
   8.4 Initial LISTEXT option registrations . . . . . . . . . . . . . =
28
   8.5 Registration template for LISTEXT extended data item . . . . . =
30
   8.6 Initial LISTEXT extended data item registrations . . . . . . . =
31

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
32

   10. Normative References . . . . . . . . . . . . . . . . . . . . . =
32

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
32

       Intellectual Property and Copyright Statements . . . . . . . . =
34

Leiba & Melnikov        Expires November 17, 2005               [Page =
3]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

1.  Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Kwds].

   The term "canonical LIST pattern" refers to the canonical pattern
   constructed internally by the server from the reference and mailbox
   name arguments (Section 6.3.8 of [IMAP4]).  The [IMAP4] LIST command
   returns only mailboxes that match the canonical LIST pattern.

   Other terms are introduced where they are referenced for the first
   time.

Leiba & Melnikov        Expires November 17, 2005               [Page =
4]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

2.  Introduction and overview

   The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:
   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");
   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");
   3.  if the LIST command has more than 2 parameters ("LIST return
       options");

   Otherwise the original syntax is used.

   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB =
commands
   described in [MBRef].  We are also defining the mechanism to request
   extended mailbox information, such as is described in the "Child
   Mailbox Extension" [CMbox].  The base LSUB command is not deprecated
   by this extension; rather, this extension adds a way to obtain
   subscription information with more options, with those server
   implementations that support it.  Clients that simply need a list of
   subscribed mailboxes, as provided by the LSUB command, SHOULD
   continue to use that command.

   This document defines an IMAP4 extension that is identified by the
   capability string "LISTEXT".  The LISTEXT extension makes the
   following changes to the IMAP4 protocol, which are described in more
   detail in Section 3 and Section 4:

   a.  defines new syntax for LIST command options.
   b.  extends LIST to allow for multiple mailbox patterns.
   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and
       RECURSIVEMATCH.
   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.
   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".
   f.  adds CHILDINFO extended data item.

Leiba & Melnikov        Expires November 17, 2005               [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

3.  Extended LIST Command

   This extension updates the syntax of the LIST command to allow for
   multiple mailbox patterns to be specified, if they are enclosed in
   parantheses.  A mailbox name match a list of mailbox patterns if it
   matches at least one mailbox pattern.  Note that if a mailbox name
   matches multiple mailbox patterns from the list, the server should
   return only a single LIST response.

   Note that the non-extended LIST command is required to treat an =
empty
   ("" string) mailbox name argument as a special request to return the
   hierarchy delimiter and the root name of the name given in the
   reference parameter (as per [IMAP4]).  However ANY extended LIST
   command (extended in any of 3 ways specified in Section 2, or any
   combination of therof) MUST NOT treat the empty mailbox name as such
   special request and any regular processing described in this =
document
   applies.  In particular, if an extended LIST command has multiple
   mailbox names and one (or more) of them is the empty string, the
   empty string MUST be ignored for the purpose of matching.

   Some servers might restrict which patterns are allowed in a LIST
   command.  If a server doesn't accept a particular pattern, it MUST
   silently ignore it.

   The LIST command syntax is also extended in two additional ways: by
   adding a parenthesized list of command options between the command
   name and the reference name (LIST selection options) and an optional
   list of options at the end that control what kind of information
   should be returned (LIST return options).  See the formal syntax in
   Section 6 for specific details.

   A LIST selection option tells the server which mailbox names should
   be selected by the LIST operation.  The server should return
   information about all mailbox names that match any of the "canonical
   LIST pattern" (as described above) and satisfy additional selection
   criteria (if any) specified by the LIST selection options.  Let's
   call any such mailbox name a "matched mailbox name".  When multiple
   selection options are specified, the server MUST return information
   about mailbox names that satisfy every selection option, unless a
   description of a particular specified option prescribes special
   rules.  An example of an option prescribing special rules is the
   RECURSIVEMATCH selection option described later in this section.  We
   will use the term "selection criteria" when referring collectively =
to
   all selection options specified in a LIST command.

   A LIST return option controls which information is returned for each
   matched mailbox name.  Note that return options MUST NOT cause the
   server to report information about additional mailbox names.  If the

Leiba & Melnikov        Expires November 17, 2005               [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   client has not specified any return option, only information about
   attributes should be returned by the server.  (Of course the server
   is allowed to include any other information at will.)

   Both selection and return command options will be defined in this
   document and in approved extension documents; each option will be
   enabled by a capability string (one capability may enable multiple
   options), and a client MUST NOT send an option for which the server
   has not advertised support.  A server MUST respond to options it =
does
   not recognize with a BAD response.  The client SHOULD NOT specify =
any
   option more than once, however if the client does this, the server
   MUST act as if it received the option only once.  The order in which
   options are specified by the client is not significant.

   In general, each selection option except for RECURSIVEMATCH will =
have
   a corresponding return option.  The REMOTE selection option is an
   anomaly in this regard, and does not have a corresponding return
   option.  That is because it expands, rather than restricts, the set
   of mailboxes that are returned.  Future extensions to this
   specification should keep parallelism in mind, and define a pair of
   corresponding options.

   This extension is identified by the capability string "LISTEXT", and
   support for it is a prerequisite for any future extensions that
   require specialized forms of the LIST command.  Such extensions MUST
   refer to this document and MUST add their function through command
   options as described herein.  Note that extensions that don't =
require
   support for an extended LIST command, but use extended LIST =
responses
   (see below), don't need to advertise the "LISTEXT" capability =
string.

   This extension also defines extensions to the LIST response, =
allowing
   a series of extended fields at the end, a parenthesized list of
   tagged data (also referred to as "extended data item").  The first
   element of an extended field is a tag, which identifies type of the
   data.  Tags MUST be registered with IANA, as described in Section =
8.5
   of this document.  An example of such extended set might be

      ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample
      "text"))

   or...

      ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more
      text"))

   See the formal grammar, below, for the full syntactic details.  The
   server MUST NOT return any extended data item, unless the client has
   expressed its ability to support extended LIST responses, for =
example

Leiba & Melnikov        Expires November 17, 2005               [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   by using an extended LIST command.  The server MAY return data in =
the
   extended fields that was not solicited by the client.  The client
   MUST ignore all extended fields it doesn't recognize.

   The LISTEXT capability also defines several new mailbox attributes.

   The "\NonExistent" attribute indicates that a mailbox does not
   actually exist.  Note that this attribute is not meaningful by
   itself, as mailboxes that match the canonical LIST pattern but don't
   exist must not be returned unless one of the two conditions listed
   below is also satisfied:

   a.  the mailbox also satisfies the selection criteria (for example,
       its name is subscribed and the "SUBSCRIBED" selection option has
       been specified)

   b.  "RECURSIVEMATCH" has been specified, and the mailbox has at =
least
       one child mailbox that matches the LIST pattern and selection
       criteria.

   In practice this means that the "\NonExistent" attribute is usually
   returned with one or more of "\Subscribed", "\Remote" or the
   CHILDINFO extended data item (see their description below).

   The "\NonExistent" attribute implies "\NoSelect".  The =
"\NonExistent"
   attribute MUST be supported and MUST be accurately computed.

   The selection options defined in this specification are

   SUBSCRIBED - causes the LIST command to list subscribed names, =
rather
      than the existing mailboxes.  This will often be a subset of the
      actual mailboxes.  It's also possible for this list to contain =
the
      names of mailboxes that don't exist.  In any case, the list MUST
      include exactly those mailbox names that match the canonical list
      pattern and are subscribed to.  This option is intended to
      supplement the LSUB command.  Of particular note are the mailbox
      attributes as returned by this option, compared with what is
      returned by LSUB.  With the latter, the attributes returned may
      not reflect the actual attribute status on the mailbox name, and
      the \NoSelect attribute has a special meaning (it indicates that
      this mailbox is not, itself, subscribed, but that it has child
      mailboxes that are).  With the SUBSCRIBED selection option
      described here, the attributes are accurate, complete, and have =
no
      special meanings.  "LSUB" and "LIST (SUBSCRIBED)" are, thus, not
      the same thing, and some servers must do significant extra work =
to
      respond to "LIST (SUBSCRIBED)".  Because of this, clients SHOULD
      continue to use "LSUB" unless they specifically want the
      additional information offered by "LIST (SUBSCRIBED)".

Leiba & Melnikov        Expires November 17, 2005               [Page =
8]
=0C

      This option defines a new mailbox attribute, "\Subscribed", that
      indicates that a mailbox name is subscribed to.  The =
"\Subscribed"
      attribute MUST be supported and MUST be accurately computed when
      the SUBSCRIBED selection option is specified.

      Note that the SUBSCRIBED selection option implies the SUBSCRIBED
      return option (see below).

   REMOTE - causes the LIST command to show remote mailboxes as well as
      local ones, as described in [MBRef].  This option is intended to
      replace the RLIST command and, in conjunction with the SUBSCRIBED
      selection option, the RLSUB command.

      This option defines a new mailbox attribute, "\Remote", that
      indicates that a mailbox is a remote mailbox.  The "\Remote"
      attribute MUST be accurately computed when the REMOTE option is
      specified.

      Note that a server implementation that doesn't support any remote
      mailboxes is compliant with this specification as long as it
      accepts and ignores the REMOTE selection option.  Note that if =
the
      server choses to ignore the REMOTE selection option, it still has
      to treat RECURSIVEMATCH REMOTE as a valid combination of =
selection
      options (see also the description of the RECURSIVEMATCH option
      below).

   RECURSIVEMATCH - this option forces the server to return information
      about parent mailboxes that don't match other selection options,
      but have some submailboxes that do.  Information about children =
is
      returned in the CHILDINFO extended data item, as described in
      Section 3.3.

      Note 1: In order for a parent mailbox to be returned, it still =
has
      to match the canonical LIST pattern.

      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.

      The RECURSIVEMATCH option MUST NOT occur as the only selection
      option, as it only makes sense when other selection options are
      also used.  The server MUST return BAD tagged response in such
      case.

      Note that even if RECURSIVEMATCH option is specified, the client
      MUST still be able to handle a case when a CHILDINFO extended =
data
      item is returned and there are no submailboxes that meet the
      selection criteria of the given LIST command, as they can be
      deleted/renamed after the LIST response was sent, but before the
      client had a chance to access them.

Leiba & Melnikov        Expires November 17, 2005               [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   The return options defined in this specification are

   SUBSCRIBED - causes the LIST command to return subscription state =
for
      all matching mailbox names.  The "\Subscribed" attribute MUST be
      supported and MUST be accurately computed when the SUBSCRIBED
      return option is specified.  Further, all mailbox flags MUST be
      accurately computed (this differs from the behaviour of the LSUB
      command).

   CHILDREN - Requests mailbox child information as originally proposed
      in [CMbox].  See Section 4, below, for details.  This option MUST
      be supported by all servers.

3.1  General principles for returning LIST responses

   This section outlines several principles that can be used by server
   implementations of this document to decide if a LIST response should
   be returned, as well as how many responses and what kind of
   information they may contain.

   1.  Exactly one LIST response should be returned for each mailbox
       name which matches the canonical LIST pattern.  Server
       implementors must not assume that clients will be able to
       assemble mailbox attributes and other information returned in
       multiple LIST responses.

   2.  There are only two reasons for including a matching mailbox name
       in the responses to the LIST command (Note that the server is
       allowed to return unsolicited responses at any time.  Such
       responses are not governed by this rule):

       A.  the mailbox name also satisfies the selection criteria;

       B.  the mailbox name doesn't satisfy the selection criteria, but
           it has at least one child mailbox name that satisfies the
           selection criteria and that doesn't match the canonical LIST
           pattern.
           For more information on this case see the CHILDINFO extended
           data item described in Section 3.3.  Note that the CHILDINFO
           extended data item can only be returned when the
           RECURSIVEMATCH selection option is specified.

   3.  Attributes returned in the same LIST response must be treated
       additively.  For example the following response

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

       means that the "Fruit/Peach" mailbox doesn't exist, but it is

Leiba & Melnikov        Expires November 17, 2005              [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       subscribed.

3.2  Additional requirements on LISTEXT clients

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred
   from it.  For example, the client must treat presence of the
   \NoInferiors attribute as if the \HasNoChildren attribute was also
   sent by the server.

   The following table summarizes inference rules described in
   Section 3.

               +--------------------+-------------------+
               | returned attribute | implied attribute |
               +--------------------+-------------------+
               |    \NoInferiors    |   \HasNoChildren  |
               |                    |                   |
               |    \NonExistent    |     \NoSelect     |
               +--------------------+-------------------+

3.3  CHILDINFO extended data item

   The CHILDINFO extended data item MUST only be returned when the
   client has specified the RECURSIVEMATCH selection option.

   The CHILDINFO extended data item in a LIST response describes the
   selection criteria that has caused it to be returned and indicates
   that the mailbox has st least one child mailbox that matches the
   selection criteria.

   The LSUB command indicates this condition by using the "\NoSelect"
   attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   CHILDINFO extended data item is more general, in that it can be used
   with any extended set of selection criteria.

   The returned selection criteria allow the client to distinguish a
   solicited response from an unsolicited one, as well as to =
distinguish
   among solicited responses caused by multiple pipelined LIST commands
   that specify different criteria.

   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.

   Examples 8 and 10 in Section 5 demonstrate the difference between

Leiba & Melnikov        Expires November 17, 2005              [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   present CHILDINFO extended data item and the "\HasChildren"
   attribute.

   The following table summarizes interaction between the =
"\NonExistent"
   attribute and CHILDINFO (the first collumn describes if the parent
   mailbox exists):

   =
+----------------+----------------+----------------+----------------+
   |     exists     |    meets the   |   has a child  |    returned    =
|
   |                |    selection   | that meets the |     LISTEXT    =
|
   |                |    criteria    |    selection   | attributes and =
|
   |                |                |    criteria    |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+
   |       no       |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       yes      |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       no       |       yes      |       no       |  (\NonExistent =
|
   |                |                |                |     <attr>)    =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       no       |    (<attr>)    =
|
   |                |                |                |                =
|
   |       no       |       no       |       yes      | (\NonExistent) =
|
   |                |                |                |   + CHILDINFO  =
|
   |                |                |                |                =
|
   |       yes      |       no       |       yes      | () + CHILDINFO =
|
   |                |                |                |                =
|
   |       no       |       yes      |       yes      |  (\NonExistent =
|
   |                |                |                |    <attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       yes      |   (<attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+

   where <attr> is one or more attributes that correspond to the
   selection criteria, for example for the SUBSCRIBED option the <attr>
   is \Subscribed.

Leiba & Melnikov        Expires November 17, 2005              [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

4.  The CHILDREN return Option

   The CHILDREN return option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [CMbox].  The CHILDREN
   return option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified.

   Many IMAP4 [IMAP4] clients present to the user a hierarchical view =
of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline =
hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.  When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.
   The CHILDREN return option provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST "" * or a LIST "" % for each mailbox name.  The
   CHILDREN return option defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren.
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN return option is provided to indicate that the
   client particularly wants this information.  If the CHILDREN return
   option is present, the server MUST return these attributes even if
   their computation is expensive.

   \HasChildren
        The presence of this attribute indicates that the mailbox has
        child mailboxes.  A server SHOULD NOT set this attribute if
        there are child mailboxes, and the user does not have
        permissions to access any of them.  In this case, =
\HasNoChildren
        SHOULD be used.  In many cases, however, a server may not be
        able to efficiently compute whether a user has access to all
        child mailboxes.  As such a client MUST be prepared to accept
        the \HasChildren attribute as a hint.  That is, a mailbox MAY =
be
        flagged with the \HasChildren attribute, but no child mailboxes
        will appear in the LIST response.

   \HasNoChildren
        The presence of this attribute indicates that the mailbox has =
NO
        child mailboxes that are accessible to the currently
        authenticated user.

Leiba & Melnikov        Expires November 17, 2005              [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

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

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.

Leiba & Melnikov        Expires November 17, 2005              [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

5.  Examples

   1:  The first example shows the complete local hierarchy that will =
be
       used for the other examples.

          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: * LIST () "/" "Vegetable/Corn"
          S: A01 OK done

   2:  In the next example, we'll see the subscribed mailboxes.  This =
is
       similar to, but not equivalent with, <LSUB "" "*">.  Note that
       the mailbox called "Fruit/Peach" is subscribed to, but does not
       actually exist (perhaps it was deleted while still subscribed).
       The "Fruit" mailbox is not subscribed to, but it has two
       subscribed children.  The "Vegetable" mailbox is subscribed and
       has two children, one of them is subscribed as well.

          C: A02 LIST (SUBSCRIBED) "" "*"
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"
          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: A02 OK done

   3:  The next example shows the use of the CHILDREN option.  The
       client, without having to list the second level of hierarchy, =
now
       knows which of the top-level mailboxes have submailboxes
       (children) and which do not.  Note that it's not necessary for
       the server to return the \HasNoChildren attribute for the inbox,
       because the \NoInferiors attribute already implies that, and has
       a stronger meaning.

          C: A03 LIST () "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Fruit"
          S: * LIST (\HasNoChildren) "/" "Tofu"
          S: * LIST (\HasChildren) "/" "Vegetable"
          S: A03 OK done

Leiba & Melnikov        Expires November 17, 2005              [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   4:  In this example we see more mailboxes, which reside on another
       server to which we may obtain referrals.  This is similar to the
       command <RLIST "" "%">.  Note that in the case of the remote
       mailboxes, the server might or might not be able to include
       CHILDREN information; it includes it if it can, and omits it if
       it can't.

          C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Fruit"
          S: * LIST (\HasNoChildren) "/" "Tofu"
          S: * LIST (\HasChildren) "/" "Vegetable"
          S: * LIST (\Remote) "/" "Bread"
          S: * LIST (\HasChildren \Remote) "/" "Meat"
          S: A04 OK done

   5:  The following example also requests the server to include
       mailboxes, which reside on another server.  The server returns
       information about all mailboxes which are subscribed.  This is
       similar to the command <RLSUB "" "%">.  We also see the use of
       two selection options.

          C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"
          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
          S: * LIST (\Subscribed) "/" "Vegetable"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: * LIST (\Remote \Subscribed) "/" "Bread"
          S: A05 OK done

   6:  The following example requests the server to include mailboxes,
       which reside on another server.  The server is requested to
       return subscription information for all returned mailboxes.  =
This
       is different from the example above.

       Note that the output of this command is not a superset of the
       output in the previous example, as it doesn't include LIST
       response for the non-existent "Fruit/Peach".

          C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST () "/" "Fruit"
          S: * LIST () "/" "Fruit/Apple"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"

Leiba & Melnikov        Expires November 17, 2005              [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST () "/" "Tofu"
          S: * LIST (\Subscribed) "/" "Vegetable"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: * LIST () "/" "Vegetable/Corn"
          S: * LIST (\Remote \Subscribed) "/" "Bread"
          S: * LIST (\Remote) "/" "Meat"
          S: A06 OK done

   7:  In the following example the client has specified multiple
       mailbox patterns.  Note that this example doesn't use the =
mailbox
       hierarchy used in the previous examples.

          C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
          S: * LIST () "/" "INBOX"
          S: * LIST (\NoInferiors) "/" "Drafts"
          S: * LIST () "/" "Sent/March2004"
          S: * LIST (\Marked) "/" "Sent/December2003"
          S: * LIST () "/" "Sent/August2004"
          S: BBB OK done

   8:  The following example demonstates the difference between
       \HasChildren attribute and CHILDINFO extended data item.

       Let's assume there is the following hierarchy:

          C: C01 LIST "" "*"
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST () "/" "Foo"
          S: * LIST () "/" "Foo/Bar"
          S: * LIST () "/" "Foo/Baz"
          S: * LIST () "/" "Moo"
          S: C01 OK done

       If the client asks RETURN (CHILDREN) it will get this:

          C: CA3 LIST "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Foo"
          S: * LIST (\HasNoChildren) "/" "Moo"
          S: CA3 OK done

       A) Let's also assume that the mailbox "Foo/Baz" is the only
       subscribed mailbox.  Then we get this result:

          C: C02 LIST (SUBSCRIBED) "" "*"

Leiba & Melnikov        Expires November 17, 2005              [Page =
17]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\Subscribed) "/" "Foo/Baz"
          S: C02 OK done

       Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
       will return no mailboxes (as the mailboxes "Moo", "Foo" and
       "Inbox" are NOT subscribed).  However, if the client issues =
this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
          S: C04 OK done

       i.e.  the mailbox "Foo" is not subscribed, but it has a child
       that is.

       A1) If the mailbox "Foo" had been subscribed instead, the last
       command would return this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       or even this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       A2) If we assume instead that the mailbox "Foo" is not part of
       the original hierarchy and is not subscribed, the last command
       will give this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       B) Now, let's assume that no mailbox is subscribed.  In this =
case
       the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will =
return
       no responses, as there are no subscribed children (even though
       "Foo" has children).

       C) And finally, suppose that only the mailboxes "Foo" and "Moo"
       are subscribed.  In that case we see this result:

          C: LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)

Leiba & Melnikov        Expires November 17, 2005              [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\HasChildren \Subscribed) "/" "Foo"
          S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"

       (which means that the mailbox "Foo" has children, but none of
       them is subscribed).

   9:  The following example demonstrates that the CHILDINFO extended
       data item is returned whether children mailboxes match the
       canonical LIST pattern or not.

       Let's assume there is the following hierarchy:

          C: D01 LIST "" "*"
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST () "/" "foo2"
          S: * LIST () "/" "foo2/bar1"
          S: * LIST () "/" "foo2/bar2"
          S: * LIST () "/" "baz2"
          S: * LIST () "/" "baz2/bar2"
          S: * LIST () "/" "baz2/bar22"
          S: * LIST () "/" "baz2/bar222"
          S: * LIST () "/" "eps2"
          S: * LIST () "/" "eps2/mamba"
          S: * LIST () "/" "quux2/bar2"
          S: D01 OK done

       And that the following mailboxes are subscribed:

          C: D02 LIST (SUBSCRIBED) "" "*"
          S: * LIST (\Subscribed) "/" "foo2/bar1"
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2"
          S: * LIST (\Subscribed) "/" "eps2/mamba"
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D02 OK done

       The client issues the following command first:

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "baz2/bar2"

Leiba & Melnikov        Expires November 17, 2005              [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D03 OK done

       and the server may also include

          S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO"
          ("SUBSCRIBED")))

       The CHILDINFO extended data item is returned for mailboxes
       "foo2", "baz2" and "eps2", because all of them have subscribed
       children, even though for the mailbox "foo2" only one of the two
       subscribed children match the pattern, for the mailbox "baz2" =
all
       the subscribed children match the pattern and for the mailbox
       "eps2" none of the subscribed children match the pattern.

       Note that if the client issues

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "foo2/bar1"
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "baz2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "eps2/mamba"
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D03 OK done

       the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
       have the CHILDINFO extended data item, even though this
       information is redundant and the client can determine it by
       itself.

   10: The following example shows usage of multiple mailbox patterns.
       It also demonstrates that the presence of the CHILDINFO extended
       data item doesn't necessarily imply \HasChildren.

          C: a1 LIST "" ("foo" "foo/*")
          S: * LIST () "/" foo

Leiba & Melnikov        Expires November 17, 2005              [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: a1 OK done

          C: a2 LIST (SUBSCRIBED) "" "foo/*"
          S: * LIST (\Subscribed \NonExistent) "/" foo/bar
          S: a2 OK done

          C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN
          (CHILDREN)
          S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
          ("SUBSCRIBED")))
          S: a3 OK done

Leiba & Melnikov        Expires November 17, 2005              [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

6.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].

   "vendor-token" is defined in [ACAP].  Note that this normative
   reference to ACAP is an issue in moving this spec forward, since =
ACAP
   will never move to Draft Standard.  The definitions of =
"vendor-token"
   and of the IANA registry must eventually go somewhere else, in a
   document that can be moved forward on the standards track.

   childinfo-extended-item =3D "CHILDINFO" SP "("
               list-select-base-opt-quoted
               *( SP list-select-base-opt-quoted ) ")"
               ; Extended data item returned when the RECURSIVEMATCH
               ; selection option is specified.
               ; Note 1: the CHILDINFO tag can be returned
               ;  with and without surrounding quotes, as per
               ;  mbox-list-extended-item-tag production.
               ; Note 2: The selection options are returned quoted,
               ;  unlike their specification in the extended LIST
               ;  command.

   child-mbox-flag =3D "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

   eitem-standard-tag =3D atom
               ; a tag for extended list data defined in a Standard
               ; Track or Experimental RFC.

   eitem-vendor-tag =3D vendor-tag
               ; a vendor specific tag for extended list data

   list =3D      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
               [SP list-return-opts]

   list-select-opts =3D "(" [*(list-select-mod-opt SP)
               list-select-base-opt
               *(SP list-select-opt)] ")"
               ; list selection options, e.g.  REMOTE

   list-select-opt =3D list-select-mod-opt / list-select-base-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

Leiba & Melnikov        Expires November 17, 2005              [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   list-select-base-opt =3D "SUBSCRIBED" / "REMOTE" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted =3D <"> list-select-base-opt <">

   list-select-mod-opt =3D "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-return-opts =3D "RETURN" SP "(" [return-option *(SP
               return-option)] ")"
               ; list return options, e.g.  CHILDREN

   mailbox-list =3D "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]

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

   mbox-list-extended-item =3D "(" mbox-list-extended-item-data ")"

   mbox-list-extended-item-data =3D mbox-list-extended-item-tag SP
               nstring-list

   mbox-list-extended-item-tag =3D astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; or "eitem-standard-tag" ABNF productions.
               ; A tag registration template is described in this
               document
               ; in Section 8.5.

   mbox-list-oflag =3D child-mbox-flag / "\NonExistent" /
               / "\Subscribed" / "\Remote"

   mbox-or-pat =3D list-mailbox / patterns

   nstring-list =3D nstring /
               "(" [nstring-list *(SP nstring-list)] ")"
               ; a recursive list definition

   option-extension =3D option-vendor-tag / option-standard-tag

   option-vendor-tag =3D vendor-tag
               ; a vendor specific option

Leiba & Melnikov        Expires November 17, 2005              [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   option-standard-tag =3D atom
               ; an option defined in a Standard Track or
               ; Experimental RFC

   patterns =3D  "(" list-mailbox *(SP list-mailbox) ")"

   return-option =3D "SUBSCRIBED" / "CHILDREN" /
               option-extension

   vendor-tag =3D vendor-token "-" atom

Leiba & Melnikov        Expires November 17, 2005              [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

7.  Security Considerations

   This document describes syntactic changes to the specification of =
the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  =
They
   are described in [IMAP4] and [MBRef].

   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all =
child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access =
to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.  In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.

   The CHILDINFO extended data item has the same security =
considerations
   as the \HasChildren attribute described above.

Leiba & Melnikov        Expires November 17, 2005              [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

8.  IANA Considerations

8.1  Guidelines for IANA

   It is requested that IANA creates two new registries for LISTEXT
   options and LISTEXT extended response data.  The templates and the
   initial registrations are detailed below.

8.2  Registration procedure and Change control

   Registration of a LISTEXT option is done by filling in the template
   in Section 8.3 and sending it via electronic mail to [email-masked].
   Registration of a LISTEXT extended data item is done by filling in
   the template in Section 8.5 and sending it via electronic mail to
   [email-masked].  IANA has the right to reject obviously bogus
   registrations, but will perform no review of claims made in the
   registration form.

   A LISTEXT option/extended data item name that starts with "V-" is
   reserved for vendor specific options/extended data items.  All
   options, whether they are vendor specific or global, should be
   registered with IANA.  If a LISTEXT extended data item is returned =
as
   a result of requesting a particular LISTEXT option, the name of the
   option SHOULD be used as the name of the LISTEXT extended data item.

   Each vendor specific options/extended data item MUST start with =
their
   vendor-token ("vendor prefix").  The vendor-token MUST be registered
   with IANA, using the [ACAP] vendor subtree registry.

   Standard LISTEXT option/extended data item names are case
   insensitive.  If the vendor prefix is omitted from a vendor specific
   LISTEXT option/extended data item name, the rest is case =
insensitive.
   The vendor prefix itself is not case-sensitive, as it might contain
   non-ASCII characters.

   While the registration procedures do not require it, authors of
   LISTEXT options/extended data items are encouraged to seek community
   review and comment whenever that is feasible.  Authors may seek
   community review by posting a specification of their proposed
   mechanism as an Internet- Draft.  LISTEXT options/extended data =
items
   intended for widespread use should be standardized through the =
normal
   IETF process, when appropriate.

   Comments on registered LISTEXT options/extended response data should
   first be sent to the "owner" of the mechanism and/or to the IMAPEXT
   WG mailing list.  Submitters of comments may, after a reasonable
   attempt to contact the owner, request IANA to attach their comment =
to
   the registration itself.  If IANA approves of this, the comment will

Leiba & Melnikov        Expires November 17, 2005              [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   be made accessible in conjunction with the registration LISTEXT
   options/ extended response data itself.

   Once a LISTEXT registration has been published by IANA, the author
   may request a change to its definition.  The change request follows
   the same procedure as the registration request.

   The owner of a LISTEXT registration may pass responsibility for the
   registered option/extended data item to another person or agency by
   informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a LISTEXT option/extended
   data item.  The most common case of this will be to enable changes =
to
   be made to mechanisms where the author of the registration has died,
   moved out of contact or is otherwise unable to make changes that are
   important to the community.

   LISTEXT registrations may not be deleted; mechanisms which are no
   longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such LISTEXT options/extended
   data items will be clearly marked in the lists published by IANA.

   The IESG is considered to be the owner of all LISTEXT
   options/extended data items which are on the IETF standards track.

8.3  Registration template for LISTEXT options

   To: [email-masked]
   Subject: Registration of LISTEXT option X

   LISTEXT option name:

   LISTEXT option type: (One of SELECTION or RETURN)

   Implied return options(s), if the option type is SELECTION: (zero or
   more)

   LISTEXT option description:

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

Leiba & Melnikov        Expires November 17, 2005              [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.4  Initial LISTEXT option registrations

   It is requested that the LISTEXT option registry be populated with
   the following entries:

   1.  To: [email-masked]
       Subject: Registration of LISTEXT option SUBSCRIBED

       LISTEXT option name: SUBSCRIBED

       LISTEXT option type: SELECTION

       Implied return options(s): SUBSCRIBED

       LISTEXT option description: Causes the LIST command to list
       subscribed mailboxes, rather than the actual mailboxes.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   2.  To: [email-masked]
       Subject: Registration of LISTEXT option REMOTE

       LISTEXT option name: REMOTE

       LISTEXT option type: SELECTION

       Implied return options(s): (none)

       LISTEXT option description: causes the LIST command to return
       remote mailboxes as well as local ones, as described in RFC =
2193.

       Published specification : XXXX, Section 3.

Leiba & Melnikov        Expires November 17, 2005              [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   3.  To: [email-masked]
       Subject: Registration of LISTEXT option SUBSCRIBED

       LISTEXT option name: SUBSCRIBED

       LISTEXT option type: RETURN

       LISTEXT option description: Causes the LIST command to return
       subscription state.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   4.  To: [email-masked]
       Subject: Registration of LISTEXT option RECURSIVEMATCH

       LISTEXT option name: RECURSIVEMATCH

       LISTEXT option type: SELECTION

       Implied return options(s): (none)

       LISTEXT option description: Requests that CHILDINFO extended =
data
       item is to be returned.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

Leiba & Melnikov        Expires November 17, 2005              [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   5.  To: [email-masked]
       Subject: Registration of LISTEXT option CHILDREN

       LISTEXT option name: CHILDREN

       LISTEXT option type: RETURN

       LISTEXT option description: Requests mailbox child information.

       Published specification : XXXX, Section 3 and Section 4.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

8.5  Registration template for LISTEXT extended data item

   To: [email-masked]
   Subject: Registration of X LISTEXT extended data item

   LISTEXT extended data item tag:

   LISTEXT extended data item description:

   Which LISTEXT option(s) (and their types) causes this extended data
   item to be returned (if any):

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

Leiba & Melnikov        Expires November 17, 2005              [Page =
30]
=0C

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.6  Initial LISTEXT extended data item registrations

   It is requested that the LISTEXT extended data item registry be
   populated with the following entries:

   1.  To: [email-masked]
       Subject: Registration of CHILDINFO LISTEXT extended data item

       LISTEXT extended data item tag: CHILDINFO

       LISTEXT extended data item description: The CHILDINFO extended
       data item describes the selection criteria that has caused it to
       be returned and indicates that the mailbox has one or more child
       mailbox that match the selection criteria.

       Which LISTEXT option(s) (and their types) causes this extended
       data item to be returned (if any): RECURSIVEMATCH selection
       option

       Published specification : XXXX, Section 3.3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

Leiba & Melnikov        Expires November 17, 2005              [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

9.  Acknowledgements

   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in Section 4, is theirs.

   This document is the result of discussions on the IMAP4 and IMAPEXT
   mailing lists and is meant to reflect consensus of those groups.  In
   particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo
   Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt
   Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were
   active participants in those discussions or made suggestions to this
   document.

10.  Normative References

   [ABNF]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 2234, November 1997.

   [ACAP]   Newman, C. and J. Myers, "ACAP -- Application Configuration
            Access Protocol", RFC 2244, November 1997.

   [CMbox]  Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.

   [IMAP4]  Crispin, M., "Internet Message Access Protocol - Version
            4rev1", RFC 3501, March 2003.

   [Kwds]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", RFC 2119, March 1997.

   [MBRef]  Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
            1997.

Authors' Addresses

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532
   US

   Phone: +1 914 784 7941
   Email: [email-masked]

Leiba & Melnikov        Expires November 17, 2005              [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: [email-masked]
   URI:   http://www.melnikov.ca/

Leiba & Melnikov        Expires November 17, 2005              [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Leiba & Melnikov        Expires November 17, 2005              [Page =
34]
=0C

--==========3BDCC6310244676E312C==========--

Date: Thu, 12 May 2005 14:20:11 -0700
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: necessary updates to RFC 2359 (UIDPLUS)
Organization: Networks & Distributed Computing
Sender: [email-masked]

RFC 2359 needs to clarify that the UIDPLUS extension indicates that the 
UID EXPUNGE extension is present, and does not necessarily indicate the 
APPENDUID and COPYUID response codes.

As presently constituted, RFC 2359 is ambiguous as to whether APPENDUID 
and COPYUID are mandatory responses for a UIDPLUS server.  It is also 
ambiguous as to whether a server which does not support UID EXPUNGE may 
send APPENDUID/COPYUID response codes.

I recommend that RFC 2359 be updated as follows:

. clarify that the UIDPLUS extension refers to the UID EXPUNGE command.

. recommend that servers SHOULD issue APPENDUID/COPYUID response codes.

The alternate interpretation, that UIDPLUS covers the response codes, 
necessitates that, in the case of a mail store that does not have sticky 
UIDs (that is, UIDVALIDITY changes at each SELECT), the server issue false 
(but plausible-seeming) information in an APPENDUID/COPYUID response code.

I can not believe that the intent of RFC 2359 is that a server send a 
complete fabrication in the case of a server which supports multiple mail 
stores, only some of which have sticky UIDs.

-- Mark --

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

Date: Thu, 12 May 2005 12:48:19 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SASLprep + ACL
Sender: [email-masked]

Hi,

now that RFC 4013 is out, it seems possible to authenticate with unicode 
user names. No problems for IMAP, as far as I can tell, with two 
possible exceptions:

1. Mailbox names. Some servers might need some additional logic instead 
of just concatenating "home." + username + ".INBOX". Doesn't seem like 
an IMAP issue at all to me, just a bit of implementation work.

2. ACL/2. ACL uses "identifiers", which are UTF-8 in 2068upd and ACL2. 
How shoiuld these be related to the SASLprepped identifiers used by 
AUTHENTICATE? It seems beneficial that they be the same, but who should 
be responsible for running them through SASLprep?

Arn

Date: Wed, 11 May 2005 13:50:44 -0400
From: Barry Leiba <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

> Any update on when to expect a LISTEXT document to last call?

Unless my memory is more feeble than I think it is (a distinct
possibility), I posted the latest draft to the mailing list and
asked for comments on a couple of things.  I got a reply from Mark,
which I've taken to heart, but have heard nothing else... and there
was at least one significant issue.

But now that you mention things, that's OK.  Since no one has
responded, it means that whatever I decide is fine.  So I will go
ahead and make the changes the way *I* think it should be, and I'll
post it for last call by the weekend.

So, guys, this is the last call before last call.  Please don't
make me do the work and THEN decide it has to be changed.

Barry

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

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Date: Wed, 11 May 2005 10:17:07 -0700
To: Barry Leiba <[email-masked]>
Sender: [email-masked]

Any update on when to expect a LISTEXT document to last call?

Lisa

On Mar 29, 2005, at 10:59 AM, Barry Leiba wrote:

>
>> below, in order  to come up with new milestone dates, I need to get
>> date promises out of  the active draft authors (Cyrus, Randy, Barry,
>> Alexey) for LISTEXT,  ANNOTATE and 2086upd as well as ACL2.
>
> I have just converted the plain text for the -11 version of ListExt
> into XML that works for xml2rfc -- that was a prerequisite for updates,
> since dealing directly with the plain text is too painful.  I sent the
> new text to Alexey the other day for review (to make sure I didn't
> break anything).
>
> I'll next be working on making the changes, and resolving the open
> issues.  Expect a -12 version, along with a list of what still has to
> be resolved, to be posted by 7 April.
>
> I don't think the things that need to be resolved will be very
> contentious, but, then, we thought that what we came up with at the
> interim meeting would go smoothly, and it didn't.  Anyway, if I can lay
> out the remaining issues clearly, we should be able to get through them
> on the list and get a last-call document out as -13.  Maybe go for end
> of April as the goal for making the last call?  Is that suitable?
>
> Barry
>
> --
> Barry Leiba, Pervasive Computing Technology  ([email-masked])
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>
>

Date: Tue, 10 May 2005 10:00:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: rfc 4013 + imap-i18n
Sender: [email-masked]

Hi,

I was just reading RFC 4013 to see what, if anything, needs changing in 
draft-ietf-imapext-18n. I don't see anything. It seems orthogonal. Am I 
missing something?

Arnt

Date: Tue, 3 May 2005 18:00:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SPAM/NOTSPAM IMAP extension.
Cc: Rob Siemborski <[email-masked]>, Lewis Thompson <[email-masked]>
Sender: [email-masked]

Rob Siemborski writes:
> I think -02 has a $AutoJunk and $Junk differentiation (along with 
> NotJunk versions)

Fine, then.

Arnt

Date: Tue, 3 May 2005 11:49:41 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Lewis Thompson <[email-masked]>
Subject: Re: SPAM/NOTSPAM IMAP extension.
Sender: [email-masked]

On Tue, 3 May 2005, Arnt Gulbrandsen wrote:

> Rob Siemborski writes:
>> Do the junk filtering keywords described in 
>> draft-melnikov-imap-keywords-XX.txt get you the functionality that you 
>> need?
>
> I've fooled around with this too, and I think that in my special case those 
> keywords can work, but in general they have a weakness:
>
>> (In this case, instead of having the imap server immediately process the 
>> change, some other "client" notices the flag change and does the update 
>> accordingly).
>
> Suppose that other client wants to do bayes training, or something else that 
> needs a message corpus.
>
> In that case, it cannot know whether the keyword was set a) autonomously by 
> an application, b) by command of a human, or c) after review by a human. In 
> the former case, the application should NOT include the message in the 
> training corpus. In the latter two cases, it generally should.
>
> (This may have been fixed in a newer version of the draft. I've only read 
> -00.)

I think -02 has a $AutoJunk and $Junk differentiation (along with NotJunk 
versions)

e.g.

http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-melnikov-imap-keywords-02.txt

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 3 May 2005 12:02:35 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SPAM/NOTSPAM IMAP extension.
Cc: Rob Siemborski <[email-masked]>, Lewis Thompson <[email-masked]>
Sender: [email-masked]

Rob Siemborski writes:
> Do the junk filtering keywords described in 
> draft-melnikov-imap-keywords-XX.txt get you the functionality that 
> you need?

I've fooled around with this too, and I think that in my special case 
those keywords can work, but in general they have a weakness:

> (In this case, instead of having the imap server immediately process 
> the change, some other "client" notices the flag change and does the 
> update accordingly).

Suppose that other client wants to do bayes training, or something else 
that needs a message corpus.

In that case, it cannot know whether the keyword was set a) autonomously 
by an application, b) by command of a human, or c) after review by a 
human. In the former case, the application should NOT include the 
message in the training corpus. In the latter two cases, it generally 
should.

(This may have been fixed in a newer version of the draft. I've only read -00.)

Arnt

Date: Mon, 2 May 2005 20:03:53 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Lewis Thompson <[email-masked]>
cc: [email-masked]
Subject: Re: SPAM/NOTSPAM IMAP extension.
Sender: [email-masked]

Do the junk filtering keywords described in 
draft-melnikov-imap-keywords-XX.txt get you the functionality that you 
need?

(In this case, instead of having the imap server immediately process the 
change, some other "client" notices the flag change and does the update 
accordingly).

-Rob

On Thu, 28 Apr 2005, Lewis Thompson wrote:

>
> Hi,
>
> I posted this question on the ietf-mta-filters list thinking it was
> somewhat related to the Sieve extension but got redirected here.
>
>> From what I've found an IMAP extension for marking email as SPAM or
> NOTSPAM does not exist.  I posted this to the ietf-mta-filters list
> explaining exactly what I meant:
>
> "My MTA is running with SpamAssassin and an email gets falsely
> identified as spam.  It gets delivered to a spam folder where I find it.
> I want to prevent it from happening again so I teach SpamAssassin it is
> ham and remove the SpamAssassin modifications.  The IMAP command (?)
> that does this would be (to make something up) NOTSPAM.
>
> I'm not sure of the IMAP syntax but it might be called something like:
> "NOTSPAM message-id".  The IMAP server then invokes SA and strips the
> junk (added by SA) and re-learns as ham.
>
> Also I would like to see SPAM, which is the opposite of NOTSPAM
> (surprisingly).  If some junk mail gets through SA then I want to teach
> SA that it is spam.  Maybe then it would be deleted or moved to a spam
> folder (this would probably be done by the user, not the IMAP server).
>
> Obviously in all these cases SpamAssassin could be replaced by any spam
> filter.  The IMAP server would have a command that the message simply
> gets piped through to do the learning/stripping of junk."
>
> I'm not really sure of exactly how RFC-style things work or whether this
> is really suitable.  I've spoken to a few people in passing about such
> an extension and all of them seem to think it is a good idea so I'm
> fairly sure there is "demand".
>
> What do you guys think about this and where should I go from here?
> Thanks very much,
>
> -Lewis Thompson.
>
> --
> I was so much older then, I'm younger than that now.  --Bob Dylan, 1964.
> -| msn:[email-masked] | jabber:[email-masked] | url:www.lewiz.org |-
>
>
>

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 31 May 2005 10:10:11 -0700
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Abusing subscriptions
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 31 May 2005, Rob Siemborski wrote:
> On 5/31/05, Mark Crispin <[email-masked]> wrote:
>> It isn't abuse to subscribe, say, all your mailboxes which receive
>> incoming mail so that you have a subset list to scan closer for new mail,
>> ignoring all the mailboxes with old archived mail.  That's the general
>> notion of what subscriptions are intended to do (and specifically
>> newsgroups).
> If the client does this automatically, without asking the user, when
> the user didn't intend for this to happen, it still seems pretty
> abusive.

I agree.

I would argue, though, that a client wouldn't know what mailboxes "receive 
incoming mail" unless told so by the user; and that the abuse is the 
presumption on the part of the client that it knows without being told.

-- Mark --

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

Date: Tue, 31 May 2005 09:09:32 -0700
From: Rob Siemborski <[email-masked]>
Reply-To: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: Abusing subscriptions
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/31/05, Mark Crispin <[email-masked]> wrote:
> It isn't abuse to subscribe, say, all your mailboxes which receive
> incoming mail so that you have a subset list to scan closer for new mail,
> ignoring all the mailboxes with old archived mail.  That's the general
> notion of what subscriptions are intended to do (and specifically
> newsgroups).

If the client does this automatically, without asking the user, when
the user didn't intend for this to happen, it still seems pretty
abusive.

-Rob

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

Date: Tue, 31 May 2005 09:01:33 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Abusing subscriptions
Sender: [email-masked]

On Tue, 31 May 2005, Arnt Gulbrandsen wrote:
>> Yes.  Recursively LISTing all mailbox names and automatically
>> subscribing every single name that comes back is an abuse of
>> subscriptions,
>> What purpose can possibly be served by recursively LISTing all names
>> and then SUBSCRIBEing?
> I agree that that's abuse, as would silently unsubscribing all
> subscribed names be. Both of those remove all information from the
> subscription list.
> Is that all you mean by abuse?

Yes.  There are, unfortunately, commonly used clients that do this.  It's 
been an ongoing problem for many years.  [Even worse, there are clients 
which, having done this, then does an LSUB and then LISTs each name 
individually.]

It isn't abuse to subscribe, say, all your mailboxes which receive 
incoming mail so that you have a subset list to scan closer for new mail, 
ignoring all the mailboxes with old archived mail.  That's the general 
notion of what subscriptions are intended to do (and specifically 
newsgroups).

-- Mark --

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

Date: Tue, 31 May 2005 08:56:15 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Abusing subscriptions
Sender: [email-masked]

On Tue, 31 May 2005, Mark Crispin wrote:
> What purpose can possibly be served by recursively LISTing all names and then 
> SUBSCRIBEing?

In a similar vein -

If you buy a magazine at the store, does this mean that the store should 
automatically subscribe you to that magazine and all other magazines that 
the store sells?

If you try some new browser, should that browser add all URLs that you 
type in or click to your Windows Address (IE bookmarks), and initiate a 
spider to hunt out other possible URLs to add?

If you connect to an anonymous FTP server, should the FTP client 
automatically download all files on the server?

I hope that the answer for the above is all "of course not"!

How, then, is it reasonable for a client to abuse subscriptions in a 
similar way?  Why is a static LSUB list, which is documented not to 
reflect what is actually on the server, better than the list from LIST?

So maybe subscriptions have another purpose.  What happens if an IMAP 
server exports newsgroups?  Wouldn't it be nice if the server kept track 
of your subscribed newsgroups instead requiring a .newsrc file on each 
client?

-- Mark --

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

Date: Tue, 31 May 2005 17:53:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Abusing subscriptions
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> Yes.  Recursively LISTing all mailbox names and automatically 
> subscribing every single name that comes back is an abuse of 
> subscriptions,
...
> What purpose can possibly be served by recursively LISTing all names 
> and then SUBSCRIBEing?

I agree that that's abuse, as would silently unsubscribing all 
subscribed names be. Both of those remove all information from the 
subscription list.

Is that all you mean by abuse?

Arnt

Date: Tue, 31 May 2005 08:33:42 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Abusing subscriptions
Sender: [email-masked]

On Tue, 31 May 2005, Arnt Gulbrandsen wrote:
> Mark Crispin writes:
>> Unfortunately, you can't use the IMAP "subscribe" feature to identify these 
>> mailboxes, because of certain poorly-written clients which abuse 
>> subscriptions.
> Abuse? How?

Yes.  Recursively LISTing all mailbox names and automatically subscribing 
every single name that comes back is an abuse of subscriptions, just as 
recursively LISTing all mailbox names and doing a STATUS of every single 
name is an abuse of the server.

The fact that hundreds, thousands, tens of thousands, ... of commands are 
being done by this is a clue that this is not the right thing to do.

> I don't actually see any text about how one is meant to use subscriptions.

There's no text that says that, the first time you run a client, the 
client shouldn't unilaterally download all messages in all mailboxes into 
a client-proprietary format, and then expunge the messages from the 
server.  That doesn't change the fact that this is abuse, and would 
probably seriously aggrieve someone who runs a client just to try it.

There's no text that says that you shouldn't rename all of HKLM in the 
Windows registry.

The world is full of things that are not explicitly stated, but are 
nonetheless implicit.  One of these implicit concepts is that software 
should not make far-ranging changes to shared state, especially not 
without the consent of the user.

Another of these implicit concepts is that, if you are not certain of the 
purpose of something, you shouldn't use it until you ascertain that 
purpose.

What purpose can possibly be served by recursively LISTing all names and 
then SUBSCRIBEing?

I shudder at the notion that without explicit instructions to the 
contrary, it's right and proper to do anything; and if something bad 
happens, it's the fault of the instructions and not the abuser's lack of 
common sense or refusal to do research.  Do we really need to have 
detailed usage instructions on a box of toothpicks?

-- Mark --

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

Date: Tue, 31 May 2005 10:52:05 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Abusing subscriptions
Sender: [email-masked]

Mark Crispin writes:
> Unfortunately, you can't use the IMAP "subscribe" feature to identify 
> these mailboxes, because of certain poorly-written clients which 
> abuse subscriptions.

Abuse? How?

I don't actually see any text about how one is meant to use subscriptions.

Arnt

Date: Tue, 31 May 2005 09:27:30 +0100
From: "Simon Tyler" <[email-masked]>
Subject: Re: IMAP4 List Command Extensions
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a MIME-encapsulated message

--==_08273053102768/PD.gordano.com==_
Content-Type: multipart/alternative; boundary="==_08273053102769/PD.gordano.com==_"

--==_08273053102769/PD.gordano.com==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 =20
Indeed the protocol should consider a wide variety of implementations. Such=
 as one which has no large overhead in obtaining the extra information I=
 was proposing. Our client will clearly backdown to using a STATUS command=
 should the extended LIST response not be found.=20
 =20
I fully understand all the issues, that is why I felt it was a reasonable=
 extension - servers which have issues returning the UID information in=
 short timescales would obviously not choose to add in such an extension.=
 Those that can obtain the information could do so.=20
 =20
Simon=20

---- Message from mailto:<[email-masked] Mark Crispin=
 <[email-masked]> at 31-May-2005 00:47:28 ------=20

I'm not sure if I was unclear in my previous message.  The point that I=20
attempted to make is that if you wish your client to interoperate with=20
multiple servers, you can not assume that UIDVALIDITY/UIDNEXT can be=20
obtained quickly.

It is an important characteristic of well-designed Internet protocol=20
implementations that they consider a wide variety of other=20
implementations.  This means, among other things, that you have to=20
consider the limitations in other implementations even if your own=20
implementation does not have that implementation.

One very large vendor is often heavily criticized because its software=
 has=20
many non-standard extensions that are implied to be part of the standard.=20
Then, when competing software does not work due to it not having these=20
non-standard extensions, the implication is that the competitor's=
 software=20
is broken.  This has led to ill feelings, and some of these problems have=20
even been offered as evidence of illegal behavior by that vendor.

It is therefore of critical importance that your software work well with=20
implementations that meet the basic compliance requirements without any=20
extensions.

As you may have noticed, STATUS does not accept a wildcard.  There is a=20
reason for this; and that reason was not stupidity on the part of the=20
protocol designer.  Please note the following text in RFC 3501, section=20
6.3.10:

       Unlike the LIST command, the STATUS command is not guaranteed to
       be fast in its response.  Under certain circumstances, it can be
       quite slow.  In some implementations, the server is obliged to
       open the mailbox read-only internally to obtain certain status
       information.  Also unlike the LIST command, the STATUS command
       does not accept wildcards.

The entire design of the STATUS command was to make a client implementor=20
think "hmm, it does not scale to do a LIST followed by a STATUS of each=20
individual name, I need to think of alternative strategies."

The bottom line is that you need to think of alternative strategies in=20
order to produce a quality IMAP client and not an "also-ran".

On Tue, 31 May 2005, Simon Tyler wrote:
> Whilst I understand that some servers may take a significant length of=20
> time to retrieve the UIDVALIDITY\UIDNEXT values others do not have this=20
> restriction. It also remains a fact that many IMAP clients will do a=20
> STATUS for each and every mailbox so for those clients it would be an=20
> improvement if this information could (optionally) be included in the=20
> LIST response.
>
> In our testing adding this sort sort of feature to the client and=
 server=20
> dramatically improved the synchronisation speed - the cost to our=
 server=20
> of getting the UIDVALIDATY\UIDNEXT being almost nothing.
>
> Simon
>
>
> ---- Message from mailto:<[email-masked] Mark Crispin=
 <[email-masked]> at 31-May-2005 00:17:08 ------
> On Tue, 31 May 2005, Simon Tyler wrote:
>> A typical client will do a
>> LIST to obtain the list of folders and then later do a STATUS on each
>> folder to get information such as the UIDVALIDITY. The cost of doing
>> this is suprisingly high (about 200ms in general) caused simply by
>> general network latency.
>
> The cost of doing this can be even higher than just that.
>
> There is no guarantee that a mail store can return the UIDVALIDITY or
> UIDNEXT in a trivial amount of time.  A LIST that returns those values
> could easily take some number of seconds per mailbox returned.  That LIST
> command returning UIDVALIDITY/UIDNEXT could take hours to complete!

-- Mark --

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

--==_08273053102769/PD.gordano.com==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style><!-- P{ margin-top:0;margin-bottom:0;} //=
 --></style></head><body><P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Indeed the protocol should consider a wide=
 variety of implementations. Such as one which has no large overhead in=
 obtaining the extra information I was proposing. Our client will clearly=
 backdown to using a STATUS command should the extended LIST response not=
 be found.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>I fully understand all the issues, that is=
 why I felt it was a reasonable extension - servers which have issues=
 returning the UID information in short timescales would obviously not=
 choose to add in such an extension. Those that can obtain the information=
 could do so.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Simon</P>
<P><BR>---- Message from <A href=3D"mailto:<[email-masked]">Mark=
 Crispin &lt;[email-masked]&gt;</A> at 31-May-2005 00:47:28=
 ------</P>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:=
 #000000 2px solid">I'm not sure if I was unclear in my previous message.=
 &nbsp;The point that I <BR>attempted to make is that if you wish your=
 client to interoperate with <BR>multiple servers, you can not assume that=
 UIDVALIDITY/UIDNEXT can be <BR>obtained quickly.<BR><BR>It is an important=
 characteristic of well-designed Internet protocol <BR>implementations that=
 they consider a wide variety of other <BR>implementations. &nbsp;This=
 means, among other things, that you have to <BR>consider the limitations=
 in other implementations even if your own <BR>implementation does not have=
 that implementation.<BR><BR>One very large vendor is often heavily=
 criticized because its software has <BR>many non-standard extensions that=
 are implied to be part of the standard. <BR>Then, when competing software=
 does not work due to it not having these <BR>non-standard extensions, the=
 implication is that the competitor's software <BR>is broken. &nbsp;This=
 has led to ill feelings, and some of these problems have <BR>even been=
 offered as evidence of illegal behavior by that vendor.<BR><BR>It is=
 therefore of critical importance that your software work well with=
 <BR>implementations that meet the basic compliance requirements without=
 any <BR>extensions.<BR><BR>As you may have noticed, STATUS does not accept=
 a wildcard. &nbsp;There is a <BR>reason for this; and that reason was not=
 stupidity on the part of the <BR>protocol designer. &nbsp;Please note the=
 following text in RFC 3501, section=
 <BR>6.3.10:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Unlike the=
 LIST command, the STATUS command is not guaranteed=
 to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be fast in its response.=
 &nbsp;Under certain circumstances, it can=
 be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;quite slow. &nbsp;In some=
 implementations, the server is obliged=
 to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;open the mailbox read-only=
 internally to obtain certain=
 status<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;information.=
 &nbsp;Also unlike the LIST command, the STATUS=
 command<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;does not accept=
 wildcards.<BR><BR>The entire design of the STATUS command was to make a=
 client implementor <BR>think "hmm, it does not scale to do a LIST followed=
 by a STATUS of each <BR>individual name, I need to think of alternative=
 strategies."<BR><BR>The bottom line is that you need to think of=
 alternative strategies in <BR>order to produce a quality IMAP client and=
 not an "also-ran".<BR><BR>On Tue, 31 May 2005, Simon Tyler wrote:<BR>&gt;=
 Whilst I understand that some servers may take a significant length of=
 <BR>&gt; time to retrieve the UIDVALIDITY\UIDNEXT values others do not=
 have this <BR>&gt; restriction. It also remains a fact that many IMAP=
 clients will do a <BR>&gt; STATUS for each and every mailbox so for those=
 clients it would be an <BR>&gt; improvement if this information could=
 (optionally) be included in the <BR>&gt; LIST response.<BR>&gt;<BR>&gt; In=
 our testing adding this sort sort of feature to the client and server=
 <BR>&gt; dramatically improved the synchronisation speed - the cost to our=
 server <BR>&gt; of getting the UIDVALIDATY\UIDNEXT being almost=
 nothing.<BR>&gt;<BR>&gt; Simon<BR>&gt;<BR>&gt;<BR>&gt; ---- Message from=
 mailto:&lt;[email-masked] Mark Crispin=
 &lt;[email-masked]&gt; at 31-May-2005 00:17:08 ------<BR>&gt; On=
 Tue, 31 May 2005, Simon Tyler wrote:<BR>&gt;&gt; A typical client will do=
 a<BR>&gt;&gt; LIST to obtain the list of folders and then later do a=
 STATUS on each<BR>&gt;&gt; folder to get information such as the=
 UIDVALIDITY. The cost of doing<BR>&gt;&gt; this is suprisingly high (about=
 200ms in general) caused simply by<BR>&gt;&gt; general network=
 latency.<BR>&gt;<BR>&gt; The cost of doing this can be even higher than=
 just that.<BR>&gt;<BR>&gt; There is no guarantee that a mail store can=
 return the UIDVALIDITY or<BR>&gt; UIDNEXT in a trivial amount of time.=
 &nbsp;A LIST that returns those values<BR>&gt; could easily take some=
 number of seconds per mailbox returned. &nbsp;That LIST<BR>&gt; command=
 returning UIDVALIDITY/UIDNEXT could take hours to complete!<BR><BR>-- Mark=
 --<BR><BR>http://staff.washington.edu/mrc<BR>Science does not emerge from=
 voting, party politics, or public debate.<BR>Si vis pacem, para=
 bellum.<BR><BR><BR></BLOCKQUOTE></FONT></body></html>

--==_08273053102769/PD.gordano.com==_--
--==_08273053102768/PD.gordano.com==_--

Date: Tue, 31 May 2005 07:52:23 +0000
From: Pawel Salek <[email-masked]>
Subject: Re: IMAP4 List Command Extensions
To: Simon Tyler <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On 05/31/2005 09:36:31 AM, Simon Tyler wrote:
> 
> 
> Whilst I understand that some servers may take a significant length  
> of time to retrieve the UIDVALIDITY\UIDNEXT values others do not have
> this restriction. It also remains a fact that many IMAP clients will
> do a STATUS for each and every mailbox so for those clients it would
> be an improvement if this information could (optionally) be included
> in the LIST response.
> 
> In our testing adding this sort sort of feature to the client and
> server dramatically improved the synchronisation speed - the cost to
> our server of getting the UIDVALIDATY\UIDNEXT being almost nothing.

If you really *insist* on fetching UIDVALIDITY, have you considered  
simply pipelining STATUS requests? This would reduce the latency as  
well and no standard change or a new extension would be required.  
Observe Mark's comments about STATUS performance remain valid: binding  
your  users to IMAP servers with specific behavior defeats the entire  
idea of standards and interoperability. I do not know good imap clients  
that unconditionally do STATUS on all the folders - and I probably  
would not like to use them either.

Pawel

> ---- Message from mailto:<[email-masked] Mark Crispin
> <[email-masked]> at 31-May-2005 00:17:08 ------
> 
> On Tue, 31 May 2005, Simon Tyler wrote:
> > A typical client will do a
> > LIST to obtain the list of folders and then later do a STATUS on
> each
> > folder to get information such as the UIDVALIDITY. The cost of doing
> 
> > this is suprisingly high (about 200ms in general) caused simply by
> > general network latency.
> 
> The cost of doing this can be even higher than just that.
> 
>  There is no guarantee that a mail store can return the UIDVALIDITY  
> or   UIDNEXT in a trivial amount of time.  A LIST that returns those   
> values   could easily take some number of seconds per mailbox  
> returned.  That  LIST  command returning UIDVALIDITY/UIDNEXT could  
> take hours to complete!

Date: Tue, 31 May 2005 00:47:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Simon Tyler <[email-masked]>
cc: [email-masked]
Subject: Re: IMAP4 List Command Extensions
Sender: [email-masked]

I'm not sure if I was unclear in my previous message.  The point that I 
attempted to make is that if you wish your client to interoperate with 
multiple servers, you can not assume that UIDVALIDITY/UIDNEXT can be 
obtained quickly.

It is an important characteristic of well-designed Internet protocol 
implementations that they consider a wide variety of other 
implementations.  This means, among other things, that you have to 
consider the limitations in other implementations even if your own 
implementation does not have that implementation.

One very large vendor is often heavily criticized because its software has 
many non-standard extensions that are implied to be part of the standard. 
Then, when competing software does not work due to it not having these 
non-standard extensions, the implication is that the competitor's software 
is broken.  This has led to ill feelings, and some of these problems have 
even been offered as evidence of illegal behavior by that vendor.

It is therefore of critical importance that your software work well with 
implementations that meet the basic compliance requirements without any 
extensions.

As you may have noticed, STATUS does not accept a wildcard.  There is a 
reason for this; and that reason was not stupidity on the part of the 
protocol designer.  Please note the following text in RFC 3501, section 
6.3.10:

       Unlike the LIST command, the STATUS command is not guaranteed to
       be fast in its response.  Under certain circumstances, it can be
       quite slow.  In some implementations, the server is obliged to
       open the mailbox read-only internally to obtain certain status
       information.  Also unlike the LIST command, the STATUS command
       does not accept wildcards.

The entire design of the STATUS command was to make a client implementor 
think "hmm, it does not scale to do a LIST followed by a STATUS of each 
individual name, I need to think of alternative strategies."

The bottom line is that you need to think of alternative strategies in 
order to produce a quality IMAP client and not an "also-ran".

On Tue, 31 May 2005, Simon Tyler wrote:
> Whilst I understand that some servers may take a significant length of 
> time to retrieve the UIDVALIDITY\UIDNEXT values others do not have this 
> restriction. It also remains a fact that many IMAP clients will do a 
> STATUS for each and every mailbox so for those clients it would be an 
> improvement if this information could (optionally) be included in the 
> LIST response.
>
> In our testing adding this sort sort of feature to the client and server 
> dramatically improved the synchronisation speed - the cost to our server 
> of getting the UIDVALIDATY\UIDNEXT being almost nothing.
>
> Simon
>
>
> ---- Message from mailto:<[email-masked] Mark Crispin <[email-masked]> at 31-May-2005 00:17:08 ------
> On Tue, 31 May 2005, Simon Tyler wrote:
>> A typical client will do a
>> LIST to obtain the list of folders and then later do a STATUS on each
>> folder to get information such as the UIDVALIDITY. The cost of doing
>> this is suprisingly high (about 200ms in general) caused simply by
>> general network latency.
>
> The cost of doing this can be even higher than just that.
>
> There is no guarantee that a mail store can return the UIDVALIDITY or
> UIDNEXT in a trivial amount of time.  A LIST that returns those values
> could easily take some number of seconds per mailbox returned.  That LIST
> command returning UIDVALIDITY/UIDNEXT could take hours to complete!

-- Mark --

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

Date: Tue, 31 May 2005 08:36:31 +0100
From: "Simon Tyler" <[email-masked]>
Subject: Re: IMAP4 List Command Extensions
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a MIME-encapsulated message

--==_07363109302704/PD.gordano.com==_
Content-Type: multipart/alternative; boundary="==_07363109302705/PD.gordano.com==_"

--==_07363109302705/PD.gordano.com==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 =20
Whilst I understand that some servers may take a significant length of time=
 to retrieve the UIDVALIDITY\UIDNEXT values others do not have this=
 restriction. It also remains a fact that many IMAP clients will do a=
 STATUS for each and every mailbox so for those clients it would be an=
 improvement if this information could (optionally) be included in the LIST=
 response.=20
 =20
In our testing adding this sort sort of feature to the client and server=
 dramatically improved the synchronisation speed - the cost to our server=
 of getting the UIDVALIDATY\UIDNEXT being almost nothing.=20
 =20
Simon=20
 =20

---- Message from mailto:<[email-masked] Mark Crispin=
 <[email-masked]> at 31-May-2005 00:17:08 ------=20

On Tue, 31 May 2005, Simon Tyler wrote:
> A typical client will do a=20
> LIST to obtain the list of folders and then later do a STATUS on each=20
> folder to get information such as the UIDVALIDITY. The cost of doing=20
> this is suprisingly high (about 200ms in general) caused simply by=20
> general network latency.

The cost of doing this can be even higher than just that.

There is no guarantee that a mail store can return the UIDVALIDITY or=20
UIDNEXT in a trivial amount of time.  A LIST that returns those values=20
could easily take some number of seconds per mailbox returned.  That LIST=20
command returning UIDVALIDITY/UIDNEXT could take hours to complete!

--==_07363109302705/PD.gordano.com==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style><!-- P{ margin-top:0;margin-bottom:0;} //=
 --></style></head><body><P>&nbsp;</P>
<P>Whilst I understand that some servers may take a significant length of=
 time to retrieve the UIDVALIDITY\UIDNEXT values others do not have this=
 restriction. It also remains a fact that many IMAP clients will do a=
 STATUS for each and every mailbox so for those clients it would be an=
 improvement if this information could (optionally) be included in the LIST=
 response.</P>
<P>&nbsp;</P>
<P>In our testing adding this sort sort of feature to the client and server=
 dramatically improved the synchronisation speed&nbsp;- the cost to our=
 server of getting the UIDVALIDATY\UIDNEXT being almost nothing.</P>
<P>&nbsp;</P>
<P>Simon</P>
<P>&nbsp;</P>
<P><FONT face=3DArial size=3D2><BR>---- Message from <A=
 href=3D"mailto:<[email-masked]">Mark Crispin=
 &lt;[email-masked]&gt;</A> at 31-May-2005 00:17:08 ------</P>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:=
 #000000 2px solid">On Tue, 31 May 2005, Simon Tyler wrote:<BR>&gt; A=
 typical client will do a <BR>&gt; LIST to obtain the list of folders and=
 then later do a STATUS on each <BR>&gt; folder to get information such as=
 the UIDVALIDITY. The cost of doing <BR>&gt; this is suprisingly high=
 (about 200ms in general) caused simply by <BR>&gt; general network=
 latency.<BR><BR>The cost of doing this can be even higher than just=
 that.<BR><BR>There is no guarantee that a mail store can return the=
 UIDVALIDITY or <BR>UIDNEXT in a trivial amount of time. &nbsp;A LIST that=
 returns those values <BR>could easily take some number of seconds per=
 mailbox returned. &nbsp;That LIST <BR>command returning=
 UIDVALIDITY/UIDNEXT could take hours to=
 complete!<BR><BR><BR></BLOCKQUOTE></FONT></body></html>

--==_07363109302705/PD.gordano.com==_--
--==_07363109302704/PD.gordano.com==_--

Date: Tue, 31 May 2005 00:17:08 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Simon Tyler <[email-masked]>
cc: [email-masked]
Subject: Re: IMAP4 List Command Extensions
Sender: [email-masked]

On Tue, 31 May 2005, Simon Tyler wrote:
> A typical client will do a 
> LIST to obtain the list of folders and then later do a STATUS on each 
> folder to get information such as the UIDVALIDITY. The cost of doing 
> this is suprisingly high (about 200ms in general) caused simply by 
> general network latency.

The cost of doing this can be even higher than just that.

There is no guarantee that a mail store can return the UIDVALIDITY or 
UIDNEXT in a trivial amount of time.  A LIST that returns those values 
could easily take some number of seconds per mailbox returned.  That LIST 
command returning UIDVALIDITY/UIDNEXT could take hours to complete!

Put another way, if your client requires that all remote mailboxes be 
synchronized in this way, you will find that it simply will not work in 
many environments.  You need to address the problem in another way.

Fortunately, it is generally not necessary to synchronize *all* mailboxes 
automatically.  Only a small number of mailboxes need to do this, while 
most other mailboxes are archives.  So, if you maintain a list of the 
small number of mailboxes you need to synchronize automatically, you can 
ignore those that do not need this.

Unfortunately, you can't use the IMAP "subscribe" feature to identify 
these mailboxes, because of certain poorly-written clients which abuse 
subscriptions.

-- Mark --

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

Date: Tue, 31 May 2005 08:06:27 +0100
From: "Simon Tyler" <[email-masked]>
Subject: IMAP4 List Command Extensions
To: <[email-masked]>
Sender: [email-masked]

This is a MIME-encapsulated message

--==_07062779602641/PD.gordano.com==_
Content-Type: multipart/alternative; boundary="==_07062779602642/PD.gordano.com==_"

--==_07062779602642/PD.gordano.com==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
 =20
Hi,=20
 =20
I was just reading your LIST Command Extensions Internet draft and have a=
 suggestion for some additions.=20
 =20
The company I work for (Gordano Ltd - http://www.gordano.com/=
 www.gordano.com) is in the process of writing our own IMAP client=
 transport to be used with our extsing IMAP server. We have noticed some=
 issues with the LIST response in particular. A typical client will do a=
 LIST to obtain the list of folders and then later do a STATUS on each=
 folder to get information such as the UIDVALIDITY. The cost of doing this=
 is suprisingly high (about 200ms in general) caused simply by general=
 network latency. If you are synchronising a large number of folders then=
 this quickly adds up.=20
 =20
We have added in a custom LIST response extension whereby the LIST response=
 includes additional information we require -UNDVALIDITY and UIDNEXT. In a=
 typical "no changes" case this vastly reduces the time a client is able to=
 sync in.=20
 =20
e.g.=20
 =20
S: * LIST (UIDVALIDITY 99999 UIDNEXT 99999) "/" "folder"=20
 =20
Clearly this could be extended to include all the STATUS fields. Similarly=
 the LIST comand itself could be extended to request the fields it=
 requires.=20
 =20
This is not ideal from our perspective - although we would like customers=
 of our client transport to also use our server, this is not always the=
 case and hence we would like to stick to established (or at least=
 proposed) standards. Would you consider adding into your draft such an=
 extension?=20
 =20
Simon

--==_07062779602642/PD.gordano.com==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style><!-- P{ margin-top:0;margin-bottom:0;} //=
 --></style></head><body><FONT face=3DArial size=3D2>
<P><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Hi,</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>I was just reading your LIST Command=
 Extensions Internet draft and have a suggestion for some=
 additions.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>The company I work for (Gordano Ltd - <A=
 href=3D"http://www.gordano.com/" target=3D_blank>www.gordano.com</A>) is=
 in the process of writing our own IMAP client transport to be used with=
 our extsing IMAP server. We have noticed some issues with the LIST=
 response in particular. A typical client will do a LIST to obtain the list=
 of folders and then later do a STATUS on each folder to get information=
 such as the UIDVALIDITY. The cost of doing this is suprisingly=
 high&nbsp;(about&nbsp;200ms&nbsp;in general)&nbsp;caused simply by general=
 network latency. If you are synchronising a large number of folders then=
 this quickly adds up.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>We have added in a custom LIST response=
 extension whereby the LIST response includes additional information we=
 require -UNDVALIDITY and UIDNEXT. In a typical "no changes" case this=
 vastly reduces the time a client is able to sync in.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>e.g.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>S:&nbsp;* LIST (UIDVALIDITY 99999 UIDNEXT=
 99999) "/" "folder"</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Clearly this could be extended to include=
 all the STATUS fields. Similarly the LIST comand itself could be extended=
 to request the fields it requires.</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>This is not ideal from our perspective -=
 although we would like customers of our client transport to also use our=
 server, this is not always the case and hence we would like to stick to=
 established (or at least proposed) standards. Would you consider adding=
 into your draft such an extension?</FONT></P>
<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>
<P><FONT face=3DArial size=3D2>Simon</FONT></P><BR><BR></FONT></body></html>

--==_07062779602642/PD.gordano.com==_--
--==_07062779602641/PD.gordano.com==_--

Date: Thu, 26 May 2005 21:21:08 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-2086upd-06
Sender: [email-masked]

Ken Murchison wrote:

> The table in section 5 lists the APPEND command twice.  I assume that 
> the second instance should be COPY instead of APPEND, since the former 
> requires the selected state.

Good catch.
Fixed in my copy.

Date: Thu, 26 May 2005 16:09:07 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: draft-ietf-imapext-2086upd-06
Sender: [email-masked]

The table in section 5 lists the APPEND command twice.  I assume that 
the second instance should be COPY instead of APPEND, since the former 
requires the selected state.

-- 
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: Thu, 26 May 2005 14:48:47 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: revision -04 to rfc2359bis
Sender: [email-masked]

Mark Crispin wrote:
> On Wed, 25 May 2005, Arnt Gulbrandsen wrote:
> 
>> Change (4) apparently affects COPYUID, which means that previously 
>> acceptable server code for COPY breaks:
>> printf( "%s OK [COPYUID %d %d:%d]\r\n", tag, validity, first, 
>> first+last-1 );
> 
> 
> OK, you've convinced me.  Draft -04 (attached) revokes change 4 and 
> alters the following explanation to the prohibitory text for APPENDUID:
>          This is because a client which does not support [MULTIAPPEND]
>          expects only a single UID and not a UID set.
> 
> Are we done now?

Hum.

-- 
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: Thu, 26 May 2005 12:24:41 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: revision -04 to rfc2359bis
Cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> Are we done now?

Hum from me.

And I'm still amazed at the speed of this.

Arnt

Date: Wed, 25 May 2005 17:50:53 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Cyrus Daboo <[email-masked]>
Subject: revision -04 to rfc2359bis
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-172342576-1117068653=:25491
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 25 May 2005, Arnt Gulbrandsen wrote:
> Change (4) apparently affects 
> COPYUID, which means that previously acceptable server code for COPY breaks:
> printf( "%s OK [COPYUID %d %d:%d]\r\n", tag, validity, first, first+last-1 );

OK, you've convinced me.  Draft -04 (attached) revokes change 4 and alters 
the following explanation to the prohibitory text for APPENDUID:
          This is because a client which does not support [MULTIAPPEND]
          expects only a single UID and not a UID set.

Are we done now?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-172342576-1117068653=:25491
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-04.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-04.txt

---1903383771-172342576-1117068653=:25491--

Date: Wed, 25 May 2005 14:47:47 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-crispin-imap-rfc2359bis-03.txt
Cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> --On May 24, 2005 4:18:13 PM -0700 Mark Crispin 
> <[email-masked]> wrote:
>> I'd like to get either a hum of concensus or a snarl of objection on 
>> this point.  Thanks.
>
> hum of approval from me.

Not from me, although I won't snarl either. Change (4) apparently 
affects COPYUID, which means that previously acceptable server code for 
COPY breaks:

printf( "%s OK [COPYUID %d %d:%d]\r\n", tag, validity, first, first+last-1 );

Change (4) seems superfluous anyway.

Little short on sleep today. Maybe I'm wrong?

Arnt

Date: Wed, 25 May 2005 08:38:15 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: draft-crispin-imap-rfc2359bis-03.txt
Sender: [email-masked]

Hi Mark,

--On May 24, 2005 4:18:13 PM -0700 Mark Crispin <[email-masked]> 
wrote:

>> I've uploaded draft -03 (and it's attached here).  I may have
>> overstepped my  boundaries by prohibiting all UID set ranges in which
>> the two values are  equal -- are there any objections to my having done
>> this?  This only applies  when both UIDPLUS and MULTIAPPEND are in
>> effect.
>
> I'd like to get either a hum of concensus or a snarl of objection on this
> point.  Thanks.

hum of approval from me.

-- 
Cyrus Daboo

Date: Wed, 25 May 2005 12:18:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-crispin-imap-rfc2359bis-03.txt
Sender: [email-masked]

Mark Crispin wrote:

> It was pointed out to me that it is possible for a server to send 
> "[APPENDUID 432 123:123]" as a response to a single APPEND, which 
> would confuse a client which doesn't implement RFC 3502.  This is 
> actually a problem introduced by the combination of RFC 2359 and RFC 
> 3502.
>
> I also observed that it used the RFC 2060 term "message set", which was
> replaced with "sequence set" in RFC 3501.  What's worse, "message set" 
> was used to refer to both RFC 3501 sequence sets and to the new 
> uid-set rule introduced in this document.
>
> I've uploaded draft -03 (and it's attached here).  I may have 
> overstepped my boundaries by prohibiting all UID set ranges in which 
> the two values are equal -- are there any objections to my having done 
> this?  This only applies when both UIDPLUS and MULTIAPPEND are in effect.

These changes are fine with me, as I've fixed "[COPYUID 12345 5:5]" in 
my server ;-).

Date: Tue, 24 May 2005 16:18:13 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-crispin-imap-rfc2359bis-03.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 May 2005, Mark Crispin wrote:
> I've uploaded draft -03 (and it's attached here).  I may have overstepped my 
> boundaries by prohibiting all UID set ranges in which the two values are 
> equal -- are there any objections to my having done this?  This only applies 
> when both UIDPLUS and MULTIAPPEND are in effect.

I'd like to get either a hum of concensus or a snarl of objection on this 
point.  Thanks.

-- Mark --

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

Date: Tue, 24 May 2005 16:08:04 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: draft-crispin-imap-rfc2359bis-03.txt
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-2009146749-1116976084=:13471
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

It was pointed out to me that it is possible for a server to send 
"[APPENDUID 432 123:123]" as a response to a single APPEND, which would 
confuse a client which doesn't implement RFC 3502.  This is actually a 
problem introduced by the combination of RFC 2359 and RFC 3502.

I also observed that it used the RFC 2060 term "message set", which was
replaced with "sequence set" in RFC 3501.  What's worse, "message set" was 
used to refer to both RFC 3501 sequence sets and to the new uid-set rule 
introduced in this document.

I've uploaded draft -03 (and it's attached here).  I may have overstepped 
my boundaries by prohibiting all UID set ranges in which the two values 
are equal -- are there any objections to my having done this?  This only 
applies when both UIDPLUS and MULTIAPPEND are in effect.

Here are the changes:

1) Add the following definition of UID set to the conventions:

    A "UID set" is similar to the [IMAP] sequence set; however, the "*"
    value for sequence number is not permitted.

2) Change all occurances of "message set" to "sequence set" or "UID set"
    as appropriate.

3) Expand the APPENDUID text in the MULTIAPPEND case to clarify that
    123:123 is prohibited:

       If the server also supports the [MULTIAPPEND] extension, and if
       multiple messages were appended in the APPEND command, then the
       second value is a UID set containing the UIDs assigned to
       the appended messages, in the order they were transmitted in the
       APPEND command.  This UID set may not contain extraneous
       UIDs or the symbol "*".

          Note: the UID set form of the APPENDUID response code MUST
          NOT be used if only a single message was appended.  In
          particular, a server MUST NOT send a range such as 123:123.

4) Same as (3), for the formal syntax of uid-range and the MULTIAPPEND
    extension to the formal syntax for append-uid:

    uid-range       = (uniqueid ":" uniqueid)
                      ; two non-equal uniqueid values and all
                      ; values between these two regards of order.
                      ; Example: 2:4 and 4:2 are equivalent.
                      ; These values MUST NOT be equal; e.g. 2:2
                      ; is not permitted.

    Servers which support [MULTIAPPEND] will have the following extension
    to the above rules:

    append-uid      =/ uid-set
                      ; only if multiple messages appended

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-2009146749-1116976084=:13471
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-03.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-03.txt

---1903383771-2009146749-1116976084=:13471--

Date: Tue, 24 May 2005 15:21:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: asking for last call on rfc2359bis document
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 24 May 2005, Arnt Gulbrandsen wrote:
> One example: IIRC there's nothing in base IMAP that requires the client to 
> parse sequence-set. For this reason, if 2359 hadn't made the issue moot, I 
> would have preferred COPYUID to use "nz-number *(SP nz-number)" like SEARCH 
> does.

IMHO, this is OK.  If the client supports 2359, it has to be able to parse 
sequence-set; if it doesn't, then the default
 	atom [SP 1*<any TEXT-CHAR except "]">]
rule in resp-text-code will ensure that the client doesn't get perturbed 
by any unsolicited APPENDUID/COPYUID.

If we could take a time machine and fix it, I would have insisted that 
APPENDUID and COPYUID be untagged responses instead of resp-text-code, and 
have an APPENDUID and COPYUID command to trigger those responses.  That's 
actually what I wanted, but I lost the battle and decided not to fight it 
further.

-- Mark --

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

Date: Tue, 24 May 2005 17:02:10 +0100
Subject: Re: asking for last call on rfc2359bis document
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Mark Crispin <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Tue May 24 12:05:42 2005, Arnt Gulbrandsen wrote:
> One example: IIRC there's nothing in base IMAP that requires the 
> client to parse sequence-set. For this reason, if 2359 hadn't made 
> the issue moot, I would have preferred COPYUID to use "nz-number 
> *(SP nz-number)" like SEARCH does.

Funnily enough, Alexey used almost the exact reverse argument to 
convince me that using set syntax was better for ESEARCH.

Anyway, I'm glad you raised this issue, as we cannot possibly let a 
draft go through without a pointless long-winded argument. :-)

In this case, copying multiple messages is very commonly copying a 
contiguous range - the most common example being the "sweep" of 
messages currently in the INBOX. This is more likely the more 
messages are copied, I suspect.

This in turn strongly suggests that sequence-set will be lower 
bandwidth - it is always lower or same bandwidth in any case. (It 
actually tends to be lower when it really is a sequence set, rather 
than a UID set, of course).

Moreover, set syntax is a valuable addition to a client's parser, as 
the lower bandwidth requirements inevitably mean less resource usage, 
and I strongly suspect that set syntax compresses better than a 
traditional text-based compression algorithm (perhaps one in the TLS 
layer) due to domain knowledge for the data involved.

Right, pointless argument over, RFC2359bis can go through to last 
call with a clean consience. :-)

Seriously, it all looks fine to me.

Dave.

Date: Tue, 24 May 2005 13:05:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: asking for last call on rfc2359bis document
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 24 May 2005, Arnt Gulbrandsen wrote:
>> Seriously, I like it. There's nothing I dislike that's fixable.
>
> Well, is there something that you dislike?

A couple of things, but 2359 has cast them in stone.

One example: IIRC there's nothing in base IMAP that requires the client 
to parse sequence-set. For this reason, if 2359 hadn't made the issue 
moot, I would have preferred COPYUID to use "nz-number *(SP nz-number)" 
like SEARCH does.

> This looks like a "let sleeping dogs lie" condition to me... :-)

I can certainly see the sense in that.

Arnt

Date: Tue, 24 May 2005 02:58:01 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: asking for last call on rfc2359bis document
Sender: [email-masked]

On Tue, 24 May 2005, Arnt Gulbrandsen wrote:
> Seriously, I like it. There's nothing I dislike that's fixable.

Well, is there something that you dislike?

> Although... how about adding a note that client authors SHOULD NOT send * in 
> the UID EXPUNGE commands?

I'm not sure why this would be needed.  I agree that "UID EXPUNGE *" does 
not seem to me to be particularly useful, with the possible exception of 
"UID EXPUNGE 1:*".  It's certainly dangerous.

On the other hand, RFC 2359 allowed it, so it can't be removed.  What's 
more, I don't want to have a situation, 5-10 years from now, of someone 
asking "why did you say such a stupid thing" and demanding an update to 
the document.

This looks like a "let sleeping dogs lie" condition to me... :-)

-- Mark --

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

Date: Tue, 24 May 2005 10:31:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: asking for last call on rfc2359bis document
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> I believe that the -02 draft of the rfc2359bis document addresses all 
> the comments that I have received so far:
>   ftp://ftp.ietf.org/internet-drafts/draft-crispin-imap-rfc2359bis-02.txt
> and consequently I think that work on it is finished.
>
> Please give it one last review, and if all is well I'll ask our 
> esteemed AD to bring it up to the IESG.  Thanks!

I am amazed, I am astonished. IMAP drafts just aren't supposed to move 
so quickly ;)

Seriously, I like it. There's nothing I dislike that's fixable.

Although... how about adding a note that client authors SHOULD NOT send 
* in the UID EXPUNGE commands?

Arnt

Date: Mon, 23 May 2005 15:45:21 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: asking for last call on rfc2359bis document
Organization: Networks & Distributed Computing
Sender: [email-masked]

I believe that the -02 draft of the rfc2359bis document addresses all the 
comments that I have received so far:
   ftp://ftp.ietf.org/internet-drafts/draft-crispin-imap-rfc2359bis-02.txt
and consequently I think that work on it is finished.

Please give it one last review, and if all is well I'll ask our esteemed 
AD to bring it up to the IESG.  Thanks!

-- Mark --

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

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'IMAP4 ACL extension' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Mon, 23 May 2005 17:33:11 -0400
Sender: [email-masked]

The IESG has received a request from the Internet Message Access Protocol 
Extension WG to consider the following document:

- 'IMAP4 ACL extension '
   <draft-ietf-imapext-2086upd-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-06-06.

This document is known to not pass IDNits checking.  That will be
corrected before IESG evaluation.  Other AD evaluation comments are
visible in the ID Tracker.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-06.txt

Date: Sun, 22 May 2005 16:06:57 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: rfc2086upd nit
Sender: [email-masked]

Alexey Melnikov wrote:

> Mark Crispin wrote:
>
>> The statement:
>>
>>    Except as noted otherwise, all alphabetic characters are
>>    case-insensitive.  The use of upper or lower case characters to
>>    define token strings is for editorial clarity only.  Implementations
>>    MUST accept these strings in a case-insensitive fashion.
>>
>> in the Formal Syntax is redundant.  RFC 2234 already requires this, 
>> and the RFC 3501 Formal Syntax emphasizes this point and others which 
>> are of equal importance.
>
> IMHO, this is one of those rules which is easy to forget (I've made 
> such mistake with IMAP keywords once).

Just to emphasize this I've changed capitalization in several examples.

Date: Sun, 22 May 2005 16:01:31 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Mark Crispin <[email-masked]>
Subject: Re: rfc2086upd nit
Sender: [email-masked]

Mark Crispin wrote:

> The statement:
>
>    Except as noted otherwise, all alphabetic characters are
>    case-insensitive.  The use of upper or lower case characters to
>    define token strings is for editorial clarity only.  Implementations
>    MUST accept these strings in a case-insensitive fashion.
>
> in the Formal Syntax is redundant.  RFC 2234 already requires this, 
> and the RFC 3501 Formal Syntax emphasizes this point and others which 
> are of equal importance.

IMHO, this is one of those rules which is easy to forget (I've made such 
mistake with IMAP keywords once).

> I recommend either omitting this paragraph entirely, or duplicating 
> all of the text that appears in the RFC 3501 Formal Syntax 
> introduction.  I think that the first of these choices is better.

Does anybody else has an opinion on that?

Alexey

Date: Fri, 20 May 2005 13:31:23 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: rfc2086upd nit
Organization: Networks & Distributed Computing
Sender: [email-masked]

The statement:

    Except as noted otherwise, all alphabetic characters are
    case-insensitive.  The use of upper or lower case characters to
    define token strings is for editorial clarity only.  Implementations
    MUST accept these strings in a case-insensitive fashion.

in the Formal Syntax is redundant.  RFC 2234 already requires this, and 
the RFC 3501 Formal Syntax emphasizes this point and others which are of 
equal importance.

I recommend either omitting this paragraph entirely, or duplicating all of 
the text that appears in the RFC 3501 Formal Syntax introduction.  I think 
that the first of these choices is better.

-- Mark --

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

Date: Fri, 20 May 2005 12:46:42 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: updated (-01) rfc2359bis
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-1035889917-1116618402=:14865
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

OK, I think that I have addressed your nits and those sent to me in 
private email by a few other people in draft -02 which I've just sent to 
the I-D repository.

It's attached to this message too.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-1035889917-1116618402=:14865
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-02.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-02.txt

---1903383771-1035889917-1116618402=:14865--

From: "Scott Hollenbeck" <[email-masked]>
To: "'Pete Resnick'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Fri, 20 May 2005 15:39:28 -0400
Sender: [email-masked]

> That said: If you are willing to go ahead with the Last Call 
> as-is, great. If you still insist on the changes before 
> issuing the Last Call, let us know and obviously the WG will 
> have Alexey make the changes and submit the new document in 
> the next day or two. In the meanwhile I will start the 
> process discussion (starting with the IETF Chair, up to and 
> including appeal). In either case, let us know one final time 
> how you want to proceed.

Pete and I had a chat by phone to talk through next steps.  I agree that my
review did not uncover any significant issues with the protocol itself, so I
have agreed to issue the last call once an "in progress" update is
available.  Pete and I have agreed that some of the issues may be left for
discussion with the community.  The unresolved issues and remaining
questions will be identified in the review request sent to the community.
Edits, including IDNits corrections, will be made in parallel with the last
call.

We believe this is a reasonable compromise.  Anyone who believes otherwise
should speak now.

-Scott-

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-06.txt
Date: Fri, 20 May 2005 15:38:17 -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 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-2086upd-06.txt
	Pages		: 0
	Date		: 2005-5-20
	
The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP) permits mailbox access control
   lists to be retrieved and manipulated through the IMAP protocol.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Fri, 20 May 2005 14:37:10 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: updated (-01) rfc2359bis
Sender: [email-masked]

Hi Mark,
Some formal syntax nits, plus one possible security issue:

--On Thursday, May 19, 2005 14:35 -0700 Mark Crispin 
<[email-masked]> wrote:

> Please review.  I'm hoping that there are no objections to this update
> and we can get through a quick last-call and submission to the IESG as
> reflecting WG concensus.

Can you please add the new capability string explicitly to the Formal 
Syntax:

  capability  =/  "UIDPLUS"

'nz_number' should be 'nz-number'.

For consistency I would suggest replacing the underscores in the resp_* 
syntax elements with dashes.

Also, the new response codes should be shown as properly extending the IMAP 
syntax, and should include UIDNOTSTICKY which is currently not defined:

  response-text-code  =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"

'uid-number' (used in 'uid-range' definition) is not defined anywhere. 
Shouldn't it be 'uniqueid'?

Security issue: it is possible to have a mailbox with permissions set so 
that a user can write to it (i.e. do COPY or APPEND) but cannot read it 
(i.e. SELECT/EXAMINE) - this would be something like a 'drop-box' In such 
cases shouldn't the COPYUID and APPENDUID responses be suppressed to avoid 
exposing information that the user would not otherwise be able to access?

-- 
Cyrus Daboo

From: [email-masked]
Cc: Scott Hollenbeck <[email-masked]>, [email-masked]
Date: Fri, 20 May 2005 10:53:02 -0700 (PDT)
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
To: Pete Resnick <[email-masked]>
Sender: [email-masked]

> On 5/19/05 at 7:39 PM -0400, Scott Hollenbeck wrote:

> >Clarification of the extension model being used (the ABNF import
> >discussion) is not an editorial issue.  It's directly related to the
> >normative reference to RFC 2234.

> There is no technical issue with regard to reference to RFC 2234. The
> ABNF in the document is correct and is correctly used as per that
> specification. The only question is whether:

>     Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>     Non-terminals referenced but not defined below are as defined by
>     [IMAP4].

> is clear. (Specifically, whether the word "modified" is correct and
> whether it is better to reference "IMAP4" or "IMAP".) None of this is
> technical in nature. There is no technical interpretation of the
> document that could be confused whether or not these corrections are
> made. (That an ABNF validator must be used in a particular way is not
> germane to the technical correctness of this specification. The only
> "normative reference" to 2234 is that you won't be able to figure out
> the syntax without also reading and understanding 2234.) The change
> requested is only an editorial objection to the clarity of a comment.

I agree 100%.

> >Whether or not this document updates 3501 is not an editorial issue.

> The contents of an "Updates" header in an RFC are subject to:

> ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt

> That seems to me very much an editorial issue. Whether this document
> is technically correct does not depend on the contents of that
> particular field in the RFC template. At most, the current text of
> "<<3501?>>" indicates that the editor was not sure whether this
> qualified as an update under those instructions. (My read of the
> instructions is that it does qualify as an update.)

I concur with this assessment, however, in the final analysis, the
determination of what constitutes an update is properly something the IESG
needs to decide.

> No technical
> review of this document will be in any way changed if that text is
> changed. It is editorial only.

> >The issue of "MAY" vs. "may" vs. a synonym is not an editorial
> >issue.  It's directly related to the normative reference to RFC 2119.

> Neither of the examples you pointed out make one iota of difference
> in the technical interpretation of the document. And it certainly has
> nothing to do with the 2119 reference: In neither case is a
> capitalized imperative used in a way that it shouldn't. In neither
> case would the use of an imperative change the *technical*
> interpretation of the text. This is strictly an editorial objection,
> that use of the non-imperative English word "may" is an inconsistent
> usage, especially in places where the imperatives are used.

Agreed as well.

> And I am fully aware that we have now spent two days on this already.
> But this is now an "in principle" discussion that I would like
> resolved, other than its effect on this particular document. My
> contention is that the IESG should not be requiring editorial and
> stylistic flubs to be cleaned up prior to Last Call. It's an utter
> waste of the IESG's time and unnecessarily delays the documents
> progression. The IESG is free to make stylistic and editorial
> comments to the editor, and these should be fixed before RFC
> publication to be sure. But to not clean these things up in parallel
> with the Last Call is IMO a problem with the review process that
> needs to be fixed. And at this point, I'm perfectly willing to make
> an appeal on this point (and obviously recuse myself from the IAB
> decision if it gets that far). But one way or the other, I'd like
> this particular process point clarified for the future.

I note in passing that a similar situation used to exist in regards to IESG
evaluations. An IESG member who found an editorial nit in a document either had
to file a DISCUSS for no good purpose or let the nit pass along with the very
real possibility that it would not get fixed prior to publication. (There were
several cases where this in fact happened, one sufficiently severe that a
revised version of a document had to be produced almost immediately.) 

The ability to create a set of nonblocking comments for the RFC Editor was
added to deal with this. I suggest that this mechanism is the appropriate one
to use to deal with all of these - editorial issues should be recorded
and dealt with either through opportunistic correction as part of a revised
version being published or by the RFC Editor.

I don't know whether the datatracker lets ADs add RFC Editor notes prior to a
ballot being created, but if not it should. (When I was an AD I used a
note-taking tool called Tinderbox to track these sorts of things, but that was
just me; it really should be incorporated into the overall workflow mechanism.)

> That said: If you are willing to go ahead with the Last Call as-is,
> great. If you still insist on the changes before issuing the Last
> Call, let us know and obviously the WG will have Alexey make the
> changes and submit the new document in the next day or two. In the
> meanwhile I will start the process discussion (starting with the IETF
> Chair, up to and including appeal). In either case, let us know one
> final time how you want to proceed.

Either way sounds like a good plan to me.

				Ned

Date: Fri, 20 May 2005 10:53:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Scott Hollenbeck <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

On Thu, 19 May 2005, Pete Resnick wrote:
> There is no technical issue with regard to reference to RFC 2234. The ABNF in 
> the document is correct and is correctly used as per that specification. The 
> only question is whether:
>   Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>   Non-terminals referenced but not defined below are as defined by
>   [IMAP4].
> is clear. (Specifically, whether the word "modified" is correct and whether 
> it is better to reference "IMAP4" or "IMAP".)

I now understand the problem.

Without arguing any of your other points, the "as modified by [IMAP4]" is 
wrong.  It's a remnant of something which is now moot.

The original text in RFC 2086 was "The following syntax specification uses 
the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] as 
modified by [IMAP4]."

RFC 2060 inherited ABNF from RFC 822.  RFC 2234 obviously did not exist 
when RFC 2060 was issued.  RFC 822 had a "#" construct which indicated 
tokens separated by one or more commas; for example,
 	#("a" / "b" / "c")
could parse
 	b,c,,,,a

RFC 2060 modified the "#" construct so that it indicated tokens separated 
by one (and only one!) space; for example:
 	#("a" / "b" / "c")
could parse
 	b c a

RFC 2234 abolished the "#" construct entirely.  In modern times, the way 
that you would do the RFC 822 style "#" is with (assuming a definition of 
abc = "a" / "b" / "c"):
 	abc *(1*(0x2c) abc)
and the way that you would do the RFC 2060 style "#" is with
 	abc *(SP abc)

As both RFC 822 and RFC 2060 are obsolete, and that the current [IMAP] 
specification (RFC 3501) does not modify ABNF in any way, the text "as 
modified by [IMAP4]" is superfluous and should be removed.

-- Mark --

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

Date: Thu, 19 May 2005 17:50:08 -0700
To: "Scott Hollenbeck" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Cc: <[email-masked]>
Sender: [email-masked]

On 5/19/05 at 7:39 PM -0400, Scott Hollenbeck wrote:

>Clarification of the extension model being used (the ABNF import 
>discussion) is not an editorial issue.  It's directly related to the 
>normative reference to RFC 2234.

There is no technical issue with regard to reference to RFC 2234. The 
ABNF in the document is correct and is correctly used as per that 
specification. The only question is whether:

    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
    Non-terminals referenced but not defined below are as defined by
    [IMAP4].

is clear. (Specifically, whether the word "modified" is correct and 
whether it is better to reference "IMAP4" or "IMAP".) None of this is 
technical in nature. There is no technical interpretation of the 
document that could be confused whether or not these corrections are 
made. (That an ABNF validator must be used in a particular way is not 
germane to the technical correctness of this specification. The only 
"normative reference" to 2234 is that you won't be able to figure out 
the syntax without also reading and understanding 2234.) The change 
requested is only an editorial objection to the clarity of a comment.

>Whether or not this document updates 3501 is not an editorial issue.

The contents of an "Updates" header in an RFC are subject to:

ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt

That seems to me very much an editorial issue. Whether this document 
is technically correct does not depend on the contents of that 
particular field in the RFC template. At most, the current text of 
"<<3501?>>" indicates that the editor was not sure whether this 
qualified as an update under those instructions. (My read of the 
instructions is that it does qualify as an update.) No technical 
review of this document will be in any way changed if that text is 
changed. It is editorial only.

>The issue of "MAY" vs. "may" vs. a synonym is not an editorial 
>issue.  It's directly related to the normative reference to RFC 2119.

Neither of the examples you pointed out make one iota of difference 
in the technical interpretation of the document. And it certainly has 
nothing to do with the 2119 reference: In neither case is a 
capitalized imperative used in a way that it shouldn't. In neither 
case would the use of an imperative change the *technical* 
interpretation of the text. This is strictly an editorial objection, 
that use of the non-imperative English word "may" is an inconsistent 
usage, especially in places where the imperatives are used.

>So what now?  I want the document updated to address these three 
>issues at a minimum before I request a last call.

I would really like to insist that the Last Call be issued before 
another draft is done. I obviously have no objection to these (like 
the other editorial) changes being done as a post-Last-Call edit, as 
that can be run in parallel and will not be blocking the process from 
moving forward.

And I am fully aware that we have now spent two days on this already. 
But this is now an "in principle" discussion that I would like 
resolved, other than its effect on this particular document. My 
contention is that the IESG should not be requiring editorial and 
stylistic flubs to be cleaned up prior to Last Call. It's an utter 
waste of the IESG's time and unnecessarily delays the documents 
progression. The IESG is free to make stylistic and editorial 
comments to the editor, and these should be fixed before RFC 
publication to be sure. But to not clean these things up in parallel 
with the Last Call is IMO a problem with the review process that 
needs to be fixed. And at this point, I'm perfectly willing to make 
an appeal on this point (and obviously recuse myself from the IAB 
decision if it gets that far). But one way or the other, I'd like 
this particular process point clarified for the future.

That said: If you are willing to go ahead with the Last Call as-is, 
great. If you still insist on the changes before issuing the Last 
Call, let us know and obviously the WG will have Alexey make the 
changes and submit the new document in the next day or two. In the 
meanwhile I will start the process discussion (starting with the IETF 
Chair, up to and including appeal). In either case, let us know one 
final time how you want to proceed.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 20 May 2005 16:38:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: "'Pete Resnick'" <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>>However, this, like the other comments Scott made, is strictly 
>>editorial. None of these things change the technical meaning of the 
>>spec and should not be required to be changed before IETF last call. 
>>I really do not want to see the IETF last call delayed waiting for 
>>another ID. I would like this one last called.
>>    
>>
>
>Most of the comments I provided were indeed editorial in nature.  Except for
>these:
>
>Clarification of the extension model being used (the ABNF import discussion)
>is not an editorial issue.  It's directly related to the normative reference
>to RFC 2234.  Note: The IESG recently approved a replacement for 2234,
>draft-crocker-abnf-rfc2234bis.  It's in the RFC Editor queue.  The reference
>might need to be updated, but we can leave that for later.
>  
>
Ok.

>Whether or not this document updates 3501 is not an editorial issue.  That
>question should be removed before the community is asked to review the
>document.
>  
>
I agree.

>The issue of "MAY" vs. "may" vs. a synonym is not an editorial issue.  It's
>directly related to the normative reference to RFC 2119.
>  
>
Sure.

>So what now?  I want the document updated to address these three issues at a
>minimum before I request a last call.
>
I suggest that I submit a new revision right now which can be Last 
Called. While this is being done I will fix ID nits.

>  The others can slide for now, but
>they will have to be addressed before I bring the document to the IESG for
>review -- wrap 'em up with whatever else might come out of the last call.
>IDnits issues can wait until after last call, too, but they will need to be
>addressed before IESG evaluation.
>  
>
Ok.

Date: Thu, 19 May 2005 18:49:24 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: updated (-01) rfc2359bis 
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 19 May 2005, Philip Guenther wrote:
> Hmm, the syntax for UID EXPUNGE no longer permits '*' in the uid-set.

Good catch.  That's unintentional, and a bug.  Although I agree with you 
that "*" is a remarkably bad thing to use with UID EXPUNGE, it was 
permitted in RFC 2359 and should in the update since otherwise it's an 
incompatible change.

I'll change the uid-expunge rule to use sequence-set instead of uid-set in 
draft -02.

Thanks!

-- Mark --

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

To: Mark Crispin <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: updated (-01) rfc2359bis 
Date: Thu, 19 May 2005 18:43:59 -0700
Sender: [email-masked]

Mark Crispin <[email-masked]> writes:
>Please review.  I'm hoping that there are no objections to this update and 
>we can get through a quick last-call and submission to the IESG as 
>reflecting WG concensus.

Hmm, the syntax for UID EXPUNGE no longer permits '*' in the uid-set.
While this makes sense given the purpose of the command, it should be
mentioned as a change somewhere.  (Is a server that accepts '*'
non-compliant or does it just become a GIGO case?)

Philip Guenther

From: "Scott Hollenbeck" <[email-masked]>
To: "'Pete Resnick'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Thu, 19 May 2005 19:39:17 -0400
Sender: [email-masked]

> However, this, like the other comments Scott made, is strictly 
> editorial. None of these things change the technical meaning of the 
> spec and should not be required to be changed before IETF last call. 
> I really do not want to see the IETF last call delayed waiting for 
> another ID. I would like this one last called.

Most of the comments I provided were indeed editorial in nature.  Except for
these:

Clarification of the extension model being used (the ABNF import discussion)
is not an editorial issue.  It's directly related to the normative reference
to RFC 2234.  Note: The IESG recently approved a replacement for 2234,
draft-crocker-abnf-rfc2234bis.  It's in the RFC Editor queue.  The reference
might need to be updated, but we can leave that for later.

Whether or not this document updates 3501 is not an editorial issue.  That
question should be removed before the community is asked to review the
document.

The issue of "MAY" vs. "may" vs. a synonym is not an editorial issue.  It's
directly related to the normative reference to RFC 2119.

So what now?  I want the document updated to address these three issues at a
minimum before I request a last call.  The others can slide for now, but
they will have to be addressed before I bring the document to the IESG for
review -- wrap 'em up with whatever else might come out of the last call.
IDnits issues can wait until after last call, too, but they will need to be
addressed before IESG evaluation.

-Scott-

Date: Thu, 19 May 2005 15:51:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Organization: Networks & Distributed Computing
Sender: [email-masked]

[Resending this message to the list as it got misdirected...]

On Mon, 16 May 2005, Dave Cridland wrote:
> My immediate thought is that Message-Id is intended to serve this kind of 
> purpose already, and any technical argument against it must also be 
> applicable to any new header.

The arguments, such as they were, were IMHO spurious; the claim was that 
it was too easy to have false matches.

> In addition, a new header wouldn't be in 
> ENVELOPE.

I don't think that this is necessary or desirable.  Since the primary 
purpose is for synchronization/location, I would think that you'd use 
SEARCH to locate it before fetching any envelopes.

> A possibly better solution might be to provide message-id search criteria 
> support.

Already in IMAP: SEARCH HEADER Message-ID text

-- Mark --

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

Date: Thu, 19 May 2005 14:35:27 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: updated (-01) rfc2359bis
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-1329043306-1116538527=:30530
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Based on the comments I've received, I've updated my proposed rfc2359bis 
document on the I-D repository.  A copy is attached to this message.

Please review.  I'm hoping that there are no objections to this update and 
we can get through a quick last-call and submission to the IESG as 
reflecting WG concensus.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-1329043306-1116538527=:30530
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-01.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-01.txt

---1903383771-1329043306-1116538527=:30530--

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Meeting in Paris
Date: Thu, 19 May 2005 10:35:14 -0700
Sender: [email-masked]

I think we should have an IMAPEXT meeting in Paris to push documents 
forward and twist peoples' arms into doing reviews.  I'll schedule one 
and start collecting agenda items.  Document editors, please let me 
know if you can make it and what to discuss for your drafts.

Lisa

Date: Thu, 19 May 2005 10:01:24 -0400
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: RFC 2359bis
Sender: [email-masked]

Mark,

A couple of comments.

    The added facilities of the features in UIDPLUS are optimizations;
    clients can provide the same functionality, albeit less efficiently,
    by using facilities in the base protocol.

I am being extremely, perhaps even pathologically, nitpicking here but I 
question whether this is strictly true.  Suppose that two client sessions 
APPEND single identical messages to a mailbox more or less at the same 
time.  In such a case, there is likely to be nothing exposed through IMAP 
that can distinguish the two messages other than their UIDs.  Now, one 
might say that if the messages are identical it hardly matters if a client 
cannot reliably identify the one that it appended.  But suppose further 
that each client chooses to immediately delete its newly appended 
message.  If, using discovery, each client happens to identify the same 
copy of the message as its own then a copy of the message could be 
unintentionally left behind.

There is an extraneous word ("is") in the line:

       a message either does not have the \Deleted flag set or is has a

Pete Maclean

At 08:50 PM 5/18/2005, Mark Crispin wrote:
>As promised, I have written my proposed revision to RFC 2359.  I've sent 
>it to the I-D respository, but attached is a copy if you want to get an 
>early look.
>
>I think that I have addressed all of Alexey's concerns (and I hope Alexey 
>will point out if I haven't).  Please note that this is a first draft and 
>so will probably need some editorial revision.
>
>-- Mark --
>
>http://staff.washington.edu/mrc
>Science does not emerge from voting, party politics, or public debate.
>Si vis pacem, para bellum.
>

Date: Thu, 19 May 2005 09:52:53 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked], Scott Hollenbeck <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Hi Pete,

--On May 19, 2005 6:29:12 AM -0700 Pete Resnick <[email-masked]> 
wrote:

> The purpose here is not to be clear to people who want to validate ABNF;
> they are not the audience for this document. The purpose here is to be
> clear to people who want to implement IMAP using the ABNF. If this needs
> fixing, perhaps the language I used in the CATENATE document would be
> useful:
>
>     The following syntax specification uses the Augmented Backus-Naur
>     Form (ABNF) [7] notation.  Elements not defined here can be found in
>     the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
>     [8] specifications.
>
> However, this, like the other comments Scott made, is strictly editorial.
> None of these things change the technical meaning of the spec and should
> not be required to be changed before IETF last call. I really do not want
> to see the IETF last call delayed waiting for another ID. I would like
> this one last called.

One thing to bear in mind with the CATENATE description - the ordering of 
'import' of ABNF from IMAP [1] and IMAP ABNF [8] is important. Yes it 
should be obvious that definitions IMAP ABNF replace those in IMAP, but 
maybe this should be explicit. As an example, here is what I had in 
ANNOTATE:

   Non-terminals referenced but not defined below are as defined by
   [RFC3501] with the new definitions in [ABNFEXT] superceding those in
   [RFC3501].

Combining this with your's:

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) [7] notation.  Elements not defined here can be found in
    the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
    [8] specifications, with the new definitions in IMAP ABNF [8] 
superceding
    those in IMAP [1].

I agree with you that this is only an editorial change and should not 
affect last call status.

-- 
Cyrus Daboo

Date: Thu, 19 May 2005 06:29:12 -0700
To: Lisa Dusseault <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Cc: Mark Crispin <[email-masked]>, [email-masked], Scott Hollenbeck <[email-masked]>
Sender: [email-masked]

On 5/18/05 at 3:54 PM -0700, Lisa Dusseault wrote:

>Seems to me that the text
>
>    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>    Non-terminals referenced but not defined below are as defined by
>    [IMAP4].
>
>is slightly misleading if not incorrect, because as Philip points 
>out IMAP4 doesn't modify ABNF itself.

Fair enough. However:

>The paragraph could be clearer for people who want to validate the 
>ABNF.  It could read:
>
>    Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
>    defined in [IMAP4].  The IMAP4 ABNF should be imported first before
>    attempting to validate these rules.

The purpose here is not to be clear to people who want to validate 
ABNF; they are not the audience for this document. The purpose here 
is to be clear to people who want to implement IMAP using the ABNF. 
If this needs fixing, perhaps the language I used in the CATENATE 
document would be useful:

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) [7] notation.  Elements not defined here can be found in
    the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
    [8] specifications.

However, this, like the other comments Scott made, is strictly 
editorial. None of these things change the technical meaning of the 
spec and should not be required to be changed before IETF last call. 
I really do not want to see the IETF last call delayed waiting for 
another ID. I would like this one last called.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

Date: Thu, 19 May 2005 06:23:01 -0700
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Cc: Scott Hollenbeck <[email-masked]>, [email-masked]
Sender: [email-masked]

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Thu, 19 May 2005 07:41:16 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 10:30 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> On Wed, 18 May 2005, Scott Hollenbeck wrote:
> >> In particular, I fail to understand how the ABNF parsing can
> >> be done any other way than starting with the ABNF from the
> >> base specification and then following with the ABNF from
> >> whatever specification is extending the base specification.
> > I've identified the sequence of improperly combined ABNF 
> rules that can
> > cause parser failure.  I agree that the sequence you 
> described above is what
> > MUST happen to ensure that the combined ABNF is valid.  
> I've been trying to
> > say that I don't believe that the text makes this sequence clear.
> 
> OK, I think I'm starting to understand.  So the ABNF is fine, and the 
> text introducing the ABNF is broken.  Correct?

Correct.  My original suggestion to change the ABNF was mistaken.

-Scott-

Date: Thu, 19 May 2005 11:31:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>, "'Pete Resnick'" <[email-masked]>
CC: [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>>-----Original Message-----
>>From: Pete Resnick [mailto:[email-masked]] 
>>Sent: Wednesday, May 18, 2005 5:25 PM
>>To: Scott Hollenbeck
>>Cc: 'Mark Crispin'; [email-masked]
>>Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
>>
>>On 5/17/05 at 6:11 PM -0400, Scott Hollenbeck wrote:
>>
>>    
>>
>>>>On Tue, 17 May 2005, Scott Hollenbeck wrote:
>>>>        
>>>>
>>>>>I'd prefer to see an ABNF comment like this if you want to do 
>>>>>something like that:
>>>>>;;capability     = <defined in [IMAP]>
>>>>>This makes it clear that a parser shouldn't try to parse the 
>>>>>incomplete rule.
>>>>>          
>>>>>
>>>>If this is done, will you then be content with the =/ definitions?
>>>>        
>>>>
>>>Yes.  I now understand the intent and believe that a little bit of 
>>>explicit clarification is all that's needed to help others avoid the 
>>>mistake I made in trying to parse the ABNF by itself.
>>>      
>>>
>>Scott, I've got to say that I really object to this 
>>silliness. There is *no* ambiguity whatsoever if you are 
>>implementing an IMAP client or server because you *must* 
>>implement 3501. This is only a problem if you are a blind 
>>reader who is not doing an implementation. The "=/" is 
>>perfectly clear that you're going to have to look for the 
>>original terminal elsewhere.
>>
>>Alexey, I would ask that you not make this change.
>>    
>>
>
>Sorry, Pete, but I disagree completely that this is silliness.  The complete
>ABNF specification will be invalid if not constructed by merging rules with
>those in 3501 in a very particular way.  The method needed to form a valid,
>complete ABNF specification is NOT clear in the draft as written.  For
>example:
>
>;; from 2086upd
>capability      =/ rights-capa
>;; from 3501
>capability      = ("AUTH=" auth-type) / atom
>
>will not parse.  The rules MUST be combined in this order:
>
>;; from 3501
>capability      = ("AUTH=" auth-type) / atom
>;; from 2086upd
>capability      =/ rights-capa
>
>Be clear now or be clear later.  I can guarantee that this situation will be
>(and has been) noted by other reviewers.
>  
>
I have not changed "=/" to "=", but I've added a clarifying statement 
about productions defined in RFC 3501.

Date: Wed, 18 May 2005 19:29:32 -0700
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Scott Hollenbeck wrote:
>> In particular, I fail to understand how the ABNF parsing can
>> be done any other way than starting with the ABNF from the
>> base specification and then following with the ABNF from
>> whatever specification is extending the base specification.
> I've identified the sequence of improperly combined ABNF rules that can
> cause parser failure.  I agree that the sequence you described above is what
> MUST happen to ensure that the combined ABNF is valid.  I've been trying to
> say that I don't believe that the text makes this sequence clear.

OK, I think I'm starting to understand.  So the ABNF is fine, and the 
text introducing the ABNF is broken.  Correct?

> By the way, this reminds of something else: I think that what I said
> yesterday about this document updating 3501 is incorrect.  I originally
> thought that the ABNF was intended to replace parts of what's in 3501, but
> as a result of this discussion I now understand that I was mistaken.  If
> someone can implement 3501 without being required to consult this spec then
> there's no update involved?

I agree that this document does not update 3501.  As with other IMAP 
extensions documents, this document extends the protocol described in 3501 
with optional facilities, which can be disregarded by an implementor of 
3501 who is not interested in those facilities.

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 22:15:37 -0400
Sender: [email-masked]

> In particular, I fail to understand how the ABNF parsing can 
> be done any other way than starting with the ABNF from the 
> base specification and then following with the ABNF from 
> whatever specification is extending the base specification.

I've identified the sequence of improperly combined ABNF rules that can
cause parser failure.  I agree that the sequence you described above is what
MUST happen to ensure that the combined ABNF is valid.  I've been trying to
say that I don't believe that the text makes this sequence clear.

By the way, this reminds of something else: I think that what I said
yesterday about this document updating 3501 is incorrect.  I originally
thought that the ABNF was intended to replace parts of what's in 3501, but
as a result of this discussion I now understand that I was mistaken.  If
someone can implement 3501 without being required to consult this spec then
there's no update involved?

-Scott-

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>, "'Lisa Dusseault'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 22:15:37 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 7:00 PM
> To: Lisa Dusseault
> Cc: [email-masked]; Scott Hollenbeck
> Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> On Wed, 18 May 2005, Lisa Dusseault wrote:
> >   Formal syntax is defined using ABNF [ABNF], extending the 
> ABNF rules
> >   defined in [IMAP4].  The IMAP4 ABNF should be imported 
> first before
> >   attempting to validate these rules.
> 
> If this is what this was all about, then I have no objection. 
>  The discussion so far suggests that it's something else, 
> hence my continued confusion.

This is what I've been trying to describe.  Sorry if that hasn't been clear.

-Scott-

Date: Wed, 18 May 2005 17:50:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: RFC 2359bis
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1903383771-1054626394-1116463832=:14801
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

As promised, I have written my proposed revision to RFC 2359.  I've sent 
it to the I-D respository, but attached is a copy if you want to get an 
early look.

I think that I have addressed all of Alexey's concerns (and I hope Alexey 
will point out if I haven't).  Please note that this is a first draft and 
so will probably need some editorial revision.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
---1903383771-1054626394-1116463832=:14801
Content-Type: TEXT/plain; charset=US-ASCII; name=draft-crispin-imap-rfc2359bis-00.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=draft-crispin-imap-rfc2359bis-00.txt

---1903383771-1054626394-1116463832=:14801--

Date: Wed, 18 May 2005 16:00:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: [email-masked], Scott Hollenbeck <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Lisa Dusseault wrote:
>   Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
>   defined in [IMAP4].  The IMAP4 ABNF should be imported first before
>   attempting to validate these rules.

If this is what this was all about, then I have no objection.  The 
discussion so far suggests that it's something else, hence my continued 
confusion.

-- Mark --

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

Date: Wed, 18 May 2005 15:57:31 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Scott Hollenbeck wrote:
> The problem is that you can't just paste the ABNF from the two documents
> together to produce a syntactically valid ABNF spec.  The rules from the
> extension MUST appear after the rules from 3501 to produce ABNF that can be
> processed without error by a validating parser because of the way that
> incremental construction works.

I fail to comprehend the distinction that is being made here.

In particular, I fail to understand how the ABNF parsing can be done any 
other way than starting with the ABNF from the base specification and then 
following with the ABNF from whatever specification is extending the base 
specification.

I may be the stupidest person in the world, but I suspect that I am not 
alone in being bewildered as to what the problem may be.

-- Mark --

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

Cc: [email-masked], Scott Hollenbeck <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 15:54:09 -0700
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

Seems to me that the text

    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
    Non-terminals referenced but not defined below are as defined by
    [IMAP4].

is slightly misleading if not incorrect, because as Philip points out 
IMAP4 doesn't modify ABNF itself.  It isn't obvious to me that 
'capability' is a non-terminal though I suppose it might be.  The 
paragraph could be clearer for people who want to validate the ABNF.  
It could read:

    Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
    defined in [IMAP4].  The IMAP4 ABNF should be imported first before
    attempting to validate these rules.

We could work around this without changing the doc by introducing it to 
the IESG along with the explanation in email but if we're changing the 
draft for a few nits we might as well include this one.

Alexey, BTW -- Ekr has a perl script that will generate a TOC from text 
if I understand correctly.  I was hoping a TOC wasn't required and that 
the line lengths could be fixed after IESG review but they can also be 
fixed now.

Lisa

On May 18, 2005, at 3:30 PM, Mark Crispin wrote:

>
> On Wed, 18 May 2005, Scott Hollenbeck wrote:
>> I am NOT suggesting that the rules be duplicated.  What I am 
>> referring to is
>> Pete's assertion that an implementer is going to have to combine the 
>> rules
>> etc. from 3501 (I'm paraphrasing here, OK?) and this document to 
>> obtain a
>> complete ABNF spec.  I agree with that.  My assertion is that when 
>> forming
>> that combination the order of the rules is significant if you're using
>> incremental construction.
>
> I guess that I still don't understand what the problem is.
>
> With any IMAP extension specification, you start with the rules in 
> [IMAP] (currently 3501) and then add the rules from the extension.  So 
> the rule defining "capability" will always appear before the rule 
> extending "capability", because "capability" is defined in [IMAP] and 
> extended in the extension.
>
> This is also the case with the MULTIAPPEND extension (3502), which 
> actually replaced a rule of [IMAP].
>
> If the problem is simply that you feel that it's unclear that [IMAP]'s 
> rules are incorporated as a prefix to the rules in the document, then 
> please suggest preferable broilerplate for that text.
>
> I have the feeling that we're all arguing loudly for the same thing, 
> but not understanding each other.  I think that what raised hackles is 
> the notion that 2086upd had to duplicate the "capability" rule rather 
> than inherit it from [IMAP].
>
> So, could we please try again, with a clearer statement of what is 
> needed?
> I'm still confused as to what was the original problem.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 18:47:05 -0400
Sender: [email-masked]

> So, could we please try again, with a clearer statement of 
> what is needed?
> I'm still confused as to what was the original problem.

The ABNF comment that we talked about yesterday, or the text just offered by
Philip Guenther, would be fine.

The problem is that you can't just paste the ABNF from the two documents
together to produce a syntactically valid ABNF spec.  The rules from the
extension MUST appear after the rules from 3501 to produce ABNF that can be
processed without error by a validating parser because of the way that
incremental construction works.

I *know* I'm being picky, but if 2234 is being cited as a normative
reference we can't ignore the parts we don't like.

-Scott-

From: [email-masked]
Cc: Scott Hollenbeck <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 18 May 2005 15:00:51 -0700 (PDT)
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
To: Pete Resnick <[email-masked]>
Sender: [email-masked]

> On 5/17/05 at 6:11 PM -0400, Scott Hollenbeck wrote:

> >>On Tue, 17 May 2005, Scott Hollenbeck wrote:
> >>>I'd prefer to see an ABNF comment like this if you want to do
> >>>something like that:
> >>>;;capability     = <defined in [IMAP]>
> >>>This makes it clear that a parser shouldn't try to parse the
> >>>incomplete rule.
> >>
> >>If this is done, will you then be content with the =/ definitions?
> >
> >Yes.  I now understand the intent and believe that a little bit of
> >explicit clarification is all that's needed to help others avoid the
> >mistake I made in trying to parse the ABNF by itself.

And here I was thinking I was the only one who had this reaction... and
keeping silent. Thanks Pete for posting this.

> Scott, I've got to say that I really object to this silliness. There
> is *no* ambiguity whatsoever if you are implementing an IMAP client
> or server because you *must* implement 3501. This is only a problem
> if you are a blind reader who is not doing an implementation. The
> "=/" is perfectly clear that you're going to have to look for the
> original terminal elsewhere.

Exactly so. We need to focus on changes that actually improve our protocols or
which make them easier to implement. And IMO this doesn't qualify.

Rigorous, repeated checking of ABNF is fine and dandy, but it has to take into 
account that ABNF rulesets routinely inherit productions from other documents.
If this cannot be taken into account the checking is causing more problems than
it solves. In my experience at least ABNF errors detectable by an automatic
checker have not been a signficant source of implementation issues. (Sadly, the
same cannot be said for cases where the ABNF parses fine but nevertheless was
broken in some way.)

> Alexey, I would ask that you not make this change.

At one level really don't care about whether or not this particular change gets
made. It's a small matter.

But the problem is that there are now so many of these small matters, each
masquerading as something important, that they are collectively causing real
damage to the overall process by causing frustration and introducing delays.

We now spend precious time discussing things like whether or not the
grammar for ABNF itself should support the ability to bind a comment to 
a particular ABNF rule. Or whether or not the ABNF grammar should specify
a multiplicity of line terminators instead of the canonical CRLF. Or whether
or not the LTRU group should extend the concept of a charset label to include
script tags. (Thankfully, this last got shut down, but before a bunch of
time was wasted on it.) And so on. These are just off the top of my head; I'm
sure I could come up with many other, and probably better, examples.

I don't have a suggestion for how to eliminate improvement suggestions whose
cost outweighs the benefits. And failing that, the only thing I know to do is
to push back on this stuff. As such, I'm with Pete in asking for this change
not to be made.

				Ned

Date: Wed, 18 May 2005 15:30:13 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Scott Hollenbeck wrote:
> I am NOT suggesting that the rules be duplicated.  What I am referring to is
> Pete's assertion that an implementer is going to have to combine the rules
> etc. from 3501 (I'm paraphrasing here, OK?) and this document to obtain a
> complete ABNF spec.  I agree with that.  My assertion is that when forming
> that combination the order of the rules is significant if you're using
> incremental construction.

I guess that I still don't understand what the problem is.

With any IMAP extension specification, you start with the rules in [IMAP] 
(currently 3501) and then add the rules from the extension.  So the rule 
defining "capability" will always appear before the rule extending 
"capability", because "capability" is defined in [IMAP] and extended in 
the extension.

This is also the case with the MULTIAPPEND extension (3502), which 
actually replaced a rule of [IMAP].

If the problem is simply that you feel that it's unclear that [IMAP]'s 
rules are incorporated as a prefix to the rules in the document, then 
please suggest preferable broilerplate for that text.

I have the feeling that we're all arguing loudly for the same thing, but 
not understanding each other.  I think that what raised hackles is the 
notion that 2086upd had to duplicate the "capability" rule rather than 
inherit it from [IMAP].

So, could we please try again, with a clearer statement of what is needed?
I'm still confused as to what was the original problem.

-- Mark --

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

From: Philip Guenther <[email-masked]>
To: Scott Hollenbeck <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd 
Date: Wed, 18 May 2005 15:22:18 -0700
Sender: [email-masked]

I wrote:
...
>(Come to think of it, I'm not sure what "as modified by [IMAP4]" was
>supposed to mean, as [IMAP] doesn't 'modify' the rules of ABNF.)

Looking backwards, I strongly suspect this originated from when RFC
2060 was the IMAP base spec, as it *did* modify the BNF syntax rules
from those in straight RFC 822.  Now that [IMAP4] is RFC 3501 and
ABNF is used without modification, I think that IMAP extensions
should drop the "as modified by" text.

Philip Guenther

From: "Scott Hollenbeck" <[email-masked]>
To: "'Philip Guenther'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd 
Date: Wed, 18 May 2005 18:14:37 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Philip Guenther [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 6:07 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd 
> 
> Scott Hollenbeck <[email-masked]> writes:
> >>Pete Resnick writes:
> ...
> >> Scott, I've got to say that I really object to this 
> silliness. There 
> >> is *no* ambiguity whatsoever if you are implementing an 
> IMAP client 
> >> or server because you *must* implement 3501. This is only 
> a problem 
> >> if you are a blind reader who is not doing an implementation. The 
> >> "=/" is perfectly clear that you're going to have to look for the 
> >> original terminal elsewhere.
> >
> >Sorry, Pete, but I disagree completely that this is silliness.  The 
> >complete ABNF specification will be invalid if not constructed by 
> >merging rules with those in 3501 in a very particular way.  
> The method 
> >needed to form a valid, complete ABNF specification is NOT 
> clear in the 
> >draft as written.  For
> >example:
> ...
> 
> The first paragraph of the Formal Syntax section reads;
>    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>    Non-terminals referenced but not defined below are as defined by
>    [IMAP4].
> 
> 
> Would it be sufficient to change that to something like:
>    Formal syntax is defined using ABNF [ABNF] as an extension to
>    the syntax in section 9 of [IMAP].
> or maybe
>    Formal syntax is defined using ABNF [ABNF], extending the rules
>    in section 9 of [IMAP].

We talked about this possibility yesterday.  I'd be OK with either text like
this or a comment in the ABNF itself, and I believe I can defend both to
future reviwers if need be.

-Scott-

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 18:10:23 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 5:54 PM
> To: Scott Hollenbeck
> Cc: 'Pete Resnick'; [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> On Wed, 18 May 2005, Scott Hollenbeck wrote:
> > ;; from 2086upd
> > capability      =/ rights-capa
> > ;; from 3501
> > capability      = ("AUTH=" auth-type) / atom
> > will not parse.  The rules MUST be combined in this order:
> > ;; from 3501
> > capability      = ("AUTH=" auth-type) / atom
> > ;; from 2086upd
> > capability      =/ rights-capa
> 
> 
> Now I am confused.
> 
> Are you really saying that ABNF can not have any forward 
> references?  If so, I vehemently object.  ABNF rules should 
> be in alphabetical order, so that mere mortals can find it.
> 
> If not, then it is completely unambiguous to state:
> 
>  	capability      =/ rights-capa
> 
>  	capability      = ("AUTH=" auth-type) / atom
> 
> because =/ is effectively a forward reference.
> 
> 
> I don't terribly mind having
> 
>  	capability      = <<defined in [IMAP]>>
> 
> if that makes the IESG happy, but I most certainly object to 
> duplicating the definition of an [IMAP] rules a different 
> document.  That will break if [IMAP] ever changes the 
> definition of the rule.

Mark, please read section 3.3 of RRC 2234.  It describes the order of the
rules when using incremental construction.  ABNF is what it is.

I am NOT suggesting that the rules be duplicated.  What I am referring to is
Pete's assertion that an implementer is going to have to combine the rules
etc. from 3501 (I'm paraphrasing here, OK?) and this document to obtain a
complete ABNF spec.  I agree with that.  My assertion is that when forming
that combination the order of the rules is significant if you're using
incremental construction.

I've tested this using Bill Fenner's ABNF parser.  It supports my claim.

Look, if you all want to push back I'll gladly ask the rest of the IESG to
comment.  They'll eventually have to look anyway, and as I said, we can
either be clear now or we can be clear later.  I believe that adding a
comment as I described earlier will address an issue that has been raised by
other reviewers for other documents that use ABNF in the same way.

-Scott-

To: Scott Hollenbeck <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd 
Date: Wed, 18 May 2005 15:07:22 -0700
Sender: [email-masked]

Scott Hollenbeck <[email-masked]> writes:
>>Pete Resnick writes:
...
>> Scott, I've got to say that I really object to this 
>> silliness. There is *no* ambiguity whatsoever if you are 
>> implementing an IMAP client or server because you *must* 
>> implement 3501. This is only a problem if you are a blind 
>> reader who is not doing an implementation. The "=/" is 
>> perfectly clear that you're going to have to look for the 
>> original terminal elsewhere.
>
>Sorry, Pete, but I disagree completely that this is silliness.  The complete
>ABNF specification will be invalid if not constructed by merging rules with
>those in 3501 in a very particular way.  The method needed to form a valid,
>complete ABNF specification is NOT clear in the draft as written.  For
>example:
...

The first paragraph of the Formal Syntax section reads;
   Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
   Non-terminals referenced but not defined below are as defined by
   [IMAP4].

Would it be sufficient to change that to something like:
   Formal syntax is defined using ABNF [ABNF] as an extension to
   the syntax in section 9 of [IMAP].
or maybe
   Formal syntax is defined using ABNF [ABNF], extending the rules
   in section 9 of [IMAP].

(Come to think of it, I'm not sure what "as modified by [IMAP4]" was
supposed to mean, as [IMAP] doesn't 'modify' the rules of ABNF.)

Philip Guenther

Date: Wed, 18 May 2005 14:54:06 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: "'Pete Resnick'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 May 2005, Scott Hollenbeck wrote:
> ;; from 2086upd
> capability      =/ rights-capa
> ;; from 3501
> capability      = ("AUTH=" auth-type) / atom
> will not parse.  The rules MUST be combined in this order:
> ;; from 3501
> capability      = ("AUTH=" auth-type) / atom
> ;; from 2086upd
> capability      =/ rights-capa

Now I am confused.

Are you really saying that ABNF can not have any forward references?  If 
so, I vehemently object.  ABNF rules should be in alphabetical order, so 
that mere mortals can find it.

If not, then it is completely unambiguous to state:

 	capability      =/ rights-capa

 	capability      = ("AUTH=" auth-type) / atom

because =/ is effectively a forward reference.

I don't terribly mind having

 	capability      = <<defined in [IMAP]>>

if that makes the IESG happy, but I most certainly object to duplicating 
the definition of an [IMAP] rules a different document.  That will break 
if [IMAP] ever changes the definition of the rule.

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Pete Resnick'" <[email-masked]>
Cc: "'Mark Crispin'" <[email-masked]>, <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Wed, 18 May 2005 17:39:58 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Pete Resnick [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 5:25 PM
> To: Scott Hollenbeck
> Cc: 'Mark Crispin'; [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> On 5/17/05 at 6:11 PM -0400, Scott Hollenbeck wrote:
> 
> >>On Tue, 17 May 2005, Scott Hollenbeck wrote:
> >>>I'd prefer to see an ABNF comment like this if you want to do 
> >>>something like that:
> >>>;;capability     = <defined in [IMAP]>
> >>>This makes it clear that a parser shouldn't try to parse the 
> >>>incomplete rule.
> >>
> >>If this is done, will you then be content with the =/ definitions?
> >
> >Yes.  I now understand the intent and believe that a little bit of 
> >explicit clarification is all that's needed to help others avoid the 
> >mistake I made in trying to parse the ABNF by itself.
> 
> Scott, I've got to say that I really object to this 
> silliness. There is *no* ambiguity whatsoever if you are 
> implementing an IMAP client or server because you *must* 
> implement 3501. This is only a problem if you are a blind 
> reader who is not doing an implementation. The "=/" is 
> perfectly clear that you're going to have to look for the 
> original terminal elsewhere.
> 
> Alexey, I would ask that you not make this change.

Sorry, Pete, but I disagree completely that this is silliness.  The complete
ABNF specification will be invalid if not constructed by merging rules with
those in 3501 in a very particular way.  The method needed to form a valid,
complete ABNF specification is NOT clear in the draft as written.  For
example:

;; from 2086upd
capability      =/ rights-capa
;; from 3501
capability      = ("AUTH=" auth-type) / atom

will not parse.  The rules MUST be combined in this order:

;; from 3501
capability      = ("AUTH=" auth-type) / atom
;; from 2086upd
capability      =/ rights-capa

Be clear now or be clear later.  I can guarantee that this situation will be
(and has been) noted by other reviewers.

-Scott-

Date: Wed, 18 May 2005 14:25:29 -0700
To: "Scott Hollenbeck" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Cc: "'Mark Crispin'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 5/17/05 at 6:11 PM -0400, Scott Hollenbeck wrote:

>>On Tue, 17 May 2005, Scott Hollenbeck wrote:
>>>I'd prefer to see an ABNF comment like this if you want to do 
>>>something like that:
>>>;;capability     = <defined in [IMAP]>
>>>This makes it clear that a parser shouldn't try to parse the 
>>>incomplete rule.
>>
>>If this is done, will you then be content with the =/ definitions?
>
>Yes.  I now understand the intent and believe that a little bit of 
>explicit clarification is all that's needed to help others avoid the 
>mistake I made in trying to parse the ABNF by itself.

Scott, I've got to say that I really object to this silliness. There 
is *no* ambiguity whatsoever if you are implementing an IMAP client 
or server because you *must* implement 3501. This is only a problem 
if you are a blind reader who is not doing an implementation. The 
"=/" is perfectly clear that you're going to have to look for the 
original terminal elsewhere.

Alexey, I would ask that you not make this change.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

Date: Wed, 18 May 2005 11:09:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

On Wed, 18 May 2005, Alexey Melnikov wrote:
> If one has a server that doesn't support persistent UIDs, what is exactly the 
> point of implementing UID EXPUNGE? Such server should instead extend EXPUNGE 
> to accept message set (which is arguable fixes a deficiency in EXPUNGE).

That's a good question.  Fortunately, there's an equally good answer.

Allowing a message sequence set in EXPUNGE opens up complex message 
sequence synchronization problems.  This is something that has proven 
problematic enough with the existing protocol without adding such a 
dangerous command.

Even though the mail store doesn't have persistent UIDs, they are 
generally persistant in the session and thus UID EXPUNGE does not have 
these problems.

Also, UID EXPUNGE can be streamed.

-- Mark --

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

Date: Wed, 18 May 2005 11:05:42 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

On Wed, 18 May 2005, Alexey Melnikov wrote:
>>> I also want a big note saying that if the server can't *ever* return a 
>>> correct APPENDUID/COPYUID, than it must not advertise support for UIDPLUS.
>>> (Some text about multiple mailstores when some of them don't support 
>>> persistent UIDs might be appropriate as well.)
>> I don't think that we can do this; such a statement would be unenforcable.
> I know, that is why it should be a "note".

"MUST" is inconsistant with being a "note".

I agree with encouraging APPENDUID/COPYUID, but I believe that is all that 
we should do.  In any case, UID EXPUNGE should not be held hostage.

> What I meant was "the code was never written to do APPENDUID/COPYUID", as 
> opposed to the server is not configured with a mailstore that supports 
> APPENDUID/COPYUID.

As a practical matter, it makes no difference to the client.  Therefore, 
it does not belong in a protocol specification.  It may be appropriate for 
an "IMAP Implementation Recommendations" document.

> Well, a server that recognizes UID EXPUNGE and always returns NO, plus never 
> returns COPYUID/APPENDUID would also be compliant with rfc2359bis.

That's arguable.  I don't think that a server should refuse UID EXPUNGE 
with a NO if it allows EXPUNGE.

I think that we can make that be a requirement.  If we do that, then "UID 
EXPUNGE always returns NO" would not be in compliance with rfc2359bis.

The rationale is that the UIDPLUS capability advertises that a useful 
implementation of UID EXPUNGE is present.  It doesn't really advertise 
APPENDUID/COPYUID because those are responses, not commands; either they 
come back or they don't come back.

-- Mark --

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

Date: Wed, 18 May 2005 18:39:24 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> It was a terrible mistake to bundle UID EXPUNGE with 
> APPENDUID/COPYUID. The intent was to pressure servers to implement 
> APPENDUID/COPYUID.  This backfired; clients can't rely upon being able 
> to use UID EXPUNGE because multiple servers implementations do not 
> have it.

If one has a server that doesn't support persistent UIDs, what is 
exactly the point of implementing UID EXPUNGE? Such server should 
instead extend EXPUNGE to accept message set (which is arguable fixes a 
deficiency in EXPUNGE).

Date: Wed, 18 May 2005 18:34:11 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 18 May 2005, Alexey Melnikov wrote:
>
>> I also want a big note saying that if the server can't *ever* return 
>> a correct APPENDUID/COPYUID, than it must not advertise support for 
>> UIDPLUS.
>> (Some text about multiple mailstores when some of them don't support 
>> persistent UIDs might be appropriate as well.)
>
> I don't think that we can do this; such a statement would be unenforcable.

I know, that is why it should be a "note".

> It has never worked in the past to use MUST/MUST NOT to enforce a 
> quality of implementation issue, especially when there are legitimate 
> reasons to violate the preferred behavior.
>
> Just what is "can't *ever*"?  Think about that.  Suppose the site' 
> mail store is entirely one without sticky UIDs.  The server software 
> is completely capable of doing UID EXPUNGE, and if a better mail store 
> is installed it could do APPENDUID/COPYUID.

What I meant was "the code was never written to do APPENDUID/COPYUID", 
as opposed to the server is not configured with a mailstore that 
supports APPENDUID/COPYUID.

> What you're saying, in effect, is that the server has to somehow check 
> to see if there is no other mail store other than the crippled one, 
> and if so it has to disable the UID EXPUNGE command and not advertise 
> UIDPLUS.

Well, that would be welcomed, but actually not what I was talking about.

>> This is basically to prevent lazy implementations which assume that 
>> implementing UID EXPUNGE and violating "SHOULD return 
>> APPENDUID/COPYUID" should be sufficient to be compliant.
>
> Although I sympathize with your intentions, I'm on the opposite side 
> from you on this.
>
> There are different standards for "compliant" and "fully implement"; 
> and "compliant" does not always mean "useful".
>
> In my opinion, a server which advertises UIDPLUS, implements UID 
> EXPUNGE, but never returns APPENDUID/COPYUID (and makes not attempt to 
> do so) is fully compliant with rfc2359bis.  I also contend that RFC 
> 2359 does not explicitly state that it is mandatory to return 
> APPENDUID/COPYUID.

Well, a server that recognizes UID EXPUNGE and always returns NO, plus 
never returns COPYUID/APPENDUID would also be compliant with rfc2359bis.

> On the other hand, such a server does not fully implement rfc2359bis.

Date: Wed, 18 May 2005 10:14:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

On Wed, 18 May 2005, Alexey Melnikov wrote:
> I also want a big note saying that if the server can't *ever* return a 
> correct APPENDUID/COPYUID, than it must not advertise support for UIDPLUS.
> (Some text about multiple mailstores when some of them don't support 
> persistent UIDs might be appropriate as well.)

I don't think that we can do this; such a statement would be unenforcable. 
It has never worked in the past to use MUST/MUST NOT to enforce a quality 
of implementation issue, especially when there are legitimate reasons to 
violate the preferred behavior.

Just what is "can't *ever*"?  Think about that.  Suppose the site' mail 
store is entirely one without sticky UIDs.  The server software is 
completely capable of doing UID EXPUNGE, and if a better mail store is 
installed it could do APPENDUID/COPYUID.

What you're saying, in effect, is that the server has to somehow check to 
see if there is no other mail store other than the crippled one, and if so 
it has to disable the UID EXPUNGE command and not advertise UIDPLUS.

> This is basically to prevent lazy implementations which assume that 
> implementing UID EXPUNGE and violating "SHOULD return APPENDUID/COPYUID" 
> should be sufficient to be compliant.

Although I sympathize with your intentions, I'm on the opposite side from 
you on this.

There are different standards for "compliant" and "fully implement"; and 
"compliant" does not always mean "useful".

In my opinion, a server which advertises UIDPLUS, implements UID EXPUNGE, 
but never returns APPENDUID/COPYUID (and makes not attempt to do so) is 
fully compliant with rfc2359bis.  I also contend that RFC 2359 does not 
explicitly state that it is mandatory to return APPENDUID/COPYUID.

On the other hand, such a server does not fully implement rfc2359bis.

It was a terrible mistake to bundle UID EXPUNGE with APPENDUID/COPYUID. 
The intent was to pressure servers to implement APPENDUID/COPYUID.  This 
backfired; clients can't rely upon being able to use UID EXPUNGE because 
multiple servers implementations do not have it.

-- Mark --

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

Date: Wed, 18 May 2005 17:36:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> On Tue, 17 May 2005, Alexey Melnikov wrote:
>
>>> It is also ambiguous as to whether a server which does not support 
>>> UID EXPUNGE may send APPENDUID/COPYUID response codes.
>>
>> I frankly can't see why implementing UID EXPUNGE might be difficult, 
>> but I don't see a reason why not.
>
> Agreed on both points.
>
>>> The alternate interpretation, that UIDPLUS covers the response codes,
>>
>> Which was always my interpretation.
>
> I agree that this is the most likely current interpretation.  I think 
> that this interpretation is wrong, because...:
>
>>> necessitates that, in the case of a mail store that does not have 
>>> sticky UIDs (that is, UIDVALIDITY changes at each SELECT), the 
>>> server issue false (but plausible-seeming) information in an 
>>> APPENDUID/COPYUID response code.
>>
>> Or the server can omit the response code entirely and any correctly 
>> written IMAP client should handle that properly.
>
> I agree that this is desirable and should be the goal, but that is not 
> what RFC 2359 implies by tying UIDPLUS to the response codes.
>
>>> I can not believe that the intent of RFC 2359 is that a server send 
>>> a complete fabrication in the case of a server which supports 
>>> multiple mail stores, only some of which have sticky UIDs.
>>
>> Omitting the response code seems better than returning fake information.
>
> I agree, which is why I want to update RFC 2359 so that:
>
> (1) The UIDPLUS capability only covers the UID EXPUNGE command.
>
> (2) ALL servers SHOULD issue APPENDUID/COPYUID responses, regardless of
>     whether or not they offer UIDPLUS.

If this means that RFC 2359 update "updates RFC 3501", than this is fine 
with me.

> (3) If a server can not issue a correct APPENDUID/COPYUID response 
> because
>     of server implementation or mail store limitation, then it MUST NOT
>     issue a APPENDUID/COPYUID with fake information.  Instead, it would
>     just omit APPENDUID/COPYUID in the response.

I also want a big note saying that if the server can't *ever* return a 
correct APPENDUID/COPYUID, than it must not advertise support for UIDPLUS.
(Some text about multiple mailstores when some of them don't support 
persistent UIDs might be appropriate as well.)
This is basically to prevent lazy implementations which assume that 
implementing UID EXPUNGE and violating "SHOULD return APPENDUID/COPYUID" 
should be sufficient to be compliant.

> I believe that RFC 2359 is correctly interpreted as saying:
>
> (a) The UIDPLUS capability covers both the UID EXPUNGE command and the
>     APPENDUID/COPYUID responses.
>
> (b) Servers which do not advertise UIDPLUS MUST NOT issue
>     APPENDUID/COPYUID responses, and servers which advertise UIDPLUS MUST
>     issue APPENDUID/COPYUID responses.
>
> (b) If a server which advertises UIDPLUS can not issue a correct
>     APPENDUID/COPYUID response because of a mail store limitation beyond
>     control of the server implementation, then it MUST issue a
>     APPENDUID/COPYUID with fake information.
>
> I consider (a) - (c) to be undesirable.  Consequently, I believe that 
> RFC 2359 should be revised to be updated as per (1) - (3) above.
>
> Is there a hum of concensus on this issue?  Or, alternatively, a snarl 
> of rejection?

Hum, assuming you agree with the 2 points mentioned above.

Date: Wed, 18 May 2005 12:09:56 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> 
> On Tue, 17 May 2005, Alexey Melnikov wrote:
> 
>>> It is also ambiguous as to whether a server which does not support 
>>> UID EXPUNGE may send APPENDUID/COPYUID response codes.
>>
>> I frankly can't see why implementing UID EXPUNGE might be difficult, 
>> but I don't see a reason why not.
> 
> 
> Agreed on both points.
> 
>>> The alternate interpretation, that UIDPLUS covers the response codes,
>>
>> Which was always my interpretation.
> 
> 
> I agree that this is the most likely current interpretation.  I think 
> that this interpretation is wrong, because...:
> 
>>> necessitates that, in the case of a mail store that does not have 
>>> sticky UIDs (that is, UIDVALIDITY changes at each SELECT), the server 
>>> issue false (but plausible-seeming) information in an 
>>> APPENDUID/COPYUID response code.
>>
>> Or the server can omit the response code entirely and any correctly 
>> written IMAP client should handle that properly.
> 
> 
> I agree that this is desirable and should be the goal, but that is not 
> what RFC 2359 implies by tying UIDPLUS to the response codes.
> 
>>> I can not believe that the intent of RFC 2359 is that a server send a 
>>> complete fabrication in the case of a server which supports multiple 
>>> mail stores, only some of which have sticky UIDs.
>>
>> Omitting the response code seems better than returning fake information.
> 
> 
> I agree, which is why I want to update RFC 2359 so that:
> 
> (1) The UIDPLUS capability only covers the UID EXPUNGE command.
> 
> (2) ALL servers SHOULD issue APPENDUID/COPYUID responses, regardless of
>     whether or not they offer UIDPLUS.
> 
> (3) If a server can not issue a correct APPENDUID/COPYUID response because
>     of server implementation or mail store limitation, then it MUST NOT
>     issue a APPENDUID/COPYUID with fake information.  Instead, it would
>     just omit APPENDUID/COPYUID in the response.

Humming...

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

Date: Wed, 18 May 2005 13:16:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>>Well, RFC 2234 section 3.3 allows for "=/". So this suggest 
>>that the parser doesn't recognize all constructs in RFC 2234.
>>    
>>
>
>It recognizes the construct all right.  The I-D isn't using it correctly.
>You MUST have an initial rule identified before you can use the "=/"
>construct, like this:
>
>ruleset = alt1 / alt2
>ruleset =/ alt3
>ruleset =/ alt4 / alt5
>
>You haven't specified the initial rule.  The parser is thus absolutely
>correct.
>  
>
Ok, I see your point now.

>If the idea is that the initial rule MUST be imported from 3501 to make this
>syntactically valid ABNF then you should make that perfectly clear, perhaps
>by adding an ABNF comment before the new alternative rules.
>  
>
Yes, will do.

Date: Tue, 17 May 2005 16:27:57 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 17 May 2005, Alexey Melnikov wrote:
>> Frankly I would rather see servers properly support APPENDUID and COPYUID.
> Me too. Should a next revision of IMAP even happen, I would prefer that 
> UIDPLUS (UID EXPUNGE and the response codes) be included in the base spec.

Please note that there are mail stores in which it is impossible to 
accomplish correct APPENDUID/COPYUID.  This means that either the server 
must generate fake information, or the option must persist for the server 
to omit APPENDUID/COPYUID.

>> So an alternative would be to introduce a new argument to APPEND and COPY 
>> that would be the clients explicit request to get APPENDUID and COPYUID 
>> back, and it would be made clear that the client should only use that 
>> argument when it really wants that data, and would otherwise fallback to 
>> some other way (likely more costly) to identify the copies/appended 
>> messages.
> This addition might be fine, but it will need a new capability string, or 
> existing clients which expect automatic COPYUID/APPENDUID will not work with 
> such servers. You also need to convince client implementors to update their 
> code.

I agree that this would have been desirable, and it was a terrible mistake 
not to have done it in RFC 2359.  I tried to prevent the mistake, but lost 
that battle.

I agree that it is too late to undo that mistake now.

However, we should undo the other mistakes, which essentially have the 
effect of creating a requirement that servers which allow UID EXPUNGE (and 
also APPENDUID/COPYUID with some mail stores) generate fake 
APPENDUID/COPYUID data for mail stores which can not support it.

-- Mark --

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

Date: Tue, 17 May 2005 16:23:35 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 17 May 2005, Alexey Melnikov wrote:
>> It is also ambiguous as to whether a server which does not support UID 
>> EXPUNGE may send APPENDUID/COPYUID response codes.
> I frankly can't see why implementing UID EXPUNGE might be difficult, but I 
> don't see a reason why not.

Agreed on both points.

>> The alternate interpretation, that UIDPLUS covers the response codes,
> Which was always my interpretation.

I agree that this is the most likely current interpretation.  I think that 
this interpretation is wrong, because...:

>> necessitates that, in the case of a mail store that does not have sticky 
>> UIDs (that is, UIDVALIDITY changes at each SELECT), the server issue false 
>> (but plausible-seeming) information in an APPENDUID/COPYUID response code.
> Or the server can omit the response code entirely and any correctly written 
> IMAP client should handle that properly.

I agree that this is desirable and should be the goal, but that is not 
what RFC 2359 implies by tying UIDPLUS to the response codes.

>> I can not believe that the intent of RFC 2359 is that a server send a 
>> complete fabrication in the case of a server which supports multiple mail 
>> stores, only some of which have sticky UIDs.
> Omitting the response code seems better than returning fake information.

I agree, which is why I want to update RFC 2359 so that:

(1) The UIDPLUS capability only covers the UID EXPUNGE command.

(2) ALL servers SHOULD issue APPENDUID/COPYUID responses, regardless of
     whether or not they offer UIDPLUS.

(3) If a server can not issue a correct APPENDUID/COPYUID response because
     of server implementation or mail store limitation, then it MUST NOT
     issue a APPENDUID/COPYUID with fake information.  Instead, it would
     just omit APPENDUID/COPYUID in the response.

I believe that RFC 2359 is correctly interpreted as saying:

(a) The UIDPLUS capability covers both the UID EXPUNGE command and the
     APPENDUID/COPYUID responses.

(b) Servers which do not advertise UIDPLUS MUST NOT issue
     APPENDUID/COPYUID responses, and servers which advertise UIDPLUS MUST
     issue APPENDUID/COPYUID responses.

(b) If a server which advertises UIDPLUS can not issue a correct
     APPENDUID/COPYUID response because of a mail store limitation beyond
     control of the server implementation, then it MUST issue a
     APPENDUID/COPYUID with fake information.

I consider (a) - (c) to be undesirable.  Consequently, I believe that RFC 
2359 should be revised to be updated as per (1) - (3) above.

Is there a hum of concensus on this issue?  Or, alternatively, a snarl of 
rejection?

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 18:11:34 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 4:11 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> On Tue, 17 May 2005, Scott Hollenbeck wrote:
> > I'd prefer to see an ABNF comment like this if you want to do 
> > something like
> > that:
> > ;;capability     = <defined in [IMAP]>
> > This makes it clear that a parser shouldn't try to parse the 
> > incomplete rule.
> 
> If this is done, will you then be content with the =/ definitions?

Yes.  I now understand the intent and believe that a little bit of explicit
clarification is all that's needed to help others avoid the mistake I made
in trying to parse the ABNF by itself.

-Scott-

Date: Tue, 17 May 2005 13:11:28 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 17 May 2005, Scott Hollenbeck wrote:
> I'd prefer to see an ABNF comment like this if you want to do something like
> that:
> ;;capability     = <defined in [IMAP]>
> This makes it clear that a parser shouldn't try to parse the incomplete
> rule.

If this is done, will you then be content with the =/ definitions?

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 15:39:56 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 3:28 PM
> To: Scott Hollenbeck
> Cc: 'Cyrus Daboo'; [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> Would it work to have the rule as a meta-variable, e.g.
> 
> capability     = <defined in [IMAP]>

I'd prefer to see an ABNF comment like this if you want to do something like
that:

;;capability     = <defined in [IMAP]>

This makes it clear that a parser shouldn't try to parse the incomplete
rule.

-Scott-

Date: Tue, 17 May 2005 12:28:07 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: "'Cyrus Daboo'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Organization: Networks & Distributed Computing
Sender: [email-masked]

Would it work to have the rule as a meta-variable, e.g.

capability     = <defined in [IMAP]>

-- Mark --

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>
Cc: [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 15:24:20 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Cyrus Daboo [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 2:56 PM
> To: Scott Hollenbeck; 'Alexey Melnikov'
> Cc: 'Lisa Dusseault'; [email-masked]
> Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> Hi Scott,
> 
> --On Tuesday, May 17, 2005 14:39 -0400 Scott Hollenbeck 
> <[email-masked]> wrote:
> 
> > If the idea is that the initial rule MUST be imported from 
> 3501 to make
> > this syntactically valid ABNF then you should make that 
> perfectly clear,
> > perhaps by adding an ABNF comment before the new alternative rules.
> 
> The first paragraph of the Formal Syntax section already states that:
> 
> 
> >    Formal syntax is defined using ABNF [ABNF] as modified 
> by [IMAP4].
> >    Non-terminals referenced but not defined below are as defined by
> >    [IMAP4].

Experience tells me that this will not be enough to warn someone.  If the
defs cause a parser to spit out a syntax error (and they do) I think a
little more text to explain why would be helpful.

> If this is no longer sufficient then it will require changes 
> to pretty much 
> all the IMAP extension documents as they all use something 
> similar. If 
> that's going to be the case then it might be worth defining a 
> new document 
> construct that lists the 'imported' formal syntax elements in 
> a manner that 
> can be parsed by ABNF checker tools.

That would be nice, but that's an ABNF weakness that we can't solve at the
moment.  I think the doc thus needs to make the needed fix more obvious.

Terminals are easy: a parser says "not defined", you say "oh, let me look in
3501", it's there, done.  The problem with this rule situation is that the
ABNF itself is structurally incomplete and parsers don't know how to import
rules to fix the problem.  Text in a comment to let people know that they
need to copy rules from 3501 to make the ABNF spec syntactically complete
would help.

On the other hand, one could also add a little more to the [IMAP4] reference
sentence. It might help to explicitly note that the ABNF is NOT intended to
stand on its own and that it MUST only be considered in union with the rules
and terminals from 3501 to be complete.

I'm poking at this because the RFC Editor is now using automated tools to
check ABNF, XML Schemas, etc.  They'll see the same syntax error I did if
they try to parse the ABNF in isolation.  It'll thus help eliminate a
possible bump later on if we can be a little more clear now.

-Scott-

Date: Tue, 17 May 2005 14:55:43 -0400
From: Cyrus Daboo <[email-masked]>
To: Scott Hollenbeck <[email-masked]>, "'Alexey Melnikov'" <[email-masked]>
cc: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Hi Scott,

--On Tuesday, May 17, 2005 14:39 -0400 Scott Hollenbeck 
<[email-masked]> wrote:

> If the idea is that the initial rule MUST be imported from 3501 to make
> this syntactically valid ABNF then you should make that perfectly clear,
> perhaps by adding an ABNF comment before the new alternative rules.

The first paragraph of the Formal Syntax section already states that:

>    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>    Non-terminals referenced but not defined below are as defined by
>    [IMAP4].

If this is no longer sufficient then it will require changes to pretty much 
all the IMAP extension documents as they all use something similar. If 
that's going to be the case then it might be worth defining a new document 
construct that lists the 'imported' formal syntax elements in a manner that 
can be parsed by ABNF checker tools.

-- 
Cyrus Daboo

From: "Scott Hollenbeck" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 14:39:22 -0400
Importance: Normal
Sender: [email-masked]

> Well, RFC 2234 section 3.3 allows for "=/". So this suggest 
> that the parser doesn't recognize all constructs in RFC 2234.

It recognizes the construct all right.  The I-D isn't using it correctly.
You MUST have an initial rule identified before you can use the "=/"
construct, like this:

ruleset = alt1 / alt2
ruleset =/ alt3
ruleset =/ alt4 / alt5

You haven't specified the initial rule.  The parser is thus absolutely
correct.

If the idea is that the initial rule MUST be imported from 3501 to make this
syntactically valid ABNF then you should make that perfectly clear, perhaps
by adding an ABNF comment before the new alternative rules.

-Scott-

Date: Tue, 17 May 2005 19:27:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>>Section 6.2 describes under what conditions servers 
>>supporting the ACL 
>>extension should return READ-WRITE or READ-ONLY response 
>>codes defined 
>>in RFC 3501. I thought that this meant that the draft updated 
>>3501, but 
>>I wasn't quite sure. Please advise.
>>    
>>
>I believe it updates 3501, especially as things relate to the ABNF.  More on
>that below.
>  
>
Ok.

>>> <>- Please remove what looks like a reference to RFC 3501 
>>> ("IMAP4rev1") from
>>
>>>the abstract, or maybe just identify the acronym as "IMAP".
>>>      
>>>
>>Is the following Ok?:
>>   The ACL (Access Control List) extension (RFC 2086) of the Internet
>>   Message Access Protocol (IMAP) permits ...
>>    
>>
>
>This looks better.
>
>[snip]
>  
>
>>> <>- Section 3, 7th paragraph: "A client may determine". Again, is 
>>> this "may"
>>
>>>supposed to be in lower case letters?
>>>      
>>>
>>The sentence is:
>>   A client may determine the set of rights granted to the logged-in 
>>user for a given mailbox name by using the MYRIGHTS
>>   command.
>>
>>The MYRIGHTS command is the only way to determine rights of the 
>>logged-in user, there is no implementation choice here.
>>So I don't think this "may" should be capitalized.
>>    
>>
>
>I think you'd be better off using a word other than "may", such as "can".
>People get confused when mixing upper and lower case forms of the 2119
>directives.  Even the IESG argues about it.  I think you'd be better off
>using the upper case form where appropriate, and synonyms like "can" to
>replace the lower case forms where no directive is intended.
>  
>
I've changed this to "can". Thanks.

>[snip]
>  
>
>>>Section 8: two minor ABNF errors:
>>>
>>>capability   =/ rights-capa
>>>command-auth =/ setacl / deleteacl / getacl / listrights / myrights
>>>
>>>should be:
>>>
>>>capability   = rights-capa
>>>command-auth = setacl / deleteacl / getacl / listrights / myrights
>>>      
>>>
>>The "capability" and "command-auth" productions are defined 
>>in RFC 3501, 
>>this document is extending them, so I think "=/" is more appropriate.
>>    
>>
>
>Here's the problem with that: the ABNF as currently written won't parse
>because you appear to have introduced a syntax error.  Try running it
>through here to see what I mean:
>
>http://irg.attlabs.net/~fenner/abnf.cgi
>
>("Bill" is Bill Fenner, one of the other IESG members.)
>  
>
Well, RFC 2234 section 3.3 allows for "=/". So this suggest that the parser doesn't recognize all constructs in RFC 2234.

>If the idea is to extend a definition from 3501, you can copy the ABNF
>terminals that are being extended from 3501 and add the new values here.
>That way we have syntactically complete ABNF that passes automated
>validation AND it makes the answer to the "does this update 3501?"
>
Most of the IMAP extensions extend ABNF in RFC 3501, but none of the 
published RFCs list them as "updating" RFC 3501. That is why I've hesitated.

> question
>very obvious.  Don't worry about the SP terminal et al. -- there's already
>text in the document to explain that missing terminals can be found in 3501,
>and I confirmed that they're truly there.
>  
>

Date: Tue, 17 May 2005 11:24:12 -0700
From: Rob Siemborski <[email-masked]>
Reply-To: Rob Siemborski <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Cc: Alexey Melnikov <[email-masked]>, Lisa Dusseault <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/17/05, Scott Hollenbeck <[email-masked]> wrote:
> If the idea is to extend a definition from 3501, you can copy the ABNF
> terminals that are being extended from 3501 and add the new values here.
> That way we have syntactically complete ABNF that passes automated
> validation AND it makes the answer to the "does this update 3501?" question
> very obvious.  Don't worry about the SP terminal et al. -- there's already
> text in the document to explain that missing terminals can be found in 3501,
> and I confirmed that they're truly there.

But what if another specification updates these terminals - which
happens all the time with CAPABILITY.  Then you have to depend on all
the documents that preceed the one you're trying to implement.  This
seems far less extensible than just referring to the definition in
RFC3501.

-Rob

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

From: "Scott Hollenbeck" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: RE: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 14:16:16 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 2:03 PM
> To: Scott Hollenbeck
> Cc: 'Lisa Dusseault'; [email-masked]
> Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
> 
> 
> Scott Hollenbeck wrote:
> 
> >Lisa Dusseault has asked me to bring 
> draft-ietf-imapext-2086upd to the IESG
> >for review.  Before I can do that, I have to review the 
> document myself and
> >I need to request an IETF last call.  Here are my review comments and
> >questions:
> >
> >- What does "Updates: <<3501?>>" mean in the first page 
> headers?  Does this
> >document update RFC 3501 or not?
> >  
> >
> Section 6.2 describes under what conditions servers 
> supporting the ACL 
> extension should return READ-WRITE or READ-ONLY response 
> codes defined 
> in RFC 3501. I thought that this meant that the draft updated 
> 3501, but 
> I wasn't quite sure. Please advise.

I believe it updates 3501, especially as things relate to the ABNF.  More on
that below.

> >- Please remove what looks like a reference to RFC 3501 
> ("IMAP4rev1") from
> >the abstract, or maybe just identify the acronym as "IMAP".
> >  
> >
> Is the following Ok?:
>    The ACL (Access Control List) extension (RFC 2086) of the Internet
>    Message Access Protocol (IMAP) permits ...

This looks better.

[snip]

> >- Section 3, 7th paragraph: "A client may determine".  
> Again, is this "may"
> >supposed to be in lower case letters?
> >
> The sentence is:
>    A client may determine the set of rights granted to the logged-in 
> user for a given mailbox name by using the MYRIGHTS
>    command.
> 
> The MYRIGHTS command is the only way to determine rights of the 
> logged-in user, there is no implementation choice here.
> So I don't think this "may" should be capitalized.

I think you'd be better off using a word other than "may", such as "can".
People get confused when mixing upper and lower case forms of the 2119
directives.  Even the IESG argues about it.  I think you'd be better off
using the upper case form where appropriate, and synonyms like "can" to
replace the lower case forms where no directive is intended.

[snip]

> >Section 8: two minor ABNF errors:
> >
> >capability   =/ rights-capa
> >command-auth =/ setacl / deleteacl / getacl / listrights / myrights
> >
> >should be:
> >
> >capability   = rights-capa
> >command-auth = setacl / deleteacl / getacl / listrights / myrights
> >  
> >
> The "capability" and "command-auth" productions are defined 
> in RFC 3501, 
> this document is extending them, so I think "=/" is more appropriate.

Here's the problem with that: the ABNF as currently written won't parse
because you appear to have introduced a syntax error.  Try running it
through here to see what I mean:

http://irg.attlabs.net/~fenner/abnf.cgi

("Bill" is Bill Fenner, one of the other IESG members.)

If the idea is to extend a definition from 3501, you can copy the ABNF
terminals that are being extended from 3501 and add the new values here.
That way we have syntactically complete ABNF that passes automated
validation AND it makes the answer to the "does this update 3501?" question
very obvious.  Don't worry about the SP terminal et al. -- there's already
text in the document to explain that missing terminals can be found in 3501,
and I confirmed that they're truly there.

-Scott-

Date: Tue, 17 May 2005 19:02:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: "'Lisa Dusseault'" <[email-masked]>, [email-masked]
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Sender: [email-masked]

Scott Hollenbeck wrote:

>Lisa Dusseault has asked me to bring draft-ietf-imapext-2086upd to the IESG
>for review.  Before I can do that, I have to review the document myself and
>I need to request an IETF last call.  Here are my review comments and
>questions:
>
>- What does "Updates: <<3501?>>" mean in the first page headers?  Does this
>document update RFC 3501 or not?
>  
>
Section 6.2 describes under what conditions servers supporting the ACL 
extension should return READ-WRITE or READ-ONLY response codes defined 
in RFC 3501. I thought that this meant that the draft updated 3501, but 
I wasn't quite sure. Please advise.

>- Please remove what looks like a reference to RFC 3501 ("IMAP4rev1") from
>the abstract, or maybe just identify the acronym as "IMAP".
>  
>
Is the following Ok?:
   The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP) permits ...

Or do you suggest to change this to:

   The ACL (Access Control List) extension (RFC 2086) of the IMAP
   permits ...

?

>- Editorial nit, Abstract and Section 2: s/the RFC 2086/RFC 2086/
>  
>
Fixed.

>- A Table of Contents is needed.  Other formatting errors found using the ID
>nits tool [1] should also be corrected.
>
>- Section 3, 6th paragraph, 1st sentence: "An implementation MAY tie rights
>together or may".  Is this second "may" supposed to be in lower case
>letters?
>  
>
I don't think so, fixed.

>- Section 3, 7th paragraph: "A client may determine".  Again, is this "may"
>supposed to be in lower case letters?
>
The sentence is:
   A client may determine the set of rights granted to the logged-in 
user for a given mailbox name by using the MYRIGHTS
   command.

The MYRIGHTS command is the only way to determine rights of the 
logged-in user, there is no implementation choice here.
So I don't think this "may" should be capitalized.

>  I won't call out any more, but let's
>consider this an open question for any other 2119 keywords that appear in
>both upper and lower case letters.  Consistency is a good thing.
>
>Section 4, first paragraph: s/that have an identifier/that has an
>identifier/
>  
>
Fixed, thanks.

>Section 8: two minor ABNF errors:
>
>capability   =/ rights-capa
>command-auth =/ setacl / deleteacl / getacl / listrights / myrights
>
>should be:
>
>capability   = rights-capa
>command-auth = setacl / deleteacl / getacl / listrights / myrights
>  
>
The "capability" and "command-auth" productions are defined in RFC 3501, 
this document is extending them, so I think "=/" is more appropriate.

>(change "=/" to "=")
>
>Let's talk about these.  An update is likely required before I can bring
>this to last call because I don't want to last call a document with known
>ABNF syntax errors or spec ambiguities.
>
>-Scott-
>
>[1]
>http://ietf.levkowetz.com/tools/idnits/idnits.pyht
>  
>

Date: Tue, 17 May 2005 10:53:19 -0700
From: Rob Siemborski <[email-masked]>
Reply-To: Rob Siemborski <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-imapext-2086upd
Cc: Lisa Dusseault <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/17/05, Scott Hollenbeck <[email-masked]> wrote:
> capability   =/ rights-capa
> command-auth =/ setacl / deleteacl / getacl / listrights / myrights
> 
> should be:
> 
> capability   = rights-capa
> command-auth = setacl / deleteacl / getacl / listrights / myrights
> 
> (change "=/" to "=")
> 
> Let's talk about these.  An update is likely required before I can bring
> this to last call because I don't want to last call a document with known
> ABNF syntax errors or spec ambiguities.

Isn't this ABNF correct, since it is extending terminals defined in
RFC3501?  Perhaps that needs to be clarified.

-Rob

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

From: "Scott Hollenbeck" <[email-masked]>
To: "'Lisa Dusseault'" <[email-masked]>
Cc: [email-masked]
Subject: AD Evaluation of draft-ietf-imapext-2086upd
Date: Tue, 17 May 2005 13:32:53 -0400
Importance: Normal
Sender: [email-masked]

Lisa Dusseault has asked me to bring draft-ietf-imapext-2086upd to the IESG
for review.  Before I can do that, I have to review the document myself and
I need to request an IETF last call.  Here are my review comments and
questions:

- What does "Updates: <<3501?>>" mean in the first page headers?  Does this
document update RFC 3501 or not?

- Please remove what looks like a reference to RFC 3501 ("IMAP4rev1") from
the abstract, or maybe just identify the acronym as "IMAP".

- Editorial nit, Abstract and Section 2: s/the RFC 2086/RFC 2086/

- A Table of Contents is needed.  Other formatting errors found using the ID
nits tool [1] should also be corrected.

- Section 3, 6th paragraph, 1st sentence: "An implementation MAY tie rights
together or may".  Is this second "may" supposed to be in lower case
letters?

- Section 3, 7th paragraph: "A client may determine".  Again, is this "may"
supposed to be in lower case letters?  I won't call out any more, but let's
consider this an open question for any other 2119 keywords that appear in
both upper and lower case letters.  Consistency is a good thing.

Section 4, first paragraph: s/that have an identifier/that has an
identifier/

Section 8: two minor ABNF errors:

capability   =/ rights-capa
command-auth =/ setacl / deleteacl / getacl / listrights / myrights

should be:

capability   = rights-capa
command-auth = setacl / deleteacl / getacl / listrights / myrights

(change "=/" to "=")

Let's talk about these.  An update is likely required before I can bring
this to last call because I don't want to last call a document with known
ABNF syntax errors or spec ambiguities.

-Scott-

[1]
http://ietf.levkowetz.com/tools/idnits/idnits.pyht

Date: Tue, 17 May 2005 17:43:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Mark,
>
> --On May 16, 2005 1:44:06 PM -0700 Mark Crispin 
> <[email-masked]> wrote:
>
>> The silence has been deafening in response to my comments about the
>> UIDPLUS specification.  Should I assume that this means that I should
>> undertake updating RFC 2359 to resolve the ambiguities that I mentioned?
>
> I checked my implementation and it does not rely on COPYUID and 
> APPENDUID even when the UIDPLUS capability is present. Of course it 
> only uses UID EXPUNGE when UIDPLUS is present. So the changes you 
> propose would not be a problem for me - obviously I can't say whether 
> others that use COPYUID/APPENDUID are in the same boat.

Mozilla/Thunderbird use COPYUID/APPENDUID. Probably others as well.

>> Also, what do people think about recommending a standard header for
>> clients to write into the header for non-UIDPLUS servers or mail stores?
>> It looks like SUN has X-SGMT-Synchronization-Tag.
>
> That's only relevant for APPENDs of course and not COPY.
>
> Frankly I would rather see servers properly support APPENDUID and COPYUID.

Me too. Should a next revision of IMAP even happen, I would prefer that 
UIDPLUS (UID EXPUNGE and the response codes) be included in the base spec.

> I realise that the main argument against it is that it is time 
> consuming to determine it, and having to do it for every COPY or 
> APPEND command is a waste, especially if the client is not using that 
> info anyway.

For some servers like Cyrus and Isode Mbox the APPENDUID/COPYUID 
information is always available, so they might as well return it all the 
time.

> So an alternative would be to introduce a new argument to APPEND and 
> COPY that would be the clients explicit request to get APPENDUID and 
> COPYUID back, and it would be made clear that the client should only 
> use that argument when it really wants that data, and would otherwise 
> fallback to some other way (likely more costly) to identify the 
> copies/appended messages.

This addition might be fine, but it will need a new capability string, 
or existing clients which expect automatic COPYUID/APPENDUID will not 
work with such servers. You also need to convince client implementors to 
update their code.

Alexey

Date: Tue, 17 May 2005 15:35:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: necessary updates to RFC 2359 (UIDPLUS)
Sender: [email-masked]

Mark Crispin wrote:

> RFC 2359 needs to clarify that the UIDPLUS extension indicates that 
> the UID EXPUNGE extension is present, and does not necessarily 
> indicate the APPENDUID and COPYUID response codes.
>
> As presently constituted, RFC 2359 is ambiguous as to whether 
> APPENDUID and COPYUID are mandatory responses for a UIDPLUS server.

> It is also ambiguous as to whether a server which does not support UID 
> EXPUNGE may send APPENDUID/COPYUID response codes.

I frankly can't see why implementing UID EXPUNGE might be difficult, but 
I don't see a reason why not.

> I recommend that RFC 2359 be updated as follows:
>
> . clarify that the UIDPLUS extension refers to the UID EXPUNGE command.
>
> . recommend that servers SHOULD issue APPENDUID/COPYUID response codes.
>
>
> The alternate interpretation, that UIDPLUS covers the response codes,

Which was always my interpretation.

> necessitates that, in the case of a mail store that does not have 
> sticky UIDs (that is, UIDVALIDITY changes at each SELECT), the server 
> issue false (but plausible-seeming) information in an 
> APPENDUID/COPYUID response code.

Or the server can omit the response code entirely and any correctly 
written IMAP client should handle that properly.

> I can not believe that the intent of RFC 2359 is that a server send a 
> complete fabrication in the case of a server which supports multiple 
> mail stores, only some of which have sticky UIDs.

Omitting the response code seems better than returning fake information.

Date: Mon, 16 May 2005 14:27:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 16 May 2005, Cyrus Daboo wrote:
>> Also, what do people think about recommending a standard header for
>> clients to write into the header for non-UIDPLUS servers or mail stores?
>> It looks like SUN has X-SGMT-Synchronization-Tag.
> That's only relevant for APPENDs of course and not COPY.

True; although we *could* create a standard header that works with both 
APPEND and COPY, and is not vulnerable to possible UID instability. 
Personally, I think that a standard header to search is technically 
superior to UIDPLUS.

> Frankly I would rather see servers properly support APPENDUID and COPYUID. I 
> realise that the main argument against it is that it is time consuming to 
> determine it, and having to do it for every COPY or APPEND command is a 
> waste, especially if the client is not using that info anyway.

That's one reason.  There's another: the mail store may not support it. 
If the mail store does not support sticky UIDs (that is, UIDVALIDITY is 
different each time), there's nothing the server can do.

> So an alternative would be to introduce a new argument to APPEND and 
> COPY that would be the clients explicit request to get APPENDUID and 
> COPYUID back, and it would be made clear that the client should only use 
> that argument when it really wants that data, and would otherwise 
> fallback to some other way (likely more costly) to identify the 
> copies/appended messages.

I asked for this years ago when UIDPLUS was first proposed.  UIDPLUS (and 
the pre-LISTEXT CHILDREN extension) stand out as being wrongly designed to 
require work on the server even when the client does not request it.

-- Mark --

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

Date: Mon, 16 May 2005 17:19:40 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: UIDPLUS comments?
Sender: [email-masked]

Hi Mark,

--On May 16, 2005 1:44:06 PM -0700 Mark Crispin <[email-masked]> 
wrote:

> The silence has been deafening in response to my comments about the
> UIDPLUS specification.  Should I assume that this means that I should
> undertake updating RFC 2359 to resolve the ambiguities that I mentioned?

I checked my implementation and it does not rely on COPYUID and APPENDUID 
even when the UIDPLUS capability is present. Of course it only uses UID 
EXPUNGE when UIDPLUS is present. So the changes you propose would not be a 
problem for me - obviously I can't say whether others that use 
COPYUID/APPENDUID are in the same boat.

> Also, what do people think about recommending a standard header for
> clients to write into the header for non-UIDPLUS servers or mail stores?
> It looks like SUN has X-SGMT-Synchronization-Tag.

That's only relevant for APPENDs of course and not COPY.

Frankly I would rather see servers properly support APPENDUID and COPYUID. 
I realise that the main argument against it is that it is time consuming to 
determine it, and having to do it for every COPY or APPEND command is a 
waste, especially if the client is not using that info anyway.

So an alternative would be to introduce a new argument to APPEND and COPY 
that would be the clients explicit request to get APPENDUID and COPYUID 
back, and it would be made clear that the client should only use that 
argument when it really wants that data, and would otherwise fallback to 
some other way (likely more costly) to identify the copies/appended 
messages.

-- 
Cyrus Daboo

Date: Mon, 16 May 2005 13:44:06 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: UIDPLUS comments?
Organization: Networks & Distributed Computing
Sender: [email-masked]

The silence has been deafening in response to my comments about the 
UIDPLUS specification.  Should I assume that this means that I should 
undertake updating RFC 2359 to resolve the ambiguities that I mentioned?

Also, what do people think about recommending a standard header for 
clients to write into the header for non-UIDPLUS servers or mail stores? 
It looks like SUN has X-SGMT-Synchronization-Tag.

-- Mark --

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-13.txt
Date: Mon, 16 May 2005 15:40:39 -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, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-13.txt
	Pages		: 38
	Date		: 2005-5-16
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists 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-13.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-13.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-13.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-13.txt

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

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

--OtherAccess--

--NextPart--

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WG Last Call of LISTEXT draft 13
Date: Mon, 16 May 2005 11:23:50 -0700
Sender: [email-masked]

I call your attention to this draft:

http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
-13.txt

That link doesn't yet work but Barry did post the 13 draft to the list  
today: http://www.imc.org/ietf-imapext/mail-archive/msg02601.html

This document is the framework for much of the syntax we're doing in  
other IMAPEXT tasks and is being referenced by other documents already,  
so it's important that it gets a good review.  I'll be expecting  
several people to review the complete draft or to review changes from a  
version they've reviewed before.  If you review it at all, or plan to  
implement, or have any opinion about standardizing this document, send  
mail to the WG list or at least to me.

Last call will go until EOD, May 31.

Lisa

Date: Mon, 16 May 2005 13:23:38 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
cc: Lisa Dusseault <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-13
Sender: [email-masked]

--==========92EB6F57300CB3B266C8==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Alexey pointed out that the capability "LISTEXT" is currently used by
several inconsistent programs.  The I-D editor also complained that I
was following the obsolete RFC 3667 IP statement instead of the new RFC
3978 one (who can keep track of all these changes, even with xml2rfc to
help?), so they wouldn't publish it as it was anyway.  I've sent the
attached update, which specifies "LIST-EXTENDED" as the capability
string.

Barry

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

--==========92EB6F57300CB3B266C8==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-imapext-list-extensions-13.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-13.txt"; size=67058

IMAP Extensions Working Group                                   B. =
Leiba
Internet-Draft                           IBM T.J. Watson Research =
Center
Updates: 2193 (if approved)                                  A. =
Melnikov
Obsoletes: 3348 (if approved)                              Isode =
Limited
Expires: November 17, 2005                                  May 16, =
2005

                     IMAP4 LIST Command Extensions
                 draft-ietf-imapext-list-extensions-13

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists 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

Leiba & Melnikov        Expires November 17, 2005               [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   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.

Note

   A revised version of this draft document will be submitted to the =
RFC
   editor as an Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked].

   This document obsoletes RFC 3348 and updates RFC 2193.

Table of Contents

   1.  Conventions used in this document  . . . . . . . . . . . . . .  =
3

   2.  Introduction and overview  . . . . . . . . . . . . . . . . . .  =
4

   3.  Extended LIST Command  . . . . . . . . . . . . . . . . . . . .  =
6
   3.1 General principles for returning LIST responses  . . . . . . . =
10
   3.2 Additional requirements on LIST-EXTENDED clients . . . . . . . =
11
   3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . =
11

   4.  The CHILDREN return Option . . . . . . . . . . . . . . . . . . =
14

   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . =
16

   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . =
26

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . =
29

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . =
30
   8.1 Guidelines for IANA  . . . . . . . . . . . . . . . . . . . . . =
30
   8.2 Registration procedure and Change control  . . . . . . . . . . =
30
   8.3 Registration template for LIST-EXTENDED options  . . . . . . . =
31
   8.4 Initial LIST-EXTENDED option registrations . . . . . . . . . . =
32
   8.5 Registration template for LIST-EXTENDED extended data item . . =
34
   8.6 Initial LIST-EXTENDED extended data item registrations . . . . =
35

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
36

   10. Normative References . . . . . . . . . . . . . . . . . . . . . =
36

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
36

       Intellectual Property and Copyright Statements . . . . . . . . =
38

Leiba & Melnikov        Expires November 17, 2005               [Page =
2]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

1.  Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Kwds].

   The term "canonical LIST pattern" refers to the canonical pattern
   constructed internally by the server from the reference and mailbox
   name arguments (Section 6.3.8 of [IMAP4]).  The [IMAP4] LIST command
   returns only mailboxes that match the canonical LIST pattern.

   Other terms are introduced where they are referenced for the first
   time.

Leiba & Melnikov        Expires November 17, 2005               [Page =
3]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

2.  Introduction and overview

   The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:

   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");

   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");

   3.  if the LIST command has more than 2 parameters ("LIST return
       options");

   Otherwise the original syntax is used.

   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB =
commands
   described in [MBRef].  We are also defining the mechanism to request
   extended mailbox information, such as is described in the "Child
   Mailbox Extension" [CMbox].  The base LSUB command is not deprecated
   by this extension; rather, this extension adds a way to obtain
   subscription information with more options, with those server
   implementations that support it.  Clients that simply need a list of
   subscribed mailboxes, as provided by the LSUB command, SHOULD
   continue to use that command.

   This document defines an IMAP4 extension that is identified by the
   capability string "LIST-EXTENDED".  The LIST-EXTENDED extension =
makes
   the following changes to the IMAP4 protocol, which are described in
   more detail in Section 3 and Section 4:

   a.  defines new syntax for LIST command options.

   b.  extends LIST to allow for multiple mailbox patterns.

   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and
       RECURSIVEMATCH.

   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.

   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".

Leiba & Melnikov        Expires November 17, 2005               [Page =
4]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   f.  adds CHILDINFO extended data item.

Leiba & Melnikov        Expires November 17, 2005               [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

3.  Extended LIST Command

   This extension updates the syntax of the LIST command to allow for
   multiple mailbox patterns to be specified, if they are enclosed in
   parantheses.  A mailbox name match a list of mailbox patterns if it
   matches at least one mailbox pattern.  Note that if a mailbox name
   matches multiple mailbox patterns from the list, the server should
   return only a single LIST response.

   Note that the non-extended LIST command is required to treat an =
empty
   ("" string) mailbox name argument as a special request to return the
   hierarchy delimiter and the root name of the name given in the
   reference parameter (as per [IMAP4]).  However ANY extended LIST
   command (extended in any of 3 ways specified in Section 2, or any
   combination of therof) MUST NOT treat the empty mailbox name as such
   special request and any regular processing described in this =
document
   applies.  In particular, if an extended LIST command has multiple
   mailbox names and one (or more) of them is the empty string, the
   empty string MUST be ignored for the purpose of matching.

   Some servers might restrict which patterns are allowed in a LIST
   command.  If a server doesn't accept a particular pattern, it MUST
   silently ignore it.

   The LIST command syntax is also extended in two additional ways: by
   adding a parenthesized list of command options between the command
   name and the reference name (LIST selection options) and an optional
   list of options at the end that control what kind of information
   should be returned (LIST return options).  See the formal syntax in
   Section 6 for specific details.

   A LIST selection option tells the server which mailbox names should
   be selected by the LIST operation.  The server should return
   information about all mailbox names that match any of the "canonical
   LIST pattern" (as described above) and satisfy additional selection
   criteria (if any) specified by the LIST selection options.  Let's
   call any such mailbox name a "matched mailbox name".  When multiple
   selection options are specified, the server MUST return information
   about mailbox names that satisfy every selection option, unless a
   description of a particular specified option prescribes special
   rules.  An example of an option prescribing special rules is the
   RECURSIVEMATCH selection option described later in this section.  We
   will use the term "selection criteria" when referring collectively =
to
   all selection options specified in a LIST command.

   A LIST return option controls which information is returned for each
   matched mailbox name.  Note that return options MUST NOT cause the
   server to report information about additional mailbox names.  If the

Leiba & Melnikov        Expires November 17, 2005               [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   client has not specified any return option, only information about
   attributes should be returned by the server.  (Of course the server
   is allowed to include any other information at will.)

   Both selection and return command options will be defined in this
   document and in approved extension documents; each option will be
   enabled by a capability string (one capability may enable multiple
   options), and a client MUST NOT send an option for which the server
   has not advertised support.  A server MUST respond to options it =
does
   not recognize with a BAD response.  The client SHOULD NOT specify =
any
   option more than once, however if the client does this, the server
   MUST act as if it received the option only once.  The order in which
   options are specified by the client is not significant.

   In general, each selection option except for RECURSIVEMATCH will =
have
   a corresponding return option.  The REMOTE selection option is an
   anomaly in this regard, and does not have a corresponding return
   option.  That is because it expands, rather than restricts, the set
   of mailboxes that are returned.  Future extensions to this
   specification should keep parallelism in mind, and define a pair of
   corresponding options.

   This extension is identified by the capability string "LIST-
   EXTENDED", and support for it is a prerequisite for any future
   extensions that require specialized forms of the LIST command.  Such
   extensions MUST refer to this document and MUST add their function
   through command options as described herein.  Note that extensions
   that don't require support for an extended LIST command, but use
   extended LIST responses (see below), don't need to advertise the
   "LIST-EXTENDED" capability string.

   This extension also defines extensions to the LIST response, =
allowing
   a series of extended fields at the end, a parenthesized list of
   tagged data (also referred to as "extended data item").  The first
   element of an extended field is a tag, which identifies type of the
   data.  Tags MUST be registered with IANA, as described in Section =
8.5
   of this document.  An example of such extended set might be

      ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample
      "text"))

   or...

      ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more
      text"))

Leiba & Melnikov        Expires November 17, 2005               [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   See the formal grammar, below, for the full syntactic details.  The
   server MUST NOT return any extended data item, unless the client has
   expressed its ability to support extended LIST responses, for =
example
   by using an extended LIST command.  The server MAY return data in =
the
   extended fields that was not solicited by the client.  The client
   MUST ignore all extended fields it doesn't recognize.

   The LIST-EXTENDED capability also defines several new mailbox
   attributes.

   The "\NonExistent" attribute indicates that a mailbox does not
   actually exist.  Note that this attribute is not meaningful by
   itself, as mailboxes that match the canonical LIST pattern but don't
   exist must not be returned unless one of the two conditions listed
   below is also satisfied:

   a.  the mailbox also satisfies the selection criteria (for example,
       its name is subscribed and the "SUBSCRIBED" selection option has
       been specified)

   b.  "RECURSIVEMATCH" has been specified, and the mailbox has at =
least
       one child mailbox that matches the LIST pattern and selection
       criteria.

   In practice this means that the "\NonExistent" attribute is usually
   returned with one or more of "\Subscribed", "\Remote" or the
   CHILDINFO extended data item (see their description below).

   The "\NonExistent" attribute implies "\NoSelect".  The =
"\NonExistent"
   attribute MUST be supported and MUST be accurately computed.

   The selection options defined in this specification are

   SUBSCRIBED - causes the LIST command to list subscribed names, =
rather
      than the existing mailboxes.  This will often be a subset of the
      actual mailboxes.  It's also possible for this list to contain =
the
      names of mailboxes that don't exist.  In any case, the list MUST
      include exactly those mailbox names that match the canonical list
      pattern and are subscribed to.  This option is intended to
      supplement the LSUB command.  Of particular note are the mailbox
      attributes as returned by this option, compared with what is
      returned by LSUB.  With the latter, the attributes returned may
      not reflect the actual attribute status on the mailbox name, and
      the \NoSelect attribute has a special meaning (it indicates that
      this mailbox is not, itself, subscribed, but that it has child
      mailboxes that are).  With the SUBSCRIBED selection option
      described here, the attributes are accurate, complete, and have =
no

Leiba & Melnikov        Expires November 17, 2005               [Page =
8]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

      special meanings.  "LSUB" and "LIST (SUBSCRIBED)" are, thus, not
      the same thing, and some servers must do significant extra work =
to
      respond to "LIST (SUBSCRIBED)".  Because of this, clients SHOULD
      continue to use "LSUB" unless they specifically want the
      additional information offered by "LIST (SUBSCRIBED)".

      This option defines a new mailbox attribute, "\Subscribed", that
      indicates that a mailbox name is subscribed to.  The =
"\Subscribed"
      attribute MUST be supported and MUST be accurately computed when
      the SUBSCRIBED selection option is specified.

      Note that the SUBSCRIBED selection option implies the SUBSCRIBED
      return option (see below).

   REMOTE - causes the LIST command to show remote mailboxes as well as
      local ones, as described in [MBRef].  This option is intended to
      replace the RLIST command and, in conjunction with the SUBSCRIBED
      selection option, the RLSUB command.

      This option defines a new mailbox attribute, "\Remote", that
      indicates that a mailbox is a remote mailbox.  The "\Remote"
      attribute MUST be accurately computed when the REMOTE option is
      specified.

      Note that a server implementation that doesn't support any remote
      mailboxes is compliant with this specification as long as it
      accepts and ignores the REMOTE selection option.  Note that if =
the
      server choses to ignore the REMOTE selection option, it still has
      to treat RECURSIVEMATCH REMOTE as a valid combination of =
selection
      options (see also the description of the RECURSIVEMATCH option
      below).

   RECURSIVEMATCH - this option forces the server to return information
      about parent mailboxes that don't match other selection options,
      but have some submailboxes that do.  Information about children =
is
      returned in the CHILDINFO extended data item, as described in
      Section 3.3.

      Note 1: In order for a parent mailbox to be returned, it still =
has
      to match the canonical LIST pattern.

      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.

      The RECURSIVEMATCH option MUST NOT occur as the only selection

Leiba & Melnikov        Expires November 17, 2005               [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

      option, as it only makes sense when other selection options are
      also used.  The server MUST return BAD tagged response in such
      case.

      Note that even if RECURSIVEMATCH option is specified, the client
      MUST still be able to handle a case when a CHILDINFO extended =
data
      item is returned and there are no submailboxes that meet the
      selection criteria of the given LIST command, as they can be
      deleted/renamed after the LIST response was sent, but before the
      client had a chance to access them.

   The return options defined in this specification are

   SUBSCRIBED - causes the LIST command to return subscription state =
for
      all matching mailbox names.  The "\Subscribed" attribute MUST be
      supported and MUST be accurately computed when the SUBSCRIBED
      return option is specified.  Further, all mailbox flags MUST be
      accurately computed (this differs from the behaviour of the LSUB
      command).

   CHILDREN - Requests mailbox child information as originally proposed
      in [CMbox].  See Section 4, below, for details.  This option MUST
      be supported by all servers.

3.1  General principles for returning LIST responses

   This section outlines several principles that can be used by server
   implementations of this document to decide if a LIST response should
   be returned, as well as how many responses and what kind of
   information they may contain.

   1.  Exactly one LIST response should be returned for each mailbox
       name which matches the canonical LIST pattern.  Server
       implementors must not assume that clients will be able to
       assemble mailbox attributes and other information returned in
       multiple LIST responses.

   2.  There are only two reasons for including a matching mailbox name
       in the responses to the LIST command (Note that the server is
       allowed to return unsolicited responses at any time.  Such
       responses are not governed by this rule):

       A.  the mailbox name also satisfies the selection criteria;

Leiba & Melnikov        Expires November 17, 2005              [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       B.  the mailbox name doesn't satisfy the selection criteria, but
           it has at least one child mailbox name that satisfies the
           selection criteria and that doesn't match the canonical LIST
           pattern.
           For more information on this case see the CHILDINFO extended
           data item described in Section 3.3.  Note that the CHILDINFO
           extended data item can only be returned when the
           RECURSIVEMATCH selection option is specified.

   3.  Attributes returned in the same LIST response must be treated
       additively.  For example the following response

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

       means that the "Fruit/Peach" mailbox doesn't exist, but it is
       subscribed.

3.2  Additional requirements on LIST-EXTENDED clients

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred
   from it.  For example, the client must treat presence of the
   \NoInferiors attribute as if the \HasNoChildren attribute was also
   sent by the server.

   The following table summarizes inference rules described in
   Section 3.

               +--------------------+-------------------+
               | returned attribute | implied attribute |
               +--------------------+-------------------+
               |    \NoInferiors    |   \HasNoChildren  |
               |                    |                   |
               |    \NonExistent    |     \NoSelect     |
               +--------------------+-------------------+

3.3  CHILDINFO extended data item

   The CHILDINFO extended data item MUST only be returned when the
   client has specified the RECURSIVEMATCH selection option.

   The CHILDINFO extended data item in a LIST response describes the
   selection criteria that has caused it to be returned and indicates

Leiba & Melnikov        Expires November 17, 2005              [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   that the mailbox has st least one child mailbox that matches the
   selection criteria.

   The LSUB command indicates this condition by using the "\NoSelect"
   attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   CHILDINFO extended data item is more general, in that it can be used
   with any extended set of selection criteria.

   The returned selection criteria allow the client to distinguish a
   solicited response from an unsolicited one, as well as to =
distinguish
   among solicited responses caused by multiple pipelined LIST commands
   that specify different criteria.

   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.

   Examples 8 and 10 in Section 5 demonstrate the difference between
   present CHILDINFO extended data item and the "\HasChildren"
   attribute.

   The following table summarizes interaction between the =
"\NonExistent"
   attribute and CHILDINFO (the first collumn describes if the parent
   mailbox exists):

   =
+----------------+----------------+----------------+----------------+
   |     exists     |    meets the   |   has a child  |    returned    =
|
   |                |    selection   | that meets the |  LIST-EXTENDED =
|
   |                |    criteria    |    selection   | attributes and =
|
   |                |                |    criteria    |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+
   |       no       |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       yes      |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       no       |       yes      |       no       |  (\NonExistent =
|
   |                |                |                |     <attr>)    =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       no       |    (<attr>)    =
|
   |                |                |                |                =
|
   |       no       |       no       |       yes      | (\NonExistent) =
|
   |                |                |                |   + CHILDINFO  =
|
   |                |                |                |                =
|

Leiba & Melnikov        Expires November 17, 2005              [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   |       yes      |       no       |       yes      | () + CHILDINFO =
|
   |                |                |                |                =
|
   |       no       |       yes      |       yes      |  (\NonExistent =
|
   |                |                |                |    <attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       yes      |   (<attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+

   where <attr> is one or more attributes that correspond to the
   selection criteria, for example for the SUBSCRIBED option the <attr>
   is \Subscribed.

Leiba & Melnikov        Expires November 17, 2005              [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

4.  The CHILDREN return Option

   The CHILDREN return option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [CMbox].  The CHILDREN
   return option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified.

   Many IMAP4 [IMAP4] clients present to the user a hierarchical view =
of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline =
hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.  When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.
   The CHILDREN return option provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST "" * or a LIST "" % for each mailbox name.  The
   CHILDREN return option defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren.
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN return option is provided to indicate that the
   client particularly wants this information.  If the CHILDREN return
   option is present, the server MUST return these attributes even if
   their computation is expensive.

   \HasChildren

        The presence of this attribute indicates that the mailbox has
        child mailboxes.  A server SHOULD NOT set this attribute if
        there are child mailboxes, and the user does not have
        permissions to access any of them.  In this case, =
\HasNoChildren
        SHOULD be used.  In many cases, however, a server may not be
        able to efficiently compute whether a user has access to all
        child mailboxes.  As such a client MUST be prepared to accept
        the \HasChildren attribute as a hint.  That is, a mailbox MAY =
be
        flagged with the \HasChildren attribute, but no child mailboxes
        will appear in the LIST response.

   \HasNoChildren

Leiba & Melnikov        Expires November 17, 2005              [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

        The presence of this attribute indicates that the mailbox has =
NO
        child mailboxes that are accessible to the currently
        authenticated user.

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

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.

Leiba & Melnikov        Expires November 17, 2005              [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

5.  Examples

   1:  The first example shows the complete local hierarchy that will =
be
       used for the other examples.

          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: * LIST () "/" "Vegetable/Corn"

          S: A01 OK done

   2:  In the next example, we'll see the subscribed mailboxes.  This =
is
       similar to, but not equivalent with, <LSUB "" "*">.  Note that
       the mailbox called "Fruit/Peach" is subscribed to, but does not
       actually exist (perhaps it was deleted while still subscribed).
       The "Fruit" mailbox is not subscribed to, but it has two
       subscribed children.  The "Vegetable" mailbox is subscribed and
       has two children, one of them is subscribed as well.

          C: A02 LIST (SUBSCRIBED) "" "*"

          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"

          S: * LIST (\Subscribed) "/" "Fruit/Banana"

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"

Leiba & Melnikov        Expires November 17, 2005              [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: A02 OK done

   3:  The next example shows the use of the CHILDREN option.  The
       client, without having to list the second level of hierarchy, =
now
       knows which of the top-level mailboxes have submailboxes
       (children) and which do not.  Note that it's not necessary for
       the server to return the \HasNoChildren attribute for the inbox,
       because the \NoInferiors attribute already implies that, and has
       a stronger meaning.

          C: A03 LIST () "" "%" RETURN (CHILDREN)

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST (\HasChildren) "/" "Fruit"

          S: * LIST (\HasNoChildren) "/" "Tofu"

          S: * LIST (\HasChildren) "/" "Vegetable"

          S: A03 OK done

   4:  In this example we see more mailboxes, which reside on another
       server to which we may obtain referrals.  This is similar to the
       command <RLIST "" "%">.  Note that in the case of the remote
       mailboxes, the server might or might not be able to include
       CHILDREN information; it includes it if it can, and omits it if
       it can't.

          C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST (\HasChildren) "/" "Fruit"

          S: * LIST (\HasNoChildren) "/" "Tofu"

          S: * LIST (\HasChildren) "/" "Vegetable"

          S: * LIST (\Remote) "/" "Bread"

Leiba & Melnikov        Expires November 17, 2005              [Page =
17]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\HasChildren \Remote) "/" "Meat"

          S: A04 OK done

   5:  The following example also requests the server to include
       mailboxes, which reside on another server.  The server returns
       information about all mailboxes which are subscribed.  This is
       similar to the command <RLSUB "" "%">.  We also see the use of
       two selection options.

          C: A05 LIST (REMOTE SUBSCRIBED) "" "*"

          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"

          S: * LIST (\Subscribed) "/" "Fruit/Banana"

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

          S: * LIST (\Subscribed) "/" "Vegetable"

          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"

          S: * LIST (\Remote \Subscribed) "/" "Bread"

          S: A05 OK done

   6:  The following example requests the server to include mailboxes,
       which reside on another server.  The server is requested to
       return subscription information for all returned mailboxes.  =
This
       is different from the example above.

       Note that the output of this command is not a superset of the
       output in the previous example, as it doesn't include LIST
       response for the non-existent "Fruit/Peach".

          C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)

          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"

          S: * LIST () "/" "Fruit"

Leiba & Melnikov        Expires November 17, 2005              [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST () "/" "Fruit/Apple"

          S: * LIST (\Subscribed) "/" "Fruit/Banana"

          S: * LIST () "/" "Tofu"

          S: * LIST (\Subscribed) "/" "Vegetable"

          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"

          S: * LIST () "/" "Vegetable/Corn"

          S: * LIST (\Remote \Subscribed) "/" "Bread"

          S: * LIST (\Remote) "/" "Meat"

          S: A06 OK done

   7:  In the following example the client has specified multiple
       mailbox patterns.  Note that this example doesn't use the =
mailbox
       hierarchy used in the previous examples.

          C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")

          S: * LIST () "/" "INBOX"

          S: * LIST (\NoInferiors) "/" "Drafts"

          S: * LIST () "/" "Sent/March2004"

          S: * LIST (\Marked) "/" "Sent/December2003"

          S: * LIST () "/" "Sent/August2004"

          S: BBB OK done

   8:  The following example demonstates the difference between
       \HasChildren attribute and CHILDINFO extended data item.

       Let's assume there is the following hierarchy:

Leiba & Melnikov        Expires November 17, 2005              [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          C: C01 LIST "" "*"

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST () "/" "Foo"

          S: * LIST () "/" "Foo/Bar"

          S: * LIST () "/" "Foo/Baz"

          S: * LIST () "/" "Moo"

          S: C01 OK done

       If the client asks RETURN (CHILDREN) it will get this:

          C: CA3 LIST "" "%" RETURN (CHILDREN)

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST (\HasChildren) "/" "Foo"

          S: * LIST (\HasNoChildren) "/" "Moo"

          S: CA3 OK done

       A) Let's also assume that the mailbox "Foo/Baz" is the only
       subscribed mailbox.  Then we get this result:

          C: C02 LIST (SUBSCRIBED) "" "*"

          S: * LIST (\Subscribed) "/" "Foo/Baz"

          S: C02 OK done

       Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
       will return no mailboxes (as the mailboxes "Moo", "Foo" and
       "Inbox" are NOT subscribed).  However, if the client issues =
this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"

Leiba & Melnikov        Expires November 17, 2005              [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))

          S: C04 OK done

       i.e. the mailbox "Foo" is not subscribed, but it has a child =
that
       is.

       A1) If the mailbox "Foo" had been subscribed instead, the last
       command would return this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"

          S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))

          S: C04 OK done

       or even this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"

          S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))

          S: C04 OK done

       A2) If we assume instead that the mailbox "Foo" is not part of
       the original hierarchy and is not subscribed, the last command
       will give this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"

          S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))

          S: C04 OK done

       B) Now, let's assume that no mailbox is subscribed.  In this =
case
       the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will =
return
       no responses, as there are no subscribed children (even though
       "Foo" has children).

Leiba & Melnikov        Expires November 17, 2005              [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       C) And finally, suppose that only the mailboxes "Foo" and "Moo"
       are subscribed.  In that case we see this result:

          C: LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)

          S: * LIST (\HasChildren \Subscribed) "/" "Foo"

          S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"

       (which means that the mailbox "Foo" has children, but none of
       them is subscribed).

   9:  The following example demonstrates that the CHILDINFO extended
       data item is returned whether children mailboxes match the
       canonical LIST pattern or not.

       Let's assume there is the following hierarchy:

          C: D01 LIST "" "*"

          S: * LIST (\Marked \NoInferiors) "/" "inbox"

          S: * LIST () "/" "foo2"

          S: * LIST () "/" "foo2/bar1"

          S: * LIST () "/" "foo2/bar2"

          S: * LIST () "/" "baz2"

          S: * LIST () "/" "baz2/bar2"

          S: * LIST () "/" "baz2/bar22"

          S: * LIST () "/" "baz2/bar222"

          S: * LIST () "/" "eps2"

          S: * LIST () "/" "eps2/mamba"

          S: * LIST () "/" "quux2/bar2"

Leiba & Melnikov        Expires November 17, 2005              [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: D01 OK done

       And that the following mailboxes are subscribed:

          C: D02 LIST (SUBSCRIBED) "" "*"

          S: * LIST (\Subscribed) "/" "foo2/bar1"

          S: * LIST (\Subscribed) "/" "foo2/bar2"

          S: * LIST (\Subscribed) "/" "baz2/bar2"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2"

          S: * LIST (\Subscribed) "/" "eps2/mamba"

          S: * LIST (\Subscribed) "/" "quux2/bar2"

          S: D02 OK done

       The client issues the following command first:

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"

          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "foo2/bar2"

          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "baz2/bar2"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))

Leiba & Melnikov        Expires November 17, 2005              [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\Subscribed) "/" "quux2/bar2"

          S: D03 OK done

       and the server may also include

          S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO"
          ("SUBSCRIBED")))

       The CHILDINFO extended data item is returned for mailboxes
       "foo2", "baz2" and "eps2", because all of them have subscribed
       children, even though for the mailbox "foo2" only one of the two
       subscribed children match the pattern, for the mailbox "baz2" =
all
       the subscribed children match the pattern and for the mailbox
       "eps2" none of the subscribed children match the pattern.

       Note that if the client issues

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"

          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "foo2/bar1"

          S: * LIST (\Subscribed) "/" "foo2/bar2"

          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "baz2/bar2"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))

          S: * LIST (\Subscribed) "/" "eps2/mamba"

          S: * LIST (\Subscribed) "/" "quux2/bar2"

          S: D03 OK done

Leiba & Melnikov        Expires November 17, 2005              [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
       have the CHILDINFO extended data item, even though this
       information is redundant and the client can determine it by
       itself.

   10: The following example shows usage of multiple mailbox patterns.
       It also demonstrates that the presence of the CHILDINFO extended
       data item doesn't necessarily imply \HasChildren.

          C: a1 LIST "" ("foo" "foo/*")

          S: * LIST () "/" foo

          S: a1 OK done

          C: a2 LIST (SUBSCRIBED) "" "foo/*"

          S: * LIST (\Subscribed \NonExistent) "/" foo/bar

          S: a2 OK done

          C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN
          (CHILDREN)

          S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
          ("SUBSCRIBED")))

          S: a3 OK done

Leiba & Melnikov        Expires November 17, 2005              [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

6.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].

   "vendor-token" is defined in [ACAP].  Note that this normative
   reference to ACAP is an issue in moving this spec forward, since =
ACAP
   will never move to Draft Standard.  The definitions of =
"vendor-token"
   and of the IANA registry must eventually go somewhere else, in a
   document that can be moved forward on the standards track.

   childinfo-extended-item =3D "CHILDINFO" SP "(" list-select-base-opt-
               quoted
               *( SP list-select-base-opt-quoted ) ")"
               ; Extended data item returned when the RECURSIVEMATCH
               ; selection option is specified.
               ; Note 1: the CHILDINFO tag can be returned
               ;  with and without surrounding quotes, as per
               ;  mbox-list-extended-item-tag production.
               ; Note 2: The selection options are returned quoted,
               ;  unlike their specification in the extended LIST
               ;  command.

   child-mbox-flag =3D "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

   eitem-standard-tag =3D atom
               ; a tag for extended list data defined in a Standard
               ; Track or Experimental RFC.

   eitem-vendor-tag =3D vendor-tag
               ; a vendor specific tag for extended list data

   list =3D      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
               [SP list-return-opts]

   list-select-opts =3D "(" [*(list-select-mod-opt SP) =
list-select-base-
               opt
               *(SP list-select-opt)] ")"
               ; list selection options, e.g.  REMOTE

Leiba & Melnikov        Expires November 17, 2005              [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   list-select-opt =3D list-select-mod-opt / list-select-base-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

   list-select-base-opt =3D "SUBSCRIBED" / "REMOTE" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted =3D <"> list-select-base-opt <">

   list-select-mod-opt =3D "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-return-opts =3D "RETURN" SP "(" [return-option *(SP return-
               option)] ")"
               ; list return options, e.g.  CHILDREN

   mailbox-list =3D "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]

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

   mbox-list-extended-item =3D "(" mbox-list-extended-item-data ")"

   mbox-list-extended-item-data =3D mbox-list-extended-item-tag SP
               nstring-list

   mbox-list-extended-item-tag =3D astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; or "eitem-standard-tag" ABNF productions.
               ; A tag registration template is described in this
               document
               ; in Section 8.5.

Leiba & Melnikov        Expires November 17, 2005              [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   mbox-list-oflag =3D child-mbox-flag / "\NonExistent" /
               / "\Subscribed" / "\Remote"

   mbox-or-pat =3D list-mailbox / patterns

   nstring-list =3D nstring /
               "(" [nstring-list *(SP nstring-list)] ")"
               ; a recursive list definition

   option-extension =3D option-vendor-tag / option-standard-tag

   option-vendor-tag =3D vendor-tag
               ; a vendor specific option

   option-standard-tag =3D atom
               ; an option defined in a Standard Track or
               ; Experimental RFC

   patterns =3D  "(" list-mailbox *(SP list-mailbox) ")"

   return-option =3D "SUBSCRIBED" / "CHILDREN" /
               option-extension

   vendor-tag =3D vendor-token "-" atom

Leiba & Melnikov        Expires November 17, 2005              [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

7.  Security Considerations

   This document describes syntactic changes to the specification of =
the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  =
They
   are described in [IMAP4] and [MBRef].

   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all =
child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access =
to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.  In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.

   The CHILDINFO extended data item has the same security =
considerations
   as the \HasChildren attribute described above.

Leiba & Melnikov        Expires November 17, 2005              [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

8.  IANA Considerations

8.1  Guidelines for IANA

   It is requested that IANA creates two new registries for LIST-
   EXTENDED options and LIST-EXTENDED response data.  The templates and
   the initial registrations are detailed below.

8.2  Registration procedure and Change control

   Registration of a LIST-EXTENDED option is done by filling in the
   template in Section 8.3 and sending it via electronic mail to
   [email-masked].  Registration of a LIST-EXTENDED extended data item =
is
   done by filling in the template in Section 8.5 and sending it via
   electronic mail to [email-masked].  IANA has the right to reject
   obviously bogus registrations, but will perform no review of claims
   made in the registration form.

   A LIST-EXTENDED option/extended data item name that starts with "V-"
   is reserved for vendor specific options/extended data items.  All
   options, whether they are vendor specific or global, should be
   registered with IANA.  If a LIST-EXTENDED extended data item is
   returned as a result of requesting a particular LIST-EXTENDED =
option,
   the name of the option SHOULD be used as the name of the LIST-
   EXTENDED extended data item.

   Each vendor specific options/extended data item MUST start with =
their
   vendor-token ("vendor prefix").  The vendor-token MUST be registered
   with IANA, using the [ACAP] vendor subtree registry.

   Standard LIST-EXTENDED option/extended data item names are case
   insensitive.  If the vendor prefix is omitted from a vendor specific
   LIST-EXTENDED option/extended data item name, the rest is case
   insensitive.  The vendor prefix itself is not case-sensitive, as it
   might contain non-ASCII characters.

   While the registration procedures do not require it, authors of =
LIST-
   EXTENDED options/extended data items are encouraged to seek =
community
   review and comment whenever that is feasible.  Authors may seek
   community review by posting a specification of their proposed
   mechanism as an Internet- Draft.  LIST-EXTENDED options/extended =
data
   items intended for widespread use should be standardized through the
   normal IETF process, when appropriate.

   Comments on registered LIST-EXTENDED options/extended response data
   should first be sent to the "owner" of the mechanism and/or to the
   IMAPEXT WG mailing list.  Submitters of comments may, after a
   reasonable attempt to contact the owner, request IANA to attach =
their

Leiba & Melnikov        Expires November 17, 2005              [Page =
30]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   comment to the registration itself.  If IANA approves of this, the
   comment will be made accessible in conjunction with the registration
   LIST-EXTENDED options/ extended response data itself.

   Once a LIST-EXTENDED registration has been published by IANA, the
   author may request a change to its definition.  The change request
   follows the same procedure as the registration request.

   The owner of a LIST-EXTENDED registration may pass responsibility =
for
   the registered option/extended data item to another person or agency
   by informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a LIST-EXTENDED option/
   extended data item.  The most common case of this will be to enable
   changes to be made to mechanisms where the author of the =
registration
   has died, moved out of contact or is otherwise unable to make =
changes
   that are important to the community.

   LIST-EXTENDED registrations may not be deleted; mechanisms which are
   no longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such LIST-EXTENDED options/
   extended data items will be clearly marked in the lists published by
   IANA.

   The IESG is considered to be the owner of all LIST-EXTENDED options/
   extended data items which are on the IETF standards track.

8.3  Registration template for LIST-EXTENDED options

   To: [email-masked]
   Subject: Registration of LIST-EXTENDED option X

   LIST-EXTENDED option name:

   LIST-EXTENDED option type: (One of SELECTION or RETURN)

   Implied return options(s), if the option type is SELECTION: (zero or
   more)

   LIST-EXTENDED option description:

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

Leiba & Melnikov        Expires November 17, 2005              [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Person and email address to contact for further information:

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.4  Initial LIST-EXTENDED option registrations

   It is requested that the LIST-EXTENDED option registry be populated
   with the following entries:

   1.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option SUBSCRIBED

       LIST-EXTENDED option name: SUBSCRIBED

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): SUBSCRIBED

       LIST-EXTENDED option description: Causes the LIST command to =
list
       subscribed mailboxes, rather than the actual mailboxes.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   2.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option REMOTE

       LIST-EXTENDED option name: REMOTE

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): (none)

       LIST-EXTENDED option description: causes the LIST command to
       return remote mailboxes as well as local ones, as described in

Leiba & Melnikov        Expires November 17, 2005              [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       RFC 2193.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   3.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option SUBSCRIBED

       LIST-EXTENDED option name: SUBSCRIBED

       LIST-EXTENDED option type: RETURN

       LIST-EXTENDED option description: Causes the LIST command to
       return subscription state.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   4.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH

       LIST-EXTENDED option name: RECURSIVEMATCH

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): (none)

       LIST-EXTENDED option description: Requests that CHILDINFO

Leiba & Melnikov        Expires November 17, 2005              [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       extended data item is to be returned.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   5.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option CHILDREN

       LIST-EXTENDED option name: CHILDREN

       LIST-EXTENDED option type: RETURN

       LIST-EXTENDED option description: Requests mailbox child
       information.

       Published specification : XXXX, Section 3 and Section 4.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

8.5  Registration template for LIST-EXTENDED extended data item

   To: [email-masked]
   Subject: Registration of X LIST-EXTENDED extended data item

   LIST-EXTENDED extended data item tag:

   LIST-EXTENDED extended data item description:

   Which LIST-EXTENDED option(s) (and their types) causes this extended
   data item to be returned (if any):

Leiba & Melnikov        Expires November 17, 2005              [Page =
34]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.6  Initial LIST-EXTENDED extended data item registrations

   It is requested that the LIST-EXTENDED extended data item registry =
be
   populated with the following entries:

   1.  To: [email-masked]
       Subject: Registration of CHILDINFO LIST-EXTENDED extended data
       item

       LIST-EXTENDED extended data item tag: CHILDINFO

       LIST-EXTENDED extended data item description: The CHILDINFO
       extended data item describes the selection criteria that has
       caused it to be returned and indicates that the mailbox has one
       or more child mailbox that match the selection criteria.

       Which LIST-EXTENDED option(s) (and their types) causes this
       extended data item to be returned (if any): RECURSIVEMATCH
       selection option

       Published specification : XXXX, Section 3.3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

Leiba & Melnikov        Expires November 17, 2005              [Page =
35]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

9.  Acknowledgements

   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in Section 4, is theirs.

   This document is the result of discussions on the IMAP4 and IMAPEXT
   mailing lists and is meant to reflect consensus of those groups.  In
   particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo
   Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt
   Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were
   active participants in those discussions or made suggestions to this
   document.

10.  Normative References

   [ABNF]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 2234, November 1997.

   [ACAP]   Newman, C. and J. Myers, "ACAP -- Application Configuration
            Access Protocol", RFC 2244, November 1997.

   [CMbox]  Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.

   [IMAP4]  Crispin, M., "Internet Message Access Protocol - Version
            4rev1", RFC 3501, March 2003.

   [Kwds]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", RFC 2119, March 1997.

   [MBRef]  Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
            September 1997.

Authors' Addresses

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532
   US

   Phone: +1 914 784 7941
   Email: [email-masked]

Leiba & Melnikov        Expires November 17, 2005              [Page =
36]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: [email-masked]
   URI:   http://www.melnikov.ca/

Leiba & Melnikov        Expires November 17, 2005              [Page =
37]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Leiba & Melnikov        Expires November 17, 2005              [Page =
38]
=0C

--==========92EB6F57300CB3B266C8==========--

Date: Mon, 16 May 2005 10:57:55 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
cc: Lisa Dusseault <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-13, ready for last call
Sender: [email-masked]

--==========3BDCC6310244676E312C==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I've just submitted the attached draft to the ID editor, and it's ready
for last call.  The only change between this and the -12 version is the
removal of the "comment on these things" notes, since there were no
comments asking for any changes.  I also removed a couple of
draft-specific things, so, for instance, the capability is now
"LISTEXT" instead of the draft placekeeper string.

I'm still not happy with all the aspects of example 9, but since no one
else had anything to say about it, it stays as is.

Lisa:  Go wild with it....

Barry

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

--==========3BDCC6310244676E312C==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-imapext-list-extensions-13.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-13.txt"; size=65554

IMAP Extensions Working Group                                   B. =
Leiba
Internet-Draft                           IBM T.J. Watson Research =
Center
Updates: 2193 (if approved)                                  A. =
Melnikov
Obsoletes: 3348 (if approved)                              Isode =
Limited
Expires: November 17, 2005                                  May 16, =
2005

                     IMAP4 LIST Command Extensions
                 draft-ietf-imapext-list-extensions-13

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists 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

Leiba & Melnikov        Expires November 17, 2005               [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   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.

Note

   A revised version of this draft document will be submitted to the =
RFC
   editor as an Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked].

   This document obsoletes RFC 3348 and updates RFC 2193.

Leiba & Melnikov        Expires November 17, 2005               [Page =
2]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

Table of Contents

   1.  Conventions used in this document  . . . . . . . . . . . . . .  =
4

   2.  Introduction and overview  . . . . . . . . . . . . . . . . . .  =
5

   3.  Extended LIST Command  . . . . . . . . . . . . . . . . . . . .  =
6
   3.1 General principles for returning LIST responses  . . . . . . . =
10
   3.2 Additional requirements on LISTEXT clients . . . . . . . . . . =
11
   3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . =
11

   4.  The CHILDREN return Option . . . . . . . . . . . . . . . . . . =
13

   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . =
15

   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . =
22

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . =
25

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . =
26
   8.1 Guidelines for IANA  . . . . . . . . . . . . . . . . . . . . . =
26
   8.2 Registration procedure and Change control  . . . . . . . . . . =
26
   8.3 Registration template for LISTEXT options  . . . . . . . . . . =
27
   8.4 Initial LISTEXT option registrations . . . . . . . . . . . . . =
28
   8.5 Registration template for LISTEXT extended data item . . . . . =
30
   8.6 Initial LISTEXT extended data item registrations . . . . . . . =
31

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
32

   10. Normative References . . . . . . . . . . . . . . . . . . . . . =
32

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
32

       Intellectual Property and Copyright Statements . . . . . . . . =
34

Leiba & Melnikov        Expires November 17, 2005               [Page =
3]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

1.  Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Kwds].

   The term "canonical LIST pattern" refers to the canonical pattern
   constructed internally by the server from the reference and mailbox
   name arguments (Section 6.3.8 of [IMAP4]).  The [IMAP4] LIST command
   returns only mailboxes that match the canonical LIST pattern.

   Other terms are introduced where they are referenced for the first
   time.

Leiba & Melnikov        Expires November 17, 2005               [Page =
4]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

2.  Introduction and overview

   The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:
   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");
   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");
   3.  if the LIST command has more than 2 parameters ("LIST return
       options");

   Otherwise the original syntax is used.

   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB =
commands
   described in [MBRef].  We are also defining the mechanism to request
   extended mailbox information, such as is described in the "Child
   Mailbox Extension" [CMbox].  The base LSUB command is not deprecated
   by this extension; rather, this extension adds a way to obtain
   subscription information with more options, with those server
   implementations that support it.  Clients that simply need a list of
   subscribed mailboxes, as provided by the LSUB command, SHOULD
   continue to use that command.

   This document defines an IMAP4 extension that is identified by the
   capability string "LISTEXT".  The LISTEXT extension makes the
   following changes to the IMAP4 protocol, which are described in more
   detail in Section 3 and Section 4:

   a.  defines new syntax for LIST command options.
   b.  extends LIST to allow for multiple mailbox patterns.
   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and
       RECURSIVEMATCH.
   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.
   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".
   f.  adds CHILDINFO extended data item.

Leiba & Melnikov        Expires November 17, 2005               [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

3.  Extended LIST Command

   This extension updates the syntax of the LIST command to allow for
   multiple mailbox patterns to be specified, if they are enclosed in
   parantheses.  A mailbox name match a list of mailbox patterns if it
   matches at least one mailbox pattern.  Note that if a mailbox name
   matches multiple mailbox patterns from the list, the server should
   return only a single LIST response.

   Note that the non-extended LIST command is required to treat an =
empty
   ("" string) mailbox name argument as a special request to return the
   hierarchy delimiter and the root name of the name given in the
   reference parameter (as per [IMAP4]).  However ANY extended LIST
   command (extended in any of 3 ways specified in Section 2, or any
   combination of therof) MUST NOT treat the empty mailbox name as such
   special request and any regular processing described in this =
document
   applies.  In particular, if an extended LIST command has multiple
   mailbox names and one (or more) of them is the empty string, the
   empty string MUST be ignored for the purpose of matching.

   Some servers might restrict which patterns are allowed in a LIST
   command.  If a server doesn't accept a particular pattern, it MUST
   silently ignore it.

   The LIST command syntax is also extended in two additional ways: by
   adding a parenthesized list of command options between the command
   name and the reference name (LIST selection options) and an optional
   list of options at the end that control what kind of information
   should be returned (LIST return options).  See the formal syntax in
   Section 6 for specific details.

   A LIST selection option tells the server which mailbox names should
   be selected by the LIST operation.  The server should return
   information about all mailbox names that match any of the "canonical
   LIST pattern" (as described above) and satisfy additional selection
   criteria (if any) specified by the LIST selection options.  Let's
   call any such mailbox name a "matched mailbox name".  When multiple
   selection options are specified, the server MUST return information
   about mailbox names that satisfy every selection option, unless a
   description of a particular specified option prescribes special
   rules.  An example of an option prescribing special rules is the
   RECURSIVEMATCH selection option described later in this section.  We
   will use the term "selection criteria" when referring collectively =
to
   all selection options specified in a LIST command.

   A LIST return option controls which information is returned for each
   matched mailbox name.  Note that return options MUST NOT cause the
   server to report information about additional mailbox names.  If the

Leiba & Melnikov        Expires November 17, 2005               [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   client has not specified any return option, only information about
   attributes should be returned by the server.  (Of course the server
   is allowed to include any other information at will.)

   Both selection and return command options will be defined in this
   document and in approved extension documents; each option will be
   enabled by a capability string (one capability may enable multiple
   options), and a client MUST NOT send an option for which the server
   has not advertised support.  A server MUST respond to options it =
does
   not recognize with a BAD response.  The client SHOULD NOT specify =
any
   option more than once, however if the client does this, the server
   MUST act as if it received the option only once.  The order in which
   options are specified by the client is not significant.

   In general, each selection option except for RECURSIVEMATCH will =
have
   a corresponding return option.  The REMOTE selection option is an
   anomaly in this regard, and does not have a corresponding return
   option.  That is because it expands, rather than restricts, the set
   of mailboxes that are returned.  Future extensions to this
   specification should keep parallelism in mind, and define a pair of
   corresponding options.

   This extension is identified by the capability string "LISTEXT", and
   support for it is a prerequisite for any future extensions that
   require specialized forms of the LIST command.  Such extensions MUST
   refer to this document and MUST add their function through command
   options as described herein.  Note that extensions that don't =
require
   support for an extended LIST command, but use extended LIST =
responses
   (see below), don't need to advertise the "LISTEXT" capability =
string.

   This extension also defines extensions to the LIST response, =
allowing
   a series of extended fields at the end, a parenthesized list of
   tagged data (also referred to as "extended data item").  The first
   element of an extended field is a tag, which identifies type of the
   data.  Tags MUST be registered with IANA, as described in Section =
8.5
   of this document.  An example of such extended set might be

      ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample
      "text"))

   or...

      ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more
      text"))

   See the formal grammar, below, for the full syntactic details.  The
   server MUST NOT return any extended data item, unless the client has
   expressed its ability to support extended LIST responses, for =
example

Leiba & Melnikov        Expires November 17, 2005               [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   by using an extended LIST command.  The server MAY return data in =
the
   extended fields that was not solicited by the client.  The client
   MUST ignore all extended fields it doesn't recognize.

   The LISTEXT capability also defines several new mailbox attributes.

   The "\NonExistent" attribute indicates that a mailbox does not
   actually exist.  Note that this attribute is not meaningful by
   itself, as mailboxes that match the canonical LIST pattern but don't
   exist must not be returned unless one of the two conditions listed
   below is also satisfied:

   a.  the mailbox also satisfies the selection criteria (for example,
       its name is subscribed and the "SUBSCRIBED" selection option has
       been specified)

   b.  "RECURSIVEMATCH" has been specified, and the mailbox has at =
least
       one child mailbox that matches the LIST pattern and selection
       criteria.

   In practice this means that the "\NonExistent" attribute is usually
   returned with one or more of "\Subscribed", "\Remote" or the
   CHILDINFO extended data item (see their description below).

   The "\NonExistent" attribute implies "\NoSelect".  The =
"\NonExistent"
   attribute MUST be supported and MUST be accurately computed.

   The selection options defined in this specification are

   SUBSCRIBED - causes the LIST command to list subscribed names, =
rather
      than the existing mailboxes.  This will often be a subset of the
      actual mailboxes.  It's also possible for this list to contain =
the
      names of mailboxes that don't exist.  In any case, the list MUST
      include exactly those mailbox names that match the canonical list
      pattern and are subscribed to.  This option is intended to
      supplement the LSUB command.  Of particular note are the mailbox
      attributes as returned by this option, compared with what is
      returned by LSUB.  With the latter, the attributes returned may
      not reflect the actual attribute status on the mailbox name, and
      the \NoSelect attribute has a special meaning (it indicates that
      this mailbox is not, itself, subscribed, but that it has child
      mailboxes that are).  With the SUBSCRIBED selection option
      described here, the attributes are accurate, complete, and have =
no
      special meanings.  "LSUB" and "LIST (SUBSCRIBED)" are, thus, not
      the same thing, and some servers must do significant extra work =
to
      respond to "LIST (SUBSCRIBED)".  Because of this, clients SHOULD
      continue to use "LSUB" unless they specifically want the
      additional information offered by "LIST (SUBSCRIBED)".

Leiba & Melnikov        Expires November 17, 2005               [Page =
8]
=0C

      This option defines a new mailbox attribute, "\Subscribed", that
      indicates that a mailbox name is subscribed to.  The =
"\Subscribed"
      attribute MUST be supported and MUST be accurately computed when
      the SUBSCRIBED selection option is specified.

      Note that the SUBSCRIBED selection option implies the SUBSCRIBED
      return option (see below).

   REMOTE - causes the LIST command to show remote mailboxes as well as
      local ones, as described in [MBRef].  This option is intended to
      replace the RLIST command and, in conjunction with the SUBSCRIBED
      selection option, the RLSUB command.

      This option defines a new mailbox attribute, "\Remote", that
      indicates that a mailbox is a remote mailbox.  The "\Remote"
      attribute MUST be accurately computed when the REMOTE option is
      specified.

      Note that a server implementation that doesn't support any remote
      mailboxes is compliant with this specification as long as it
      accepts and ignores the REMOTE selection option.  Note that if =
the
      server choses to ignore the REMOTE selection option, it still has
      to treat RECURSIVEMATCH REMOTE as a valid combination of =
selection
      options (see also the description of the RECURSIVEMATCH option
      below).

   RECURSIVEMATCH - this option forces the server to return information
      about parent mailboxes that don't match other selection options,
      but have some submailboxes that do.  Information about children =
is
      returned in the CHILDINFO extended data item, as described in
      Section 3.3.

      Note 1: In order for a parent mailbox to be returned, it still =
has
      to match the canonical LIST pattern.

      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.

      The RECURSIVEMATCH option MUST NOT occur as the only selection
      option, as it only makes sense when other selection options are
      also used.  The server MUST return BAD tagged response in such
      case.

      Note that even if RECURSIVEMATCH option is specified, the client
      MUST still be able to handle a case when a CHILDINFO extended =
data
      item is returned and there are no submailboxes that meet the
      selection criteria of the given LIST command, as they can be
      deleted/renamed after the LIST response was sent, but before the
      client had a chance to access them.

Leiba & Melnikov        Expires November 17, 2005               [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   The return options defined in this specification are

   SUBSCRIBED - causes the LIST command to return subscription state =
for
      all matching mailbox names.  The "\Subscribed" attribute MUST be
      supported and MUST be accurately computed when the SUBSCRIBED
      return option is specified.  Further, all mailbox flags MUST be
      accurately computed (this differs from the behaviour of the LSUB
      command).

   CHILDREN - Requests mailbox child information as originally proposed
      in [CMbox].  See Section 4, below, for details.  This option MUST
      be supported by all servers.

3.1  General principles for returning LIST responses

   This section outlines several principles that can be used by server
   implementations of this document to decide if a LIST response should
   be returned, as well as how many responses and what kind of
   information they may contain.

   1.  Exactly one LIST response should be returned for each mailbox
       name which matches the canonical LIST pattern.  Server
       implementors must not assume that clients will be able to
       assemble mailbox attributes and other information returned in
       multiple LIST responses.

   2.  There are only two reasons for including a matching mailbox name
       in the responses to the LIST command (Note that the server is
       allowed to return unsolicited responses at any time.  Such
       responses are not governed by this rule):

       A.  the mailbox name also satisfies the selection criteria;

       B.  the mailbox name doesn't satisfy the selection criteria, but
           it has at least one child mailbox name that satisfies the
           selection criteria and that doesn't match the canonical LIST
           pattern.
           For more information on this case see the CHILDINFO extended
           data item described in Section 3.3.  Note that the CHILDINFO
           extended data item can only be returned when the
           RECURSIVEMATCH selection option is specified.

   3.  Attributes returned in the same LIST response must be treated
       additively.  For example the following response

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

       means that the "Fruit/Peach" mailbox doesn't exist, but it is

Leiba & Melnikov        Expires November 17, 2005              [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       subscribed.

3.2  Additional requirements on LISTEXT clients

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred
   from it.  For example, the client must treat presence of the
   \NoInferiors attribute as if the \HasNoChildren attribute was also
   sent by the server.

   The following table summarizes inference rules described in
   Section 3.

               +--------------------+-------------------+
               | returned attribute | implied attribute |
               +--------------------+-------------------+
               |    \NoInferiors    |   \HasNoChildren  |
               |                    |                   |
               |    \NonExistent    |     \NoSelect     |
               +--------------------+-------------------+

3.3  CHILDINFO extended data item

   The CHILDINFO extended data item MUST only be returned when the
   client has specified the RECURSIVEMATCH selection option.

   The CHILDINFO extended data item in a LIST response describes the
   selection criteria that has caused it to be returned and indicates
   that the mailbox has st least one child mailbox that matches the
   selection criteria.

   The LSUB command indicates this condition by using the "\NoSelect"
   attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   CHILDINFO extended data item is more general, in that it can be used
   with any extended set of selection criteria.

   The returned selection criteria allow the client to distinguish a
   solicited response from an unsolicited one, as well as to =
distinguish
   among solicited responses caused by multiple pipelined LIST commands
   that specify different criteria.

   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.

   Examples 8 and 10 in Section 5 demonstrate the difference between

Leiba & Melnikov        Expires November 17, 2005              [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   present CHILDINFO extended data item and the "\HasChildren"
   attribute.

   The following table summarizes interaction between the =
"\NonExistent"
   attribute and CHILDINFO (the first collumn describes if the parent
   mailbox exists):

   =
+----------------+----------------+----------------+----------------+
   |     exists     |    meets the   |   has a child  |    returned    =
|
   |                |    selection   | that meets the |     LISTEXT    =
|
   |                |    criteria    |    selection   | attributes and =
|
   |                |                |    criteria    |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+
   |       no       |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       yes      |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       no       |       yes      |       no       |  (\NonExistent =
|
   |                |                |                |     <attr>)    =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       no       |    (<attr>)    =
|
   |                |                |                |                =
|
   |       no       |       no       |       yes      | (\NonExistent) =
|
   |                |                |                |   + CHILDINFO  =
|
   |                |                |                |                =
|
   |       yes      |       no       |       yes      | () + CHILDINFO =
|
   |                |                |                |                =
|
   |       no       |       yes      |       yes      |  (\NonExistent =
|
   |                |                |                |    <attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       yes      |   (<attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+

   where <attr> is one or more attributes that correspond to the
   selection criteria, for example for the SUBSCRIBED option the <attr>
   is \Subscribed.

Leiba & Melnikov        Expires November 17, 2005              [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

4.  The CHILDREN return Option

   The CHILDREN return option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [CMbox].  The CHILDREN
   return option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified.

   Many IMAP4 [IMAP4] clients present to the user a hierarchical view =
of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline =
hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.  When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.
   The CHILDREN return option provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST "" * or a LIST "" % for each mailbox name.  The
   CHILDREN return option defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren.
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN return option is provided to indicate that the
   client particularly wants this information.  If the CHILDREN return
   option is present, the server MUST return these attributes even if
   their computation is expensive.

   \HasChildren
        The presence of this attribute indicates that the mailbox has
        child mailboxes.  A server SHOULD NOT set this attribute if
        there are child mailboxes, and the user does not have
        permissions to access any of them.  In this case, =
\HasNoChildren
        SHOULD be used.  In many cases, however, a server may not be
        able to efficiently compute whether a user has access to all
        child mailboxes.  As such a client MUST be prepared to accept
        the \HasChildren attribute as a hint.  That is, a mailbox MAY =
be
        flagged with the \HasChildren attribute, but no child mailboxes
        will appear in the LIST response.

   \HasNoChildren
        The presence of this attribute indicates that the mailbox has =
NO
        child mailboxes that are accessible to the currently
        authenticated user.

Leiba & Melnikov        Expires November 17, 2005              [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

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

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.

Leiba & Melnikov        Expires November 17, 2005              [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

5.  Examples

   1:  The first example shows the complete local hierarchy that will =
be
       used for the other examples.

          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: * LIST () "/" "Vegetable/Corn"
          S: A01 OK done

   2:  In the next example, we'll see the subscribed mailboxes.  This =
is
       similar to, but not equivalent with, <LSUB "" "*">.  Note that
       the mailbox called "Fruit/Peach" is subscribed to, but does not
       actually exist (perhaps it was deleted while still subscribed).
       The "Fruit" mailbox is not subscribed to, but it has two
       subscribed children.  The "Vegetable" mailbox is subscribed and
       has two children, one of them is subscribed as well.

          C: A02 LIST (SUBSCRIBED) "" "*"
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"
          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: A02 OK done

   3:  The next example shows the use of the CHILDREN option.  The
       client, without having to list the second level of hierarchy, =
now
       knows which of the top-level mailboxes have submailboxes
       (children) and which do not.  Note that it's not necessary for
       the server to return the \HasNoChildren attribute for the inbox,
       because the \NoInferiors attribute already implies that, and has
       a stronger meaning.

          C: A03 LIST () "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Fruit"
          S: * LIST (\HasNoChildren) "/" "Tofu"
          S: * LIST (\HasChildren) "/" "Vegetable"
          S: A03 OK done

Leiba & Melnikov        Expires November 17, 2005              [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   4:  In this example we see more mailboxes, which reside on another
       server to which we may obtain referrals.  This is similar to the
       command <RLIST "" "%">.  Note that in the case of the remote
       mailboxes, the server might or might not be able to include
       CHILDREN information; it includes it if it can, and omits it if
       it can't.

          C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Fruit"
          S: * LIST (\HasNoChildren) "/" "Tofu"
          S: * LIST (\HasChildren) "/" "Vegetable"
          S: * LIST (\Remote) "/" "Bread"
          S: * LIST (\HasChildren \Remote) "/" "Meat"
          S: A04 OK done

   5:  The following example also requests the server to include
       mailboxes, which reside on another server.  The server returns
       information about all mailboxes which are subscribed.  This is
       similar to the command <RLSUB "" "%">.  We also see the use of
       two selection options.

          C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"
          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
          S: * LIST (\Subscribed) "/" "Vegetable"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: * LIST (\Remote \Subscribed) "/" "Bread"
          S: A05 OK done

   6:  The following example requests the server to include mailboxes,
       which reside on another server.  The server is requested to
       return subscription information for all returned mailboxes.  =
This
       is different from the example above.

       Note that the output of this command is not a superset of the
       output in the previous example, as it doesn't include LIST
       response for the non-existent "Fruit/Peach".

          C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST () "/" "Fruit"
          S: * LIST () "/" "Fruit/Apple"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"

Leiba & Melnikov        Expires November 17, 2005              [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST () "/" "Tofu"
          S: * LIST (\Subscribed) "/" "Vegetable"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: * LIST () "/" "Vegetable/Corn"
          S: * LIST (\Remote \Subscribed) "/" "Bread"
          S: * LIST (\Remote) "/" "Meat"
          S: A06 OK done

   7:  In the following example the client has specified multiple
       mailbox patterns.  Note that this example doesn't use the =
mailbox
       hierarchy used in the previous examples.

          C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
          S: * LIST () "/" "INBOX"
          S: * LIST (\NoInferiors) "/" "Drafts"
          S: * LIST () "/" "Sent/March2004"
          S: * LIST (\Marked) "/" "Sent/December2003"
          S: * LIST () "/" "Sent/August2004"
          S: BBB OK done

   8:  The following example demonstates the difference between
       \HasChildren attribute and CHILDINFO extended data item.

       Let's assume there is the following hierarchy:

          C: C01 LIST "" "*"
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST () "/" "Foo"
          S: * LIST () "/" "Foo/Bar"
          S: * LIST () "/" "Foo/Baz"
          S: * LIST () "/" "Moo"
          S: C01 OK done

       If the client asks RETURN (CHILDREN) it will get this:

          C: CA3 LIST "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Foo"
          S: * LIST (\HasNoChildren) "/" "Moo"
          S: CA3 OK done

       A) Let's also assume that the mailbox "Foo/Baz" is the only
       subscribed mailbox.  Then we get this result:

          C: C02 LIST (SUBSCRIBED) "" "*"

Leiba & Melnikov        Expires November 17, 2005              [Page =
17]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\Subscribed) "/" "Foo/Baz"
          S: C02 OK done

       Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
       will return no mailboxes (as the mailboxes "Moo", "Foo" and
       "Inbox" are NOT subscribed).  However, if the client issues =
this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
          S: C04 OK done

       i.e.  the mailbox "Foo" is not subscribed, but it has a child
       that is.

       A1) If the mailbox "Foo" had been subscribed instead, the last
       command would return this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       or even this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       A2) If we assume instead that the mailbox "Foo" is not part of
       the original hierarchy and is not subscribed, the last command
       will give this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       B) Now, let's assume that no mailbox is subscribed.  In this =
case
       the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will =
return
       no responses, as there are no subscribed children (even though
       "Foo" has children).

       C) And finally, suppose that only the mailboxes "Foo" and "Moo"
       are subscribed.  In that case we see this result:

          C: LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)

Leiba & Melnikov        Expires November 17, 2005              [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\HasChildren \Subscribed) "/" "Foo"
          S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"

       (which means that the mailbox "Foo" has children, but none of
       them is subscribed).

   9:  The following example demonstrates that the CHILDINFO extended
       data item is returned whether children mailboxes match the
       canonical LIST pattern or not.

       Let's assume there is the following hierarchy:

          C: D01 LIST "" "*"
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST () "/" "foo2"
          S: * LIST () "/" "foo2/bar1"
          S: * LIST () "/" "foo2/bar2"
          S: * LIST () "/" "baz2"
          S: * LIST () "/" "baz2/bar2"
          S: * LIST () "/" "baz2/bar22"
          S: * LIST () "/" "baz2/bar222"
          S: * LIST () "/" "eps2"
          S: * LIST () "/" "eps2/mamba"
          S: * LIST () "/" "quux2/bar2"
          S: D01 OK done

       And that the following mailboxes are subscribed:

          C: D02 LIST (SUBSCRIBED) "" "*"
          S: * LIST (\Subscribed) "/" "foo2/bar1"
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2"
          S: * LIST (\Subscribed) "/" "eps2/mamba"
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D02 OK done

       The client issues the following command first:

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "baz2/bar2"

Leiba & Melnikov        Expires November 17, 2005              [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D03 OK done

       and the server may also include

          S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO"
          ("SUBSCRIBED")))

       The CHILDINFO extended data item is returned for mailboxes
       "foo2", "baz2" and "eps2", because all of them have subscribed
       children, even though for the mailbox "foo2" only one of the two
       subscribed children match the pattern, for the mailbox "baz2" =
all
       the subscribed children match the pattern and for the mailbox
       "eps2" none of the subscribed children match the pattern.

       Note that if the client issues

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "foo2/bar1"
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "baz2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "eps2/mamba"
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D03 OK done

       the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
       have the CHILDINFO extended data item, even though this
       information is redundant and the client can determine it by
       itself.

   10: The following example shows usage of multiple mailbox patterns.
       It also demonstrates that the presence of the CHILDINFO extended
       data item doesn't necessarily imply \HasChildren.

          C: a1 LIST "" ("foo" "foo/*")
          S: * LIST () "/" foo

Leiba & Melnikov        Expires November 17, 2005              [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

          S: a1 OK done

          C: a2 LIST (SUBSCRIBED) "" "foo/*"
          S: * LIST (\Subscribed \NonExistent) "/" foo/bar
          S: a2 OK done

          C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN
          (CHILDREN)
          S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
          ("SUBSCRIBED")))
          S: a3 OK done

Leiba & Melnikov        Expires November 17, 2005              [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

6.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].

   "vendor-token" is defined in [ACAP].  Note that this normative
   reference to ACAP is an issue in moving this spec forward, since =
ACAP
   will never move to Draft Standard.  The definitions of =
"vendor-token"
   and of the IANA registry must eventually go somewhere else, in a
   document that can be moved forward on the standards track.

   childinfo-extended-item =3D "CHILDINFO" SP "("
               list-select-base-opt-quoted
               *( SP list-select-base-opt-quoted ) ")"
               ; Extended data item returned when the RECURSIVEMATCH
               ; selection option is specified.
               ; Note 1: the CHILDINFO tag can be returned
               ;  with and without surrounding quotes, as per
               ;  mbox-list-extended-item-tag production.
               ; Note 2: The selection options are returned quoted,
               ;  unlike their specification in the extended LIST
               ;  command.

   child-mbox-flag =3D "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

   eitem-standard-tag =3D atom
               ; a tag for extended list data defined in a Standard
               ; Track or Experimental RFC.

   eitem-vendor-tag =3D vendor-tag
               ; a vendor specific tag for extended list data

   list =3D      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
               [SP list-return-opts]

   list-select-opts =3D "(" [*(list-select-mod-opt SP)
               list-select-base-opt
               *(SP list-select-opt)] ")"
               ; list selection options, e.g.  REMOTE

   list-select-opt =3D list-select-mod-opt / list-select-base-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

Leiba & Melnikov        Expires November 17, 2005              [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   list-select-base-opt =3D "SUBSCRIBED" / "REMOTE" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted =3D <"> list-select-base-opt <">

   list-select-mod-opt =3D "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-return-opts =3D "RETURN" SP "(" [return-option *(SP
               return-option)] ")"
               ; list return options, e.g.  CHILDREN

   mailbox-list =3D "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]

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

   mbox-list-extended-item =3D "(" mbox-list-extended-item-data ")"

   mbox-list-extended-item-data =3D mbox-list-extended-item-tag SP
               nstring-list

   mbox-list-extended-item-tag =3D astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; or "eitem-standard-tag" ABNF productions.
               ; A tag registration template is described in this
               document
               ; in Section 8.5.

   mbox-list-oflag =3D child-mbox-flag / "\NonExistent" /
               / "\Subscribed" / "\Remote"

   mbox-or-pat =3D list-mailbox / patterns

   nstring-list =3D nstring /
               "(" [nstring-list *(SP nstring-list)] ")"
               ; a recursive list definition

   option-extension =3D option-vendor-tag / option-standard-tag

   option-vendor-tag =3D vendor-tag
               ; a vendor specific option

Leiba & Melnikov        Expires November 17, 2005              [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   option-standard-tag =3D atom
               ; an option defined in a Standard Track or
               ; Experimental RFC

   patterns =3D  "(" list-mailbox *(SP list-mailbox) ")"

   return-option =3D "SUBSCRIBED" / "CHILDREN" /
               option-extension

   vendor-tag =3D vendor-token "-" atom

Leiba & Melnikov        Expires November 17, 2005              [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

7.  Security Considerations

   This document describes syntactic changes to the specification of =
the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  =
They
   are described in [IMAP4] and [MBRef].

   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all =
child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access =
to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.  In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.

   The CHILDINFO extended data item has the same security =
considerations
   as the \HasChildren attribute described above.

Leiba & Melnikov        Expires November 17, 2005              [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

8.  IANA Considerations

8.1  Guidelines for IANA

   It is requested that IANA creates two new registries for LISTEXT
   options and LISTEXT extended response data.  The templates and the
   initial registrations are detailed below.

8.2  Registration procedure and Change control

   Registration of a LISTEXT option is done by filling in the template
   in Section 8.3 and sending it via electronic mail to [email-masked].
   Registration of a LISTEXT extended data item is done by filling in
   the template in Section 8.5 and sending it via electronic mail to
   [email-masked].  IANA has the right to reject obviously bogus
   registrations, but will perform no review of claims made in the
   registration form.

   A LISTEXT option/extended data item name that starts with "V-" is
   reserved for vendor specific options/extended data items.  All
   options, whether they are vendor specific or global, should be
   registered with IANA.  If a LISTEXT extended data item is returned =
as
   a result of requesting a particular LISTEXT option, the name of the
   option SHOULD be used as the name of the LISTEXT extended data item.

   Each vendor specific options/extended data item MUST start with =
their
   vendor-token ("vendor prefix").  The vendor-token MUST be registered
   with IANA, using the [ACAP] vendor subtree registry.

   Standard LISTEXT option/extended data item names are case
   insensitive.  If the vendor prefix is omitted from a vendor specific
   LISTEXT option/extended data item name, the rest is case =
insensitive.
   The vendor prefix itself is not case-sensitive, as it might contain
   non-ASCII characters.

   While the registration procedures do not require it, authors of
   LISTEXT options/extended data items are encouraged to seek community
   review and comment whenever that is feasible.  Authors may seek
   community review by posting a specification of their proposed
   mechanism as an Internet- Draft.  LISTEXT options/extended data =
items
   intended for widespread use should be standardized through the =
normal
   IETF process, when appropriate.

   Comments on registered LISTEXT options/extended response data should
   first be sent to the "owner" of the mechanism and/or to the IMAPEXT
   WG mailing list.  Submitters of comments may, after a reasonable
   attempt to contact the owner, request IANA to attach their comment =
to
   the registration itself.  If IANA approves of this, the comment will

Leiba & Melnikov        Expires November 17, 2005              [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   be made accessible in conjunction with the registration LISTEXT
   options/ extended response data itself.

   Once a LISTEXT registration has been published by IANA, the author
   may request a change to its definition.  The change request follows
   the same procedure as the registration request.

   The owner of a LISTEXT registration may pass responsibility for the
   registered option/extended data item to another person or agency by
   informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a LISTEXT option/extended
   data item.  The most common case of this will be to enable changes =
to
   be made to mechanisms where the author of the registration has died,
   moved out of contact or is otherwise unable to make changes that are
   important to the community.

   LISTEXT registrations may not be deleted; mechanisms which are no
   longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such LISTEXT options/extended
   data items will be clearly marked in the lists published by IANA.

   The IESG is considered to be the owner of all LISTEXT
   options/extended data items which are on the IETF standards track.

8.3  Registration template for LISTEXT options

   To: [email-masked]
   Subject: Registration of LISTEXT option X

   LISTEXT option name:

   LISTEXT option type: (One of SELECTION or RETURN)

   Implied return options(s), if the option type is SELECTION: (zero or
   more)

   LISTEXT option description:

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

Leiba & Melnikov        Expires November 17, 2005              [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.4  Initial LISTEXT option registrations

   It is requested that the LISTEXT option registry be populated with
   the following entries:

   1.  To: [email-masked]
       Subject: Registration of LISTEXT option SUBSCRIBED

       LISTEXT option name: SUBSCRIBED

       LISTEXT option type: SELECTION

       Implied return options(s): SUBSCRIBED

       LISTEXT option description: Causes the LIST command to list
       subscribed mailboxes, rather than the actual mailboxes.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   2.  To: [email-masked]
       Subject: Registration of LISTEXT option REMOTE

       LISTEXT option name: REMOTE

       LISTEXT option type: SELECTION

       Implied return options(s): (none)

       LISTEXT option description: causes the LIST command to return
       remote mailboxes as well as local ones, as described in RFC =
2193.

       Published specification : XXXX, Section 3.

Leiba & Melnikov        Expires November 17, 2005              [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   3.  To: [email-masked]
       Subject: Registration of LISTEXT option SUBSCRIBED

       LISTEXT option name: SUBSCRIBED

       LISTEXT option type: RETURN

       LISTEXT option description: Causes the LIST command to return
       subscription state.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   4.  To: [email-masked]
       Subject: Registration of LISTEXT option RECURSIVEMATCH

       LISTEXT option name: RECURSIVEMATCH

       LISTEXT option type: SELECTION

       Implied return options(s): (none)

       LISTEXT option description: Requests that CHILDINFO extended =
data
       item is to be returned.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

Leiba & Melnikov        Expires November 17, 2005              [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   5.  To: [email-masked]
       Subject: Registration of LISTEXT option CHILDREN

       LISTEXT option name: CHILDREN

       LISTEXT option type: RETURN

       LISTEXT option description: Requests mailbox child information.

       Published specification : XXXX, Section 3 and Section 4.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

8.5  Registration template for LISTEXT extended data item

   To: [email-masked]
   Subject: Registration of X LISTEXT extended data item

   LISTEXT extended data item tag:

   LISTEXT extended data item description:

   Which LISTEXT option(s) (and their types) causes this extended data
   item to be returned (if any):

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

Leiba & Melnikov        Expires November 17, 2005              [Page =
30]
=0C

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.6  Initial LISTEXT extended data item registrations

   It is requested that the LISTEXT extended data item registry be
   populated with the following entries:

   1.  To: [email-masked]
       Subject: Registration of CHILDINFO LISTEXT extended data item

       LISTEXT extended data item tag: CHILDINFO

       LISTEXT extended data item description: The CHILDINFO extended
       data item describes the selection criteria that has caused it to
       be returned and indicates that the mailbox has one or more child
       mailbox that match the selection criteria.

       Which LISTEXT option(s) (and their types) causes this extended
       data item to be returned (if any): RECURSIVEMATCH selection
       option

       Published specification : XXXX, Section 3.3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

Leiba & Melnikov        Expires November 17, 2005              [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

9.  Acknowledgements

   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in Section 4, is theirs.

   This document is the result of discussions on the IMAP4 and IMAPEXT
   mailing lists and is meant to reflect consensus of those groups.  In
   particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo
   Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt
   Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were
   active participants in those discussions or made suggestions to this
   document.

10.  Normative References

   [ABNF]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 2234, November 1997.

   [ACAP]   Newman, C. and J. Myers, "ACAP -- Application Configuration
            Access Protocol", RFC 2244, November 1997.

   [CMbox]  Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.

   [IMAP4]  Crispin, M., "Internet Message Access Protocol - Version
            4rev1", RFC 3501, March 2003.

   [Kwds]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", RFC 2119, March 1997.

   [MBRef]  Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
            1997.

Authors' Addresses

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532
   US

   Phone: +1 914 784 7941
   Email: [email-masked]

Leiba & Melnikov        Expires November 17, 2005              [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: [email-masked]
   URI:   http://www.melnikov.ca/

Leiba & Melnikov        Expires November 17, 2005              [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions             May =
2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Leiba & Melnikov        Expires November 17, 2005              [Page =
34]
=0C

--==========3BDCC6310244676E312C==========--

Date: Thu, 12 May 2005 14:20:11 -0700
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: necessary updates to RFC 2359 (UIDPLUS)
Organization: Networks & Distributed Computing
Sender: [email-masked]

RFC 2359 needs to clarify that the UIDPLUS extension indicates that the 
UID EXPUNGE extension is present, and does not necessarily indicate the 
APPENDUID and COPYUID response codes.

As presently constituted, RFC 2359 is ambiguous as to whether APPENDUID 
and COPYUID are mandatory responses for a UIDPLUS server.  It is also 
ambiguous as to whether a server which does not support UID EXPUNGE may 
send APPENDUID/COPYUID response codes.

I recommend that RFC 2359 be updated as follows:

. clarify that the UIDPLUS extension refers to the UID EXPUNGE command.

. recommend that servers SHOULD issue APPENDUID/COPYUID response codes.

The alternate interpretation, that UIDPLUS covers the response codes, 
necessitates that, in the case of a mail store that does not have sticky 
UIDs (that is, UIDVALIDITY changes at each SELECT), the server issue false 
(but plausible-seeming) information in an APPENDUID/COPYUID response code.

I can not believe that the intent of RFC 2359 is that a server send a 
complete fabrication in the case of a server which supports multiple mail 
stores, only some of which have sticky UIDs.

-- Mark --

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

Date: Thu, 12 May 2005 12:48:19 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SASLprep + ACL
Sender: [email-masked]

Hi,

now that RFC 4013 is out, it seems possible to authenticate with unicode 
user names. No problems for IMAP, as far as I can tell, with two 
possible exceptions:

1. Mailbox names. Some servers might need some additional logic instead 
of just concatenating "home." + username + ".INBOX". Doesn't seem like 
an IMAP issue at all to me, just a bit of implementation work.

2. ACL/2. ACL uses "identifiers", which are UTF-8 in 2068upd and ACL2. 
How shoiuld these be related to the SASLprepped identifiers used by 
AUTHENTICATE? It seems beneficial that they be the same, but who should 
be responsible for running them through SASLprep?

Arn

Date: Wed, 11 May 2005 13:50:44 -0400
From: Barry Leiba <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

> Any update on when to expect a LISTEXT document to last call?

Unless my memory is more feeble than I think it is (a distinct
possibility), I posted the latest draft to the mailing list and
asked for comments on a couple of things.  I got a reply from Mark,
which I've taken to heart, but have heard nothing else... and there
was at least one significant issue.

But now that you mention things, that's OK.  Since no one has
responded, it means that whatever I decide is fine.  So I will go
ahead and make the changes the way *I* think it should be, and I'll
post it for last call by the weekend.

So, guys, this is the last call before last call.  Please don't
make me do the work and THEN decide it has to be changed.

Barry

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

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Date: Wed, 11 May 2005 10:17:07 -0700
To: Barry Leiba <[email-masked]>
Sender: [email-masked]

Any update on when to expect a LISTEXT document to last call?

Lisa

On Mar 29, 2005, at 10:59 AM, Barry Leiba wrote:

>
>> below, in order  to come up with new milestone dates, I need to get
>> date promises out of  the active draft authors (Cyrus, Randy, Barry,
>> Alexey) for LISTEXT,  ANNOTATE and 2086upd as well as ACL2.
>
> I have just converted the plain text for the -11 version of ListExt
> into XML that works for xml2rfc -- that was a prerequisite for updates,
> since dealing directly with the plain text is too painful.  I sent the
> new text to Alexey the other day for review (to make sure I didn't
> break anything).
>
> I'll next be working on making the changes, and resolving the open
> issues.  Expect a -12 version, along with a list of what still has to
> be resolved, to be posted by 7 April.
>
> I don't think the things that need to be resolved will be very
> contentious, but, then, we thought that what we came up with at the
> interim meeting would go smoothly, and it didn't.  Anyway, if I can lay
> out the remaining issues clearly, we should be able to get through them
> on the list and get a last-call document out as -13.  Maybe go for end
> of April as the goal for making the last call?  Is that suitable?
>
> Barry
>
> --
> Barry Leiba, Pervasive Computing Technology  ([email-masked])
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>
>

Date: Tue, 10 May 2005 10:00:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: rfc 4013 + imap-i18n
Sender: [email-masked]

Hi,

I was just reading RFC 4013 to see what, if anything, needs changing in 
draft-ietf-imapext-18n. I don't see anything. It seems orthogonal. Am I 
missing something?

Arnt

Date: Tue, 3 May 2005 18:00:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SPAM/NOTSPAM IMAP extension.
Cc: Rob Siemborski <[email-masked]>, Lewis Thompson <[email-masked]>
Sender: [email-masked]

Rob Siemborski writes:
> I think -02 has a $AutoJunk and $Junk differentiation (along with 
> NotJunk versions)

Fine, then.

Arnt

Date: Tue, 3 May 2005 11:49:41 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Lewis Thompson <[email-masked]>
Subject: Re: SPAM/NOTSPAM IMAP extension.
Sender: [email-masked]

On Tue, 3 May 2005, Arnt Gulbrandsen wrote:

> Rob Siemborski writes:
>> Do the junk filtering keywords described in 
>> draft-melnikov-imap-keywords-XX.txt get you the functionality that you 
>> need?
>
> I've fooled around with this too, and I think that in my special case those 
> keywords can work, but in general they have a weakness:
>
>> (In this case, instead of having the imap server immediately process the 
>> change, some other "client" notices the flag change and does the update 
>> accordingly).
>
> Suppose that other client wants to do bayes training, or something else that 
> needs a message corpus.
>
> In that case, it cannot know whether the keyword was set a) autonomously by 
> an application, b) by command of a human, or c) after review by a human. In 
> the former case, the application should NOT include the message in the 
> training corpus. In the latter two cases, it generally should.
>
> (This may have been fixed in a newer version of the draft. I've only read 
> -00.)

I think -02 has a $AutoJunk and $Junk differentiation (along with NotJunk 
versions)

e.g.

http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-melnikov-imap-keywords-02.txt

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 3 May 2005 12:02:35 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SPAM/NOTSPAM IMAP extension.
Cc: Rob Siemborski <[email-masked]>, Lewis Thompson <[email-masked]>
Sender: [email-masked]

Rob Siemborski writes:
> Do the junk filtering keywords described in 
> draft-melnikov-imap-keywords-XX.txt get you the functionality that 
> you need?

I've fooled around with this too, and I think that in my special case 
those keywords can work, but in general they have a weakness:

> (In this case, instead of having the imap server immediately process 
> the change, some other "client" notices the flag change and does the 
> update accordingly).

Suppose that other client wants to do bayes training, or something else 
that needs a message corpus.

In that case, it cannot know whether the keyword was set a) autonomously 
by an application, b) by command of a human, or c) after review by a 
human. In the former case, the application should NOT include the 
message in the training corpus. In the latter two cases, it generally 
should.

(This may have been fixed in a newer version of the draft. I've only read -00.)

Arnt

Date: Mon, 2 May 2005 20:03:53 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Lewis Thompson <[email-masked]>
cc: [email-masked]
Subject: Re: SPAM/NOTSPAM IMAP extension.
Sender: [email-masked]

Do the junk filtering keywords described in 
draft-melnikov-imap-keywords-XX.txt get you the functionality that you 
need?

(In this case, instead of having the imap server immediately process the 
change, some other "client" notices the flag change and does the update 
accordingly).

-Rob

On Thu, 28 Apr 2005, Lewis Thompson wrote:

>
> Hi,
>
> I posted this question on the ietf-mta-filters list thinking it was
> somewhat related to the Sieve extension but got redirected here.
>
>> From what I've found an IMAP extension for marking email as SPAM or
> NOTSPAM does not exist.  I posted this to the ietf-mta-filters list
> explaining exactly what I meant:
>
> "My MTA is running with SpamAssassin and an email gets falsely
> identified as spam.  It gets delivered to a spam folder where I find it.
> I want to prevent it from happening again so I teach SpamAssassin it is
> ham and remove the SpamAssassin modifications.  The IMAP command (?)
> that does this would be (to make something up) NOTSPAM.
>
> I'm not sure of the IMAP syntax but it might be called something like:
> "NOTSPAM message-id".  The IMAP server then invokes SA and strips the
> junk (added by SA) and re-learns as ham.
>
> Also I would like to see SPAM, which is the opposite of NOTSPAM
> (surprisingly).  If some junk mail gets through SA then I want to teach
> SA that it is spam.  Maybe then it would be deleted or moved to a spam
> folder (this would probably be done by the user, not the IMAP server).
>
> Obviously in all these cases SpamAssassin could be replaced by any spam
> filter.  The IMAP server would have a command that the message simply
> gets piped through to do the learning/stripping of junk."
>
> I'm not really sure of exactly how RFC-style things work or whether this
> is really suitable.  I've spoken to a few people in passing about such
> an extension and all of them seem to think it is a good idea so I'm
> fairly sure there is "demand".
>
> What do you guys think about this and where should I go from here?
> Thanks very much,
>
> -Lewis Thompson.
>
> --
> I was so much older then, I'm younger than that now.  --Bob Dylan, 1964.
> -| msn:[email-masked] | jabber:[email-masked] | url:www.lewiz.org |-
>
>
>

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----