Subject: SPAM/NOTSPAM IMAP extension.
From: Lewis Thompson <[email-masked]>
To: [email-masked]
Date: Thu, 28 Apr 2005 23:52:56 +0100
List-Id: <ietf-imapext.imc.org>

Hi,

I posted this question on the ietf-mta-filters list thinking it was
somewhat related to the Sieve extension but got redirected here.

>From what I've found an IMAP extension for marking email as SPAM or
NOTSPAM does not exist.  I posted this to the ietf-mta-filters list
explaining exactly what I meant:

"My MTA is running with SpamAssassin and an email gets falsely
identified as spam.  It gets delivered to a spam folder where I find it.
I want to prevent it from happening again so I teach SpamAssassin it is
ham and remove the SpamAssassin modifications.  The IMAP command (?)
that does this would be (to make something up) NOTSPAM.

I'm not sure of the IMAP syntax but it might be called something like:
"NOTSPAM message-id".  The IMAP server then invokes SA and strips the
junk (added by SA) and re-learns as ham.

Also I would like to see SPAM, which is the opposite of NOTSPAM
(surprisingly).  If some junk mail gets through SA then I want to teach
SA that it is spam.  Maybe then it would be deleted or moved to a spam
folder (this would probably be done by the user, not the IMAP server).

Obviously in all these cases SpamAssassin could be replaced by any spam
filter.  The IMAP server would have a command that the message simply
gets piped through to do the learning/stripping of junk."

I'm not really sure of exactly how RFC-style things work or whether this
is really suitable.  I've spoken to a few people in passing about such
an extension and all of them seem to think it is a good idea so I'm
fairly sure there is "demand".

What do you guys think about this and where should I go from here?
Thanks very much,

-Lewis Thompson.

-- 
I was so much older then, I'm younger than that now.  --Bob Dylan, 1964.
-| msn:[email-masked] | jabber:[email-masked] | url:www.lewiz.org |-

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-05.txt
Date: Wed, 27 Apr 2005 15:52:09 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 25 Apr 2005 09:17:50 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: 2086upd + two variants of concurrency
Sender: [email-masked]

> Personally, I'd be entirely happy to drop case (b).

I agree.

I have never approved of the use of NO when the real problem is "horrible 
error 69."  It was a mistake that FETCH documented a NO return, since all 
the useful cases are covered by OK and BAD.

This is the sort of circumstance that BYE was created to cover ("the rug 
has been pulled out from under me, time to die").

Hence I favor the (a) case.

The (c) case is the UNIX filesystem behavior; that is, the "r" right is 
enforced by SELECT/EXAMINE but not by FETCH, just as UNIX enforces 
protections on open() and subsequent read() calls depend upon the open 
mode.

So the (c) case is alright too, simply because it may be the natural thing 
to implement for some servers.

-- Mark --

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

From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: 2086upd + two variants of concurrency
Date: Mon, 25 Apr 2005 09:22:22 +0100
Sender: [email-masked]

On Fri Apr 22 15:27:42 2005, Arnt Gulbrandsen wrote:
> 
> Alexey Melnikov wrote:
>> Alexey Melnikov wrote, answering me:
>>>> Some guidance would not be amiss. I don't know what's right or 
>>>> natural. BYE seems overblown, though.
>>> 
>>> A server implementation can start sending NO responses to all 
>>> commands.
> 
> That's what I too thought at first, but then I thought about NOOP, 
> where NO is not permitted, and UW, which sends BYE in a similar 
> case.
> 
> 
Sending BYE might well be the only reasonable way to implement the 
case where the server finds itself unable to read the mailbox data.

Since any good client can handle this case - and probably easier than 
handling a series of NO responses - it's probably the more 
interoperable solution.

> I suggest adding wording roughly like this: "If a server detects 
> that the client has lost access to the current mailbox while in 
> selected state, the server SHOULD send NO to COPY, EXPUNGE, FETCH, 
> SEARCH, STORE and their UID equivalents, and process other commands 
> normally. Servers are not required to detect this case, however."

Rather than that, I'd make it something like:

"
If a server detects that the client no longer has the "r" right to 
the selected mailbox, then it MUST do one of the following:

a) Issue a unilateral BYE response and terminate the connection.
b) Issue none of the responses from sections 7.3 or 7.4 of [IMAP4], 
or the FLAGS response, and issue immediate NO responses to any 
command only valid in the selected state. Any command in progress at 
the time of the change in rights MUST complete normally, as if the 
rights had not changed.
c) Do nothing, and act as if the client still has the "r" right in 
that session.
"

This covers all situations which I feel are acceptable.

Personally, I'd be entirely happy to drop case (b). The comaritively 
large amount of text required to specify it doesn't go nearly far 
enough - IDLE, for instance, requires further text.

Unless we can get very careful semantics on case (b), I'd rather 
receive a unilateral BYE and deal with that. I think it's "obvious" 
what the (b) case should be, but I also think it's a very difficult 
case to detect in the client, and not trivial in the server either, 
and, most importantly, very difficult to specify.

Since many clients will raise a modal dialog when they receive a NO, 
I really don't think servers ought to do this unless they want to 
confuse clients, end-users, or both.

Dave.

Date: Fri, 22 Apr 2005 16:27:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: 2086upd + two variants of concurrency
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov wrote:
> Alexey Melnikov wrote, answering me:
>>> Some guidance would not be amiss. I don't know what's right or 
>>> natural. BYE seems overblown, though.
>>
>> A server implementation can start sending NO responses to all commands.

That's what I too thought at first, but then I thought about NOOP, where 
NO is not permitted, and UW, which sends BYE in a similar case.

I suggest adding wording roughly like this: "If a server detects that 
the client has lost access to the current mailbox while in selected 
state, the server SHOULD send NO to COPY, EXPUNGE, FETCH, SEARCH, STORE 
and their UID equivalents, and process other commands normally. Servers 
are not required to detect this case, however."

Arnt

Date: Fri, 22 Apr 2005 12:00:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: 2086upd + two variants of concurrency
Sender: [email-masked]

Alexey Melnikov wrote:

>> 2.
>>
>> If a session is in selected state, and a SETACL/DELETEACL command 
>> means that the session would not any more have the ability to enter 
>> selected state for the current mailbox, what should the server say?
>>
>> Doing nothing is accepted by the draft. I think that's okay. But if 
>> the server doesn't want to do nothing at all, what should it do?
>>
>> Some guidance would not be amiss. I don't know what's right or 
>> natural. BYE seems overblown, though.
>
> A server implementation can start sending NO responses to all commands.
>
> Do people think that anything has to be said about this?

Actually, section 6.1.1 already has some text about this:

   Servers MAY cache the rights a user has on a mailbox when the mailbox
   is selected, so that if a client's rights on a mailbox are changed with
   SETACL or DELETEACL, commands specific to the selected state (e.g., 
STORE,
   EXPUNGE) might not reflect the changed rights until the mailbox is
   re-selected. If the server checks the rights on each command, then it 
SHOULD
   send FLAGS and PERMANENTFLAGS responses if they have changed.

So, how about adding the following to the end of this paragraph:
   If such server detects that the user no longer has read access to the
   mailbox, it MAY refuse to execute all commands specific to the 
selected state
   until the mailbox is closed.

I think just saying "refuse to execute" is better than saying "refuse to 
execute with NO tagged response", because some commands should never 
return NO.

Alexey

Date: Fri, 22 Apr 2005 11:39:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: 2086upd + two variants of concurrency
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Hi,
>
> I'm not sure whether either of these need changes to 2086upd. Since I 
> can't remember any discussion of this, I thought I'd post, though.
>
> 1.
>
> There isn't any specific mention of concurrent exection in 2086upd. 
> The way I read 3501 section 5.5, it says/implies the right thing. But 
> it wouldn't hurt to state specifically that SETACL/DELETEACL affects 
> all commands received by the server after it receives the 
> SETALC/DELETEACL command. ("Receive" as opposed to "execute".)

I think this might be a sensible reminder to add.

(As a side note, does anybody know of a server that processes IMAP 
commands out of order?)

> 2.
>
> If a session is in selected state, and a SETACL/DELETEACL command 
> means that the session would not any more have the ability to enter 
> selected state for the current mailbox, what should the server say?
>
> Doing nothing is accepted by the draft. I think that's okay. But if 
> the server doesn't want to do nothing at all, what should it do?
>
> Some guidance would not be amiss. I don't know what's right or 
> natural. BYE seems overblown, though.

A server implementation can start sending NO responses to all commands.

Do people think that anything has to be said about this?

Date: Wed, 20 Apr 2005 23:09:51 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: 2086upd + two variants of concurrency
Sender: [email-masked]

Hi,

I'm not sure whether either of these need changes to 2086upd. Since I 
can't remember any discussion of this, I thought I'd post, though.

1.

There isn't any specific mention of concurrent exection in 2086upd. The 
way I read 3501 section 5.5, it says/implies the right thing. But it 
wouldn't hurt to state specifically that SETACL/DELETEACL affects all 
commands received by the server after it receives the SETALC/DELETEACL 
command. ("Receive" as opposed to "execute".)

2.

If a session is in selected state, and a SETACL/DELETEACL command means 
that the session would not any more have the ability to enter selected 
state for the current mailbox, what should the server say?

Doing nothing is accepted by the draft. I think that's okay. But if the 
server doesn't want to do nothing at all, what should it do?

Some guidance would not be amiss. I don't know what's right or natural. 
BYE seems overblown, though.

Arnt

Date: Tue, 19 Apr 2005 18:02:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Extensions of ACL Extension (fwd)
Organization: Networks & Distributed Computing
Sender: [email-masked]

I received the following message regarding ACL.  This should go into 
consideration as part of ACL2.

-- Mark --

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

