Subject: RE: "Friends of IMAP" dinner on Tuesday, November 8th?
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 31 Oct 2005 15:47:48 -0500
List-Id: <ietf-imapext.imc.org>

I'm in. 

Corby Wilson
Security & Mobile Connectivity

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Alexey
Melnikov
Sent: Monday, October 31, 2005 3:08 PM
To: IMAP Extensions WG
Subject: "Friends of IMAP" dinner on Tuesday, November 8th?

Hi folks,
Sorry for being so late with this message, but I would like to invite
people who haven't bought a ticket to the IETF social to come to a
dinner on Tuesday evening.
Let's call it "friends of IMAP, revision 2" :-).
I don't know where this would be yet, but I am hoping to get help from
somebody local.
If you want to join me, please email to me directly. Also let me know
about any food preferences.

Regards,
Alexey

Date: Mon, 31 Oct 2005 20:08:00 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: "Friends of IMAP" dinner on Tuesday, November 8th?
Sender: [email-masked]

Hi folks,
Sorry for being so late with this message, but I would like to invite 
people who haven't bought a ticket to the IETF social to come to a 
dinner on Tuesday evening.
Let's call it "friends of IMAP, revision 2" :-).
I don't know where this would be yet, but I am hoping to get help from 
somebody local.
If you want to join me, please email to me directly. Also let me know 
about any food preferences.

Regards,
Alexey

Date: Sun, 30 Oct 2005 14:49:50 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: annotate: wording change request
Sender: [email-masked]

In section 3.2.1, the first paragraph currently reads

    Entry names MUST be specified in a standards track or IESG approved
    experimental RFC, or fall under the vendor namespace.  See Section
    6.1 for the registration template.

I believe the intention of that is to ensure that no two clients use a 
single entry in conflicting ways. I would like to change the wording to 
clarify that.

    To ensure interoperation, entry names MUST be specified in a standards
    track or IESG approved experimental RFC. See section 6.1 for a registration
    template.

    The vendor namespace provides an exception. Within the vendor namespace,
    each vendor can define the meanings for its own annotation subtree.

Or something like that.

Arnt

Date: Fri, 28 Oct 2005 10:47:42 -0400
From: Barry Leiba <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Agenda for Vancouver meeting, Nov 8
Sender: [email-masked]

 > Of the authors of these drafts, who will be present physically?

Moi.

Barry

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

Date: Fri, 28 Oct 2005 10:33:51 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

Lisa Dusseault wrote:

> I call your attention to this draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
> -14.txt
>
> We previously did a WG last call in May 2005 but we decided for a  
> "do-over" since there were a few significant changes.
>
> 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.

Just one note: I've already told Barry to use the same syntax for 
"option-value" non-terminal as used by IMAP ABNF extensions. My 
impression was that he agreed, so consider this fixed.

> 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.  Send me email even if you reviewed draft 13 and 
> previously sent  me email about that, to let me know if you have 
> reviewed the changes in  draft 14 and are OK with them.

I've implemented revision 12.

> Because of the IETF meeting in a little over a week, let's do this 
> last  call until EOD Nov 17 (three weeks).  If you have any chance to 
> bring  up issues before IMAPEXT meets on Tuesday Nov 8, that would be 
> much  appreciated because it would give us an extra forum for discussion.

Date: Fri, 28 Oct 2005 10:29:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Agenda for Vancouver meeting, Nov 8
Sender: [email-masked]

Lisa Dusseault wrote:

> The IMAPEXT WG meeting is scheduled for 1300-1500, Tuesday Nov. 8.
>
> Here's my thought for an agenda:
>
> 1.  See if any issues have come up during WG last call on LISTEXT 
> (more  on this in separate email)
>       
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
> -14.txt
> 2.  Review status of comparator, review next steps, and nag  
> authors/editors to do revision
>      http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-05.txt
> 3.  Review status of Annotate, see if anything big has changed, nag  
> authors/editors to do revision
>      - recall last meeting the only major new thing we planned on was 
> a  response code so the server could say it didn't support private  
> annotations
>       
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-13.txt
>
> Any other agenda input?  Of the authors of these drafts, who will be  
> present physically?  Who will be in the Jabber room if they can't 
> make  it physically?

I think we should also quickly review my recent update to CONDSTORE and 
LC comments on IMAP ABNF (whichi is dependency for CONDSTORE, ANNOTATE 
and several Lemonade drafts). I would suggest to insert the discussion 
items after #1 (or #2).

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WG Last Call of LISTEXT draft 14
Date: Thu, 27 Oct 2005 16:25:13 -0700
Sender: [email-masked]

I call your attention to this draft:

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

We previously did a WG last call in May 2005 but we decided for a  
"do-over" since there were a few significant changes.

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.

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.  Send me email even if you reviewed draft 13 and previously sent  
me email about that, to let me know if you have reviewed the changes in  
draft 14 and are OK with them.

Because of the IETF meeting in a little over a week, let's do this last  
call until EOD Nov 17 (three weeks).  If you have any chance to bring  
up issues before IMAPEXT meets on Tuesday Nov 8, that would be much  
appreciated because it would give us an extra forum for discussion.

Thanks,

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Agenda for Vancouver meeting, Nov 8
Date: Thu, 27 Oct 2005 16:21:03 -0700
Sender: [email-masked]

The IMAPEXT WG meeting is scheduled for 1300-1500, Tuesday Nov. 8.

Here's my thought for an agenda:

1.  See if any issues have come up during WG last call on LISTEXT (more  
on this in separate email)
       
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
-14.txt
2.  Review status of comparator, review next steps, and nag  
authors/editors to do revision
      http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-05.txt
3.  Review status of Annotate, see if anything big has changed, nag  
authors/editors to do revision
      - recall last meeting the only major new thing we planned on was a  
response code so the server could say it didn't support private  
annotations
       
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-13.txt

Any other agenda input?  Of the authors of these drafts, who will be  
present physically?  Who will be in the Jabber room if they can't make  
it physically?

Thanks,
Lisa

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-14.txt 
Date: Fri, 21 Oct 2005 10:50:01 -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-14.txt
	Pages		: 39
	Date		: 2005-10-21
	
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-14.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-14.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-14.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-14.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 20 Oct 2005 13:44:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

>>And alternative is to have
>>
>>  option-standard-tag = atom SP option-value
>>
>>and allow option-value to be "()" if there is no value.
>>
>>I prefer this change, as this will need changes to not that many
>>documents.
>>    
>>
>
>OK, that suits my need for syntactic clarity, but it requires every
>option to have a value, so now we'd have to say
>   (SUBSCRIBED () REMOTE () RECURSIVEMATCH ())
>
>Do you really want that?
>  
>
Just for the archive: this doesn't work very well for extensions like 
CONDSTORE, which doesn't have any value after the CONSTORE select parameter.

Date: Thu, 20 Oct 2005 13:40:54 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

> > Major question:
> > What should the syntax for options with parameter values be?
>
> I'm going with this:
>
>>    option-standard-tag = atom [SP option-value]
>>
>>    option-value = "(" astring *(SP astring) ")"
>
I was about to propose the same, but please use IMAP ABNF syntax, which 
is even more permissive (allows for nested lists).

> ...which defines this:
>
> > LIST (TASTY COLOUR ("red") FRUIT TYPE ("sweet" "tart"))
> > LIST (TASTY COLOUR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))

The only problem with this is that the APPEND syntax doesn't use () 
around values. However I feel that APPEND is a different beast 
altogether and using a slightly different syntax for it is Ok. I really 
don't want to change CATENATE syntax as this moment.

Date: Wed, 19 Oct 2005 18:43:44 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070504060305030703000508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I have submitted the attached draft, intended for IETF last call.

Barry

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

--------------070504060305030703000508
Content-Type: text/plain;
 name="draft-ietf-imapext-list-extensions-14.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-imapext-list-extensions-14.txt"

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: April 22, 2006                                 October 19, 2005

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

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 April 22, 2006.

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 April 22, 2006                 [Page 1]

Internet-Draft        IMAP4 LIST Command Extensions         October 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  . . . . . . . . . . . . . . . . . . . 30

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

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37

   10. Normative References . . . . . . . . . . . . . . . . . . . . . 37

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37

       Intellectual Property and Copyright Statements . . . . . . . . 39

Leiba & Melnikov         Expires April 22, 2006                 [Page 2]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                 [Page 3]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                 [Page 4]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   f.  adds CHILDINFO extended data item.

Leiba & Melnikov         Expires April 22, 2006                 [Page 5]

Internet-Draft        IMAP4 LIST Command Extensions         October 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
   parentheses.  A mailbox name matches a list of mailbox patterns if it
   matches at least one mailbox pattern.  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 April 22, 2006                 [Page 6]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                 [Page 7]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   See the formal syntax, in Section 6, 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 descendant mailbox that does not match the LIST pattern and
       does match the 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
      descendant mailboxes that are).  With the SUBSCRIBED selection
      option described here, the attributes are accurate, complete, and

Leiba & Melnikov         Expires April 22, 2006                 [Page 8]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

      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)".

      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.

      The REMOTE selection option has no interaction with other options.
      Its effect is to tell the server to apply the other options, if
      any, to remote mailboxes, in addition to local ones.  In
      particular, it has no interaction with RECURSIVEMATCH (see below).
      A request for (REMOTE RECURSIVEMATCH) is invalid, because a
      request for (RECURSIVEMATCH) is.  A request for (REMOTE
      RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes,
      both local and remote.

   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.

Leiba & Melnikov         Expires April 22, 2006                 [Page 9]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

      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.

   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):

Leiba & Melnikov         Expires April 22, 2006                [Page 10]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

       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 descendant 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.

Leiba & Melnikov         Expires April 22, 2006                [Page 11]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   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 at least one descendant 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>)    |
   |                |                |                |                |

Leiba & Melnikov         Expires April 22, 2006                [Page 12]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   |       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 April 22, 2006                [Page 13]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 14]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 15]

Internet-Draft        IMAP4 LIST Command Extensions         October 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"

Leiba & Melnikov         Expires April 22, 2006                [Page 16]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

          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

   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"

Leiba & Melnikov         Expires April 22, 2006                [Page 17]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

          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"

Leiba & Melnikov         Expires April 22, 2006                [Page 18]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

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

          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 April 22, 2006                [Page 19]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 20]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 21]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

       C) And finally, suppose that only the mailboxes "Foo" and "Moo"
       are subscribed.  In that case we see this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN
          (CHILDREN)

          S: * LIST (\HasChildren \Subscribed) "/" "Foo"

          S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"

          S: C04 OK done

       (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"

Leiba & Melnikov         Expires April 22, 2006                [Page 22]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

          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"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))

Leiba & Melnikov         Expires April 22, 2006                [Page 23]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 24]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 25]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 = "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 = "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

   eitem-standard-tag = atom
               ; a tag for extended list data defined in a Standard
               ; Track or Experimental RFC.

   eitem-vendor-tag = vendor-tag
               ; a vendor specific tag for extended list data

   list =      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
               [SP list-return-opts]

   list-return-opts = "RETURN" SP "(" [return-option *(SP return-
               option)] ")"
               ; list return options, e.g.  CHILDREN

Leiba & Melnikov         Expires April 22, 2006                [Page 26]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   list-select-base-opt = "SUBSCRIBED" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted = <"> list-select-base-opt <">

   list-select-independent-opt = "REMOTE" / option-extension
               ; options that do not syntactically interact with
               ; other options

   list-select-mod-opt = "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-select-opt = list-select-base-opt / list-select-independent-opt
               / list-select-mod-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

   list-select-opts = "(" [
                 (*(list-select-opt SP) list-select-base-opt
                  *(SP list-select-opt))
               / (list-select-independent-opt
                  *(SP list-select-independent-opt))
               ] ")"
               ; Any number of options may be in any order
               ; This allows these:
               ;   ()
               ;   (REMOTE)
               ;   (SUBSCRIBED)
               ;   (SUBSCRIBED REMOTE)
               ;   (SUBSCRIBED RECURSIVEMATCH)
               ;   (SUBSCRIBED REMOTE RECURSIVEMATCH)
               ; But does NOT allow these:
               ;   (RECURSIVEMATCH)
               ;   (REMOTE RECURSIVEMATCH)

   mailbox-list = "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]

Leiba & Melnikov         Expires April 22, 2006                [Page 27]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

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

   mbox-list-extended-item = "(" mbox-list-extended-item-data ")"

   mbox-list-extended-item-data = mbox-list-extended-item-tag SP
               nstring-list

   mbox-list-extended-item-tag = 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 = child-mbox-flag / "\NonExistent" /
               / "\Subscribed" / "\Remote"

   mbox-or-pat = list-mailbox / patterns

   nstring-list = nstring /
               "(" [nstring-list *(SP nstring-list)] ")"
               ; a recursive list definition

   option-extension = (option-standard-tag / option-vendor-tag) [SP
               option-value]

   option-standard-tag = atom
               ; an option defined in a Standards Track or Experimental
               RFC

   option-value = "(" astring *(SP astring) ")"

   option-vendor-tag = vendor-token "-" atom
               ; a vendor specific option, non-standard

Leiba & Melnikov         Expires April 22, 2006                [Page 28]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   patterns =  "(" list-mailbox *(SP list-mailbox) ")"

   return-option = "SUBSCRIBED" / "CHILDREN" /
               option-extension

Leiba & Melnikov         Expires April 22, 2006                [Page 29]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 30]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 31]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 32]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 33]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 34]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 35]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 36]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 37]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 38]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 39]


--------------070504060305030703000508--

Date: Wed, 19 Oct 2005 17:40:09 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Cc: Barry Leiba <[email-masked]>
Sender: [email-masked]

Barry Leiba writes:
> I'm going with this:
>
>>    option-standard-tag = atom [SP option-value]
>>
>>    option-value = "(" astring *(SP astring) ")"

Fine.

> Alea jacta est.

Independently of the previous: Fine.

Arnt

Date: Wed, 19 Oct 2005 11:24:31 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

OK; lacking further responses, I'm going to declare the following,
and submit the draft:

 > General question:
 > Should we extend the syntax for selection options, to allow for
 > selection options that have parameter values?  We have no significant
 > objections to this, but only a small desire for it.  Given that there
 > is desire, and no objection, I want to put it in if we can get the
 > syntax nailed down, so I think the answer to this is "Yes."

The consensus is "yes".  Arnt doesn't like it much, Dave and Alexey
do, and I've been convinced that it's not a morass [mostly because I
was able to write reasonable grammar for it :-) ].  That's not a very
strong consensus, but it is a sufficiently rough one.

 > Minor question:
 > Should we also extend the syntax for return options?  I hadn't
 > thought we wanted to, but Alexey asked for it and I see no reason
 > not to.  Let me at least hear a little bit of "hum" here.

Same as above, answer is "yes".

 > Major question:
 > What should the syntax for options with parameter values be?

I'm going with this:

>    option-standard-tag = atom [SP option-value]
> 
>    option-value = "(" astring *(SP astring) ")"

...which defines this:

 > LIST (TASTY COLOUR ("red") FRUIT TYPE ("sweet" "tart"))
 > LIST (TASTY COLOUR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))

Alea jacta est.

Barry

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

Date: Wed, 19 Oct 2005 10:32:17 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotation and /flags/\xxx
Cc: Cyrus Daboo <[email-masked]>, Peter Coates <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> This issue was discussed at length quite a while ago and the current 
> situation is the compromise that was settled on.

But AFAICT: Everyone's unhappy with the aggregate complexity of annotate.

Arnt

Date: Wed, 19 Oct 2005 08:48:52 +0100
Subject: Re: fetch annotate response
From: Dave Cridland <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Oct 18 23:48:29 2005, Peter Coates wrote:
> S: * 1 FETCH (ANNOTATION
>    ("/comment" ("value.priv" "My comment")
>     "/altsubject" ("value.priv" "My subject")
>     "/comment" ("value.shared" "Our comment")
>     "/altsubject" ("value.shared" "Our comment")))
> S: a OK Fetch complete
> 
> 
Or:

* 1 FETCH (ANNOTATION ("/comment" ("value.priv" "My comment")))
* 1 FETCH (ANNOTATION ("/comment" ("value.shared" "Our comment")))

etc.

> I do not see anything to preclude this is the spec, but I don't 
> want to
> generate something that clients might choke on.  Perhaps I'm being 
> naive
> reading the spec.

It seems generally sane to use the most compact representation 
whenever possible, but I think the usual rule applies - a client only 
knows the server has sent everything it can when the FETCH command is 
reported to have been completed, and not when a particular FETCH 
response is received.

The problem is only worse with ANNOTATE because there's numerous ways 
of saying the same thing - if BODY[x] was rewritten to be BODY (x 
...) the same thing would apply there.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 18 Oct 2005 15:48:29 -0700
From: Peter Coates <[email-masked]>
Subject: fetch annotate response
To: [email-masked]
Sender: [email-masked]

Consider an annotate request of the form
 
C: a fetch 1 (annotation ((""/comment" "/altsubject") "value"))
 
is the required response of the form
S: * 1 FETCH (ANNOTATION
   ("/comment" ("value.priv" "My comment"
                "value.shared" "Our comment")
    "/altsubject" ("value.priv" "My subject"
                   "value.shared" "Our comment")))
S: a OK Fetch complete

Or is the following permitted?
S: * 1 FETCH (ANNOTATION
   ("/comment" ("value.priv" "My comment")
    "/comment" ("value.shared" "Our comment")
    "/altsubject" ("value.priv" "My subject")
    "/altsubject" ("value.shared" "Our comment")))
S: a OK Fetch complete

Or even the following:
S: * 1 FETCH (ANNOTATION
   ("/comment" ("value.priv" "My comment")
    "/altsubject" ("value.priv" "My subject")
    "/comment" ("value.shared" "Our comment")
    "/altsubject" ("value.shared" "Our comment")))
S: a OK Fetch complete

I do not see anything to preclude this is the spec, but I don't want to
generate something that clients might choke on.  Perhaps I'm being naive
reading the spec.

Peter

Date: Tue, 18 Oct 2005 16:26:44 -0400
From: Cyrus Daboo <[email-masked]>
To: Peter Coates <[email-masked]>, [email-masked]
Subject: Re: annotation and /flags/\xxx
Sender: [email-masked]

Hi Peter,

--On October 17, 2005 1:03:15 PM -0700 Peter Coates <[email-masked]> 
wrote:

> Why is this second way of accessing the message flags part of the
> annotate extension.  It really makes the life of a server implementer
> more difficult.  Is there any other instance in imap of having 2
> different mechanisms for accessing the same data?  Is is really that
> attractive to client implanters?

This issue was discussed at length quite a while ago and the current 
situation is the compromise that was settled on.

-- 
Cyrus Daboo

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-06.txt 
Date: Tue, 18 Oct 2005 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-06.txt
	Pages		: 16
	Date		: 2005-10-18
	
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on 
behalf of the same user, and multiple users accessing shared mailboxes. 
These clients need a mechanism to synchronize state changes for messages
within the mailbox. They must be able to guarantee that only one client 
can change message state (e.g., message flags) at any time.  An example
of such an application is use of an IMAP mailbox as a message queue with 
multiple dequeueing clients.

    The Conditional Store facility provides a protected update mechanism for
    message state information that can detect and resolve conflicts between
    multiple writing mail clients.

    This document defines an extension to IMAP (RFC 3501).

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 18 Oct 2005 21:13:49 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba writes:
> So we have two votes for this version.

It also seems to suit my concerns fairly well. Correct me if I'm wrong, 
but it seems to me that anyone who's handled listext+postaddress has 
already handled almost all of the syntax. Perhaps all.

Arnt
(proud+tired parent)

Date: Tue, 18 Oct 2005 13:43:04 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

>>   LIST (TASTY COLOR ("red") FRUIT () TYPE ("sweet" "tart"))
>>   LIST (TASTY COLOR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))
> 
> I'd actually prefer:
> 
> LIST (TASTY COLOUR ("red") FRUIT TYPE ("sweet" "tart"))
> LIST (TASTY COLOUR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))
> 
> Note two things:
> 1) List only used for parameters, not for the absence of them. I
> don't see the need.