---------- Forwarded message ----------
Date: Mon, 18 Apr 2005 09:36:47 +0200
From: Arnaud Taddei <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Extensions of ACL Extension

Hi Mark, again me,

I have very very naive questions on the ACL extension.

Today with the ACL extension you can only manipulate a pair of
information which are:

     * an identifier
     * permissions (which are, btw, exclusively 'CMU' or 'AFS' alike,
       with the famous list of letters 'rlidwka').

Firstly, just at this level this is very painful because I would need to
manipulate a 'triplet' and not a 'pair' of information

     * a human readable name identifier,
     * an identifier ID for the system to uniquely identify the resource,
     * permissions

because there is only one possibility to describe the identifier, if you
can just enter a number and not a Human readable name, the poor human is
quite confused and there are needs for many new look ups to present
something decent to the end user.

Secondly, in fact I was telling myself that there are many different
permissions or authorisation models such as the UNIX file system, I
guess there must be a POSIX one which may be a bit different, AFS and
CMU had their ones, MS Exchange has a different model (which can operate
at the level of one mail or item), etc. etc.

Now for AUTHENTICATION we have a capability called AUTH which gives us a
nice modality model

Why, for the natural 'companion' of Authentication which is
Authorisation, we don't have such a modality model?

At least we could have modality values such as: unix, afs, msexchange,
cmu, etc. etc. we could call the capability AUTHORISATION or something
that makes sense in proper English.

Ok this is far from perfect because each client would need to have the
right 'mapping' for the models it supports or not but at least this
would allow everyone to access the ACCESS Controls and potentially to
remap them.

But at least these 2 points could significantly improve the current
situation which is far from satisfactory.

Well on my side when migrating from MS Exchange to Sun there is no ACL
extension on MS Exchange 5.5 so we had to write a MAPI program to do a
first pass on folders (which is anyway necessary as there are folders
which contain a / in the name and the MS Exchange 5.5 IMAP server cannot
list them when you IMAP LIST so you need to modify the folders name to
see them appear in the IMAP list and then change their name back! and as
well you need to do it because otherwise you will list ALL folders even
those which do not contain mail messages and the folder type is only
available by MAPI - sic)  to retrive their ACLs.

Then we remap them with an agreement with our engineering on what makes
sense and what not etc. and then we can reapply them.

Maybe this is too naive or pragmatic but it works and is accepted by our
customers, etc.

Again, maybe somebody thought about it, but if not, I would simply
volunteer to initiate an update on IMAP ACL extension.

Just let me know

A++

Date: Tue, 12 Apr 2005 11:16:55 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Alexey Melnikov wrote:

> Cyrus Daboo wrote:
>
>> Section 6.1.2 - client cannot preserve an unknown tied right, when 
>> changing the known tied right. e.g. if we have tied rights 'r1', and 
>> the client does not understand '1', it must still be able to remove 
>> 'r' (and thus '1') without violating spec.
>
> The client should ask the user if she wants to either set both, or 
> remove both. That was the intent.
> The text is trying to say that the default should be to set both.
> This needs to be clarified.

The current text in -04 is:

   A client implementation that allows a user to read and update ACLs MUST
   preserve unrecognized rights that it doesn't allow the user to change
   when updating the rights. Otherwise the client could risk unintentionally
   removing permissions.

After thinking more about this, maybe the following text would be better:

   A client implementation that allows a user to read and update ACLs MUST
   preserve unrecognized rights that it doesn't allow the user to change.
   For example, if the server ties "r" and "1" and the client doesn't
   understand the "1" right, it should present the user with the choice
   (a dialog or a configuration option) to grant both rights or to revoke
   both rights. If the client can't do that, for example the client is not
   an interactive one or can't be configured, it must grant both rights.
   Otherwise the client could risk unintentionally removing permissions.

Comments?

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-12.txt
Date: Mon, 11 Apr 2005 15:42:28 -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-12.txt
	Pages		: 34
	Date		: 2005-4-11
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 11 Apr 2005 14:15:23 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-12.txt
Sender: [email-masked]

> Clients, on the other hand, very likely already have a table into
> which they are inserting names from LIST; and as most of these tables
> tend to be sorted there is no particular overhead in dealing with
> duplicates.

That's good enough to change my mind; I'm happy leaving it as it is and
taking out the comment.  Unless others want to violently argue, and
given that "SHOULD" is how the discussion had been going, that is what
I'll do, and I'll consider this item closed.

Barry

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

Date: Mon, 11 Apr 2005 11:06:26 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-12.txt
Sender: [email-masked]

On Mon, 11 Apr 2005, Barry Leiba wrote:
>   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.
>   [[anchor3: Should this be a MUST?]]
> This makes it a "quality of implementation" issue for the server,
> acknowledging that some servers may have difficulty eliminating the
> redundant entries (maybe requiring a subsequent pass through the
> results to pick them out).  On the other hand, it makes the client do
> it.  I'd rather turn it into MUST, but I don't think I can do that
> unilaterally.

Without looking into how it would affect my server, I would still say that 
making it a MUST imposes an "unfunded mandate" on servers that may lead to 
this extension not getting implemented.

It seems to require the server to have a table of what it has sent, and 
for each proposed new item check to see if it is in the table.  Also, what 
if the new item has different status -- this is a particularly nasty 
problem brought about by the bizarre requirement that IMAP allow 
"dual-use" names that are both mailboxes and directories.

Clients, on the other hand, very likely already have a table into which 
they are inserting names from LIST; and as most of these tables tend to be 
sorted there is no particular overhead in dealing with duplicates.

-- Mark --

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

Date: Mon, 11 Apr 2005 13:55:52 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-12.txt
Sender: [email-masked]

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

I have just sent the attached draft to the ID-editor.  It still has
three unresolved issues in it -- look for "[[" in the text
(corresponding to <cref> in the xml source).

I'll repeat them here, with my comments:

1:
      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.  [[anchor2: Is
      this really what we want?  Why?]]

This seems wrong to me, and I don't remember the discussion behind it.
Resolution of this also affects examples 9 and 10.

2:
   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.
   [[anchor3: Should this be a MUST?]]

This makes it a "quality of implementation" issue for the server,
acknowledging that some servers may have difficulty eliminating the
redundant entries (maybe requiring a subsequent pass through the
results to pick them out).  On the other hand, it makes the client do
it.  I'd rather turn it into MUST, but I don't think I can do that
unilaterally.

3:
   "vendor-token" is defined in [ACAP].  [[anchor4: This is an issue in
   moving forward, since ACAP will never move to Draft Standard.  Should
   we define vendor-token here, and also define the IANA registry here?
   Should we put it into another document?  Is there someplace else we
   can get the same definition?]]

I think the only good answer here is to take the text from RFC 2244 and
put it into a separate document that defines "vendor-token" and that
defines the registry.  That document can then be used as a normative
reference from whatever places need to do this, and it will be separate
from the ACAP spec.

Apart from those, I think the -12 version documents the latest
consensus.  Please give it a good look, and point out anything that's
wrong, or that I've messed up in conversion of the source to XML.

Barry

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

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

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: September 2, 2005                                    March =
2005

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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

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

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

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

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

   This Internet-Draft will expire on September 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists we have had to expand the number of list commands,
   since each extension must add its function to both LIST and LSUB, =
and
   these commands are not, as they are defined, extensible.  If we've