The need, in general, is for semantic-ignorant parsing.  I believe it's
good to have a syntax that makes it clear what something is, without
having to know what the semantics are.

In this case, I can accept your version as fitting my need -- the
parser knows, in the first case, that "TYPE" is not a value, so "FRUIT"
must be an option with no values, and in the second case, that "("
begins a value for "FRUIT".

So we have two votes for this version.  The key is whether Alexey can
make his documents use this syntax without terrible hassle... or,
alternatively, whether the hassle is worth it.

I believe that this syntax implements Dave's preference:

   option-standard-tag = atom [SP option-value]

   option-value = "(" astring *(SP astring) ")"

...so this is the currently active proposal.

Barry

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

Date: Tue, 18 Oct 2005 17:22:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Cc: Barry Leiba <[email-masked]>
Sender: [email-masked]

Barry Leiba writes:
> There's an important decision to make here before I submit the current 
> ("final") ListExt draft, and no one but Alexey and I have piped up.  
> We need more comments about how y'all want this syntax element to be, 
> or else I can't put it in.

I've been quiet because I suspect I'm a minority of one.

I think that the ideal is a listext where all the syntax is used right 
away. Where no productions exist only for future expansion.

Arnt

Date: Tue, 18 Oct 2005 17:21:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Cc: Barry Leiba <[email-masked]>
Sender: [email-masked]

Barry Leiba writes:
> I could easily change the grammar to eliminate (COLOR ("yellow")), 
> allowing the inner parentheses only if there are more than one value. 
> I don't care either way.

Please don't. If we have values, please let's have only one syntax for 
it. Less to implement, less to test.

Arnt

Date: Tue, 18 Oct 2005 16:17:20 +0100
Subject: Re: draft-ietf-imapext-list-extensions-14
From: Dave Cridland <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Oct 18 15:59:18 2005, Barry Leiba wrote:
> General question:
> Should we extend the syntax for selection options, to allow for
> selection options that have parameter values?  We have no 
> significant
> objections to this, but only a small desire for it.  Given that 
> there
> is desire, and no objection, I want to put it in if we can get the
> syntax nailed down, so I think the answer to this is "Yes."
> 
> 
Yes.

> Minor question:
> Should we also extend the syntax for return options?  I hadn't
> thought we wanted to, but Alexey asked for it and I see no reason
> not to.  Let me at least hear a little bit of "hum" here.
> 
> 
Yes. I can think of useful uses for this.

> Assuming the following:
>   Option TASTY, with no value.
>   Option COLOR, with one required value.
>   Option FRUIT, with one optional value.
>   Option TYPE, with multiple required values.
> I prefer this syntax:
> 
>   LIST (TASTY (COLOR "red") FRUIT (TYPE ("sweet" "tart")))
>   LIST (TASTY (COLOR "red") (FRUIT "apple") (TYPE ("sweet" "tart")))
> 
> 
 From a readability perspective, I find this confusing. From a 
parsing perspective, it's fine.

> Alexey has suggested (read previous posts) a syntax that matches
> other documents he's working on, but that syntax permits this:
>   LIST (TASTY COLOR RED FRUIT APPLE TYPE (SWEET TART))
> ...which I very much do NOT like.
> 
> 
The problem with this is that it makes it difficult for, say, an IMAP 
proxy to know how to find the options it can provide locally, and 
which to pass on. This is possible with the first syntax. Whether 
it's a desirable feature of an IMAP proxy is, of course, an entirely 
different flame war.

> Another option would allow these:
>   LIST (TASTY COLOR ("red") FRUIT () TYPE ("sweet" "tart"))
>   LIST (TASTY COLOR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))
> ...but I don't have Alexey's opinion on that.  I could live with 
> that,
> but I prefer my original.  I'm also interested in hearing 
> alternatives
> that will satisfy parsing needs here.
> 
> 
I'd actually prefer:

LIST (TASTY COLOUR ("red") FRUIT TYPE ("sweet" "tart"))
LIST (TASTY COLOUR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))

Note two things:
1) List only used for parameters, not for the absence of them. I 
don't see the need.
2) COLOUR is spelt correctly.

The latter point is, of course, vital. ;-)

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 18 Oct 2005 10:59:18 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

There's an important decision to make here before I submit the
current ("final") ListExt draft, and no one but Alexey and I have
piped up.  We need more comments about how y'all want this syntax
element to be, or else I can't put it in.

General question:
Should we extend the syntax for selection options, to allow for
selection options that have parameter values?  We have no significant
objections to this, but only a small desire for it.  Given that there
is desire, and no objection, I want to put it in if we can get the
syntax nailed down, so I think the answer to this is "Yes."

Minor question:
Should we also extend the syntax for return options?  I hadn't
thought we wanted to, but Alexey asked for it and I see no reason
not to.  Let me at least hear a little bit of "hum" here.

Major question:
What should the syntax for options with parameter values be?
Assuming the following:
   Option TASTY, with no value.
   Option COLOR, with one required value.
   Option FRUIT, with one optional value.
   Option TYPE, with multiple required values.
I prefer this syntax:

   LIST (TASTY (COLOR "red") FRUIT (TYPE ("sweet" "tart")))
   LIST (TASTY (COLOR "red") (FRUIT "apple") (TYPE ("sweet" "tart")))

Alexey has suggested (read previous posts) a syntax that matches
other documents he's working on, but that syntax permits this:
   LIST (TASTY COLOR RED FRUIT APPLE TYPE (SWEET TART))
...which I very much do NOT like.

Another option would allow these:
   LIST (TASTY COLOR ("red") FRUIT () TYPE ("sweet" "tart"))
   LIST (TASTY COLOR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))
...but I don't have Alexey's opinion on that.  I could live with that,
but I prefer my original.  I'm also interested in hearing alternatives
that will satisfy parsing needs here.

Please read the discussion and comment quickly, so I can get a final 
draft in by the Monday morning deadline.  Thanks, all.

Barry

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

Date: Tue, 18 Oct 2005 10:14:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: fetch annotation and missing values
Cc: Peter Coates <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> This would suggest that wildcarding attributes can be removed, too.

In fact, I didn't implement them, expecting that they would be removed ;)

Arnt

Date: Tue, 18 Oct 2005 10:13:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotation and /flags/\xxx
Cc: Peter Coates <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> On Mon Oct 17 21:03:15 2005, Peter Coates wrote:
>> Why is this second way of accessing the message flags part of the annotate
>> extension.  It really makes the life of a server implementer more difficult.
>> Is there any other instance in imap of having 2 different mechanisms for
>> accessing the same data?  Is is really that attractive to client implanters?
>
> As a client implementor (although not an implanter, though it'd make 
> for an interesting feature), I see no need to access flags via 
> ANNOTATE.

As a server implementor, the only use I see for it is to provide flags 
on embedded message/rfc822 messages.

I'd drop that in a second to simplify the extension.

Peter: I'll get around to your messages. Many of them seem to be the 
same things as I ran across when I started implementing last month. My 
three-week-old daughter is currently preventing me from working very 
much ;)

Arnt

Date: Mon, 17 Oct 2005 23:02:13 +0100
Subject: RE: fetch annotation and missing values
From: Dave Cridland <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Oct 17 22:57:27 2005, Peter Coates wrote:
> Wild carding might still have a use matching multiple parts of a 
> message, so
> "/*/comment" would match "/1/comment", "/2/comment", "2.2"/comment" 
> etc.  I
> could tell you how happy I am with that concept too.

That would be "/%/comment", but in any case, that's wildcarding on 
the ANNOTATE entry, rather than the ANNOTATE attribute.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Mon, 17 Oct 2005 14:57:27 -0700
From: Peter Coates <[email-masked]>
Subject: RE: fetch annotation and missing values
To: "'Dave Cridland'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Wild carding might still have a use matching multiple parts of a message, so
"/*/comment" would match "/1/comment", "/2/comment", "2.2"/comment" etc.  I
could tell you how happy I am with that concept too.

Peter

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]] 
Sent: October 17, 2005 14:47
To: Peter Coates
Cc: [email-masked]
Subject: Re: fetch annotation and missing values

On Mon Oct 17 21:31:16 2005, Peter Coates wrote:
> C: a fetch 1 (ANNOTATION ("/comment" "val*"))
> S: * 1 FETCH (ANNOTATION ("/comment"
>                          ("value.priv" "my comment"))
> S: a OK Fetch complete

The only purpose for this syntax I can see is to allow clients to obtain
vendor.* attributes, but these are being removed.

This would suggest that wildcarding attributes can be removed, too.

Then a client can ask for "value.shared", "value.priv", or both by the
shorthand "value".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Mon, 17 Oct 2005 22:47:02 +0100
Subject: Re: fetch annotation and missing values
From: Dave Cridland <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Oct 17 21:31:16 2005, Peter Coates wrote:
> C: a fetch 1 (ANNOTATION ("/comment" "val*"))
> S: * 1 FETCH (ANNOTATION ("/comment"
>                          ("value.priv" "my comment"))
> S: a OK Fetch complete

The only purpose for this syntax I can see is to allow clients to 
obtain vendor.* attributes, but these are being removed.

This would suggest that wildcarding attributes can be removed, too.

Then a client can ask for "value.shared", "value.priv", or both by 
the shorthand "value".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Mon, 17 Oct 2005 22:44:47 +0100
Subject: Re: annotation and /flags/\xxx
From: Dave Cridland <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Oct 17 21:03:15 2005, Peter Coates wrote:
> Why is this second way of accessing the message flags part of the 
> annotate
> extension.  It really makes the life of a server implementer more 
> difficult.
> Is there any other instance in imap of having 2 different 
> mechanisms for
> accessing the same data?  Is is really that attractive to client 
> implanters?

As a client implementor (although not an implanter, though it'd make 
for an interesting feature), I see no need to access flags via 
ANNOTATE.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Mon, 17 Oct 2005 13:31:16 -0700
From: Peter Coates <[email-masked]>
Subject: fetch annotation and missing values
To: [email-masked]
Sender: [email-masked]

It seems to me that the behaviour of the server as specified in the annotate
draft is a bit inconsistent when it comes to attribute that are not set.
 
For instance, if the only annotation set for message 1 is "/comment"
("value.priv" "my comment")
 
then by the specifications the following are the required responses to the
following requests:
 
C: a fetch 1 (ANNOTATION ("/comment" "value"))
S: * 1 FETCH (ANNOTATION ("/comment"
                         ("value.priv" "my comment"
                          "value.shared" NIL)))
S: a OK Fetch complete

C: a fetch 1 (ANNOTATION ("/comment" "val*"))
S: * 1 FETCH (ANNOTATION ("/comment"
                         ("value.priv" "my comment"))
S: a OK Fetch complete

In what way does returning a NIL for attributes not set help clients?  This
feels inconsistent, and it also could make the implementation of the server
side harder.

Peter

Date: Mon, 17 Oct 2005 13:03:15 -0700
From: Peter Coates <[email-masked]>
Subject: annotation and /flags/\xxx
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_s7BRIUFySCUcalvH+7FB8A)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Why is this second way of accessing the message flags part of the annotate
extension.  It really makes the life of a server implementer more difficult.
Is there any other instance in imap of having 2 different mechanisms for
accessing the same data?  Is is really that attractive to client implanters?
 
Peter

--Boundary_(ID_s7BRIUFySCUcalvH+7FB8A)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=026440020-17102005><FONT size=2>Why is this second way of 
accessing the message flags part of the annotate extension.&nbsp; It really 
makes the life of a server implementer more difficult.&nbsp; Is there any other 
instance in imap of having 2 different mechanisms for accessing the same 
data?&nbsp; Is is really that attractive to client 
implanters?</FONT></SPAN></DIV>
<DIV><SPAN class=026440020-17102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=026440020-17102005><FONT 
size=2>Peter</FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_s7BRIUFySCUcalvH+7FB8A)--

Date: Fri, 14 Oct 2005 14:36:56 -0700
From: Peter Coates <[email-masked]>
Subject: imap annotate issues
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_cBTUaxNmDTVJ+1b+GyNSpQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

(1) The content-language attribute is used for two different purposes: (a)
for the language of the value (b) for the language of the display-name.
This forces the display-name to be in the same language as the value of the
entry.  The wording of the description of content-language does not talk
about the display-name, but does indicate that content-language is not
required for flags.  But flags presumable can have display names which are
presumably affected by content-language, n'est pas?
 
(2) allowing values to be literals really messes me up in the append
command.  shame that.  I guess that's my problem.

--Boundary_(ID_cBTUaxNmDTVJ+1b+GyNSpQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=326235219-14102005><FONT size=2>(1) The content-language 
attribute is used for two different purposes: (a) for the language of the value 
(b) for the language of the display-name.&nbsp; This forces the display-name to 
be in the same language as the value of the entry.&nbsp; The wording of the 
description of content-language does not talk about the display-name, but does 
indicate that content-language is not required for flags.&nbsp; But flags 
presumable can have display names which are presumably affected by 
content-language, n'est pas?</FONT></SPAN></DIV>
<DIV><SPAN class=326235219-14102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=326235219-14102005><FONT size=2>
<DIV><SPAN class=326235219-14102005><FONT size=2>(2) allowing values to be 
literals really messes me up in the append command.&nbsp; shame that.&nbsp; I 
guess that's my problem.</FONT></SPAN></DIV>
<DIV><SPAN class=326235219-14102005><FONT 
size=2></FONT></SPAN>&nbsp;</DIV></FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_cBTUaxNmDTVJ+1b+GyNSpQ)--

Date: Fri, 14 Oct 2005 10:54:36 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

> And alternative is to have
> 
>   option-standard-tag = atom SP option-value
> 
> and allow option-value to be "()" if there is no value.
> 
> I prefer this change, as this will need changes to not that many
> documents.

OK, that suits my need for syntactic clarity, but it requires every
option to have a value, so now we'd have to say
   (SUBSCRIBED () REMOTE () RECURSIVEMATCH ())

Do you really want that?

Barry

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

Date: Fri, 14 Oct 2005 14:40:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Alexey Melnikov wrote:

>> I'm happy to accept the change to option-value, but I'd rather leave
>> option-standard-tag (and option-vendor-tag) my way:
>>
>>   option-standard-tag = atom / "(" atom SP option-value ")"
>>
>> ...which puts options that have values into parentheses.  It more
>> clearly groups the option names and their values.
>
And alternative is to have

  option-standard-tag = atom SP option-value

and allow option-value to be "()" if there is no value.

I prefer this change, as this will need changes to not that many documents.

Date: Fri, 14 Oct 2005 09:03:14 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

>> I don't like this because it means that there's no syntactic
>> difference between "(SUBSCRIBED REMOTE)" (two separate options,
>> neither of which has a value) and "(TYPE REMOTE)" (one option,
>> called TYPE, with the value REMOTE).
>> 
> As Philip pointed out, there are no options optional for the server.
> In order to parse the list the server has to recognize all options.
> So the server will always know which options have parameters and
> which don't.

That's why I said "no SYNTACTIC difference".  Yes, semantically there
might be no difference, but I think there's value in having a syntactic
distinction.  Apart from the human-readability issue, some people use
parsers that are independent of the semantics.  That requires a grammar
that can be definitively parse by considering only the syntax.

But I don't agree with the "no optional" statement anyway.  We could
certainly require that all options either have no values, or require
values.  Lacking that, though, it's entirely possible to define an
option with an optional value (the absence of which indicates a default
value), which would make parsing difficult without a syntactic
distinction.

My opinion is very strong on this.

> I want to use the same extension syntax for all commands (currently
> also affects FETCH, SEARCH, SELECT, CREATE, RENAME, APPEND),
> otherwise this is just going to be too confusing.

I agree with this, and, if you recall, Cyrus and I tried to do this a
while ago and got no support on it.  Actually, I have a peeve with how
you've done it, since the options don't go in the same place on all
commands.  When Cyrus and I did it, we noted that no base command uses
a parenthesized thing as the second token, so we could always do this:
  COMMAND (...options...) rest of line
and it was syntactically clean.  So we put the options immediately
after the command, always.  Your version doesn't do that.

> Hmm, changing APPEND syntax affects the CATENATE extension which has
> passed WGLC.

Oh, well.  I think it's worth changing.

Barry

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

Date: Fri, 14 Oct 2005 13:30:54 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

>Alexey says...
>  
>
>>Can we use syntax consistent with IMAPABNF document?
>>    
>>
>...
>  
>
>>   option-standard-tag = atom [SP option-value]
>>    
>>
>
>I don't like this because it means that there's no syntactic difference
>between "(SUBSCRIBED REMOTE)" (two separate options, neither of which
>has a value) and "(TYPE REMOTE)" (one option, called TYPE, with the
>value REMOTE).
>  
>
As Philip pointed out, there are no options optional for the server. In 
order to parse the list the server has to recognize all options.
So the server will always know which options have parameters and which 
don't.

>I'm happy to accept the change to option-value, but I'd rather leave
>option-standard-tag (and option-vendor-tag) my way:
>
>   option-standard-tag = atom / "(" atom SP option-value ")"
>
>...which puts options that have values into parentheses.  It more
>clearly groups the option names and their values.
>  
>
What other people think?

I want to use the same extension syntax for all commands (currently also 
affects FETCH, SEARCH, SELECT, CREATE, RENAME, APPEND), otherwise this 
is just going to be too confusing. So if people want to use Barry's 
syntax, I will need to change IMAPABNF and all other documents affected 
by the change.

Hmm, changing APPEND syntax affects the CATENATE extension which has 
passed WGLC.

>>So your example would change to be:
>>
>> (TASTY (FRUIT "banana" COLOR "yellow") TYPE ("rough" "ready"))
>>    
>>
>
>No, it wouldn't, and the fact that you got it wrong is one reason I
>don't like the grammar you're suggesting.  My example was this:
>
> (TASTY (FRUIT "banana") (COLOR ("yellow")) (TYPE ("rough" "ready")))
>
>...which means this:
>  Option called TASTY, with no values.
>  Option called FRUIT, with one value, "banana".
>  Option called COLOR, with one calue, "yellow".
>  Option called TYPE, with two values, "rough" and "ready".
>
>With your grammar change, it would become this:
>
> (TASTY FRUIT "banana" COLOR ("yellow") TYPE ("rough" "ready"))
>
>...(parens around "yellow" are optional in both your grammar and mine)
>and yours also allows this variant:
>
> (TASTY FRUIT BANANA COLOR YELLOW TYPE (ROUGH READY))
>
>...which I really dislike.  I have a preference for making the option
>values "string", not "astring".  We have no current options that have
>values, so there's no compatibility issue, and I think the use of atoms
>for option values is a bad thing, syntatically.
>  
>
Some extensions like CONDSTORE use 64bit numbers, which are atoms. Other 
are using message sequences, which can also be represented as atoms.
Anyway, a particular extensions doesn't need to use atom, it can mandate 
string. Nothing says that atom and string representations must be 
treated as equivalent.

Date: Fri, 14 Oct 2005 13:20:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

>>And I would also like to make return options extensible in the same
>>way. For example a client would be able to ask to return subscribed
>>mailboxes that have more than 500 messages in them.
>>    
>>
>
>Hm, I thought that would be a selection option, not a return option,
>and I didn't think we were asking for this change to be made to return
>options.
>
Ok, what about "return the following list of mailbox annotations"?

>  Obviously, changing the grammar for return options is easy
>enough, if it's what we want.  Are we sure it is?
>
>Opinions from others?  
>

Date: Fri, 14 Oct 2005 08:00:57 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Alexey says...
> Can we use syntax consistent with IMAPABNF document?
...
>    option-standard-tag = atom [SP option-value]

I don't like this because it means that there's no syntactic difference
between "(SUBSCRIBED REMOTE)" (two separate options, neither of which
has a value) and "(TYPE REMOTE)" (one option, called TYPE, with the
value REMOTE).

I'm happy to accept the change to option-value, but I'd rather leave
option-standard-tag (and option-vendor-tag) my way:

   option-standard-tag = atom / "(" atom SP option-value ")"

...which puts options that have values into parentheses.  It more
clearly groups the option names and their values.

> So your example would change to be:
> 
>  (TASTY (FRUIT "banana" COLOR "yellow") TYPE ("rough" "ready"))

No, it wouldn't, and the fact that you got it wrong is one reason I
don't like the grammar you're suggesting.  My example was this:

 (TASTY (FRUIT "banana") (COLOR ("yellow")) (TYPE ("rough" "ready")))

...which means this:
  Option called TASTY, with no values.
  Option called FRUIT, with one value, "banana".
  Option called COLOR, with one calue, "yellow".
  Option called TYPE, with two values, "rough" and "ready".

With your grammar change, it would become this:

 (TASTY FRUIT "banana" COLOR ("yellow") TYPE ("rough" "ready"))

...(parens around "yellow" are optional in both your grammar and mine)
and yours also allows this variant:

 (TASTY FRUIT BANANA COLOR YELLOW TYPE (ROUGH READY))

...which I really dislike.  I have a preference for making the option
values "string", not "astring".  We have no current options that have
values, so there's no compatibility issue, and I think the use of atoms
for option values is a bad thing, syntatically.

> And I would also like to make return options extensible in the same
> way. For example a client would be able to ask to return subscribed
> mailboxes that have more than 500 messages in them.

Hm, I thought that would be a selection option, not a return option,
and I didn't think we were asking for this change to be made to return
options.  Obviously, changing the grammar for return options is easy
enough, if it's what we want.  Are we sure it is?

Opinions from others?

Barry

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

Date: Fri, 14 Oct 2005 12:13:46 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

>1. The option syntax now allows for options that have values.  The
>following would be syntactically valid for the selection options:
>(TASTY (FRUIT "banana") (COLOR ("yellow")) (TYPE ("rough" "ready")))
>
>I could easily change the grammar to eliminate (COLOR ("yellow")),
>allowing the inner parentheses only if there are more than one value.
>I don't care either way.
>
Sorry for being too late with the reply.
Can we use syntax consistent with IMAPABNF document? I.e. each option 
has an optional value, which is enclosed in parenthesizes if it contains 
multiple strings/atoms. If we are to use the same syntax, here is how it 
would look like:

   option-standard-tag = atom [SP option-value]
               ; an option defined in a Standards Track or Experimental RFC

   option-value = astring / "(" [option-value-comp] ")"

   option-value-comp     = astring /
                      option-value-comp *(SP option-value-comp) /
                      "(" option-value-comp ")"

   option-vendor-tag = vendor-token "-" atom [SP option-value]
               ; a vendor specific option, non-standard

So your example would change to be:

 (TASTY (FRUIT "banana" COLOR "yellow") TYPE ("rough" "ready"))

And I would also like to make return options extensible in the same way. 
For example a client would be able to ask to return subscribed mailboxes 
that have more than 500 messages in them.

Date: Wed, 12 Oct 2005 16:57:05 -0700
From: Peter Coates <[email-masked]>
Subject: search annotation
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_Rmx2dFbo7njzK3g/U4zOog)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Unlike some of my previous observations, this note is purely about
difficulty of implementation, rather than about ambiguity or impossibility
of implementation.
 
Consider a search of
 
aa search (annotate "/flags/\*" "value" "1")
 
First, what use is this?  Is is ever going to be used by a client?  Second,
note that it is different from the search
 
aa search (annotate "/flags/\answered" "value" "1" annotate
"/flags/\flagged" "value" "1" annotate "/flags/\deleted" "value" "1"
annotate "/flags/\seen" "value" "1" annotate "/flags/\draft" "value" "1"
annotate "/flags/\recent" "value" "1" )
 
The first search means messages with ANY flag set, the second means messages
with ALL flags set  The first search requires a lot of work to represent as
flag masks so the search can be represented in an efficient form.  The same
goes, obviously for searches where there is wild carding that includes both
flags and"real" annotations, eg
 
aa search (annotation "*" "value" "1")
 
There is a huge amount of work to implement these things efficiently, and
the usefulness of these searches escapes me.  The only use for wild cards in
searches that seem to me to be even remotely useful is where the wild card
matches the body part specifier, eg
 
aa search (annotation "/%/comment "value" "foo")
 
which means (usefully) "find those messages where any part comment contains
foo".

I would preclude any wild carding of the entry name in the search other than
this one case.
 
Wildcarding the attribute name seems to me to be even less useful.  I would
explicitly forbid it.
 
I'm not afraid of a bit of hard work to implement this stuff, but where it
feels like gratuitous hard work for no useful gain, then ...  Besides, you
end up with infrequently used code paths in the system, and it is is such
dark corners that bugs lurk.
 
Peter

--Boundary_(ID_Rmx2dFbo7njzK3g/U4zOog)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=319431623-12102005><FONT size=2>Unlike some of my previous 
observations, this note is purely about difficulty of implementation, rather 
than about ambiguity or impossibility of implementation.</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>Consider a search 
of</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>aa search (annotate "/flags/\*" 
"value" "1")</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>First, what use is this? 
&nbsp;Is is ever going to be used by a client?&nbsp; Second, note that it is 
different from the search</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>aa search (annotate 
"/flags/\answered" "value" "1" annotate "/flags/\flagged" "value" "1" annotate 
"/flags/\deleted" "value" "1" annotate "/flags/\seen" "value" "1" annotate 
"/flags/\draft" "value" "1" annotate "/flags/\recent" "value" "1" 
)</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>The first search means messages 
with ANY flag set, the second means messages with ALL flags set&nbsp;&nbsp;The 
first search&nbsp;requires&nbsp;a lot of&nbsp;work to represent as flag masks so 
the search can be represented in an efficient form.&nbsp; The same goes, 
obviously for searches where there is wild carding that includes both flags 
and"real" annotations, eg</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>aa search (annotation "*" 
"value" "1")</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>There is a huge amount of work 
to implement these things efficiently, and the usefulness&nbsp;of these searches 
escapes me.&nbsp; The only use for wild cards in searches that seem to me to be 
even remotely useful is where the wild card matches the body part specifier, 
eg</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>aa search (annotation 
"/%/comment "value" "foo")</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV><SPAN 
class=319431623-12102005><FONT size=2>
<DIV><SPAN class=319431623-12102005><FONT size=2>which means (usefully) "find 
those messages where any part comment contains foo".</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I would preclude any wild carding of the entry name in the search other 
than this one case.</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005></SPAN><SPAN class=319431623-12102005><FONT 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>Wildcarding the attribute name 
seems to me to be even less useful.&nbsp; I would explicitly forbid 
it.</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>I'm not afraid of a bit of hard 
work to implement this stuff, but where it feels like gratuitous hard work for 
no useful gain, then ...&nbsp; Besides, you end up with infrequently used code 
paths in the system, and it is is such dark corners that bugs 
lurk.</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT 
size=2>Peter</FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_Rmx2dFbo7njzK3g/U4zOog)--

Date: Wed, 12 Oct 2005 09:49:20 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

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

I was hoping to get this dreadfully-late draft out yesterday, but ran
into a snag with a change to the ABNF that I had trouble sorting out.
Please take particular care to examine the "list-select-*" elements in
the ABNF, to make sure they're right.

Also look at the "option-*" elements, because I changed those, too, to
allow options with values (in fact, I allow multiple values).

Apart from minor editorial changes, some of which were suggested on
this list, I've made the following significant changes:

1. The option syntax now allows for options that have values.  The
following would be syntactically valid for the selection options:
(TASTY (FRUIT "banana") (COLOR ("yellow")) (TYPE ("rough" "ready")))

I could easily change the grammar to eliminate (COLOR ("yellow")),
allowing the inner parentheses only if there are more than one value.
I don't care either way.

2. In discussion to resolve the "what does (REMOTE RECURSIVEMATCH)
mean?" question, I think we decided that "REMOTE" is a special option,
and I've changed the text to reflect that (see the third paragraph
about "REMOTE" on page 9).  I changed the ABNF to match this.

The ABNF used to have two types of selection options, which it called
"base" and "mod"; if any "mod" options were present, at least one
"base" option had to be present also.  RECURSIVEMATCH is the only "mod"
option.  So the point, here, was that you can't have RECURSIVEMATCH by
itself.

But now we have REMOTE being different -- its presence doesn't change
anything with regard to what other options are permitted.  So I've
defined a third type of option, and we now have this:

base -- SUBSCRIBED is the only one of these right now.  If a base
option is present, a mod option MAY also be present.

mod -- RECURSIVEMATCH is the only one right now.  If a mod option is
present, a base option MUST also be present.

independent -- REMOTE is the only one right now.  Independent options
do not syntactically affect the other options.

Add to this the requirement that any number of options may appear, and
the order is not significant.

Again, please make sure I got this right.  If I don't hear by Thursday
morning (New York time) that I made a major goof, I'll submit it to the
I-D editor then.