Leiba & Melnikov        Expires September 2, 2005               [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   needed the extensions to work together, we've had to add a set of
   commands to mix the different options, the set increasing in size
   with each new extension.  This document describes an extension to =
the
   base LIST command that will allow these additions to be done with
   mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.

Note

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

   This document obsoletes RFC 3348 and updates RFC 2193.

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

Table of Contents

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

   2.  Introduction and overview  . . . . . . . . . . . . . . . . . .  =
5

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

   4.  The CHILDREN return Option . . . . . . . . . . . . . . . . . . =
13

   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . =
15

   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . =
22

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . =
25

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . =
26
   8.1 Guidelines for IANA  . . . . . . . . . . . . . . . . . . . . . =
26
   8.2 Registration procedure and Change control  . . . . . . . . . . =
26
   8.3 Registration template for LISTEXT options  . . . . . . . . . . =
27
   8.4 Initial LISTEXT option registrations . . . . . . . . . . . . . =
28
   8.5 Registration template for LISTEXT extended data item . . . . . =
30
   8.6 Initial LISTEXT extended data item registrations . . . . . . . =
31

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
32

   10. Normative References . . . . . . . . . . . . . . . . . . . . . =
32

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
32

       Intellectual Property and Copyright Statements . . . . . . . . =
34

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

2.  Introduction and overview

   The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:
   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");
   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");
   3.  if the LIST command has more than 2 parameters ("LIST return
       options");

   Otherwise the original syntax is used.

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

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

   a.  defines new syntax for LIST command options.
   b.  extends LIST to allow for multiple mailbox patterns.
   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and
       RECURSIVEMATCH.
   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.
   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".
   f.  adds CHILDINFO extended data item.

Leiba & Melnikov        Expires September 2, 2005               [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

3.  Extended LIST Command

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

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

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

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

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

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

Leiba & Melnikov        Expires September 2, 2005               [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

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

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

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

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

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

   or...

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

   See the formal grammar, below, for the full syntactic details.  The
   server MUST NOT return any extended data item, unless the client has
   expressed its ability to support extended LIST responses, for =
example

Leiba & Melnikov        Expires September 2, 2005               [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   by using an extended LIST command.  The server MAY return data in =
the
   extended fields that was not solicited by the client.  The client
   MUST ignore all extended fields it doesn't recognize.

   The LISTEXT capability also defines several new mailbox attributes.

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

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

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

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

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

   The selection options defined in this specification are

   SUBSCRIBED - causes the LIST command to list subscribed names, =
rather
      than the existing mailboxes.  This will often be a subset of the
      actual mailboxes.  It's also possible for this list to contain =
the
      names of mailboxes that don't exist.  In any case, the list MUST
      include exactly those mailbox names that match the canonical list
      pattern and are subscribed to.  This option is intended to
      supplement the LSUB command.  Of particular note are the mailbox
      attributes as returned by this option, compared with what is
      returned by LSUB.  With the latter, the attributes returned may
      not reflect the actual attribute status on the mailbox name, and
      the \NoSelect attribute has a special meaning (it indicates that
      this mailbox is not, itself, subscribed, but that it has child
      mailboxes that are).  With the SUBSCRIBED selection option
      described here, the attributes are accurate, complete, and have =
no
      special meanings.  "LSUB" and "LIST (SUBSCRIBED)" are, thus, not
      the same thing, and some servers must do significant extra work =
to
      respond to "LIST (SUBSCRIBED)".  Because of this, clients SHOULD
      continue to use "LSUB" unless they specifically want the
      additional information offered by "LIST (SUBSCRIBED)".

Leiba & Melnikov        Expires September 2, 2005               [Page =
8]
=0C

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

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

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

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

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

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

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

      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.  [[anchor2: Is
      this really what we want?  Why?]]

      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

Leiba & Melnikov        Expires September 2, 2005               [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

      client had a chance to access them.

   The return options defined in this specification are

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

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

3.1  General principles for returning LIST responses

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

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

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

       A.  the mailbox name also satisfies the selection criteria;

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

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

3.2  Additional requirements on LISTEXT clients

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

   The following table summarizes inference rules described in
   Section 3.

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

3.3  CHILDINFO extended data item

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

   The CHILDINFO extended data item in a LIST response describes the
   selection criteria that has caused it to be returned and indicates
   that the mailbox has st least one child mailbox that matches the
   selection criteria.

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

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   That is, servers SHOULD suppress redundant CHILDINFO responses.
   [[anchor3: Should this be a MUST?]]

   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 |     LISTEXT    =
|
   |                |    criteria    |    selection   | attributes and =
|
   |                |                |    criteria    |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+
   |       no       |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       yes      |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       no       |       yes      |       no       |  (\NonExistent =
|
   |                |                |                |     <attr>)    =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       no       |    (<attr>)    =
|
   |                |                |                |                =
|
   |       no       |       no       |       yes      | (\NonExistent) =
|
   |                |                |                |   + CHILDINFO  =
|
   |                |                |                |                =
|
   |       yes      |       no       |       yes      | () + CHILDINFO =
|
   |                |                |                |                =
|
   |       no       |       yes      |       yes      |  (\NonExistent =
|
   |                |                |                |    <attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       yes      |   (<attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

4.  The CHILDREN return Option

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

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

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

5.  Examples

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

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

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

          C: A02 LIST (SUBSCRIBED) "" "*"
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"
          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: A02 OK done

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

          C: A03 LIST () "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Fruit"
          S: * LIST (\HasNoChildren) "/" "Tofu"
          S: * LIST (\HasChildren) "/" "Vegetable"
          S: A03 OK done

Leiba & Melnikov        Expires September 2, 2005              [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

          C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Fruit"
          S: * LIST (\HasNoChildren) "/" "Tofu"
          S: * LIST (\HasChildren) "/" "Vegetable"
          S: * LIST (\Remote) "/" "Bread"
          S: * LIST (\HasChildren \Remote) "/" "Meat"
          S: A04 OK done

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

          C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"
          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
          S: * LIST (\Subscribed) "/" "Vegetable"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: * LIST (\Remote \Subscribed) "/" "Bread"
          S: A05 OK done

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

       Note that the output of this command is not a superset of the
       output in the previous example, as it doesn't include LIST
       response for the non-existent "Fruit/Peach".

          C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST () "/" "Fruit"
          S: * LIST () "/" "Fruit/Apple"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"

Leiba & Melnikov        Expires September 2, 2005              [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

          S: * LIST () "/" "Tofu"
          S: * LIST (\Subscribed) "/" "Vegetable"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: * LIST () "/" "Vegetable/Corn"
          S: * LIST (\Remote \Subscribed) "/" "Bread"
          S: * LIST (\Remote) "/" "Meat"
          S: A06 OK done

   7:  In the following example the client has specified multiple
       mailbox patterns.  Note that this example doesn't use the =
mailbox
       hierarchy used in the previous examples.

          C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
          S: * LIST () "/" "INBOX"
          S: * LIST (\NoInferiors) "/" "Drafts"
          S: * LIST () "/" "Sent/March2004"
          S: * LIST (\Marked) "/" "Sent/December2003"
          S: * LIST () "/" "Sent/August2004"
          S: BBB OK done

   8:  The following example demonstates the difference between
       \HasChildren attribute and CHILDINFO extended data item.

       Let's assume there is the following hierarchy:

          C: C01 LIST "" "*"
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST () "/" "Foo"
          S: * LIST () "/" "Foo/Bar"
          S: * LIST () "/" "Foo/Baz"
          S: * LIST () "/" "Moo"
          S: C01 OK done

       If the client asks RETURN (CHILDREN) it will get this:

          C: CA3 LIST "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Foo"
          S: * LIST (\HasNoChildren) "/" "Moo"
          S: CA3 OK done

       A) Let's also assume that the mailbox "Foo/Baz" is the only
       subscribed mailbox.  Then we get this result:

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

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

          S: * LIST (\Subscribed) "/" "Foo/Baz"
          S: C02 OK done

       Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
       will return no mailboxes (as the mailboxes "Moo", "Foo" and
       "Inbox" are NOT subscribed).  However, if the client issues =
this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
          S: C04 OK done

       i.e.  the mailbox "Foo" is not subscribed, but it has a child
       that is.

       A1) If the mailbox "Foo" had been subscribed instead, the last
       command would return this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       or even this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       A2) If we assume instead that the mailbox "Foo" is not part of
       the original hierarchy and is not subscribed, the last command
       will give this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       B) Now, let's assume that no mailbox is subscribed.  In this =
case
       the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will =
return
       no responses, as there are no subscribed children (even though
       "Foo" has children).

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

       (which means that the mailbox "Foo" has children, but none of
       them is subscribed).

   9:  The following example demonstrates that the CHILDINFO extended
       data item is returned whether children mailboxes match the
       canonical LIST pattern or not.

       Let's assume there is the following hierarchy:

          C: D01 LIST "" "*"
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST () "/" "foo2"
          S: * LIST () "/" "foo2/bar1"
          S: * LIST () "/" "foo2/bar2"
          S: * LIST () "/" "baz2"
          S: * LIST () "/" "baz2/bar2"
          S: * LIST () "/" "baz2/bar22"
          S: * LIST () "/" "baz2/bar222"
          S: * LIST () "/" "eps2"
          S: * LIST () "/" "eps2/mamba"
          S: * LIST () "/" "quux2/bar2"
          S: D01 OK done

       And that the following mailboxes are subscribed:

          C: D02 LIST (SUBSCRIBED) "" "*"
          S: * LIST (\Subscribed) "/" "foo2/bar1"
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2"
          S: * LIST (\Subscribed) "/" "eps2/mamba"
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D02 OK done

       The client issues the following command first:

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "baz2/bar2"

Leiba & Melnikov        Expires September 2, 2005              [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D03 OK done

       and the server may also include

          S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO"
          ("SUBSCRIBED")))

       The CHILDINFO extended data item is returned for mailboxes
       "foo2", "baz2" and "eps2", because all of them have subscribed
       children, even though for the mailbox "foo2" only one of the two
       subscribed children match the pattern, for the mailbox "baz2" =
all
       the subscribed children match the pattern and for the mailbox
       "eps2" none of the subscribed children match the pattern.

       Note that if the client issues

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "foo2/bar1"
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "baz2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "eps2/mamba"
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D03 OK done

       the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
       have the CHILDINFO extended data item, even though this
       information is redundant and the client can determine it by
       itself.

   10: The following example shows usage of multiple mailbox patterns.
       It also demonstrates that the presence of the CHILDINFO extended
       data item doesn't necessarily imply \HasChildren.

          C: a1 LIST "" ("foo" "foo/*")
          S: * LIST () "/" foo

Leiba & Melnikov        Expires September 2, 2005              [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

          S: a1 OK done

          C: a2 LIST (SUBSCRIBED) "" "foo/*"
          S: * LIST (\Subscribed \NonExistent) "/" foo/bar
          S: a2 OK done

          C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN
          (CHILDREN)
          S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
          ("SUBSCRIBED")))
          S: a3 OK done

Leiba & Melnikov        Expires September 2, 2005              [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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].  [[anchor4: This is an issue in
   moving forward, since ACAP will never move to Draft Standard.  =
Should
   we define vendor-token here, and also define the IANA registry here?
   Should we put it into another document?  Is there someplace else we
   can get the same definition?]]

   childinfo-extended-item =3D "CHILDINFO" SP "("
               list-select-base-opt-quoted
               *( SP list-select-base-opt-quoted ) ")"
               ; Extended data item returned when the RECURSIVEMATCH
               ; selection option is specified.
               ; Note 1: the CHILDINFO tag can be returned
               ;  with and without surrounding quotes, as per
               ;  mbox-list-extended-item-tag production.
               ; Note 2: The selection options are returned quoted,
               ;  unlike their specification in the extended LIST
               ;  command.

   child-mbox-flag =3D "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

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

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

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

   list-select-opts =3D "(" [*(list-select-mod-opt SP)
               list-select-base-opt
               *(SP list-select-opt)] ")"
               ; list selection options, e.g.  REMOTE

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

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

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

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

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

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

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

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

   mbox-list-extended-item-tag =3D astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; or "eitem-standard-tag" ABNF productions.
               ; A tag registration template is described in this
               document
               ; in Section 8.5.

   mbox-list-oflag =3D child-mbox-flag / "\NonExistent" /
               / "\Subscribed" / "\Remote"

   mbox-or-pat =3D list-mailbox / patterns

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

   option-extension =3D option-vendor-tag / option-standard-tag

   option-vendor-tag =3D vendor-tag
               ; a vendor specific option

Leiba & Melnikov        Expires September 2, 2005              [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   option-standard-tag =3D atom
               ; an option defined in a Standard Track or
               ; Experimental RFC

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

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

   vendor-tag =3D vendor-token "-" atom

Leiba & Melnikov        Expires September 2, 2005              [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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 September 2, 2005              [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

8.  IANA Considerations

8.1  Guidelines for IANA

   It is requested that IANA creates two new registries for LISTEXT
   options and LISTEXT extended response data.  The templates and the
   initial registrations are detailed below.

8.2  Registration procedure and Change control

   Registration of a LISTEXT option is done by filling in the template
   in Section 8.3 and sending it via electronic mail to [email-masked].
   Registration of a LISTEXT extended data item is done by filling in
   the template in Section 8.5 and sending it via electronic mail to
   [email-masked].  IANA has the right to reject obviously bogus
   registrations, but will perform no review of claims made in the
   registration form.

   A LISTEXT option/extended data item name that starts with "V-" is
   reserved for vendor specific options/extended data items.  All
   options, whether they are vendor specific or global, should be
   registered with IANA.  If a LISTEXT extended data item is returned =
as
   a result of requesting a particular LISTEXT option, the name of the
   option SHOULD be used as the name of the LISTEXT extended data item.

   Each vendor specific options/extended data item MUST start with =
their
   vendor-token ("vendor prefix").  The vendor-token MUST be registered
   with IANA, using the [ACAP] vendor subtree registry.

   Standard LISTEXT option/extended data item names are case
   insensitive.  If the vendor prefix is omitted from a vendor specific
   LISTEXT option/extended data item name, the rest is case =
insensitive.
   The vendor prefix itself is not case-sensitive, as it might contain
   non-ASCII characters.

   While the registration procedures do not require it, authors of
   LISTEXT options/extended data items are encouraged to seek community
   review and comment whenever that is feasible.  Authors may seek
   community review by posting a specification of their proposed
   mechanism as an Internet- Draft.  LISTEXT options/extended data =
items
   intended for widespread use should be standardized through the =
normal
   IETF process, when appropriate.

   Comments on registered LISTEXT options/extended response data should
   first be sent to the "owner" of the mechanism and/or to the IMAPEXT
   WG mailing list.  Submitters of comments may, after a reasonable
   attempt to contact the owner, request IANA to attach their comment =
to
   the registration itself.  If IANA approves of this, the comment will

Leiba & Melnikov        Expires September 2, 2005              [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   be made accessible in conjunction with the registration LISTEXT
   options/ extended response data itself.

   Once a LISTEXT registration has been published by IANA, the author
   may request a change to its definition.  The change request follows
   the same procedure as the registration request.

   The owner of a LISTEXT registration may pass responsibility for the
   registered option/extended data item to another person or agency by
   informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a LISTEXT option/extended
   data item.  The most common case of this will be to enable changes =
to
   be made to mechanisms where the author of the registration has died,
   moved out of contact or is otherwise unable to make changes that are
   important to the community.

   LISTEXT registrations may not be deleted; mechanisms which are no
   longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such LISTEXT options/extended
   data items will be clearly marked in the lists published by IANA.

   The IESG is considered to be the owner of all LISTEXT
   options/extended data items which are on the IETF standards track.

8.3  Registration template for LISTEXT options

   To: [email-masked]
   Subject: Registration of LISTEXT option X

   LISTEXT option name:

   LISTEXT option type: (One of SELECTION or RETURN)

   Implied return options(s), if the option type is SELECTION: (zero or
   more)

   LISTEXT option description:

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

Leiba & Melnikov        Expires September 2, 2005              [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.4  Initial LISTEXT option registrations

   It is requested that the LISTEXT option registry be populated with
   the following entries:

   1.  To: [email-masked]
       Subject: Registration of LISTEXT option SUBSCRIBED

       LISTEXT option name: SUBSCRIBED

       LISTEXT option type: SELECTION

       Implied return options(s): SUBSCRIBED

       LISTEXT option description: Causes the LIST command to list
       subscribed mailboxes, rather than the actual mailboxes.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   2.  To: [email-masked]
       Subject: Registration of LISTEXT option REMOTE

       LISTEXT option name: REMOTE

       LISTEXT option type: SELECTION

       Implied return options(s): (none)

       LISTEXT option description: causes the LIST command to return
       remote mailboxes as well as local ones, as described in RFC =
2193.

       Published specification : XXXX, Section 3.

Leiba & Melnikov        Expires September 2, 2005              [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   3.  To: [email-masked]
       Subject: Registration of LISTEXT option SUBSCRIBED

       LISTEXT option name: SUBSCRIBED

       LISTEXT option type: RETURN

       LISTEXT option description: Causes the LIST command to return
       subscription state.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   4.  To: [email-masked]
       Subject: Registration of LISTEXT option RECURSIVEMATCH

       LISTEXT option name: RECURSIVEMATCH

       LISTEXT option type: SELECTION

       Implied return options(s): (none)

       LISTEXT option description: Requests that CHILDINFO extended =
data
       item is to be returned.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

Leiba & Melnikov        Expires September 2, 2005              [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   5.  To: [email-masked]
       Subject: Registration of LISTEXT option CHILDREN

       LISTEXT option name: CHILDREN

       LISTEXT option type: RETURN

       LISTEXT option description: Requests mailbox child information.

       Published specification : XXXX, Section 3 and Section 4.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

8.5  Registration template for LISTEXT extended data item

   To: [email-masked]
   Subject: Registration of X LISTEXT extended data item

   LISTEXT extended data item tag:

   LISTEXT extended data item description:

   Which LISTEXT option(s) (and their types) causes this extended data
   item to be returned (if any):

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

Leiba & Melnikov        Expires September 2, 2005              [Page =
30]
=0C

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.6  Initial LISTEXT extended data item registrations

   It is requested that the LISTEXT extended data item registry be
   populated with the following entries:

   1.  To: [email-masked]
       Subject: Registration of CHILDINFO LISTEXT extended data item

       LISTEXT extended data item tag: CHILDINFO

       LISTEXT extended data item description: The CHILDINFO extended
       data item describes the selection criteria that has caused it to
       be returned and indicates that the mailbox has one or more child
       mailbox that match the selection criteria.

       Which LISTEXT option(s) (and their types) causes this extended
       data item to be returned (if any): RECURSIVEMATCH selection
       option

       Published specification : XXXX, Section 3.3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

Leiba & Melnikov        Expires September 2, 2005              [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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 September 2, 2005              [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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 September 2, 2005              [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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 September 2, 2005              [Page =
34]
=0C

--==========1639DEC584825A667DBE==========--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-04.txt
Date: Fri, 08 Apr 2005 15:26:49 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 07 Apr 2005 19:19:01 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

Lisa Dusseault wrote:

> Don't forget the deliverables from the IETF this month, both new 
> drafts  and promised reviews... in addition to the deliverables below, 
> in order  to come up with new milestone dates, I need to get date 
> promises out of  the active draft authors (Cyrus, Randy, Barry, 
> Alexey) for LISTEXT,  ANNOTATE and 2086upd as well as ACL2.
>
> Lisa
>
> On Mar 10, 2005, at 1:53 PM, Lisa Dusseault wrote:
>
>> This is great.  I'll just use this opportunity to extract the  
>> deliverables:
>>  - Lisa to deliver recharter (new milestone dates) for WG
>>  - Alexey to produce new draft of 2086upd addressing last-call and  
>> post-last-call nits
>
Done.

>>  - Cyrus to produce new draft of annotate addressing last call 
>> issues  and incorporating decisions recorded in these minutes
>>  - Alexey and Barry to produce new draft of LISTEXT with no open or  
>> editorial issues remaining, suitable for last call
>>  - Alexey to produce syntax draft for Annotate to use
>
Done (revision -02 is out now, Cyrus is co-authoring).

>>  - Tony Hanson and Barry Leiba to review Chris's Comparator draft 
>> and  ping Chris about it
>>  - Chris Newman to put cycles into Comparator
>>  - Arnt (who was absent) to review Chris's proposed simplification  
>> allowing only one comparator per search query
>

Date: Thu, 07 Apr 2005 19:05:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> In rights table, use 'i' to indicate 'implicit' rights. e.g. for 
> FETCH, the 'r' right is implicit as that is needed to first SELECT the 
> mailbox. Alternatively, provide clear splits in the table for sections 
> based on IMAP state (unauthenticate, authenticated, selected)

I've split the table as you suggested and added the following note:

   Note: for all commands in the selected state the "r" is implied, because
         it is required to SELECT/EXAMINE a mailbox. Servers are not 
required
         to check presence of the "r" right once a mailbox is successfully
         selected.

I think this is the remaining issue I needed to address and I will post 
a new revision of the draft now.

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-13.txt
Date: Fri, 01 Apr 2005 15:24:58 -0500
Sender: [email-masked]

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Subject: SPAM/NOTSPAM IMAP extension.
From: Lewis Thompson <[email-masked]>
To: [email-masked]
Date: Thu, 28 Apr 2005 23:52:56 +0100
Sender: [email-masked]

Hi,

I posted this question on the ietf-mta-filters list thinking it was
somewhat related to the Sieve extension but got redirected here.

>From what I've found an IMAP extension for marking email as SPAM or
NOTSPAM does not exist.  I posted this to the ietf-mta-filters list
explaining exactly what I meant:

"My MTA is running with SpamAssassin and an email gets falsely
identified as spam.  It gets delivered to a spam folder where I find it.
I want to prevent it from happening again so I teach SpamAssassin it is
ham and remove the SpamAssassin modifications.  The IMAP command (?)
that does this would be (to make something up) NOTSPAM.

I'm not sure of the IMAP syntax but it might be called something like:
"NOTSPAM message-id".  The IMAP server then invokes SA and strips the
junk (added by SA) and re-learns as ham.

Also I would like to see SPAM, which is the opposite of NOTSPAM
(surprisingly).  If some junk mail gets through SA then I want to teach
SA that it is spam.  Maybe then it would be deleted or moved to a spam
folder (this would probably be done by the user, not the IMAP server).

Obviously in all these cases SpamAssassin could be replaced by any spam
filter.  The IMAP server would have a command that the message simply
gets piped through to do the learning/stripping of junk."

I'm not really sure of exactly how RFC-style things work or whether this
is really suitable.  I've spoken to a few people in passing about such
an extension and all of them seem to think it is a good idea so I'm
fairly sure there is "demand".

What do you guys think about this and where should I go from here?
Thanks very much,

-Lewis Thompson.

-- 
I was so much older then, I'm younger than that now.  --Bob Dylan, 1964.
-| msn:[email-masked] | jabber:[email-masked] | url:www.lewiz.org |-

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-05.txt
Date: Wed, 27 Apr 2005 15:52:09 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 25 Apr 2005 09:17:50 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: 2086upd + two variants of concurrency
Sender: [email-masked]

> Personally, I'd be entirely happy to drop case (b).

I agree.

I have never approved of the use of NO when the real problem is "horrible 
error 69."  It was a mistake that FETCH documented a NO return, since all 
the useful cases are covered by OK and BAD.

This is the sort of circumstance that BYE was created to cover ("the rug 
has been pulled out from under me, time to die").

Hence I favor the (a) case.

The (c) case is the UNIX filesystem behavior; that is, the "r" right is 
enforced by SELECT/EXAMINE but not by FETCH, just as UNIX enforces 
protections on open() and subsequent read() calls depend upon the open 
mode.

So the (c) case is alright too, simply because it may be the natural thing 
to implement for some servers.

-- Mark --

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

From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: 2086upd + two variants of concurrency
Date: Mon, 25 Apr 2005 09:22:22 +0100
Sender: [email-masked]

On Fri Apr 22 15:27:42 2005, Arnt Gulbrandsen wrote:
> 
> Alexey Melnikov wrote:
>> Alexey Melnikov wrote, answering me:
>>>> Some guidance would not be amiss. I don't know what's right or 
>>>> natural. BYE seems overblown, though.
>>> 
>>> A server implementation can start sending NO responses to all 
>>> commands.
> 
> That's what I too thought at first, but then I thought about NOOP, 
> where NO is not permitted, and UW, which sends BYE in a similar 
> case.
> 
> 
Sending BYE might well be the only reasonable way to implement the 
case where the server finds itself unable to read the mailbox data.

Since any good client can handle this case - and probably easier than 
handling a series of NO responses - it's probably the more 
interoperable solution.

> I suggest adding wording roughly like this: "If a server detects 
> that the client has lost access to the current mailbox while in 
> selected state, the server SHOULD send NO to COPY, EXPUNGE, FETCH, 
> SEARCH, STORE and their UID equivalents, and process other commands 
> normally. Servers are not required to detect this case, however."

Rather than that, I'd make it something like:

"
If a server detects that the client no longer has the "r" right to 
the selected mailbox, then it MUST do one of the following:

a) Issue a unilateral BYE response and terminate the connection.
b) Issue none of the responses from sections 7.3 or 7.4 of [IMAP4], 
or the FLAGS response, and issue immediate NO responses to any 
command only valid in the selected state. Any command in progress at 
the time of the change in rights MUST complete normally, as if the 
rights had not changed.
c) Do nothing, and act as if the client still has the "r" right in 
that session.
"

This covers all situations which I feel are acceptable.

Personally, I'd be entirely happy to drop case (b). The comaritively 
large amount of text required to specify it doesn't go nearly far 
enough - IDLE, for instance, requires further text.

Unless we can get very careful semantics on case (b), I'd rather 
receive a unilateral BYE and deal with that. I think it's "obvious" 
what the (b) case should be, but I also think it's a very difficult 
case to detect in the client, and not trivial in the server either, 
and, most importantly, very difficult to specify.

Since many clients will raise a modal dialog when they receive a NO, 
I really don't think servers ought to do this unless they want to 
confuse clients, end-users, or both.

Dave.

Date: Fri, 22 Apr 2005 16:27:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: 2086upd + two variants of concurrency
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov wrote:
> Alexey Melnikov wrote, answering me:
>>> Some guidance would not be amiss. I don't know what's right or 
>>> natural. BYE seems overblown, though.
>>
>> A server implementation can start sending NO responses to all commands.

That's what I too thought at first, but then I thought about NOOP, where 
NO is not permitted, and UW, which sends BYE in a similar case.

I suggest adding wording roughly like this: "If a server detects that 
the client has lost access to the current mailbox while in selected 
state, the server SHOULD send NO to COPY, EXPUNGE, FETCH, SEARCH, STORE 
and their UID equivalents, and process other commands normally. Servers 
are not required to detect this case, however."

Arnt

Date: Fri, 22 Apr 2005 12:00:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: 2086upd + two variants of concurrency
Sender: [email-masked]

Alexey Melnikov wrote:

>> 2.
>>
>> If a session is in selected state, and a SETACL/DELETEACL command 
>> means that the session would not any more have the ability to enter 
>> selected state for the current mailbox, what should the server say?
>>
>> Doing nothing is accepted by the draft. I think that's okay. But if 
>> the server doesn't want to do nothing at all, what should it do?
>>
>> Some guidance would not be amiss. I don't know what's right or 
>> natural. BYE seems overblown, though.
>
> A server implementation can start sending NO responses to all commands.
>
> Do people think that anything has to be said about this?

Actually, section 6.1.1 already has some text about this:

   Servers MAY cache the rights a user has on a mailbox when the mailbox
   is selected, so that if a client's rights on a mailbox are changed with
   SETACL or DELETEACL, commands specific to the selected state (e.g., 
STORE,
   EXPUNGE) might not reflect the changed rights until the mailbox is
   re-selected. If the server checks the rights on each command, then it 
SHOULD
   send FLAGS and PERMANENTFLAGS responses if they have changed.

So, how about adding the following to the end of this paragraph:
   If such server detects that the user no longer has read access to the
   mailbox, it MAY refuse to execute all commands specific to the 
selected state
   until the mailbox is closed.

I think just saying "refuse to execute" is better than saying "refuse to 
execute with NO tagged response", because some commands should never 
return NO.

Alexey

Date: Fri, 22 Apr 2005 11:39:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: 2086upd + two variants of concurrency
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Hi,
>
> I'm not sure whether either of these need changes to 2086upd. Since I 
> can't remember any discussion of this, I thought I'd post, though.
>
> 1.
>
> There isn't any specific mention of concurrent exection in 2086upd. 
> The way I read 3501 section 5.5, it says/implies the right thing. But 
> it wouldn't hurt to state specifically that SETACL/DELETEACL affects 
> all commands received by the server after it receives the 
> SETALC/DELETEACL command. ("Receive" as opposed to "execute".)

I think this might be a sensible reminder to add.

(As a side note, does anybody know of a server that processes IMAP 
commands out of order?)

> 2.
>
> If a session is in selected state, and a SETACL/DELETEACL command 
> means that the session would not any more have the ability to enter 
> selected state for the current mailbox, what should the server say?
>
> Doing nothing is accepted by the draft. I think that's okay. But if 
> the server doesn't want to do nothing at all, what should it do?
>
> Some guidance would not be amiss. I don't know what's right or 
> natural. BYE seems overblown, though.

A server implementation can start sending NO responses to all commands.

Do people think that anything has to be said about this?

Date: Wed, 20 Apr 2005 23:09:51 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: 2086upd + two variants of concurrency
Sender: [email-masked]

Hi,

I'm not sure whether either of these need changes to 2086upd. Since I 
can't remember any discussion of this, I thought I'd post, though.

1.

There isn't any specific mention of concurrent exection in 2086upd. The 
way I read 3501 section 5.5, it says/implies the right thing. But it 
wouldn't hurt to state specifically that SETACL/DELETEACL affects all 
commands received by the server after it receives the SETALC/DELETEACL 
command. ("Receive" as opposed to "execute".)

2.

If a session is in selected state, and a SETACL/DELETEACL command means 
that the session would not any more have the ability to enter selected 
state for the current mailbox, what should the server say?

Doing nothing is accepted by the draft. I think that's okay. But if the 
server doesn't want to do nothing at all, what should it do?

Some guidance would not be amiss. I don't know what's right or natural. 
BYE seems overblown, though.

Arnt

Date: Tue, 19 Apr 2005 18:02:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Extensions of ACL Extension (fwd)
Organization: Networks & Distributed Computing
Sender: [email-masked]

I received the following message regarding ACL.  This should go into 
consideration as part of ACL2.

-- Mark --

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

---------- Forwarded message ----------
Date: Mon, 18 Apr 2005 09:36:47 +0200
From: Arnaud Taddei <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Extensions of ACL Extension

Hi Mark, again me,

I have very very naive questions on the ACL extension.

Today with the ACL extension you can only manipulate a pair of
information which are:

     * an identifier
     * permissions (which are, btw, exclusively 'CMU' or 'AFS' alike,
       with the famous list of letters 'rlidwka').

Firstly, just at this level this is very painful because I would need to
manipulate a 'triplet' and not a 'pair' of information

     * a human readable name identifier,
     * an identifier ID for the system to uniquely identify the resource,
     * permissions

because there is only one possibility to describe the identifier, if you
can just enter a number and not a Human readable name, the poor human is
quite confused and there are needs for many new look ups to present
something decent to the end user.

Secondly, in fact I was telling myself that there are many different
permissions or authorisation models such as the UNIX file system, I
guess there must be a POSIX one which may be a bit different, AFS and
CMU had their ones, MS Exchange has a different model (which can operate
at the level of one mail or item), etc. etc.

Now for AUTHENTICATION we have a capability called AUTH which gives us a
nice modality model

Why, for the natural 'companion' of Authentication which is
Authorisation, we don't have such a modality model?

At least we could have modality values such as: unix, afs, msexchange,
cmu, etc. etc. we could call the capability AUTHORISATION or something
that makes sense in proper English.

Ok this is far from perfect because each client would need to have the
right 'mapping' for the models it supports or not but at least this
would allow everyone to access the ACCESS Controls and potentially to
remap them.

But at least these 2 points could significantly improve the current
situation which is far from satisfactory.

Well on my side when migrating from MS Exchange to Sun there is no ACL
extension on MS Exchange 5.5 so we had to write a MAPI program to do a
first pass on folders (which is anyway necessary as there are folders
which contain a / in the name and the MS Exchange 5.5 IMAP server cannot
list them when you IMAP LIST so you need to modify the folders name to
see them appear in the IMAP list and then change their name back! and as
well you need to do it because otherwise you will list ALL folders even
those which do not contain mail messages and the folder type is only
available by MAPI - sic)  to retrive their ACLs.

Then we remap them with an agreement with our engineering on what makes
sense and what not etc. and then we can reapply them.

Maybe this is too naive or pragmatic but it works and is accepted by our
customers, etc.

Again, maybe somebody thought about it, but if not, I would simply
volunteer to initiate an update on IMAP ACL extension.

Just let me know

A++

Date: Tue, 12 Apr 2005 11:16:55 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Alexey Melnikov wrote:

> Cyrus Daboo wrote:
>
>> Section 6.1.2 - client cannot preserve an unknown tied right, when 
>> changing the known tied right. e.g. if we have tied rights 'r1', and 
>> the client does not understand '1', it must still be able to remove 
>> 'r' (and thus '1') without violating spec.
>
> The client should ask the user if she wants to either set both, or 
> remove both. That was the intent.
> The text is trying to say that the default should be to set both.
> This needs to be clarified.

The current text in -04 is:

   A client implementation that allows a user to read and update ACLs MUST
   preserve unrecognized rights that it doesn't allow the user to change
   when updating the rights. Otherwise the client could risk unintentionally
   removing permissions.

After thinking more about this, maybe the following text would be better:

   A client implementation that allows a user to read and update ACLs MUST
   preserve unrecognized rights that it doesn't allow the user to change.
   For example, if the server ties "r" and "1" and the client doesn't
   understand the "1" right, it should present the user with the choice
   (a dialog or a configuration option) to grant both rights or to revoke
   both rights. If the client can't do that, for example the client is not
   an interactive one or can't be configured, it must grant both rights.
   Otherwise the client could risk unintentionally removing permissions.

Comments?

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-12.txt
Date: Mon, 11 Apr 2005 15:42:28 -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-12.txt
	Pages		: 34
	Date		: 2005-4-11
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 11 Apr 2005 14:15:23 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-12.txt
Sender: [email-masked]

> Clients, on the other hand, very likely already have a table into
> which they are inserting names from LIST; and as most of these tables
> tend to be sorted there is no particular overhead in dealing with
> duplicates.

That's good enough to change my mind; I'm happy leaving it as it is and
taking out the comment.  Unless others want to violently argue, and
given that "SHOULD" is how the discussion had been going, that is what
I'll do, and I'll consider this item closed.

Barry

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

Date: Mon, 11 Apr 2005 11:06:26 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: draft-ietf-imapext-list-extensions-12.txt
Sender: [email-masked]

On Mon, 11 Apr 2005, Barry Leiba wrote:
>   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.
>   [[anchor3: Should this be a MUST?]]
> This makes it a "quality of implementation" issue for the server,
> acknowledging that some servers may have difficulty eliminating the
> redundant entries (maybe requiring a subsequent pass through the
> results to pick them out).  On the other hand, it makes the client do
> it.  I'd rather turn it into MUST, but I don't think I can do that
> unilaterally.

Without looking into how it would affect my server, I would still say that 
making it a MUST imposes an "unfunded mandate" on servers that may lead to 
this extension not getting implemented.

It seems to require the server to have a table of what it has sent, and 
for each proposed new item check to see if it is in the table.  Also, what 
if the new item has different status -- this is a particularly nasty 
problem brought about by the bizarre requirement that IMAP allow 
"dual-use" names that are both mailboxes and directories.

Clients, on the other hand, very likely already have a table into which 
they are inserting names from LIST; and as most of these tables tend to be 
sorted there is no particular overhead in dealing with duplicates.

-- Mark --

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

Date: Mon, 11 Apr 2005 13:55:52 -0400
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-ietf-imapext-list-extensions-12.txt
Sender: [email-masked]

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

I have just sent the attached draft to the ID-editor.  It still has
three unresolved issues in it -- look for "[[" in the text
(corresponding to <cref> in the xml source).

I'll repeat them here, with my comments:

1:
      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.  [[anchor2: Is
      this really what we want?  Why?]]

This seems wrong to me, and I don't remember the discussion behind it.
Resolution of this also affects examples 9 and 10.

2:
   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.
   [[anchor3: Should this be a MUST?]]

This makes it a "quality of implementation" issue for the server,
acknowledging that some servers may have difficulty eliminating the
redundant entries (maybe requiring a subsequent pass through the
results to pick them out).  On the other hand, it makes the client do
it.  I'd rather turn it into MUST, but I don't think I can do that
unilaterally.

3:
   "vendor-token" is defined in [ACAP].  [[anchor4: This is an issue in
   moving forward, since ACAP will never move to Draft Standard.  Should
   we define vendor-token here, and also define the IANA registry here?
   Should we put it into another document?  Is there someplace else we
   can get the same definition?]]

I think the only good answer here is to take the text from RFC 2244 and
put it into a separate document that defines "vendor-token" and that
defines the registry.  That document can then be used as a normative
reference from whatever places need to do this, and it will be separate
from the ACAP spec.

Apart from those, I think the -12 version documents the latest
consensus.  Please give it a good look, and point out anything that's
wrong, or that I've messed up in conversion of the source to XML.

Barry

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

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

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: September 2, 2005                                    March =
2005

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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

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

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

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

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

   This Internet-Draft will expire on September 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists we have had to expand the number of list commands,
   since each extension must add its function to both LIST and LSUB, =
and
   these commands are not, as they are defined, extensible.  If we've

Leiba & Melnikov        Expires September 2, 2005               [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   needed the extensions to work together, we've had to add a set of
   commands to mix the different options, the set increasing in size
   with each new extension.  This document describes an extension to =
the
   base LIST command that will allow these additions to be done with
   mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.

Note

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

   This document obsoletes RFC 3348 and updates RFC 2193.

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

Table of Contents

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

   2.  Introduction and overview  . . . . . . . . . . . . . . . . . .  =
5

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

   4.  The CHILDREN return Option . . . . . . . . . . . . . . . . . . =
13

   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . =
15

   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . =
22

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . =
25

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . =
26
   8.1 Guidelines for IANA  . . . . . . . . . . . . . . . . . . . . . =
26
   8.2 Registration procedure and Change control  . . . . . . . . . . =
26
   8.3 Registration template for LISTEXT options  . . . . . . . . . . =
27
   8.4 Initial LISTEXT option registrations . . . . . . . . . . . . . =
28
   8.5 Registration template for LISTEXT extended data item . . . . . =
30
   8.6 Initial LISTEXT extended data item registrations . . . . . . . =
31

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
32

   10. Normative References . . . . . . . . . . . . . . . . . . . . . =
32

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
32

       Intellectual Property and Copyright Statements . . . . . . . . =
34

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

2.  Introduction and overview

   The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:
   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");
   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");
   3.  if the LIST command has more than 2 parameters ("LIST return
       options");

   Otherwise the original syntax is used.

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

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

   a.  defines new syntax for LIST command options.
   b.  extends LIST to allow for multiple mailbox patterns.
   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and
       RECURSIVEMATCH.
   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.
   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".
   f.  adds CHILDINFO extended data item.

Leiba & Melnikov        Expires September 2, 2005               [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

3.  Extended LIST Command

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

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

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

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

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

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

Leiba & Melnikov        Expires September 2, 2005               [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

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

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

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

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

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

   or...

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

   See the formal grammar, below, for the full syntactic details.  The
   server MUST NOT return any extended data item, unless the client has
   expressed its ability to support extended LIST responses, for =
example

Leiba & Melnikov        Expires September 2, 2005               [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   by using an extended LIST command.  The server MAY return data in =
the
   extended fields that was not solicited by the client.  The client
   MUST ignore all extended fields it doesn't recognize.

   The LISTEXT capability also defines several new mailbox attributes.

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

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

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

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

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

   The selection options defined in this specification are

   SUBSCRIBED - causes the LIST command to list subscribed names, =
rather
      than the existing mailboxes.  This will often be a subset of the
      actual mailboxes.  It's also possible for this list to contain =
the
      names of mailboxes that don't exist.  In any case, the list MUST
      include exactly those mailbox names that match the canonical list
      pattern and are subscribed to.  This option is intended to
      supplement the LSUB command.  Of particular note are the mailbox
      attributes as returned by this option, compared with what is
      returned by LSUB.  With the latter, the attributes returned may
      not reflect the actual attribute status on the mailbox name, and
      the \NoSelect attribute has a special meaning (it indicates that
      this mailbox is not, itself, subscribed, but that it has child
      mailboxes that are).  With the SUBSCRIBED selection option
      described here, the attributes are accurate, complete, and have =
no
      special meanings.  "LSUB" and "LIST (SUBSCRIBED)" are, thus, not
      the same thing, and some servers must do significant extra work =
to
      respond to "LIST (SUBSCRIBED)".  Because of this, clients SHOULD
      continue to use "LSUB" unless they specifically want the
      additional information offered by "LIST (SUBSCRIBED)".

Leiba & Melnikov        Expires September 2, 2005               [Page =
8]
=0C

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

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

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

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

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

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

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

      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.  [[anchor2: Is
      this really what we want?  Why?]]

      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

Leiba & Melnikov        Expires September 2, 2005               [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

      client had a chance to access them.

   The return options defined in this specification are

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

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

3.1  General principles for returning LIST responses

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

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

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

       A.  the mailbox name also satisfies the selection criteria;

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

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

3.2  Additional requirements on LISTEXT clients

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

   The following table summarizes inference rules described in
   Section 3.

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

3.3  CHILDINFO extended data item

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

   The CHILDINFO extended data item in a LIST response describes the
   selection criteria that has caused it to be returned and indicates
   that the mailbox has st least one child mailbox that matches the
   selection criteria.

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

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   That is, servers SHOULD suppress redundant CHILDINFO responses.
   [[anchor3: Should this be a MUST?]]

   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 |     LISTEXT    =
|
   |                |    criteria    |    selection   | attributes and =
|
   |                |                |    criteria    |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+
   |       no       |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       yes      |       no       |       no       |     no LIST    =
|
   |                |                |                |    response    =
|
   |                |                |                |    returned    =
|
   |                |                |                |                =
|
   |       no       |       yes      |       no       |  (\NonExistent =
|
   |                |                |                |     <attr>)    =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       no       |    (<attr>)    =
|
   |                |                |                |                =
|
   |       no       |       no       |       yes      | (\NonExistent) =
|
   |                |                |                |   + CHILDINFO  =
|
   |                |                |                |                =
|
   |       yes      |       no       |       yes      | () + CHILDINFO =
|
   |                |                |                |                =
|
   |       no       |       yes      |       yes      |  (\NonExistent =
|
   |                |                |                |    <attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   |                |                |                |                =
|
   |       yes      |       yes      |       yes      |   (<attr>) +   =
|
   |                |                |                |    CHILDINFO   =
|
   =
+----------------+----------------+----------------+----------------+

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

4.  The CHILDREN return Option

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

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

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

5.  Examples

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

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

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

          C: A02 LIST (SUBSCRIBED) "" "*"
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"
          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: A02 OK done

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

          C: A03 LIST () "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Fruit"
          S: * LIST (\HasNoChildren) "/" "Tofu"
          S: * LIST (\HasChildren) "/" "Vegetable"
          S: A03 OK done

Leiba & Melnikov        Expires September 2, 2005              [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

          C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Fruit"
          S: * LIST (\HasNoChildren) "/" "Tofu"
          S: * LIST (\HasChildren) "/" "Vegetable"
          S: * LIST (\Remote) "/" "Bread"
          S: * LIST (\HasChildren \Remote) "/" "Meat"
          S: A04 OK done

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

          C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"
          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
          S: * LIST (\Subscribed) "/" "Vegetable"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: * LIST (\Remote \Subscribed) "/" "Bread"
          S: A05 OK done

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

       Note that the output of this command is not a superset of the
       output in the previous example, as it doesn't include LIST
       response for the non-existent "Fruit/Peach".

          C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
          S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
          S: * LIST () "/" "Fruit"
          S: * LIST () "/" "Fruit/Apple"
          S: * LIST (\Subscribed) "/" "Fruit/Banana"

Leiba & Melnikov        Expires September 2, 2005              [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

          S: * LIST () "/" "Tofu"
          S: * LIST (\Subscribed) "/" "Vegetable"
          S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
          S: * LIST () "/" "Vegetable/Corn"
          S: * LIST (\Remote \Subscribed) "/" "Bread"
          S: * LIST (\Remote) "/" "Meat"
          S: A06 OK done

   7:  In the following example the client has specified multiple
       mailbox patterns.  Note that this example doesn't use the =
mailbox
       hierarchy used in the previous examples.

          C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
          S: * LIST () "/" "INBOX"
          S: * LIST (\NoInferiors) "/" "Drafts"
          S: * LIST () "/" "Sent/March2004"
          S: * LIST (\Marked) "/" "Sent/December2003"
          S: * LIST () "/" "Sent/August2004"
          S: BBB OK done

   8:  The following example demonstates the difference between
       \HasChildren attribute and CHILDINFO extended data item.

       Let's assume there is the following hierarchy:

          C: C01 LIST "" "*"
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST () "/" "Foo"
          S: * LIST () "/" "Foo/Bar"
          S: * LIST () "/" "Foo/Baz"
          S: * LIST () "/" "Moo"
          S: C01 OK done

       If the client asks RETURN (CHILDREN) it will get this:

          C: CA3 LIST "" "%" RETURN (CHILDREN)
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST (\HasChildren) "/" "Foo"
          S: * LIST (\HasNoChildren) "/" "Moo"
          S: CA3 OK done

       A) Let's also assume that the mailbox "Foo/Baz" is the only
       subscribed mailbox.  Then we get this result:

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

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

          S: * LIST (\Subscribed) "/" "Foo/Baz"
          S: C02 OK done

       Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
       will return no mailboxes (as the mailboxes "Moo", "Foo" and
       "Inbox" are NOT subscribed).  However, if the client issues =
this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
          S: C04 OK done

       i.e.  the mailbox "Foo" is not subscribed, but it has a child
       that is.

       A1) If the mailbox "Foo" had been subscribed instead, the last
       command would return this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       or even this:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       A2) If we assume instead that the mailbox "Foo" is not part of
       the original hierarchy and is not subscribed, the last command
       will give this result:

          C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
          S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: C04 OK done

       B) Now, let's assume that no mailbox is subscribed.  In this =
case
       the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will =
return
       no responses, as there are no subscribed children (even though
       "Foo" has children).

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

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

       (which means that the mailbox "Foo" has children, but none of
       them is subscribed).

   9:  The following example demonstrates that the CHILDINFO extended
       data item is returned whether children mailboxes match the
       canonical LIST pattern or not.

       Let's assume there is the following hierarchy:

          C: D01 LIST "" "*"
          S: * LIST (\Marked \NoInferiors) "/" "inbox"
          S: * LIST () "/" "foo2"
          S: * LIST () "/" "foo2/bar1"
          S: * LIST () "/" "foo2/bar2"
          S: * LIST () "/" "baz2"
          S: * LIST () "/" "baz2/bar2"
          S: * LIST () "/" "baz2/bar22"
          S: * LIST () "/" "baz2/bar222"
          S: * LIST () "/" "eps2"
          S: * LIST () "/" "eps2/mamba"
          S: * LIST () "/" "quux2/bar2"
          S: D01 OK done

       And that the following mailboxes are subscribed:

          C: D02 LIST (SUBSCRIBED) "" "*"
          S: * LIST (\Subscribed) "/" "foo2/bar1"
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2"
          S: * LIST (\Subscribed) "/" "eps2/mamba"
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D02 OK done

       The client issues the following command first:

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "baz2/bar2"

Leiba & Melnikov        Expires September 2, 2005              [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D03 OK done

       and the server may also include

          S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO"
          ("SUBSCRIBED")))

       The CHILDINFO extended data item is returned for mailboxes
       "foo2", "baz2" and "eps2", because all of them have subscribed
       children, even though for the mailbox "foo2" only one of the two
       subscribed children match the pattern, for the mailbox "baz2" =
all
       the subscribed children match the pattern and for the mailbox
       "eps2" none of the subscribed children match the pattern.

       Note that if the client issues

          C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
          S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "foo2/bar1"
          S: * LIST (\Subscribed) "/" "foo2/bar2"
          S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "baz2/bar2"
          S: * LIST (\Subscribed) "/" "baz2/bar22"
          S: * LIST (\Subscribed) "/" "baz2/bar222"
          S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
          ("SUBSCRIBED")))
          S: * LIST (\Subscribed) "/" "eps2/mamba"
          S: * LIST (\Subscribed) "/" "quux2/bar2"
          S: D03 OK done

       the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
       have the CHILDINFO extended data item, even though this
       information is redundant and the client can determine it by
       itself.

   10: The following example shows usage of multiple mailbox patterns.
       It also demonstrates that the presence of the CHILDINFO extended
       data item doesn't necessarily imply \HasChildren.

          C: a1 LIST "" ("foo" "foo/*")
          S: * LIST () "/" foo

Leiba & Melnikov        Expires September 2, 2005              [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

          S: a1 OK done

          C: a2 LIST (SUBSCRIBED) "" "foo/*"
          S: * LIST (\Subscribed \NonExistent) "/" foo/bar
          S: a2 OK done

          C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN
          (CHILDREN)
          S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
          ("SUBSCRIBED")))
          S: a3 OK done

Leiba & Melnikov        Expires September 2, 2005              [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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].  [[anchor4: This is an issue in
   moving forward, since ACAP will never move to Draft Standard.  =
Should
   we define vendor-token here, and also define the IANA registry here?
   Should we put it into another document?  Is there someplace else we
   can get the same definition?]]

   childinfo-extended-item =3D "CHILDINFO" SP "("
               list-select-base-opt-quoted
               *( SP list-select-base-opt-quoted ) ")"
               ; Extended data item returned when the RECURSIVEMATCH
               ; selection option is specified.
               ; Note 1: the CHILDINFO tag can be returned
               ;  with and without surrounding quotes, as per
               ;  mbox-list-extended-item-tag production.
               ; Note 2: The selection options are returned quoted,
               ;  unlike their specification in the extended LIST
               ;  command.

   child-mbox-flag =3D "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

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

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

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

   list-select-opts =3D "(" [*(list-select-mod-opt SP)
               list-select-base-opt
               *(SP list-select-opt)] ")"
               ; list selection options, e.g.  REMOTE

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

Leiba & Melnikov        Expires September 2, 2005              [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

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

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

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

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

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

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

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

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

   mbox-list-extended-item-tag =3D astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; or "eitem-standard-tag" ABNF productions.
               ; A tag registration template is described in this
               document
               ; in Section 8.5.

   mbox-list-oflag =3D child-mbox-flag / "\NonExistent" /
               / "\Subscribed" / "\Remote"

   mbox-or-pat =3D list-mailbox / patterns

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

   option-extension =3D option-vendor-tag / option-standard-tag

   option-vendor-tag =3D vendor-tag
               ; a vendor specific option

Leiba & Melnikov        Expires September 2, 2005              [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   option-standard-tag =3D atom
               ; an option defined in a Standard Track or
               ; Experimental RFC

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

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

   vendor-tag =3D vendor-token "-" atom

Leiba & Melnikov        Expires September 2, 2005              [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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 September 2, 2005              [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

8.  IANA Considerations

8.1  Guidelines for IANA

   It is requested that IANA creates two new registries for LISTEXT
   options and LISTEXT extended response data.  The templates and the
   initial registrations are detailed below.

8.2  Registration procedure and Change control

   Registration of a LISTEXT option is done by filling in the template
   in Section 8.3 and sending it via electronic mail to [email-masked].
   Registration of a LISTEXT extended data item is done by filling in
   the template in Section 8.5 and sending it via electronic mail to
   [email-masked].  IANA has the right to reject obviously bogus
   registrations, but will perform no review of claims made in the
   registration form.

   A LISTEXT option/extended data item name that starts with "V-" is
   reserved for vendor specific options/extended data items.  All
   options, whether they are vendor specific or global, should be
   registered with IANA.  If a LISTEXT extended data item is returned =
as
   a result of requesting a particular LISTEXT option, the name of the
   option SHOULD be used as the name of the LISTEXT extended data item.

   Each vendor specific options/extended data item MUST start with =
their
   vendor-token ("vendor prefix").  The vendor-token MUST be registered
   with IANA, using the [ACAP] vendor subtree registry.

   Standard LISTEXT option/extended data item names are case
   insensitive.  If the vendor prefix is omitted from a vendor specific
   LISTEXT option/extended data item name, the rest is case =
insensitive.
   The vendor prefix itself is not case-sensitive, as it might contain
   non-ASCII characters.

   While the registration procedures do not require it, authors of
   LISTEXT options/extended data items are encouraged to seek community
   review and comment whenever that is feasible.  Authors may seek
   community review by posting a specification of their proposed
   mechanism as an Internet- Draft.  LISTEXT options/extended data =
items
   intended for widespread use should be standardized through the =
normal
   IETF process, when appropriate.

   Comments on registered LISTEXT options/extended response data should
   first be sent to the "owner" of the mechanism and/or to the IMAPEXT
   WG mailing list.  Submitters of comments may, after a reasonable
   attempt to contact the owner, request IANA to attach their comment =
to
   the registration itself.  If IANA approves of this, the comment will

Leiba & Melnikov        Expires September 2, 2005              [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   be made accessible in conjunction with the registration LISTEXT
   options/ extended response data itself.

   Once a LISTEXT registration has been published by IANA, the author
   may request a change to its definition.  The change request follows
   the same procedure as the registration request.

   The owner of a LISTEXT registration may pass responsibility for the
   registered option/extended data item to another person or agency by
   informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a LISTEXT option/extended
   data item.  The most common case of this will be to enable changes =
to
   be made to mechanisms where the author of the registration has died,
   moved out of contact or is otherwise unable to make changes that are
   important to the community.

   LISTEXT registrations may not be deleted; mechanisms which are no
   longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such LISTEXT options/extended
   data items will be clearly marked in the lists published by IANA.

   The IESG is considered to be the owner of all LISTEXT
   options/extended data items which are on the IETF standards track.

8.3  Registration template for LISTEXT options

   To: [email-masked]
   Subject: Registration of LISTEXT option X

   LISTEXT option name:

   LISTEXT option type: (One of SELECTION or RETURN)

   Implied return options(s), if the option type is SELECTION: (zero or
   more)

   LISTEXT option description:

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

Leiba & Melnikov        Expires September 2, 2005              [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.4  Initial LISTEXT option registrations

   It is requested that the LISTEXT option registry be populated with
   the following entries:

   1.  To: [email-masked]
       Subject: Registration of LISTEXT option SUBSCRIBED

       LISTEXT option name: SUBSCRIBED

       LISTEXT option type: SELECTION

       Implied return options(s): SUBSCRIBED

       LISTEXT option description: Causes the LIST command to list
       subscribed mailboxes, rather than the actual mailboxes.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   2.  To: [email-masked]
       Subject: Registration of LISTEXT option REMOTE

       LISTEXT option name: REMOTE

       LISTEXT option type: SELECTION

       Implied return options(s): (none)

       LISTEXT option description: causes the LIST command to return
       remote mailboxes as well as local ones, as described in RFC =
2193.

       Published specification : XXXX, Section 3.

Leiba & Melnikov        Expires September 2, 2005              [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   3.  To: [email-masked]
       Subject: Registration of LISTEXT option SUBSCRIBED

       LISTEXT option name: SUBSCRIBED

       LISTEXT option type: RETURN

       LISTEXT option description: Causes the LIST command to return
       subscription state.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   4.  To: [email-masked]
       Subject: Registration of LISTEXT option RECURSIVEMATCH

       LISTEXT option name: RECURSIVEMATCH

       LISTEXT option type: SELECTION

       Implied return options(s): (none)

       LISTEXT option description: Requests that CHILDINFO extended =
data
       item is to be returned.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

Leiba & Melnikov        Expires September 2, 2005              [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
2005

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   5.  To: [email-masked]
       Subject: Registration of LISTEXT option CHILDREN

       LISTEXT option name: CHILDREN

       LISTEXT option type: RETURN

       LISTEXT option description: Requests mailbox child information.

       Published specification : XXXX, Section 3 and Section 4.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

8.5  Registration template for LISTEXT extended data item

   To: [email-masked]
   Subject: Registration of X LISTEXT extended data item

   LISTEXT extended data item tag:

   LISTEXT extended data item description:

   Which LISTEXT option(s) (and their types) causes this extended data
   item to be returned (if any):

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

Leiba & Melnikov        Expires September 2, 2005              [Page =
30]
=0C

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.6  Initial LISTEXT extended data item registrations

   It is requested that the LISTEXT extended data item registry be
   populated with the following entries:

   1.  To: [email-masked]
       Subject: Registration of CHILDINFO LISTEXT extended data item

       LISTEXT extended data item tag: CHILDINFO

       LISTEXT extended data item description: The CHILDINFO extended
       data item describes the selection criteria that has caused it to
       be returned and indicates that the mailbox has one or more child
       mailbox that match the selection criteria.

       Which LISTEXT option(s) (and their types) causes this extended
       data item to be returned (if any): RECURSIVEMATCH selection
       option

       Published specification : XXXX, Section 3.3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

Leiba & Melnikov        Expires September 2, 2005              [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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 September 2, 2005              [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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 September 2, 2005              [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions           March =
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 September 2, 2005              [Page =
34]
=0C

--==========1639DEC584825A667DBE==========--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-2086upd-04.txt
Date: Fri, 08 Apr 2005 15:26:49 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 07 Apr 2005 19:19:01 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

Lisa Dusseault wrote:

> Don't forget the deliverables from the IETF this month, both new 
> drafts  and promised reviews... in addition to the deliverables below, 
> in order  to come up with new milestone dates, I need to get date 
> promises out of  the active draft authors (Cyrus, Randy, Barry, 
> Alexey) for LISTEXT,  ANNOTATE and 2086upd as well as ACL2.
>
> Lisa
>
> On Mar 10, 2005, at 1:53 PM, Lisa Dusseault wrote:
>
>> This is great.  I'll just use this opportunity to extract the  
>> deliverables:
>>  - Lisa to deliver recharter (new milestone dates) for WG
>>  - Alexey to produce new draft of 2086upd addressing last-call and  
>> post-last-call nits
>
Done.

>>  - Cyrus to produce new draft of annotate addressing last call 
>> issues  and incorporating decisions recorded in these minutes
>>  - Alexey and Barry to produce new draft of LISTEXT with no open or  
>> editorial issues remaining, suitable for last call
>>  - Alexey to produce syntax draft for Annotate to use
>
Done (revision -02 is out now, Cyrus is co-authoring).

>>  - Tony Hanson and Barry Leiba to review Chris's Comparator draft 
>> and  ping Chris about it
>>  - Chris Newman to put cycles into Comparator
>>  - Arnt (who was absent) to review Chris's proposed simplification  
>> allowing only one comparator per search query
>

Date: Thu, 07 Apr 2005 19:05:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> In rights table, use 'i' to indicate 'implicit' rights. e.g. for 
> FETCH, the 'r' right is implicit as that is needed to first SELECT the 
> mailbox. Alternatively, provide clear splits in the table for sections 
> based on IMAP state (unauthenticate, authenticated, selected)

I've split the table as you suggested and added the following note:

   Note: for all commands in the selected state the "r" is implied, because
         it is required to SELECT/EXAMINE a mailbox. Servers are not 
required
         to check presence of the "r" right once a mailbox is successfully
         selected.

I think this is the remaining issue I needed to address and I will post 
a new revision of the draft now.

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-13.txt
Date: Fri, 01 Apr 2005 15:24:58 -0500
Sender: [email-masked]

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--