Barry

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

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

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: April 15, 2006                                 October 12, =
2005

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

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 April 15, 2006.

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 April 15, 2006                 [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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  . . . . . . . . . . . . . . . . . . . =
30

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

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
37

   10. Normative References . . . . . . . . . . . . . . . . . . . . . =
37

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
37

       Intellectual Property and Copyright Statements . . . . . . . . =
39

Leiba & Melnikov         Expires April 15, 2006                 [Page =
2]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                 [Page =
3]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                 [Page =
4]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   f.  adds CHILDINFO extended data item.

Leiba & Melnikov         Expires April 15, 2006                 [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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
   parentheses.  A mailbox name matches a list of mailbox patterns if =
it
   matches at least one mailbox pattern.  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 April 15, 2006                 [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                 [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   See the formal syntax, in Section 6, 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 descendant mailbox that does not match the LIST pattern and
       does match the 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
      descendant mailboxes that are).  With the SUBSCRIBED selection
      option described here, the attributes are accurate, complete, and

Leiba & Melnikov         Expires April 15, 2006                 [Page =
8]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

      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)".

      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.

      The REMOTE selection option has no interaction with other =
options.
      Its effect is to tell the server to apply the other options, if
      any, to remote mailboxes, in addition to local ones.  In
      particular, it has no interaction with RECURSIVEMATCH (see =
below).
      A request for (REMOTE RECURSIVEMATCH) is invalid, because a
      request for (RECURSIVEMATCH) is.  A request for (REMOTE
      RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed =
mailboxes,
      both local and remote.

   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.

Leiba & Melnikov         Expires April 15, 2006                 [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

      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.

   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):

Leiba & Melnikov         Expires April 15, 2006                [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

       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 descendant 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.

Leiba & Melnikov         Expires April 15, 2006                [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   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 at least one descendant 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>)    =
|
   |                |                |                |                =
|

Leiba & Melnikov         Expires April 15, 2006                [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   |       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 April 15, 2006                [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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"

Leiba & Melnikov         Expires April 15, 2006                [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

          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

   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"

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

          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"

Leiba & Melnikov         Expires April 15, 2006                [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

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

          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 April 15, 2006                [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

       C) And finally, suppose that only the mailboxes "Foo" and "Moo"
       are subscribed.  In that case we see this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN
          (CHILDREN)

          S: * LIST (\HasChildren \Subscribed) "/" "Foo"

          S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"

          S: C04 OK done

       (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"

Leiba & Melnikov         Expires April 15, 2006                [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

          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"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))

Leiba & Melnikov         Expires April 15, 2006                [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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-return-opts =3D "RETURN" SP "(" [return-option *(SP return-
               option)] ")"
               ; list return options, e.g.  CHILDREN

Leiba & Melnikov         Expires April 15, 2006                [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   list-select-base-opt =3D "SUBSCRIBED" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted =3D <"> list-select-base-opt <">

   list-select-independent-opt =3D "REMOTE" / option-extension
               ; options that do not syntactically interact with
               ; other options

   list-select-mod-opt =3D "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-select-opt =3D list-select-base-opt / =
list-select-independent-opt
               / list-select-mod-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

   list-select-opts =3D "(" [
                 (*(list-select-opt SP) list-select-base-opt
                  *(SP list-select-opt))
               / (list-select-independent-opt
                  *(SP list-select-independent-opt))
               ] ")"
               ; Any number of options may be in any order
               ; This allows these:
               ;   ()
               ;   (REMOTE)
               ;   (SUBSCRIBED)
               ;   (SUBSCRIBED REMOTE)
               ;   (SUBSCRIBED RECURSIVEMATCH)
               ;   (SUBSCRIBED REMOTE RECURSIVEMATCH)
               ; But does NOT allow these:
               ;   (RECURSIVEMATCH)
               ;   (REMOTE RECURSIVEMATCH)

   mailbox-list =3D "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]

Leiba & Melnikov         Expires April 15, 2006                [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   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-standard-tag / option-vendor-tag

   option-standard-tag =3D atom / "(" atom SP option-value ")"
               ; an option defined in a Standards Track or Experimental
               RFC

   option-value =3D string / "(" string *(SP string) ")"

   option-vendor-tag =3D vendor-token "-" atom / "(" vendor-token "-" =
atom
               SP option-value ")"
               ; a vendor specific option, non-standard

Leiba & Melnikov         Expires April 15, 2006                [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   patterns =3D  "(" list-mailbox *(SP list-mailbox) ")"

   return-option =3D "SUBSCRIBED" / "CHILDREN" /
               option-extension

Leiba & Melnikov         Expires April 15, 2006                [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
30]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
34]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
35]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
36]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
37]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
38]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
39]
=0C

--==========F62F6F521464FD90C56C==========--

Date: Tue, 11 Oct 2005 11:15:52 -0700
From: Peter Coates <[email-masked]>
Subject: annotations in sort and search
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_ehIHerWEXR/nHYI4Ge58aQ)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

In search, the meaning of ANNOTATE <entry> <attribute> <value> is SUCCESS if
<value> occurs as a substring in any matching attribute in any matching
entry.  At least that's how I read it.  This clearly has use if the
attributes being searched are really text.  But what of the size attribute.
What use is it to be able to search a numeric field for a substring?  the
meaning of a search on size should be better defined.  Here are some
suggestions
 
(1) preclude search on the size attribute
(2) make search on ANNOTATE <entry> "size*" <value>  return SUCCESS is size
>= value
(3) define a mime type of "text/numeric", define the type of size to be this
type, define the behaviour of search on a "text/numeric" to be as described
in (2)
 
Option 3 allows clients to define better semantics for values too.
 
Note that numeric values sort differently from text.  one might want to sort
on the size of an annotation, and unless the size was defined to be a text
string 8 characters long padded on the left with leading zeros, you would
not get the anticipated result.  On the other hand, why be able to
sort/search on size etc of annotations when you can not search or sort on
the size of headers?
 
Peter

--Boundary_(ID_ehIHerWEXR/nHYI4Ge58aQ)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=343210118-11102005><FONT size=2>In search, the meaning of 
ANNOTATE &lt;entry&gt; &lt;attribute&gt; &lt;value&gt; is SUCCESS if 
&lt;value&gt; occurs as a substring in any matching attribute in any matching 
entry.&nbsp; At least that's how I read it.&nbsp; This clearly has use if the 
attributes being searched are really text.&nbsp; But what of the size 
attribute.&nbsp; What use is it to be able to search a numeric field for a 
substring?&nbsp; the meaning of a search on size should be better defined.&nbsp; 
Here are some suggestions</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>(1) preclude search on the size 
attribute</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>(2) make search on ANNOTATE 
&lt;entry&gt; "size*" &lt;value&gt;&nbsp; return SUCCESS is size &gt;= 
value</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>(3) define a mime type of 
"text/numeric", define the type of size to be this type, define the behaviour of 
search on a "text/numeric" to be as described in (2)</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>Option 3 allows clients to 
define better semantics for values too.</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>Note that numeric values sort 
differently from text.&nbsp; one might want to sort on the size of an 
annotation, and unless the size was defined to be a text string 8 characters 
long padded on the left with leading zeros, you would not get the anticipated 
result.&nbsp; On the other hand, why be able to sort/search on size etc of 
annotations when you can not search or sort on the size of 
headers?</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=343210118-11102005><FONT 
size=2>Peter</FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_ehIHerWEXR/nHYI4Ge58aQ)--

Date: Tue, 11 Oct 2005 18:21:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Meetings, agenda and forward progress
Sender: [email-masked]

Lisa Dusseault wrote:

> I've asked for a meeting for IMAPEXT for the upcoming Vancouver IETF, 
> Nov 6-11.  The agenda for this IETF should be published a little 
> earlier than normal to make it easier for people to make travel plans 
> so of course the request had to go in even earlier.  If we have 
> nothing new to discuss I can cancel the meeting request.
>
> So here's hoping that we'll have something new to discuss by then: new 
> drafts of the comparator document, annotate or list extensions.  These 
> are all overdue already according to the milestones we put together in 
> Paris.  I know a couple authors have had some "stuff" going on but we 
> really need to keep this work on track to finish IMAPEXT and stop 
> blocking other work.
>
> Alexey, Arnt, Barry, Cyrus, and Randy: please follow up with me on 
> whether you'll be in Vancouver; what are the agenda items (open issues 
> for your drafts) including some of the recent traffic on annotations.

I've just requested LC for draft-melnikov-imap-ext-abnf-05.txt.

I've updated my copy of CONDSTORE not to reference ANNOTATE. It turned 
out that no ABNF production has to move to 
draft-melnikov-imap-ext-abnf-05.txt as the result of this change.

And of course there are other IMAP extensions not in our charter that we 
can talk about.

Date: Tue, 11 Oct 2005 12:45:33 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt]
Sender: [email-masked]

--------------000708070907010809050105
Content-type: multipart/alternative; boundary="------------060403000605060503060207"

--------------060403000605060503060207
Content-type: text/plain; charset="us-ascii"

Hi folks,
I intend to LC the following draft shortly, so now is a good time for 
people to review it.

Thanks,
Alexey
-------- Original Message --------
Subject: 	I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt
Date: 	Mon, 10 Oct 2005 15:50:01 -0400
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Collected extensions to IMAP4 ABNF
	Author(s)	: C. Daboo, A. Melnikov
	Filename	: draft-melnikov-imap-ext-abnf-05.txt
	Pages		: 0
	Date		: 2005-10-10
	
Over years many documents from IMAPEXT and LEMONADE working groups,
   as well as many individual documents have added syntactic
   extensions to many base IMAP commands described in RFC 3501. For
   ease of reference this document collects most of such ABNF changes
   in one place.
   
   This document updates ABNF in RFC 3501, RFC 2342 and RFC 2088.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-05.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-ext-abnf-05.txt".

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

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

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

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

-- 
Alexey Melnikov
__________________________________________
Isode M-Box Message Store developer
http://www.isode.com/products/m-box.html

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

Personal Home Page: http://www.melnikov.ca
__________________________________________

--------------060403000605060503060207
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi folks,<br>
I intend to LC the following draft shortly, so now is a good time for
people to review it.<br>
<br>
Thanks,<br>
Alexey<br>
-------- Original Message --------
<table border="0" cellpadding="0" cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Mon, 10 Oct 2005 15:50:01 -0400</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Reply-To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Collected extensions to IMAP4 ABNF
	Author(s)	: C. Daboo, A. Melnikov
	Filename	: draft-melnikov-imap-ext-abnf-05.txt
	Pages		: 0
	Date		: 2005-10-10
	
Over years many documents from IMAPEXT and LEMONADE working groups,
   as well as many individual documents have added syntactic
   extensions to many base IMAP commands described in RFC 3501. For
   ease of reference this document collects most of such ABNF changes
   in one place.
   
   This document updates ABNF in RFC 3501, RFC 2342 and RFC 2088.

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-05.txt">http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-05.txt</a>

To remove yourself from the I-D Announcement list, send a message to 
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> with the word unsubscribe in the body of the message.  
You can also visit <a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1.ietf.org/mailman/listinfo/I-D-announce</a> 
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-melnikov-imap-ext-abnf-05.txt".

A list of Internet-Drafts directories can be found in
<a class="moz-txt-link-freetext" href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> 
or <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>

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

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

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

</pre>
<br>
<pre class="moz-signature" cols="72">-- 
Alexey Melnikov
__________________________________________
Isode M-Box Message Store developer
<a class="moz-txt-link-freetext" href="http://www.isode.com/products/m-box.html">http://www.isode.com/products/m-box.html</a>

IETF standard related pages:
<a class="moz-txt-link-freetext" href="http://www.melnikov.ca/mel/devel/Links.html">http://www.melnikov.ca/mel/devel/Links.html</a>

Personal Home Page: <a class="moz-txt-link-freetext" href="http://www.melnikov.ca">http://www.melnikov.ca</a>
__________________________________________
</pre>
</body>
</html>

--------------060403000605060503060207--

--------------000708070907010809050105
Content-type: Message/External-body; name="draft-melnikov-imap-ext-abnf-05.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="draft-melnikov-imap-ext-abnf-05.txt"

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

--------------000708070907010809050105
Content-type: text/plain; name="file:///D|/TEMP/nsmail-1.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="file:///D|/TEMP/nsmail-1.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------000708070907010809050105--

Date: Mon, 10 Oct 2005 16:54:13 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Behaviour of fetch annotation
To: "'Mark Crispin'" <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

OK, so lets look at what we have for fetch annotate.  Remember that the
annotation have to be evaluated for each message.

1) the entries and attributes can be wild carded, including message part
specifiers. 
2) wild carded requests (currently) are required to return at least one
value for each message in whose context they are evaluated.

If we change that so that a request for an attribute for an entry on a bogus
body part returns nothing, then what of bogus wild carded entries?  ("/1.*",
for instance).  Is the initial parse (not in the context of a message)
supposed to distinguish between a wild card that implicates body parts from
those that don't/

Mark, you suggest that a query 
1 fetch 1 annotation ("/2/comment" "value.priv")
should result in
* FETCH 1 (ANNOTATION (NIL)) 

Should 
1 fetch 1 annotation ("/2/*" "value.priv")
should result in the same?

What of
1 fetch 1 annotation (("/1/*" "/2/*") "value.priv")

What should be returned for 
1 fetch 1 annotation (("/2/*" "/comment) "value.priv")

I think the only hope is to reject as many bogus requests as possible early,
and that means any wild card entries that start "/x where x is non wild and
not a digit and which do not match nay known entry names.  Wild cards that
start * or /* have to be accepted initially even if they prove eventually to
match no entries for any message.  Entries starting % are illegal.  Entries
starting /% have to be accepted if they contain a / other than in the final
position or if they contain a *.  This is getting seriously ugly.

I'm thinking that "servers SHOULD reject entry names that match no entries
with a BAD response", and "if for a given message none of the entries are
valid, then the fetch response for that message should be of the form
* nn FETCH (ANNOTATION (NIL)) "

That is implementable without too much grief, and is probably useful for
clients.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Crispin
Sent: October 8, 2005 09:03
To: Arnt Gulbrandsen
Cc: [email-masked]; Peter Coates
Subject: Re: Behaviour of fetch annotation

On Sat, 8 Oct 2005, Arnt Gulbrandsen wrote:
> This is, as I see it, the IMAP way.

The IMAP way would be to return a NIL for the messages where the requested
FETCH message data is irrelevant, not return a tagged BAD.

A tagged BAD response is for invalid protocol, not for "data not set". 
The reason why fetching no such message returns BAD is that the client knows
in advance that the message is bad; it does not do so for no such UID.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Meetings, agenda and forward progress
Date: Mon, 10 Oct 2005 15:30:42 -0700
Sender: [email-masked]

I've asked for a meeting for IMAPEXT for the upcoming Vancouver IETF, 
Nov 6-11.  The agenda for this IETF should be published a little 
earlier than normal to make it easier for people to make travel plans 
so of course the request had to go in even earlier.  If we have nothing 
new to discuss I can cancel the meeting request.

So here's hoping that we'll have something new to discuss by then: new 
drafts of the comparator document, annotate or list extensions.  These 
are all overdue already according to the milestones we put together in 
Paris.  I know a couple authors have had some "stuff" going on but we 
really need to keep this work on track to finish IMAPEXT and stop 
blocking other work.

Alexey, Arnt, Barry, Cyrus, and Randy: please follow up with me on 
whether you'll be in Vancouver; what are the agenda items (open issues 
for your drafts) including some of the recent traffic on annotations.

Lisa

Date: Mon, 10 Oct 2005 12:17:04 -0700
From: Peter Coates <[email-masked]>
Subject: value of /flag/* entries
To: [email-masked]
Sender: [email-masked]

Section 3.2.1 says that the value of /flags entries must be one of "0", "1",
or "NIL", Why the two possible values for not set?  This makes searching on
one of these flags more difficult: If I want to find messages that have not
been forwarded I have to say
 
1 search utf-8 (not (annotation "/flags/$forwarded" "value.priv" "1')) 
instead of the more obvious
1 search utf-8 (annotation "/flags/$forwarded" "value.priv" "0')
 
If would appear that the behaviour of the second request is not defined.  It
should not return any messages that have been forwarded, but it may not
return those that have either.  that seems a little unfortunate.

This also affect the sort command, as "0" sorts before "1", but "NIL" sorts
after it.
 
Peter

Date: Sat, 8 Oct 2005 09:03:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Peter Coates <[email-masked]>
Subject: Re: Behaviour of fetch annotation
Sender: [email-masked]

On Sat, 8 Oct 2005, Arnt Gulbrandsen wrote:
> This is, as I see it, the IMAP way.

The IMAP way would be to return a NIL for the messages where the requested 
FETCH message data is irrelevant, not return a tagged BAD.

A tagged BAD response is for invalid protocol, not for "data not set". 
The reason why fetching no such message returns BAD is that the client 
knows in advance that the message is bad; it does not do so for no such 
UID.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Sat, 8 Oct 2005 16:55:46 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Behaviour of fetch annotation
Cc: Peter Coates <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> As I see it, yes. The client is asserting that messages 1 to 100 have 
> a part 2, and is fetching information about it. If the assertion is 
> BAD, the information request is irrelevant.

This is, as I see it, the IMAP way.

I agree that it isn't the only possible way to approach this problem. 
Personally, I rather like the approach you outlined, but in this case I 
think what you or I like is less important than what fits well into the 
existing design.

Arnt

PS: For those who were at the IMAP dinner in Paris, it's a girl. Sofie. 
All is now well, after a bit of a hair-raising start.

Date: Sat, 8 Oct 2005 10:17:54 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Behaviour of fetch annotation
Cc: Peter Coates <[email-masked]>
Sender: [email-masked]

Peter Coates writes:
> But suppose a client sends a command such as
>
> AA fetch 1:100 (annotation ("/2/comment ("value.priv")))
>
> Body part 2 might exist for some, but not all of the messages 
> requested. Is the server supposed to build up its response, and only 
> send the annotations if all messages have a body part 2?

As I see it, yes. The client is asserting that messages 1 to 100 have a 
part 2, and is fetching information about it. If the assertion is BAD, 
the information request is irrelevant.

My implementation is rather suboptimal in this case - it wastes lots of 
RAM and CPU cycles before realising that it has to send BAD. But I 
think that's okay - it's better to optimise for the useful case.

Btw. There's nothing that prohibits this:

C: a fetch 1 (annotation ("/44444/comment ("value")))
S: * 1 FETCH (UID 45)
S: a BAD No such bodypart

In this scenario, the FETCH response is an unsolicited response, 
perfectly legal.

Arnt

Date: Fri, 07 Oct 2005 16:18:18 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Behaviour of fetch annotation
To: "'Peter Coates'" <[email-masked]>, [email-masked]
Sender: [email-masked]

I made a mistake at the end of my last message.  The last suggested
=interaction should have been

Or (if that is ambiguous with having the comment body part present and the
comment NIL) how about

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" NIL) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring comment"))
BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

-------------

And to make life more difficult, what is one supposed to do (assuming that a
BAD response it not actually the answer -- I can believe I'm missing
something here) in the following scenario:

Same store state as before, but with the fetch request:

C: AA fetch 3:4 (body[2] annotation ("/2/* ("value.priv")))

One option would be to expand the * so one gets back something like
S: * 3 FETCH (ANNOTATION ("/2/comment" NIL
                          "/2/flags/\\seen" NIL 
                          "/2/flags/\\answered" NIL
                          "/2/flags/\\flagged" NIL
                          "/2/flags/\\forwarded" NIL)
              BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring")
                          "/2/flags/\\seen" 1 
                          "/2/flags/\\answered" 0
                          "/2/flags/\\flagged" 0
                          "/2/flags/\\forwarded" 0)
              BODY[2] {8}
S: test
S: 
S: )
S: AA OK Completed

Another option would be to reply specifically about the section part

S: * 3 FETCH (ANNOTATION ("/2" NIL))
              BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring")
                          "/2/flags/\\seen" 1 
                          "/2/flags/\\answered" 0
                          "/2/flags/\\flagged" 0
                          "/2/flags/\\forwarded" 0)
              BODY[2] {8}
S: test
S: 
S: )
S: AA OK Completed

Yet another approach would be to generate no output for that particular
entry

S: * 3 FETCH (ANNOTATION ())
              BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring")
                          "/2/flags/\\seen" 1 
                          "/2/flags/\\answered" 0
                          "/2/flags/\\flagged" 0
                          "/2/flags/\\forwarded" 0)
              BODY[2] {8}
S: test
S: 
S: )
S: AA OK Completed

I think I prefer the last option.  Servers should be expected to reject
badly formed entry and attribute names, things that can be recognised as bad
regardless of the message context in which they may be evaluated.  Entries
that can not be determined to be bad as they are parsed, but which do not
match an valid section part, should generate no return data.  Thus it would
be legal for a fetch annotation reply to be "ANNOTATION ()".

Peter Coates

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter Coates
Sent: October 7, 2005 14:43
To: [email-masked]
Subject: Behaviour of fetch annotation

In section 3.2.1 of the IMAP ANNOTATE extension draft-13, it states
 
/<section-part>
      Defines the top-level of entries associated with a specific body
      part of a message.  This entry itself does not contain any
      attributes.  The section-part uses the same numeric part specifier
      syntax as the BODY message data item in the FETCH command
      [RFC3501].  The server MUST return a BAD response if the client
      uses an incorrect part specifier (either incorrect syntax or a
      specifier referring to a non-existent part).  The server MUST
      return a BAD response if the client uses an empty part specifier
      (which is used in IMAP to represent the entire message).

That is quite clear.

But suppose a client sends a command such as

AA fetch 1:100 (annotation ("/2/comment ("value.priv")))

Body part 2 might exist for some, but not all of the messages requested.  Is
the server supposed to build up its response, and only send the annotations
if all messages have a body part 2?

The problem is compounded if you consider that the fetch might look like

AA fetch 1:100 (body[2] annotation ("/2/comment ("value.priv")))

Now it becomes clear that the server can not build up a tentative reply
before realizing that it should reply with a BAD response.

There is also an asymmetry here.  If fetch asks for a body part that doesn't
exist, the response replies NIL.  For instance

C: aa fetch 1:5 body[2]
S: * 1 FETCH (BODY[2] NIL)
S: * 2 FETCH (BODY[2] NIL)
S: * 3 FETCH (BODY[2] NIL)
S: * 4 FETCH (BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (BODY[2] NIL)
S: aa OK Completed

The specification would be far more implementable (and consistent with the
base IMAP specification) if the absence of a body part caused a fetch
annotation for an entry associated with that body part to return NIL rather
than for the whole command to response BAD.

I'm suggesting that the correct behaviour be as illustrated:

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring comment"))
BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

Or (if that is ambiguous with having the comment body part present and the
comment NIL) how about

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" NIL) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring comment"))
BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

Peter Coates

Date: Fri, 07 Oct 2005 14:42:42 -0700
From: Peter Coates <[email-masked]>
Subject: Behaviour of fetch annotation
To: [email-masked]
Sender: [email-masked]

In section 3.2.1 of the IMAP ANNOTATE extension draft-13, it states
 
/<section-part>
      Defines the top-level of entries associated with a specific body
      part of a message.  This entry itself does not contain any
      attributes.  The section-part uses the same numeric part specifier
      syntax as the BODY message data item in the FETCH command
      [RFC3501].  The server MUST return a BAD response if the client
      uses an incorrect part specifier (either incorrect syntax or a
      specifier referring to a non-existent part).  The server MUST
      return a BAD response if the client uses an empty part specifier
      (which is used in IMAP to represent the entire message).

That is quite clear.

But suppose a client sends a command such as

AA fetch 1:100 (annotation ("/2/comment ("value.priv")))

Body part 2 might exist for some, but not all of the messages requested.  Is
the server supposed to build up its response, and only send the annotations
if all messages have a body part 2?

The problem is compounded if you consider that the fetch might look like

AA fetch 1:100 (body[2] annotation ("/2/comment ("value.priv")))

Now it becomes clear that the server can not build up a tentative reply
before realizing that it should reply with a BAD response.

There is also an asymmetry here.  If fetch asks for a body part that doesn't
exist, the response replies NIL.  For instance

C: aa fetch 1:5 body[2]
S: * 1 FETCH (BODY[2] NIL)
S: * 2 FETCH (BODY[2] NIL)
S: * 3 FETCH (BODY[2] NIL)
S: * 4 FETCH (BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (BODY[2] NIL)
S: aa OK Completed

The specification would be far more implementable (and consistent with the
base IMAP specification) if the absence of a body part caused a fetch
annotation for an entry associated with that body part to return NIL rather
than for the whole command to response BAD.

I'm suggesting that the correct behaviour be as illustrated:

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring comment"))
BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

Or (if that is ambiguous with having the comment body part present and the
comment NIL) how about

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" NIL) BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

Peter Coates

Date: Mon, 03 Oct 2005 14:15:12 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Revision of IMAP URL (RFC 2192)
Sender: [email-masked]

Hi folks,
Lemonade WG has asked if IMAP URL revision (currently 
draft-melnikov-rfc2192bis-00.txt) can be done in the Lemonade WG.
I personally don't see any problem with that, as most of the IMAPEXT 
participants are participating in the Lemonade WG. But if you have any 
concerns, please speak up now.

Thanks,
Alexey

Content-class: urn:content-classes:message
Subject: RE: "Friends of IMAP" dinner on Tuesday, November 8th?
Date: Mon, 31 Oct 2005 15:47:48 -0500
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I'm in. 

Corby Wilson
Security & Mobile Connectivity

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Alexey
Melnikov
Sent: Monday, October 31, 2005 3:08 PM
To: IMAP Extensions WG
Subject: "Friends of IMAP" dinner on Tuesday, November 8th?

Hi folks,
Sorry for being so late with this message, but I would like to invite
people who haven't bought a ticket to the IETF social to come to a
dinner on Tuesday evening.
Let's call it "friends of IMAP, revision 2" :-).
I don't know where this would be yet, but I am hoping to get help from
somebody local.
If you want to join me, please email to me directly. Also let me know
about any food preferences.

Regards,
Alexey

Date: Mon, 31 Oct 2005 20:08:00 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: "Friends of IMAP" dinner on Tuesday, November 8th?
Sender: [email-masked]

Hi folks,
Sorry for being so late with this message, but I would like to invite 
people who haven't bought a ticket to the IETF social to come to a 
dinner on Tuesday evening.
Let's call it "friends of IMAP, revision 2" :-).
I don't know where this would be yet, but I am hoping to get help from 
somebody local.
If you want to join me, please email to me directly. Also let me know 
about any food preferences.

Regards,
Alexey

Date: Sun, 30 Oct 2005 14:49:50 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: annotate: wording change request
Sender: [email-masked]

In section 3.2.1, the first paragraph currently reads

    Entry names MUST be specified in a standards track or IESG approved
    experimental RFC, or fall under the vendor namespace.  See Section
    6.1 for the registration template.

I believe the intention of that is to ensure that no two clients use a 
single entry in conflicting ways. I would like to change the wording to 
clarify that.

    To ensure interoperation, entry names MUST be specified in a standards
    track or IESG approved experimental RFC. See section 6.1 for a registration
    template.

    The vendor namespace provides an exception. Within the vendor namespace,
    each vendor can define the meanings for its own annotation subtree.

Or something like that.

Arnt

Date: Fri, 28 Oct 2005 10:47:42 -0400
From: Barry Leiba <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Agenda for Vancouver meeting, Nov 8
Sender: [email-masked]

 > Of the authors of these drafts, who will be present physically?

Moi.

Barry

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

Date: Fri, 28 Oct 2005 10:33:51 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

Lisa Dusseault wrote:

> I call your attention to this draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
> -14.txt
>
> We previously did a WG last call in May 2005 but we decided for a  
> "do-over" since there were a few significant changes.
>
> 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.

Just one note: I've already told Barry to use the same syntax for 
"option-value" non-terminal as used by IMAP ABNF extensions. My 
impression was that he agreed, so consider this fixed.

> 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.  Send me email even if you reviewed draft 13 and 
> previously sent  me email about that, to let me know if you have 
> reviewed the changes in  draft 14 and are OK with them.

I've implemented revision 12.

> Because of the IETF meeting in a little over a week, let's do this 
> last  call until EOD Nov 17 (three weeks).  If you have any chance to 
> bring  up issues before IMAPEXT meets on Tuesday Nov 8, that would be 
> much  appreciated because it would give us an extra forum for discussion.

Date: Fri, 28 Oct 2005 10:29:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Agenda for Vancouver meeting, Nov 8
Sender: [email-masked]

Lisa Dusseault wrote:

> The IMAPEXT WG meeting is scheduled for 1300-1500, Tuesday Nov. 8.
>
> Here's my thought for an agenda:
>
> 1.  See if any issues have come up during WG last call on LISTEXT 
> (more  on this in separate email)
>       
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
> -14.txt
> 2.  Review status of comparator, review next steps, and nag  
> authors/editors to do revision
>      http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-05.txt
> 3.  Review status of Annotate, see if anything big has changed, nag  
> authors/editors to do revision
>      - recall last meeting the only major new thing we planned on was 
> a  response code so the server could say it didn't support private  
> annotations
>       
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-13.txt
>
> Any other agenda input?  Of the authors of these drafts, who will be  
> present physically?  Who will be in the Jabber room if they can't 
> make  it physically?

I think we should also quickly review my recent update to CONDSTORE and 
LC comments on IMAP ABNF (whichi is dependency for CONDSTORE, ANNOTATE 
and several Lemonade drafts). I would suggest to insert the discussion 
items after #1 (or #2).

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: WG Last Call of LISTEXT draft 14
Date: Thu, 27 Oct 2005 16:25:13 -0700
Sender: [email-masked]

I call your attention to this draft:

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

We previously did a WG last call in May 2005 but we decided for a  
"do-over" since there were a few significant changes.

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.

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.  Send me email even if you reviewed draft 13 and previously sent  
me email about that, to let me know if you have reviewed the changes in  
draft 14 and are OK with them.

Because of the IETF meeting in a little over a week, let's do this last  
call until EOD Nov 17 (three weeks).  If you have any chance to bring  
up issues before IMAPEXT meets on Tuesday Nov 8, that would be much  
appreciated because it would give us an extra forum for discussion.

Thanks,

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Agenda for Vancouver meeting, Nov 8
Date: Thu, 27 Oct 2005 16:21:03 -0700
Sender: [email-masked]

The IMAPEXT WG meeting is scheduled for 1300-1500, Tuesday Nov. 8.

Here's my thought for an agenda:

1.  See if any issues have come up during WG last call on LISTEXT (more  
on this in separate email)
       
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions 
-14.txt
2.  Review status of comparator, review next steps, and nag  
authors/editors to do revision
      http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-05.txt
3.  Review status of Annotate, see if anything big has changed, nag  
authors/editors to do revision
      - recall last meeting the only major new thing we planned on was a  
response code so the server could say it didn't support private  
annotations
       
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-13.txt

Any other agenda input?  Of the authors of these drafts, who will be  
present physically?  Who will be in the Jabber room if they can't make  
it physically?

Thanks,
Lisa

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-14.txt 
Date: Fri, 21 Oct 2005 10:50:01 -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-14.txt
	Pages		: 39
	Date		: 2005-10-21
	
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-14.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-14.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-14.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-14.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 20 Oct 2005 13:44:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

>>And alternative is to have
>>
>>  option-standard-tag = atom SP option-value
>>
>>and allow option-value to be "()" if there is no value.
>>
>>I prefer this change, as this will need changes to not that many
>>documents.
>>    
>>
>
>OK, that suits my need for syntactic clarity, but it requires every
>option to have a value, so now we'd have to say
>   (SUBSCRIBED () REMOTE () RECURSIVEMATCH ())
>
>Do you really want that?
>  
>
Just for the archive: this doesn't work very well for extensions like 
CONDSTORE, which doesn't have any value after the CONSTORE select parameter.

Date: Thu, 20 Oct 2005 13:40:54 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

> > Major question:
> > What should the syntax for options with parameter values be?
>
> I'm going with this:
>
>>    option-standard-tag = atom [SP option-value]
>>
>>    option-value = "(" astring *(SP astring) ")"
>
I was about to propose the same, but please use IMAP ABNF syntax, which 
is even more permissive (allows for nested lists).

> ...which defines this:
>
> > LIST (TASTY COLOUR ("red") FRUIT TYPE ("sweet" "tart"))
> > LIST (TASTY COLOUR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))

The only problem with this is that the APPEND syntax doesn't use () 
around values. However I feel that APPEND is a different beast 
altogether and using a slightly different syntax for it is Ok. I really 
don't want to change CATENATE syntax as this moment.

Date: Wed, 19 Oct 2005 18:43:44 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070504060305030703000508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I have submitted the attached draft, intended for IETF last call.

Barry

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

--------------070504060305030703000508
Content-Type: text/plain;
 name="draft-ietf-imapext-list-extensions-14.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-imapext-list-extensions-14.txt"

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: April 22, 2006                                 October 19, 2005

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

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 April 22, 2006.

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 April 22, 2006                 [Page 1]

Internet-Draft        IMAP4 LIST Command Extensions         October 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  . . . . . . . . . . . . . . . . . . . 30

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

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37

   10. Normative References . . . . . . . . . . . . . . . . . . . . . 37

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37

       Intellectual Property and Copyright Statements . . . . . . . . 39

Leiba & Melnikov         Expires April 22, 2006                 [Page 2]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                 [Page 3]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                 [Page 4]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   f.  adds CHILDINFO extended data item.

Leiba & Melnikov         Expires April 22, 2006                 [Page 5]

Internet-Draft        IMAP4 LIST Command Extensions         October 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
   parentheses.  A mailbox name matches a list of mailbox patterns if it
   matches at least one mailbox pattern.  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 April 22, 2006                 [Page 6]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                 [Page 7]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   See the formal syntax, in Section 6, 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 descendant mailbox that does not match the LIST pattern and
       does match the 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
      descendant mailboxes that are).  With the SUBSCRIBED selection
      option described here, the attributes are accurate, complete, and

Leiba & Melnikov         Expires April 22, 2006                 [Page 8]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

      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)".

      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.

      The REMOTE selection option has no interaction with other options.
      Its effect is to tell the server to apply the other options, if
      any, to remote mailboxes, in addition to local ones.  In
      particular, it has no interaction with RECURSIVEMATCH (see below).
      A request for (REMOTE RECURSIVEMATCH) is invalid, because a
      request for (RECURSIVEMATCH) is.  A request for (REMOTE
      RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes,
      both local and remote.

   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.

Leiba & Melnikov         Expires April 22, 2006                 [Page 9]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

      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.

   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):

Leiba & Melnikov         Expires April 22, 2006                [Page 10]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

       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 descendant 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.

Leiba & Melnikov         Expires April 22, 2006                [Page 11]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   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 at least one descendant 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>)    |
   |                |                |                |                |

Leiba & Melnikov         Expires April 22, 2006                [Page 12]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   |       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 April 22, 2006                [Page 13]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 14]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 15]

Internet-Draft        IMAP4 LIST Command Extensions         October 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"

Leiba & Melnikov         Expires April 22, 2006                [Page 16]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

          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

   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"

Leiba & Melnikov         Expires April 22, 2006                [Page 17]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

          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"

Leiba & Melnikov         Expires April 22, 2006                [Page 18]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

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

          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 April 22, 2006                [Page 19]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 20]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 21]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

       C) And finally, suppose that only the mailboxes "Foo" and "Moo"
       are subscribed.  In that case we see this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN
          (CHILDREN)

          S: * LIST (\HasChildren \Subscribed) "/" "Foo"

          S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"

          S: C04 OK done

       (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"

Leiba & Melnikov         Expires April 22, 2006                [Page 22]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

          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"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))

Leiba & Melnikov         Expires April 22, 2006                [Page 23]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 24]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 25]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 = "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 = "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

   eitem-standard-tag = atom
               ; a tag for extended list data defined in a Standard
               ; Track or Experimental RFC.

   eitem-vendor-tag = vendor-tag
               ; a vendor specific tag for extended list data

   list =      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
               [SP list-return-opts]

   list-return-opts = "RETURN" SP "(" [return-option *(SP return-
               option)] ")"
               ; list return options, e.g.  CHILDREN

Leiba & Melnikov         Expires April 22, 2006                [Page 26]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   list-select-base-opt = "SUBSCRIBED" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted = <"> list-select-base-opt <">

   list-select-independent-opt = "REMOTE" / option-extension
               ; options that do not syntactically interact with
               ; other options

   list-select-mod-opt = "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-select-opt = list-select-base-opt / list-select-independent-opt
               / list-select-mod-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

   list-select-opts = "(" [
                 (*(list-select-opt SP) list-select-base-opt
                  *(SP list-select-opt))
               / (list-select-independent-opt
                  *(SP list-select-independent-opt))
               ] ")"
               ; Any number of options may be in any order
               ; This allows these:
               ;   ()
               ;   (REMOTE)
               ;   (SUBSCRIBED)
               ;   (SUBSCRIBED REMOTE)
               ;   (SUBSCRIBED RECURSIVEMATCH)
               ;   (SUBSCRIBED REMOTE RECURSIVEMATCH)
               ; But does NOT allow these:
               ;   (RECURSIVEMATCH)
               ;   (REMOTE RECURSIVEMATCH)

   mailbox-list = "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]

Leiba & Melnikov         Expires April 22, 2006                [Page 27]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

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

   mbox-list-extended-item = "(" mbox-list-extended-item-data ")"

   mbox-list-extended-item-data = mbox-list-extended-item-tag SP
               nstring-list

   mbox-list-extended-item-tag = 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 = child-mbox-flag / "\NonExistent" /
               / "\Subscribed" / "\Remote"

   mbox-or-pat = list-mailbox / patterns

   nstring-list = nstring /
               "(" [nstring-list *(SP nstring-list)] ")"
               ; a recursive list definition

   option-extension = (option-standard-tag / option-vendor-tag) [SP
               option-value]

   option-standard-tag = atom
               ; an option defined in a Standards Track or Experimental
               RFC

   option-value = "(" astring *(SP astring) ")"

   option-vendor-tag = vendor-token "-" atom
               ; a vendor specific option, non-standard

Leiba & Melnikov         Expires April 22, 2006                [Page 28]

Internet-Draft        IMAP4 LIST Command Extensions         October 2005

   patterns =  "(" list-mailbox *(SP list-mailbox) ")"

   return-option = "SUBSCRIBED" / "CHILDREN" /
               option-extension

Leiba & Melnikov         Expires April 22, 2006                [Page 29]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 30]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 31]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 32]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 33]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 34]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 35]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 36]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 37]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 38]

Internet-Draft        IMAP4 LIST Command Extensions         October 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 April 22, 2006                [Page 39]


--------------070504060305030703000508--

Date: Wed, 19 Oct 2005 17:40:09 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Cc: Barry Leiba <[email-masked]>
Sender: [email-masked]

Barry Leiba writes:
> I'm going with this:
>
>>    option-standard-tag = atom [SP option-value]
>>
>>    option-value = "(" astring *(SP astring) ")"

Fine.

> Alea jacta est.

Independently of the previous: Fine.

Arnt

Date: Wed, 19 Oct 2005 11:24:31 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

OK; lacking further responses, I'm going to declare the following,
and submit the draft:

 > General question:
 > Should we extend the syntax for selection options, to allow for
 > selection options that have parameter values?  We have no significant
 > objections to this, but only a small desire for it.  Given that there
 > is desire, and no objection, I want to put it in if we can get the
 > syntax nailed down, so I think the answer to this is "Yes."

The consensus is "yes".  Arnt doesn't like it much, Dave and Alexey
do, and I've been convinced that it's not a morass [mostly because I
was able to write reasonable grammar for it :-) ].  That's not a very
strong consensus, but it is a sufficiently rough one.

 > Minor question:
 > Should we also extend the syntax for return options?  I hadn't
 > thought we wanted to, but Alexey asked for it and I see no reason
 > not to.  Let me at least hear a little bit of "hum" here.

Same as above, answer is "yes".

 > Major question:
 > What should the syntax for options with parameter values be?

I'm going with this:

>    option-standard-tag = atom [SP option-value]
> 
>    option-value = "(" astring *(SP astring) ")"

...which defines this:

 > LIST (TASTY COLOUR ("red") FRUIT TYPE ("sweet" "tart"))
 > LIST (TASTY COLOUR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))

Alea jacta est.

Barry

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

Date: Wed, 19 Oct 2005 10:32:17 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotation and /flags/\xxx
Cc: Cyrus Daboo <[email-masked]>, Peter Coates <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> This issue was discussed at length quite a while ago and the current 
> situation is the compromise that was settled on.

But AFAICT: Everyone's unhappy with the aggregate complexity of annotate.

Arnt

Date: Wed, 19 Oct 2005 08:48:52 +0100
Subject: Re: fetch annotate response
From: Dave Cridland <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Oct 18 23:48:29 2005, Peter Coates wrote:
> S: * 1 FETCH (ANNOTATION
>    ("/comment" ("value.priv" "My comment")
>     "/altsubject" ("value.priv" "My subject")
>     "/comment" ("value.shared" "Our comment")
>     "/altsubject" ("value.shared" "Our comment")))
> S: a OK Fetch complete
> 
> 
Or:

* 1 FETCH (ANNOTATION ("/comment" ("value.priv" "My comment")))
* 1 FETCH (ANNOTATION ("/comment" ("value.shared" "Our comment")))

etc.

> I do not see anything to preclude this is the spec, but I don't 
> want to
> generate something that clients might choke on.  Perhaps I'm being 
> naive
> reading the spec.

It seems generally sane to use the most compact representation 
whenever possible, but I think the usual rule applies - a client only 
knows the server has sent everything it can when the FETCH command is 
reported to have been completed, and not when a particular FETCH 
response is received.

The problem is only worse with ANNOTATE because there's numerous ways 
of saying the same thing - if BODY[x] was rewritten to be BODY (x 
...) the same thing would apply there.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 18 Oct 2005 15:48:29 -0700
From: Peter Coates <[email-masked]>
Subject: fetch annotate response
To: [email-masked]
Sender: [email-masked]

Consider an annotate request of the form
 
C: a fetch 1 (annotation ((""/comment" "/altsubject") "value"))
 
is the required response of the form
S: * 1 FETCH (ANNOTATION
   ("/comment" ("value.priv" "My comment"
                "value.shared" "Our comment")
    "/altsubject" ("value.priv" "My subject"
                   "value.shared" "Our comment")))
S: a OK Fetch complete

Or is the following permitted?
S: * 1 FETCH (ANNOTATION
   ("/comment" ("value.priv" "My comment")
    "/comment" ("value.shared" "Our comment")
    "/altsubject" ("value.priv" "My subject")
    "/altsubject" ("value.shared" "Our comment")))
S: a OK Fetch complete

Or even the following:
S: * 1 FETCH (ANNOTATION
   ("/comment" ("value.priv" "My comment")
    "/altsubject" ("value.priv" "My subject")
    "/comment" ("value.shared" "Our comment")
    "/altsubject" ("value.shared" "Our comment")))
S: a OK Fetch complete

I do not see anything to preclude this is the spec, but I don't want to
generate something that clients might choke on.  Perhaps I'm being naive
reading the spec.

Peter

Date: Tue, 18 Oct 2005 16:26:44 -0400
From: Cyrus Daboo <[email-masked]>
To: Peter Coates <[email-masked]>, [email-masked]
Subject: Re: annotation and /flags/\xxx
Sender: [email-masked]

Hi Peter,

--On October 17, 2005 1:03:15 PM -0700 Peter Coates <[email-masked]> 
wrote:

> Why is this second way of accessing the message flags part of the
> annotate extension.  It really makes the life of a server implementer
> more difficult.  Is there any other instance in imap of having 2
> different mechanisms for accessing the same data?  Is is really that
> attractive to client implanters?

This issue was discussed at length quite a while ago and the current 
situation is the compromise that was settled on.

-- 
Cyrus Daboo

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-06.txt 
Date: Tue, 18 Oct 2005 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-06.txt
	Pages		: 16
	Date		: 2005-10-18
	
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on 
behalf of the same user, and multiple users accessing shared mailboxes. 
These clients need a mechanism to synchronize state changes for messages
within the mailbox. They must be able to guarantee that only one client 
can change message state (e.g., message flags) at any time.  An example
of such an application is use of an IMAP mailbox as a message queue with 
multiple dequeueing clients.

    The Conditional Store facility provides a protected update mechanism for
    message state information that can detect and resolve conflicts between
    multiple writing mail clients.

    This document defines an extension to IMAP (RFC 3501).

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 18 Oct 2005 21:13:49 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba writes:
> So we have two votes for this version.

It also seems to suit my concerns fairly well. Correct me if I'm wrong, 
but it seems to me that anyone who's handled listext+postaddress has 
already handled almost all of the syntax. Perhaps all.

Arnt
(proud+tired parent)

Date: Tue, 18 Oct 2005 13:43:04 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

>>   LIST (TASTY COLOR ("red") FRUIT () TYPE ("sweet" "tart"))
>>   LIST (TASTY COLOR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))
> 
> I'd actually prefer:
> 
> LIST (TASTY COLOUR ("red") FRUIT TYPE ("sweet" "tart"))
> LIST (TASTY COLOUR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))
> 
> Note two things:
> 1) List only used for parameters, not for the absence of them. I
> don't see the need.

The need, in general, is for semantic-ignorant parsing.  I believe it's
good to have a syntax that makes it clear what something is, without
having to know what the semantics are.

In this case, I can accept your version as fitting my need -- the
parser knows, in the first case, that "TYPE" is not a value, so "FRUIT"
must be an option with no values, and in the second case, that "("
begins a value for "FRUIT".

So we have two votes for this version.  The key is whether Alexey can
make his documents use this syntax without terrible hassle... or,
alternatively, whether the hassle is worth it.

I believe that this syntax implements Dave's preference:

   option-standard-tag = atom [SP option-value]

   option-value = "(" astring *(SP astring) ")"

...so this is the currently active proposal.

Barry

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

Date: Tue, 18 Oct 2005 17:22:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Cc: Barry Leiba <[email-masked]>
Sender: [email-masked]

Barry Leiba writes:
> There's an important decision to make here before I submit the current 
> ("final") ListExt draft, and no one but Alexey and I have piped up.  
> We need more comments about how y'all want this syntax element to be, 
> or else I can't put it in.

I've been quiet because I suspect I'm a minority of one.

I think that the ideal is a listext where all the syntax is used right 
away. Where no productions exist only for future expansion.

Arnt

Date: Tue, 18 Oct 2005 17:21:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-imapext-list-extensions-14
Cc: Barry Leiba <[email-masked]>
Sender: [email-masked]

Barry Leiba writes:
> I could easily change the grammar to eliminate (COLOR ("yellow")), 
> allowing the inner parentheses only if there are more than one value. 
> I don't care either way.

Please don't. If we have values, please let's have only one syntax for 
it. Less to implement, less to test.

Arnt

Date: Tue, 18 Oct 2005 16:17:20 +0100
Subject: Re: draft-ietf-imapext-list-extensions-14
From: Dave Cridland <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Oct 18 15:59:18 2005, Barry Leiba wrote:
> General question:
> Should we extend the syntax for selection options, to allow for
> selection options that have parameter values?  We have no 
> significant
> objections to this, but only a small desire for it.  Given that 
> there
> is desire, and no objection, I want to put it in if we can get the
> syntax nailed down, so I think the answer to this is "Yes."
> 
> 
Yes.

> Minor question:
> Should we also extend the syntax for return options?  I hadn't
> thought we wanted to, but Alexey asked for it and I see no reason
> not to.  Let me at least hear a little bit of "hum" here.
> 
> 
Yes. I can think of useful uses for this.

> Assuming the following:
>   Option TASTY, with no value.
>   Option COLOR, with one required value.
>   Option FRUIT, with one optional value.
>   Option TYPE, with multiple required values.
> I prefer this syntax:
> 
>   LIST (TASTY (COLOR "red") FRUIT (TYPE ("sweet" "tart")))
>   LIST (TASTY (COLOR "red") (FRUIT "apple") (TYPE ("sweet" "tart")))
> 
> 
 From a readability perspective, I find this confusing. From a 
parsing perspective, it's fine.

> Alexey has suggested (read previous posts) a syntax that matches
> other documents he's working on, but that syntax permits this:
>   LIST (TASTY COLOR RED FRUIT APPLE TYPE (SWEET TART))
> ...which I very much do NOT like.
> 
> 
The problem with this is that it makes it difficult for, say, an IMAP 
proxy to know how to find the options it can provide locally, and 
which to pass on. This is possible with the first syntax. Whether 
it's a desirable feature of an IMAP proxy is, of course, an entirely 
different flame war.

> Another option would allow these:
>   LIST (TASTY COLOR ("red") FRUIT () TYPE ("sweet" "tart"))
>   LIST (TASTY COLOR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))
> ...but I don't have Alexey's opinion on that.  I could live with 
> that,
> but I prefer my original.  I'm also interested in hearing 
> alternatives
> that will satisfy parsing needs here.
> 
> 
I'd actually prefer:

LIST (TASTY COLOUR ("red") FRUIT TYPE ("sweet" "tart"))
LIST (TASTY COLOUR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))

Note two things:
1) List only used for parameters, not for the absence of them. I 
don't see the need.
2) COLOUR is spelt correctly.

The latter point is, of course, vital. ;-)

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 18 Oct 2005 10:59:18 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

There's an important decision to make here before I submit the
current ("final") ListExt draft, and no one but Alexey and I have
piped up.  We need more comments about how y'all want this syntax
element to be, or else I can't put it in.

General question:
Should we extend the syntax for selection options, to allow for
selection options that have parameter values?  We have no significant
objections to this, but only a small desire for it.  Given that there
is desire, and no objection, I want to put it in if we can get the
syntax nailed down, so I think the answer to this is "Yes."

Minor question:
Should we also extend the syntax for return options?  I hadn't
thought we wanted to, but Alexey asked for it and I see no reason
not to.  Let me at least hear a little bit of "hum" here.

Major question:
What should the syntax for options with parameter values be?
Assuming the following:
   Option TASTY, with no value.
   Option COLOR, with one required value.
   Option FRUIT, with one optional value.
   Option TYPE, with multiple required values.
I prefer this syntax:

   LIST (TASTY (COLOR "red") FRUIT (TYPE ("sweet" "tart")))
   LIST (TASTY (COLOR "red") (FRUIT "apple") (TYPE ("sweet" "tart")))

Alexey has suggested (read previous posts) a syntax that matches
other documents he's working on, but that syntax permits this:
   LIST (TASTY COLOR RED FRUIT APPLE TYPE (SWEET TART))
...which I very much do NOT like.

Another option would allow these:
   LIST (TASTY COLOR ("red") FRUIT () TYPE ("sweet" "tart"))
   LIST (TASTY COLOR ("red") FRUIT ("apple") TYPE ("sweet" "tart"))
...but I don't have Alexey's opinion on that.  I could live with that,
but I prefer my original.  I'm also interested in hearing alternatives
that will satisfy parsing needs here.

Please read the discussion and comment quickly, so I can get a final 
draft in by the Monday morning deadline.  Thanks, all.

Barry

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

Date: Tue, 18 Oct 2005 10:14:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: fetch annotation and missing values
Cc: Peter Coates <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> This would suggest that wildcarding attributes can be removed, too.

In fact, I didn't implement them, expecting that they would be removed ;)

Arnt

Date: Tue, 18 Oct 2005 10:13:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotation and /flags/\xxx
Cc: Peter Coates <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> On Mon Oct 17 21:03:15 2005, Peter Coates wrote:
>> Why is this second way of accessing the message flags part of the annotate
>> extension.  It really makes the life of a server implementer more difficult.
>> Is there any other instance in imap of having 2 different mechanisms for
>> accessing the same data?  Is is really that attractive to client implanters?
>
> As a client implementor (although not an implanter, though it'd make 
> for an interesting feature), I see no need to access flags via 
> ANNOTATE.

As a server implementor, the only use I see for it is to provide flags 
on embedded message/rfc822 messages.

I'd drop that in a second to simplify the extension.

Peter: I'll get around to your messages. Many of them seem to be the 
same things as I ran across when I started implementing last month. My 
three-week-old daughter is currently preventing me from working very 
much ;)

Arnt

Date: Mon, 17 Oct 2005 23:02:13 +0100
Subject: RE: fetch annotation and missing values
From: Dave Cridland <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Oct 17 22:57:27 2005, Peter Coates wrote:
> Wild carding might still have a use matching multiple parts of a 
> message, so
> "/*/comment" would match "/1/comment", "/2/comment", "2.2"/comment" 
> etc.  I
> could tell you how happy I am with that concept too.

That would be "/%/comment", but in any case, that's wildcarding on 
the ANNOTATE entry, rather than the ANNOTATE attribute.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Mon, 17 Oct 2005 14:57:27 -0700
From: Peter Coates <[email-masked]>
Subject: RE: fetch annotation and missing values
To: "'Dave Cridland'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Wild carding might still have a use matching multiple parts of a message, so
"/*/comment" would match "/1/comment", "/2/comment", "2.2"/comment" etc.  I
could tell you how happy I am with that concept too.

Peter

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]] 
Sent: October 17, 2005 14:47
To: Peter Coates
Cc: [email-masked]
Subject: Re: fetch annotation and missing values

On Mon Oct 17 21:31:16 2005, Peter Coates wrote:
> C: a fetch 1 (ANNOTATION ("/comment" "val*"))
> S: * 1 FETCH (ANNOTATION ("/comment"
>                          ("value.priv" "my comment"))
> S: a OK Fetch complete

The only purpose for this syntax I can see is to allow clients to obtain
vendor.* attributes, but these are being removed.

This would suggest that wildcarding attributes can be removed, too.

Then a client can ask for "value.shared", "value.priv", or both by the
shorthand "value".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Mon, 17 Oct 2005 22:47:02 +0100
Subject: Re: fetch annotation and missing values
From: Dave Cridland <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Oct 17 21:31:16 2005, Peter Coates wrote:
> C: a fetch 1 (ANNOTATION ("/comment" "val*"))
> S: * 1 FETCH (ANNOTATION ("/comment"
>                          ("value.priv" "my comment"))
> S: a OK Fetch complete

The only purpose for this syntax I can see is to allow clients to 
obtain vendor.* attributes, but these are being removed.

This would suggest that wildcarding attributes can be removed, too.

Then a client can ask for "value.shared", "value.priv", or both by 
the shorthand "value".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Mon, 17 Oct 2005 22:44:47 +0100
Subject: Re: annotation and /flags/\xxx
From: Dave Cridland <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Oct 17 21:03:15 2005, Peter Coates wrote:
> Why is this second way of accessing the message flags part of the 
> annotate
> extension.  It really makes the life of a server implementer more 
> difficult.
> Is there any other instance in imap of having 2 different 
> mechanisms for
> accessing the same data?  Is is really that attractive to client 
> implanters?

As a client implementor (although not an implanter, though it'd make 
for an interesting feature), I see no need to access flags via 
ANNOTATE.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Mon, 17 Oct 2005 13:31:16 -0700
From: Peter Coates <[email-masked]>
Subject: fetch annotation and missing values
To: [email-masked]
Sender: [email-masked]

It seems to me that the behaviour of the server as specified in the annotate
draft is a bit inconsistent when it comes to attribute that are not set.
 
For instance, if the only annotation set for message 1 is "/comment"
("value.priv" "my comment")
 
then by the specifications the following are the required responses to the
following requests:
 
C: a fetch 1 (ANNOTATION ("/comment" "value"))
S: * 1 FETCH (ANNOTATION ("/comment"
                         ("value.priv" "my comment"
                          "value.shared" NIL)))
S: a OK Fetch complete

C: a fetch 1 (ANNOTATION ("/comment" "val*"))
S: * 1 FETCH (ANNOTATION ("/comment"
                         ("value.priv" "my comment"))
S: a OK Fetch complete

In what way does returning a NIL for attributes not set help clients?  This
feels inconsistent, and it also could make the implementation of the server
side harder.

Peter

Date: Mon, 17 Oct 2005 13:03:15 -0700
From: Peter Coates <[email-masked]>
Subject: annotation and /flags/\xxx
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_s7BRIUFySCUcalvH+7FB8A)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Why is this second way of accessing the message flags part of the annotate
extension.  It really makes the life of a server implementer more difficult.
Is there any other instance in imap of having 2 different mechanisms for
accessing the same data?  Is is really that attractive to client implanters?
 
Peter

--Boundary_(ID_s7BRIUFySCUcalvH+7FB8A)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=026440020-17102005><FONT size=2>Why is this second way of 
accessing the message flags part of the annotate extension.&nbsp; It really 
makes the life of a server implementer more difficult.&nbsp; Is there any other 
instance in imap of having 2 different mechanisms for accessing the same 
data?&nbsp; Is is really that attractive to client 
implanters?</FONT></SPAN></DIV>
<DIV><SPAN class=026440020-17102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=026440020-17102005><FONT 
size=2>Peter</FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_s7BRIUFySCUcalvH+7FB8A)--

Date: Fri, 14 Oct 2005 14:36:56 -0700
From: Peter Coates <[email-masked]>
Subject: imap annotate issues
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_cBTUaxNmDTVJ+1b+GyNSpQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

(1) The content-language attribute is used for two different purposes: (a)
for the language of the value (b) for the language of the display-name.
This forces the display-name to be in the same language as the value of the
entry.  The wording of the description of content-language does not talk
about the display-name, but does indicate that content-language is not
required for flags.  But flags presumable can have display names which are
presumably affected by content-language, n'est pas?
 
(2) allowing values to be literals really messes me up in the append
command.  shame that.  I guess that's my problem.

--Boundary_(ID_cBTUaxNmDTVJ+1b+GyNSpQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=326235219-14102005><FONT size=2>(1) The content-language 
attribute is used for two different purposes: (a) for the language of the value 
(b) for the language of the display-name.&nbsp; This forces the display-name to 
be in the same language as the value of the entry.&nbsp; The wording of the 
description of content-language does not talk about the display-name, but does 
indicate that content-language is not required for flags.&nbsp; But flags 
presumable can have display names which are presumably affected by 
content-language, n'est pas?</FONT></SPAN></DIV>
<DIV><SPAN class=326235219-14102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=326235219-14102005><FONT size=2>
<DIV><SPAN class=326235219-14102005><FONT size=2>(2) allowing values to be 
literals really messes me up in the append command.&nbsp; shame that.&nbsp; I 
guess that's my problem.</FONT></SPAN></DIV>
<DIV><SPAN class=326235219-14102005><FONT 
size=2></FONT></SPAN>&nbsp;</DIV></FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_cBTUaxNmDTVJ+1b+GyNSpQ)--

Date: Fri, 14 Oct 2005 10:54:36 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

> And alternative is to have
> 
>   option-standard-tag = atom SP option-value
> 
> and allow option-value to be "()" if there is no value.
> 
> I prefer this change, as this will need changes to not that many
> documents.

OK, that suits my need for syntactic clarity, but it requires every
option to have a value, so now we'd have to say
   (SUBSCRIBED () REMOTE () RECURSIVEMATCH ())

Do you really want that?

Barry

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

Date: Fri, 14 Oct 2005 14:40:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Alexey Melnikov wrote:

>> I'm happy to accept the change to option-value, but I'd rather leave
>> option-standard-tag (and option-vendor-tag) my way:
>>
>>   option-standard-tag = atom / "(" atom SP option-value ")"
>>
>> ...which puts options that have values into parentheses.  It more
>> clearly groups the option names and their values.
>
And alternative is to have

  option-standard-tag = atom SP option-value

and allow option-value to be "()" if there is no value.

I prefer this change, as this will need changes to not that many documents.

Date: Fri, 14 Oct 2005 09:03:14 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

>> I don't like this because it means that there's no syntactic
>> difference between "(SUBSCRIBED REMOTE)" (two separate options,
>> neither of which has a value) and "(TYPE REMOTE)" (one option,
>> called TYPE, with the value REMOTE).
>> 
> As Philip pointed out, there are no options optional for the server.
> In order to parse the list the server has to recognize all options.
> So the server will always know which options have parameters and
> which don't.

That's why I said "no SYNTACTIC difference".  Yes, semantically there
might be no difference, but I think there's value in having a syntactic
distinction.  Apart from the human-readability issue, some people use
parsers that are independent of the semantics.  That requires a grammar
that can be definitively parse by considering only the syntax.

But I don't agree with the "no optional" statement anyway.  We could
certainly require that all options either have no values, or require
values.  Lacking that, though, it's entirely possible to define an
option with an optional value (the absence of which indicates a default
value), which would make parsing difficult without a syntactic
distinction.

My opinion is very strong on this.

> I want to use the same extension syntax for all commands (currently
> also affects FETCH, SEARCH, SELECT, CREATE, RENAME, APPEND),
> otherwise this is just going to be too confusing.

I agree with this, and, if you recall, Cyrus and I tried to do this a
while ago and got no support on it.  Actually, I have a peeve with how
you've done it, since the options don't go in the same place on all
commands.  When Cyrus and I did it, we noted that no base command uses
a parenthesized thing as the second token, so we could always do this:
  COMMAND (...options...) rest of line
and it was syntactically clean.  So we put the options immediately
after the command, always.  Your version doesn't do that.

> Hmm, changing APPEND syntax affects the CATENATE extension which has
> passed WGLC.

Oh, well.  I think it's worth changing.

Barry

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

Date: Fri, 14 Oct 2005 13:30:54 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

>Alexey says...
>  
>
>>Can we use syntax consistent with IMAPABNF document?
>>    
>>
>...
>  
>
>>   option-standard-tag = atom [SP option-value]
>>    
>>
>
>I don't like this because it means that there's no syntactic difference
>between "(SUBSCRIBED REMOTE)" (two separate options, neither of which
>has a value) and "(TYPE REMOTE)" (one option, called TYPE, with the
>value REMOTE).
>  
>
As Philip pointed out, there are no options optional for the server. In 
order to parse the list the server has to recognize all options.
So the server will always know which options have parameters and which 
don't.

>I'm happy to accept the change to option-value, but I'd rather leave
>option-standard-tag (and option-vendor-tag) my way:
>
>   option-standard-tag = atom / "(" atom SP option-value ")"
>
>...which puts options that have values into parentheses.  It more
>clearly groups the option names and their values.
>  
>
What other people think?

I want to use the same extension syntax for all commands (currently also 
affects FETCH, SEARCH, SELECT, CREATE, RENAME, APPEND), otherwise this 
is just going to be too confusing. So if people want to use Barry's 
syntax, I will need to change IMAPABNF and all other documents affected 
by the change.

Hmm, changing APPEND syntax affects the CATENATE extension which has 
passed WGLC.

>>So your example would change to be:
>>
>> (TASTY (FRUIT "banana" COLOR "yellow") TYPE ("rough" "ready"))
>>    
>>
>
>No, it wouldn't, and the fact that you got it wrong is one reason I
>don't like the grammar you're suggesting.  My example was this:
>
> (TASTY (FRUIT "banana") (COLOR ("yellow")) (TYPE ("rough" "ready")))
>
>...which means this:
>  Option called TASTY, with no values.
>  Option called FRUIT, with one value, "banana".
>  Option called COLOR, with one calue, "yellow".
>  Option called TYPE, with two values, "rough" and "ready".
>
>With your grammar change, it would become this:
>
> (TASTY FRUIT "banana" COLOR ("yellow") TYPE ("rough" "ready"))
>
>...(parens around "yellow" are optional in both your grammar and mine)
>and yours also allows this variant:
>
> (TASTY FRUIT BANANA COLOR YELLOW TYPE (ROUGH READY))
>
>...which I really dislike.  I have a preference for making the option
>values "string", not "astring".  We have no current options that have
>values, so there's no compatibility issue, and I think the use of atoms
>for option values is a bad thing, syntatically.
>  
>
Some extensions like CONDSTORE use 64bit numbers, which are atoms. Other 
are using message sequences, which can also be represented as atoms.
Anyway, a particular extensions doesn't need to use atom, it can mandate 
string. Nothing says that atom and string representations must be 
treated as equivalent.

Date: Fri, 14 Oct 2005 13:20:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

>>And I would also like to make return options extensible in the same
>>way. For example a client would be able to ask to return subscribed
>>mailboxes that have more than 500 messages in them.
>>    
>>
>
>Hm, I thought that would be a selection option, not a return option,
>and I didn't think we were asking for this change to be made to return
>options.
>
Ok, what about "return the following list of mailbox annotations"?

>  Obviously, changing the grammar for return options is easy
>enough, if it's what we want.  Are we sure it is?
>
>Opinions from others?  
>

Date: Fri, 14 Oct 2005 08:00:57 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Alexey says...
> Can we use syntax consistent with IMAPABNF document?
...
>    option-standard-tag = atom [SP option-value]

I don't like this because it means that there's no syntactic difference
between "(SUBSCRIBED REMOTE)" (two separate options, neither of which
has a value) and "(TYPE REMOTE)" (one option, called TYPE, with the
value REMOTE).

I'm happy to accept the change to option-value, but I'd rather leave
option-standard-tag (and option-vendor-tag) my way:

   option-standard-tag = atom / "(" atom SP option-value ")"

...which puts options that have values into parentheses.  It more
clearly groups the option names and their values.

> So your example would change to be:
> 
>  (TASTY (FRUIT "banana" COLOR "yellow") TYPE ("rough" "ready"))

No, it wouldn't, and the fact that you got it wrong is one reason I
don't like the grammar you're suggesting.  My example was this:

 (TASTY (FRUIT "banana") (COLOR ("yellow")) (TYPE ("rough" "ready")))

...which means this:
  Option called TASTY, with no values.
  Option called FRUIT, with one value, "banana".
  Option called COLOR, with one calue, "yellow".
  Option called TYPE, with two values, "rough" and "ready".

With your grammar change, it would become this:

 (TASTY FRUIT "banana" COLOR ("yellow") TYPE ("rough" "ready"))

...(parens around "yellow" are optional in both your grammar and mine)
and yours also allows this variant:

 (TASTY FRUIT BANANA COLOR YELLOW TYPE (ROUGH READY))

...which I really dislike.  I have a preference for making the option
values "string", not "astring".  We have no current options that have
values, so there's no compatibility issue, and I think the use of atoms
for option values is a bad thing, syntatically.

> And I would also like to make return options extensible in the same
> way. For example a client would be able to ask to return subscribed
> mailboxes that have more than 500 messages in them.

Hm, I thought that would be a selection option, not a return option,
and I didn't think we were asking for this change to be made to return
options.  Obviously, changing the grammar for return options is easy
enough, if it's what we want.  Are we sure it is?

Opinions from others?

Barry

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

Date: Fri, 14 Oct 2005 12:13:46 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

Barry Leiba wrote:

>1. The option syntax now allows for options that have values.  The
>following would be syntactically valid for the selection options:
>(TASTY (FRUIT "banana") (COLOR ("yellow")) (TYPE ("rough" "ready")))
>
>I could easily change the grammar to eliminate (COLOR ("yellow")),
>allowing the inner parentheses only if there are more than one value.
>I don't care either way.
>
Sorry for being too late with the reply.
Can we use syntax consistent with IMAPABNF document? I.e. each option 
has an optional value, which is enclosed in parenthesizes if it contains 
multiple strings/atoms. If we are to use the same syntax, here is how it 
would look like:

   option-standard-tag = atom [SP option-value]
               ; an option defined in a Standards Track or Experimental RFC

   option-value = astring / "(" [option-value-comp] ")"

   option-value-comp     = astring /
                      option-value-comp *(SP option-value-comp) /
                      "(" option-value-comp ")"

   option-vendor-tag = vendor-token "-" atom [SP option-value]
               ; a vendor specific option, non-standard

So your example would change to be:

 (TASTY (FRUIT "banana" COLOR "yellow") TYPE ("rough" "ready"))

And I would also like to make return options extensible in the same way. 
For example a client would be able to ask to return subscribed mailboxes 
that have more than 500 messages in them.

Date: Wed, 12 Oct 2005 16:57:05 -0700
From: Peter Coates <[email-masked]>
Subject: search annotation
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_Rmx2dFbo7njzK3g/U4zOog)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Unlike some of my previous observations, this note is purely about
difficulty of implementation, rather than about ambiguity or impossibility
of implementation.
 
Consider a search of
 
aa search (annotate "/flags/\*" "value" "1")
 
First, what use is this?  Is is ever going to be used by a client?  Second,
note that it is different from the search
 
aa search (annotate "/flags/\answered" "value" "1" annotate
"/flags/\flagged" "value" "1" annotate "/flags/\deleted" "value" "1"
annotate "/flags/\seen" "value" "1" annotate "/flags/\draft" "value" "1"
annotate "/flags/\recent" "value" "1" )
 
The first search means messages with ANY flag set, the second means messages
with ALL flags set  The first search requires a lot of work to represent as
flag masks so the search can be represented in an efficient form.  The same
goes, obviously for searches where there is wild carding that includes both
flags and"real" annotations, eg
 
aa search (annotation "*" "value" "1")
 
There is a huge amount of work to implement these things efficiently, and
the usefulness of these searches escapes me.  The only use for wild cards in
searches that seem to me to be even remotely useful is where the wild card
matches the body part specifier, eg
 
aa search (annotation "/%/comment "value" "foo")
 
which means (usefully) "find those messages where any part comment contains
foo".

I would preclude any wild carding of the entry name in the search other than
this one case.
 
Wildcarding the attribute name seems to me to be even less useful.  I would
explicitly forbid it.
 
I'm not afraid of a bit of hard work to implement this stuff, but where it
feels like gratuitous hard work for no useful gain, then ...  Besides, you
end up with infrequently used code paths in the system, and it is is such
dark corners that bugs lurk.
 
Peter

--Boundary_(ID_Rmx2dFbo7njzK3g/U4zOog)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=319431623-12102005><FONT size=2>Unlike some of my previous 
observations, this note is purely about difficulty of implementation, rather 
than about ambiguity or impossibility of implementation.</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>Consider a search 
of</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>aa search (annotate "/flags/\*" 
"value" "1")</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>First, what use is this? 
&nbsp;Is is ever going to be used by a client?&nbsp; Second, note that it is 
different from the search</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>aa search (annotate 
"/flags/\answered" "value" "1" annotate "/flags/\flagged" "value" "1" annotate 
"/flags/\deleted" "value" "1" annotate "/flags/\seen" "value" "1" annotate 
"/flags/\draft" "value" "1" annotate "/flags/\recent" "value" "1" 
)</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>The first search means messages 
with ANY flag set, the second means messages with ALL flags set&nbsp;&nbsp;The 
first search&nbsp;requires&nbsp;a lot of&nbsp;work to represent as flag masks so 
the search can be represented in an efficient form.&nbsp; The same goes, 
obviously for searches where there is wild carding that includes both flags 
and"real" annotations, eg</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>aa search (annotation "*" 
"value" "1")</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>There is a huge amount of work 
to implement these things efficiently, and the usefulness&nbsp;of these searches 
escapes me.&nbsp; The only use for wild cards in searches that seem to me to be 
even remotely useful is where the wild card matches the body part specifier, 
eg</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>aa search (annotation 
"/%/comment "value" "foo")</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV><SPAN 
class=319431623-12102005><FONT size=2>
<DIV><SPAN class=319431623-12102005><FONT size=2>which means (usefully) "find 
those messages where any part comment contains foo".</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I would preclude any wild carding of the entry name in the search other 
than this one case.</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005></SPAN><SPAN class=319431623-12102005><FONT 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>Wildcarding the attribute name 
seems to me to be even less useful.&nbsp; I would explicitly forbid 
it.</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2>I'm not afraid of a bit of hard 
work to implement this stuff, but where it feels like gratuitous hard work for 
no useful gain, then ...&nbsp; Besides, you end up with infrequently used code 
paths in the system, and it is is such dark corners that bugs 
lurk.</FONT></SPAN></DIV>
<DIV><SPAN class=319431623-12102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=319431623-12102005><FONT 
size=2>Peter</FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_Rmx2dFbo7njzK3g/U4zOog)--

Date: Wed, 12 Oct 2005 09:49:20 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-14
Sender: [email-masked]

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

I was hoping to get this dreadfully-late draft out yesterday, but ran
into a snag with a change to the ABNF that I had trouble sorting out.
Please take particular care to examine the "list-select-*" elements in
the ABNF, to make sure they're right.

Also look at the "option-*" elements, because I changed those, too, to
allow options with values (in fact, I allow multiple values).

Apart from minor editorial changes, some of which were suggested on
this list, I've made the following significant changes:

1. The option syntax now allows for options that have values.  The
following would be syntactically valid for the selection options:
(TASTY (FRUIT "banana") (COLOR ("yellow")) (TYPE ("rough" "ready")))

I could easily change the grammar to eliminate (COLOR ("yellow")),
allowing the inner parentheses only if there are more than one value.
I don't care either way.

2. In discussion to resolve the "what does (REMOTE RECURSIVEMATCH)
mean?" question, I think we decided that "REMOTE" is a special option,
and I've changed the text to reflect that (see the third paragraph
about "REMOTE" on page 9).  I changed the ABNF to match this.

The ABNF used to have two types of selection options, which it called
"base" and "mod"; if any "mod" options were present, at least one
"base" option had to be present also.  RECURSIVEMATCH is the only "mod"
option.  So the point, here, was that you can't have RECURSIVEMATCH by
itself.

But now we have REMOTE being different -- its presence doesn't change
anything with regard to what other options are permitted.  So I've
defined a third type of option, and we now have this:

base -- SUBSCRIBED is the only one of these right now.  If a base
option is present, a mod option MAY also be present.

mod -- RECURSIVEMATCH is the only one right now.  If a mod option is
present, a base option MUST also be present.

independent -- REMOTE is the only one right now.  Independent options
do not syntactically affect the other options.

Add to this the requirement that any number of options may appear, and
the order is not significant.

Again, please make sure I got this right.  If I don't hear by Thursday
morning (New York time) that I made a major goof, I'll submit it to the
I-D editor then.

Barry

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

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

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: April 15, 2006                                 October 12, =
2005

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

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 April 15, 2006.

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 April 15, 2006                 [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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  . . . . . . . . . . . . . . . . . . . =
30

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

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
37

   10. Normative References . . . . . . . . . . . . . . . . . . . . . =
37

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
37

       Intellectual Property and Copyright Statements . . . . . . . . =
39

Leiba & Melnikov         Expires April 15, 2006                 [Page =
2]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                 [Page =
3]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                 [Page =
4]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   f.  adds CHILDINFO extended data item.

Leiba & Melnikov         Expires April 15, 2006                 [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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
   parentheses.  A mailbox name matches a list of mailbox patterns if =
it
   matches at least one mailbox pattern.  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 April 15, 2006                 [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                 [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   See the formal syntax, in Section 6, 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 descendant mailbox that does not match the LIST pattern and
       does match the 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
      descendant mailboxes that are).  With the SUBSCRIBED selection
      option described here, the attributes are accurate, complete, and

Leiba & Melnikov         Expires April 15, 2006                 [Page =
8]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

      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)".

      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.

      The REMOTE selection option has no interaction with other =
options.
      Its effect is to tell the server to apply the other options, if
      any, to remote mailboxes, in addition to local ones.  In
      particular, it has no interaction with RECURSIVEMATCH (see =
below).
      A request for (REMOTE RECURSIVEMATCH) is invalid, because a
      request for (RECURSIVEMATCH) is.  A request for (REMOTE
      RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed =
mailboxes,
      both local and remote.

   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.

Leiba & Melnikov         Expires April 15, 2006                 [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

      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.

   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):

Leiba & Melnikov         Expires April 15, 2006                [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

       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 descendant 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.

Leiba & Melnikov         Expires April 15, 2006                [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   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 at least one descendant 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>)    =
|
   |                |                |                |                =
|

Leiba & Melnikov         Expires April 15, 2006                [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   |       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 April 15, 2006                [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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"

Leiba & Melnikov         Expires April 15, 2006                [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

          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

   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"

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

          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"

Leiba & Melnikov         Expires April 15, 2006                [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

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

          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 April 15, 2006                [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

       C) And finally, suppose that only the mailboxes "Foo" and "Moo"
       are subscribed.  In that case we see this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN
          (CHILDREN)

          S: * LIST (\HasChildren \Subscribed) "/" "Foo"

          S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"

          S: C04 OK done

       (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"

Leiba & Melnikov         Expires April 15, 2006                [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

          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"

          S: * LIST (\Subscribed) "/" "baz2/bar22"

          S: * LIST (\Subscribed) "/" "baz2/bar222"

          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))

Leiba & Melnikov         Expires April 15, 2006                [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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-return-opts =3D "RETURN" SP "(" [return-option *(SP return-
               option)] ")"
               ; list return options, e.g.  CHILDREN

Leiba & Melnikov         Expires April 15, 2006                [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   list-select-base-opt =3D "SUBSCRIBED" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted =3D <"> list-select-base-opt <">

   list-select-independent-opt =3D "REMOTE" / option-extension
               ; options that do not syntactically interact with
               ; other options

   list-select-mod-opt =3D "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-select-opt =3D list-select-base-opt / =
list-select-independent-opt
               / list-select-mod-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

   list-select-opts =3D "(" [
                 (*(list-select-opt SP) list-select-base-opt
                  *(SP list-select-opt))
               / (list-select-independent-opt
                  *(SP list-select-independent-opt))
               ] ")"
               ; Any number of options may be in any order
               ; This allows these:
               ;   ()
               ;   (REMOTE)
               ;   (SUBSCRIBED)
               ;   (SUBSCRIBED REMOTE)
               ;   (SUBSCRIBED RECURSIVEMATCH)
               ;   (SUBSCRIBED REMOTE RECURSIVEMATCH)
               ; But does NOT allow these:
               ;   (RECURSIVEMATCH)
               ;   (REMOTE RECURSIVEMATCH)

   mailbox-list =3D "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]

Leiba & Melnikov         Expires April 15, 2006                [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   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-standard-tag / option-vendor-tag

   option-standard-tag =3D atom / "(" atom SP option-value ")"
               ; an option defined in a Standards Track or Experimental
               RFC

   option-value =3D string / "(" string *(SP string) ")"

   option-vendor-tag =3D vendor-token "-" atom / "(" vendor-token "-" =
atom
               SP option-value ")"
               ; a vendor specific option, non-standard

Leiba & Melnikov         Expires April 15, 2006                [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
2005

   patterns =3D  "(" list-mailbox *(SP list-mailbox) ")"

   return-option =3D "SUBSCRIBED" / "CHILDREN" /
               option-extension

Leiba & Melnikov         Expires April 15, 2006                [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
30]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
34]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
35]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
36]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
37]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
38]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         October =
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 April 15, 2006                [Page =
39]
=0C

--==========F62F6F521464FD90C56C==========--

Date: Tue, 11 Oct 2005 11:15:52 -0700
From: Peter Coates <[email-masked]>
Subject: annotations in sort and search
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_ehIHerWEXR/nHYI4Ge58aQ)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

In search, the meaning of ANNOTATE <entry> <attribute> <value> is SUCCESS if
<value> occurs as a substring in any matching attribute in any matching
entry.  At least that's how I read it.  This clearly has use if the
attributes being searched are really text.  But what of the size attribute.
What use is it to be able to search a numeric field for a substring?  the
meaning of a search on size should be better defined.  Here are some
suggestions
 
(1) preclude search on the size attribute
(2) make search on ANNOTATE <entry> "size*" <value>  return SUCCESS is size
>= value
(3) define a mime type of "text/numeric", define the type of size to be this
type, define the behaviour of search on a "text/numeric" to be as described
in (2)
 
Option 3 allows clients to define better semantics for values too.
 
Note that numeric values sort differently from text.  one might want to sort
on the size of an annotation, and unless the size was defined to be a text
string 8 characters long padded on the left with leading zeros, you would
not get the anticipated result.  On the other hand, why be able to
sort/search on size etc of annotations when you can not search or sort on
the size of headers?
 
Peter

--Boundary_(ID_ehIHerWEXR/nHYI4Ge58aQ)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=343210118-11102005><FONT size=2>In search, the meaning of 
ANNOTATE &lt;entry&gt; &lt;attribute&gt; &lt;value&gt; is SUCCESS if 
&lt;value&gt; occurs as a substring in any matching attribute in any matching 
entry.&nbsp; At least that's how I read it.&nbsp; This clearly has use if the 
attributes being searched are really text.&nbsp; But what of the size 
attribute.&nbsp; What use is it to be able to search a numeric field for a 
substring?&nbsp; the meaning of a search on size should be better defined.&nbsp; 
Here are some suggestions</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>(1) preclude search on the size 
attribute</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>(2) make search on ANNOTATE 
&lt;entry&gt; "size*" &lt;value&gt;&nbsp; return SUCCESS is size &gt;= 
value</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>(3) define a mime type of 
"text/numeric", define the type of size to be this type, define the behaviour of 
search on a "text/numeric" to be as described in (2)</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>Option 3 allows clients to 
define better semantics for values too.</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2>Note that numeric values sort 
differently from text.&nbsp; one might want to sort on the size of an 
annotation, and unless the size was defined to be a text string 8 characters 
long padded on the left with leading zeros, you would not get the anticipated 
result.&nbsp; On the other hand, why be able to sort/search on size etc of 
annotations when you can not search or sort on the size of 
headers?</FONT></SPAN></DIV>
<DIV><SPAN class=343210118-11102005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=343210118-11102005><FONT 
size=2>Peter</FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_ehIHerWEXR/nHYI4Ge58aQ)--

Date: Tue, 11 Oct 2005 18:21:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Meetings, agenda and forward progress
Sender: [email-masked]

Lisa Dusseault wrote:

> I've asked for a meeting for IMAPEXT for the upcoming Vancouver IETF, 
> Nov 6-11.  The agenda for this IETF should be published a little 
> earlier than normal to make it easier for people to make travel plans 
> so of course the request had to go in even earlier.  If we have 
> nothing new to discuss I can cancel the meeting request.
>
> So here's hoping that we'll have something new to discuss by then: new 
> drafts of the comparator document, annotate or list extensions.  These 
> are all overdue already according to the milestones we put together in 
> Paris.  I know a couple authors have had some "stuff" going on but we 
> really need to keep this work on track to finish IMAPEXT and stop 
> blocking other work.
>
> Alexey, Arnt, Barry, Cyrus, and Randy: please follow up with me on 
> whether you'll be in Vancouver; what are the agenda items (open issues 
> for your drafts) including some of the recent traffic on annotations.

I've just requested LC for draft-melnikov-imap-ext-abnf-05.txt.

I've updated my copy of CONDSTORE not to reference ANNOTATE. It turned 
out that no ABNF production has to move to 
draft-melnikov-imap-ext-abnf-05.txt as the result of this change.

And of course there are other IMAP extensions not in our charter that we 
can talk about.

Date: Tue, 11 Oct 2005 12:45:33 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt]
Sender: [email-masked]

--------------000708070907010809050105
Content-type: multipart/alternative; boundary="------------060403000605060503060207"

--------------060403000605060503060207
Content-type: text/plain; charset="us-ascii"

Hi folks,
I intend to LC the following draft shortly, so now is a good time for 
people to review it.

Thanks,
Alexey
-------- Original Message --------
Subject: 	I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt
Date: 	Mon, 10 Oct 2005 15:50:01 -0400
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Collected extensions to IMAP4 ABNF
	Author(s)	: C. Daboo, A. Melnikov
	Filename	: draft-melnikov-imap-ext-abnf-05.txt
	Pages		: 0
	Date		: 2005-10-10
	
Over years many documents from IMAPEXT and LEMONADE working groups,
   as well as many individual documents have added syntactic
   extensions to many base IMAP commands described in RFC 3501. For
   ease of reference this document collects most of such ABNF changes
   in one place.
   
   This document updates ABNF in RFC 3501, RFC 2342 and RFC 2088.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-05.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-ext-abnf-05.txt".

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

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

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

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

-- 
Alexey Melnikov
__________________________________________
Isode M-Box Message Store developer
http://www.isode.com/products/m-box.html

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

Personal Home Page: http://www.melnikov.ca
__________________________________________

--------------060403000605060503060207
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi folks,<br>
I intend to LC the following draft shortly, so now is a good time for
people to review it.<br>
<br>
Thanks,<br>
Alexey<br>
-------- Original Message --------
<table border="0" cellpadding="0" cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Mon, 10 Oct 2005 15:50:01 -0400</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Reply-To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Collected extensions to IMAP4 ABNF
	Author(s)	: C. Daboo, A. Melnikov
	Filename	: draft-melnikov-imap-ext-abnf-05.txt
	Pages		: 0
	Date		: 2005-10-10
	
Over years many documents from IMAPEXT and LEMONADE working groups,
   as well as many individual documents have added syntactic
   extensions to many base IMAP commands described in RFC 3501. For
   ease of reference this document collects most of such ABNF changes
   in one place.
   
   This document updates ABNF in RFC 3501, RFC 2342 and RFC 2088.

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-05.txt">http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-05.txt</a>

To remove yourself from the I-D Announcement list, send a message to 
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> with the word unsubscribe in the body of the message.  
You can also visit <a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1.ietf.org/mailman/listinfo/I-D-announce</a> 
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-melnikov-imap-ext-abnf-05.txt".

A list of Internet-Drafts directories can be found in
<a class="moz-txt-link-freetext" href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> 
or <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>

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

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

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

</pre>
<br>
<pre class="moz-signature" cols="72">-- 
Alexey Melnikov
__________________________________________
Isode M-Box Message Store developer
<a class="moz-txt-link-freetext" href="http://www.isode.com/products/m-box.html">http://www.isode.com/products/m-box.html</a>

IETF standard related pages:
<a class="moz-txt-link-freetext" href="http://www.melnikov.ca/mel/devel/Links.html">http://www.melnikov.ca/mel/devel/Links.html</a>

Personal Home Page: <a class="moz-txt-link-freetext" href="http://www.melnikov.ca">http://www.melnikov.ca</a>
__________________________________________
</pre>
</body>
</html>

--------------060403000605060503060207--

--------------000708070907010809050105
Content-type: Message/External-body; name="draft-melnikov-imap-ext-abnf-05.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="draft-melnikov-imap-ext-abnf-05.txt"

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

--------------000708070907010809050105
Content-type: text/plain; name="file:///D|/TEMP/nsmail-1.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="file:///D|/TEMP/nsmail-1.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------000708070907010809050105--

Date: Mon, 10 Oct 2005 16:54:13 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Behaviour of fetch annotation
To: "'Mark Crispin'" <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

OK, so lets look at what we have for fetch annotate.  Remember that the
annotation have to be evaluated for each message.

1) the entries and attributes can be wild carded, including message part
specifiers. 
2) wild carded requests (currently) are required to return at least one
value for each message in whose context they are evaluated.

If we change that so that a request for an attribute for an entry on a bogus
body part returns nothing, then what of bogus wild carded entries?  ("/1.*",
for instance).  Is the initial parse (not in the context of a message)
supposed to distinguish between a wild card that implicates body parts from
those that don't/

Mark, you suggest that a query 
1 fetch 1 annotation ("/2/comment" "value.priv")
should result in
* FETCH 1 (ANNOTATION (NIL)) 

Should 
1 fetch 1 annotation ("/2/*" "value.priv")
should result in the same?

What of
1 fetch 1 annotation (("/1/*" "/2/*") "value.priv")

What should be returned for 
1 fetch 1 annotation (("/2/*" "/comment) "value.priv")

I think the only hope is to reject as many bogus requests as possible early,
and that means any wild card entries that start "/x where x is non wild and
not a digit and which do not match nay known entry names.  Wild cards that
start * or /* have to be accepted initially even if they prove eventually to
match no entries for any message.  Entries starting % are illegal.  Entries
starting /% have to be accepted if they contain a / other than in the final
position or if they contain a *.  This is getting seriously ugly.

I'm thinking that "servers SHOULD reject entry names that match no entries
with a BAD response", and "if for a given message none of the entries are
valid, then the fetch response for that message should be of the form
* nn FETCH (ANNOTATION (NIL)) "

That is implementable without too much grief, and is probably useful for
clients.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Crispin
Sent: October 8, 2005 09:03
To: Arnt Gulbrandsen
Cc: [email-masked]; Peter Coates
Subject: Re: Behaviour of fetch annotation

On Sat, 8 Oct 2005, Arnt Gulbrandsen wrote:
> This is, as I see it, the IMAP way.

The IMAP way would be to return a NIL for the messages where the requested
FETCH message data is irrelevant, not return a tagged BAD.

A tagged BAD response is for invalid protocol, not for "data not set". 
The reason why fetching no such message returns BAD is that the client knows
in advance that the message is bad; it does not do so for no such UID.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Meetings, agenda and forward progress
Date: Mon, 10 Oct 2005 15:30:42 -0700
Sender: [email-masked]

I've asked for a meeting for IMAPEXT for the upcoming Vancouver IETF, 
Nov 6-11.  The agenda for this IETF should be published a little 
earlier than normal to make it easier for people to make travel plans 
so of course the request had to go in even earlier.  If we have nothing 
new to discuss I can cancel the meeting request.

So here's hoping that we'll have something new to discuss by then: new 
drafts of the comparator document, annotate or list extensions.  These 
are all overdue already according to the milestones we put together in 
Paris.  I know a couple authors have had some "stuff" going on but we 
really need to keep this work on track to finish IMAPEXT and stop 
blocking other work.

Alexey, Arnt, Barry, Cyrus, and Randy: please follow up with me on 
whether you'll be in Vancouver; what are the agenda items (open issues 
for your drafts) including some of the recent traffic on annotations.

Lisa

Date: Mon, 10 Oct 2005 12:17:04 -0700
From: Peter Coates <[email-masked]>
Subject: value of /flag/* entries
To: [email-masked]
Sender: [email-masked]

Section 3.2.1 says that the value of /flags entries must be one of "0", "1",
or "NIL", Why the two possible values for not set?  This makes searching on
one of these flags more difficult: If I want to find messages that have not
been forwarded I have to say
 
1 search utf-8 (not (annotation "/flags/$forwarded" "value.priv" "1')) 
instead of the more obvious
1 search utf-8 (annotation "/flags/$forwarded" "value.priv" "0')
 
If would appear that the behaviour of the second request is not defined.  It
should not return any messages that have been forwarded, but it may not
return those that have either.  that seems a little unfortunate.

This also affect the sort command, as "0" sorts before "1", but "NIL" sorts
after it.
 
Peter

Date: Sat, 8 Oct 2005 09:03:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Peter Coates <[email-masked]>
Subject: Re: Behaviour of fetch annotation
Sender: [email-masked]

On Sat, 8 Oct 2005, Arnt Gulbrandsen wrote:
> This is, as I see it, the IMAP way.

The IMAP way would be to return a NIL for the messages where the requested 
FETCH message data is irrelevant, not return a tagged BAD.

A tagged BAD response is for invalid protocol, not for "data not set". 
The reason why fetching no such message returns BAD is that the client 
knows in advance that the message is bad; it does not do so for no such 
UID.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Sat, 8 Oct 2005 16:55:46 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Behaviour of fetch annotation
Cc: Peter Coates <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> As I see it, yes. The client is asserting that messages 1 to 100 have 
> a part 2, and is fetching information about it. If the assertion is 
> BAD, the information request is irrelevant.

This is, as I see it, the IMAP way.

I agree that it isn't the only possible way to approach this problem. 
Personally, I rather like the approach you outlined, but in this case I 
think what you or I like is less important than what fits well into the 
existing design.

Arnt

PS: For those who were at the IMAP dinner in Paris, it's a girl. Sofie. 
All is now well, after a bit of a hair-raising start.

Date: Sat, 8 Oct 2005 10:17:54 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Behaviour of fetch annotation
Cc: Peter Coates <[email-masked]>
Sender: [email-masked]

Peter Coates writes:
> But suppose a client sends a command such as
>
> AA fetch 1:100 (annotation ("/2/comment ("value.priv")))
>
> Body part 2 might exist for some, but not all of the messages 
> requested. Is the server supposed to build up its response, and only 
> send the annotations if all messages have a body part 2?

As I see it, yes. The client is asserting that messages 1 to 100 have a 
part 2, and is fetching information about it. If the assertion is BAD, 
the information request is irrelevant.

My implementation is rather suboptimal in this case - it wastes lots of 
RAM and CPU cycles before realising that it has to send BAD. But I 
think that's okay - it's better to optimise for the useful case.

Btw. There's nothing that prohibits this:

C: a fetch 1 (annotation ("/44444/comment ("value")))
S: * 1 FETCH (UID 45)
S: a BAD No such bodypart

In this scenario, the FETCH response is an unsolicited response, 
perfectly legal.

Arnt

Date: Fri, 07 Oct 2005 16:18:18 -0700
From: Peter Coates <[email-masked]>
Subject: RE: Behaviour of fetch annotation
To: "'Peter Coates'" <[email-masked]>, [email-masked]
Sender: [email-masked]

I made a mistake at the end of my last message.  The last suggested
=interaction should have been

Or (if that is ambiguous with having the comment body part present and the
comment NIL) how about

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" NIL) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring comment"))
BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

-------------

And to make life more difficult, what is one supposed to do (assuming that a
BAD response it not actually the answer -- I can believe I'm missing
something here) in the following scenario:

Same store state as before, but with the fetch request:

C: AA fetch 3:4 (body[2] annotation ("/2/* ("value.priv")))

One option would be to expand the * so one gets back something like
S: * 3 FETCH (ANNOTATION ("/2/comment" NIL
                          "/2/flags/\\seen" NIL 
                          "/2/flags/\\answered" NIL
                          "/2/flags/\\flagged" NIL
                          "/2/flags/\\forwarded" NIL)
              BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring")
                          "/2/flags/\\seen" 1 
                          "/2/flags/\\answered" 0
                          "/2/flags/\\flagged" 0
                          "/2/flags/\\forwarded" 0)
              BODY[2] {8}
S: test
S: 
S: )
S: AA OK Completed

Another option would be to reply specifically about the section part

S: * 3 FETCH (ANNOTATION ("/2" NIL))
              BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring")
                          "/2/flags/\\seen" 1 
                          "/2/flags/\\answered" 0
                          "/2/flags/\\flagged" 0
                          "/2/flags/\\forwarded" 0)
              BODY[2] {8}
S: test
S: 
S: )
S: AA OK Completed

Yet another approach would be to generate no output for that particular
entry

S: * 3 FETCH (ANNOTATION ())
              BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring")
                          "/2/flags/\\seen" 1 
                          "/2/flags/\\answered" 0
                          "/2/flags/\\flagged" 0
                          "/2/flags/\\forwarded" 0)
              BODY[2] {8}
S: test
S: 
S: )
S: AA OK Completed

I think I prefer the last option.  Servers should be expected to reject
badly formed entry and attribute names, things that can be recognised as bad
regardless of the message context in which they may be evaluated.  Entries
that can not be determined to be bad as they are parsed, but which do not
match an valid section part, should generate no return data.  Thus it would
be legal for a fetch annotation reply to be "ANNOTATION ()".

Peter Coates

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter Coates
Sent: October 7, 2005 14:43
To: [email-masked]
Subject: Behaviour of fetch annotation

In section 3.2.1 of the IMAP ANNOTATE extension draft-13, it states
 
/<section-part>
      Defines the top-level of entries associated with a specific body
      part of a message.  This entry itself does not contain any
      attributes.  The section-part uses the same numeric part specifier
      syntax as the BODY message data item in the FETCH command
      [RFC3501].  The server MUST return a BAD response if the client
      uses an incorrect part specifier (either incorrect syntax or a
      specifier referring to a non-existent part).  The server MUST
      return a BAD response if the client uses an empty part specifier
      (which is used in IMAP to represent the entire message).

That is quite clear.

But suppose a client sends a command such as

AA fetch 1:100 (annotation ("/2/comment ("value.priv")))

Body part 2 might exist for some, but not all of the messages requested.  Is
the server supposed to build up its response, and only send the annotations
if all messages have a body part 2?

The problem is compounded if you consider that the fetch might look like

AA fetch 1:100 (body[2] annotation ("/2/comment ("value.priv")))

Now it becomes clear that the server can not build up a tentative reply
before realizing that it should reply with a BAD response.

There is also an asymmetry here.  If fetch asks for a body part that doesn't
exist, the response replies NIL.  For instance

C: aa fetch 1:5 body[2]
S: * 1 FETCH (BODY[2] NIL)
S: * 2 FETCH (BODY[2] NIL)
S: * 3 FETCH (BODY[2] NIL)
S: * 4 FETCH (BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (BODY[2] NIL)
S: aa OK Completed

The specification would be far more implementable (and consistent with the
base IMAP specification) if the absence of a body part caused a fetch
annotation for an entry associated with that body part to return NIL rather
than for the whole command to response BAD.

I'm suggesting that the correct behaviour be as illustrated:

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring comment"))
BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

Or (if that is ambiguous with having the comment body part present and the
comment NIL) how about

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" NIL) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring comment"))
BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

Peter Coates

Date: Fri, 07 Oct 2005 14:42:42 -0700
From: Peter Coates <[email-masked]>
Subject: Behaviour of fetch annotation
To: [email-masked]
Sender: [email-masked]

In section 3.2.1 of the IMAP ANNOTATE extension draft-13, it states
 
/<section-part>
      Defines the top-level of entries associated with a specific body
      part of a message.  This entry itself does not contain any
      attributes.  The section-part uses the same numeric part specifier
      syntax as the BODY message data item in the FETCH command
      [RFC3501].  The server MUST return a BAD response if the client
      uses an incorrect part specifier (either incorrect syntax or a
      specifier referring to a non-existent part).  The server MUST
      return a BAD response if the client uses an empty part specifier
      (which is used in IMAP to represent the entire message).

That is quite clear.

But suppose a client sends a command such as

AA fetch 1:100 (annotation ("/2/comment ("value.priv")))

Body part 2 might exist for some, but not all of the messages requested.  Is
the server supposed to build up its response, and only send the annotations
if all messages have a body part 2?

The problem is compounded if you consider that the fetch might look like

AA fetch 1:100 (body[2] annotation ("/2/comment ("value.priv")))

Now it becomes clear that the server can not build up a tentative reply
before realizing that it should reply with a BAD response.

There is also an asymmetry here.  If fetch asks for a body part that doesn't
exist, the response replies NIL.  For instance

C: aa fetch 1:5 body[2]
S: * 1 FETCH (BODY[2] NIL)
S: * 2 FETCH (BODY[2] NIL)
S: * 3 FETCH (BODY[2] NIL)
S: * 4 FETCH (BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (BODY[2] NIL)
S: aa OK Completed

The specification would be far more implementable (and consistent with the
base IMAP specification) if the absence of a body part caused a fetch
annotation for an entry associated with that body part to return NIL rather
than for the whole command to response BAD.

I'm suggesting that the correct behaviour be as illustrated:

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" ("value.priv" "boring comment"))
BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

Or (if that is ambiguous with having the comment body part present and the
comment NIL) how about

C: AA fetch 3:5 (body[2] annotation ("/2/comment ("value.priv")))
S: * 3 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: * 4 FETCH (ANNOTATION ("/2/comment" NIL) BODY[2] {8}
S: test
S: 
S: )
S: * 5 FETCH (ANNOTATION ("/2/comment" ("value.priv" NIL)) BODY[2] NIL)
S: AA OK Completed

Peter Coates

Date: Mon, 03 Oct 2005 14:15:12 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Revision of IMAP URL (RFC 2192)
Sender: [email-masked]

Hi folks,
Lemonade WG has asked if IMAP URL revision (currently 
draft-melnikov-rfc2192bis-00.txt) can be done in the Lemonade WG.
I personally don't see any problem with that, as most of the IMAPEXT 
participants are participating in the Lemonade WG. But if you have any 
concerns, please speak up now.

Thanks,
Alexey