draft-ietf-imapext-list-extensions-15.txt   draft-ietf-imapext-list-extensions-16.txt 
IMAP Extensions Working Group B. Leiba IMAP Extensions Working Group B. Leiba
Internet-Draft IBM T.J. Watson Research Center Internet-Draft IBM T.J. Watson Research Center
Updates: 2193 (if approved) A. Melnikov Updates: 2193 (if approved) A. Melnikov
Obsoletes: 3348 (if approved) Isode Limited Obsoletes: 3348 (if approved) Isode Limited
Expires: April 4, 2006 October 2005 Expires: September 5, 2006 March 4, 2006
IMAP4 LIST Command Extensions IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-15 draft-ietf-imapext-list-extensions-16
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2006. This Internet-Draft will expire on September 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we
have added extensions, such as Mailbox Referrals, that have required have added extensions, such as Mailbox Referrals, that have required
specialized lists we have had to expand the number of list commands, 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 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 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 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 commands to mix the different options, the set increasing in size
skipping to change at page 2, line 33 skipping to change at page 2, line 33
3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 6 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 6
3.1 General principles for returning LIST responses . . . . . . . 10 3.1 General principles for returning LIST responses . . . . . . . 10
3.2 Additional requirements on LIST-EXTENDED clients . . . . . . . 11 3.2 Additional requirements on LIST-EXTENDED clients . . . . . . . 11
3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . 11 3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . 11
4. The CHILDREN return Option . . . . . . . . . . . . . . . . . . 14 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . . 14
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . . 31 8.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . . 28
8.2 Registration procedure and Change control . . . . . . . . . . 31 8.2 Registration procedure and Change control . . . . . . . . . . 28
8.3 Registration template for LIST-EXTENDED options . . . . . . . 32 8.3 Registration template for LIST-EXTENDED options . . . . . . . 29
8.4 Initial LIST-EXTENDED option registrations . . . . . . . . . . 33 8.4 Initial LIST-EXTENDED option registrations . . . . . . . . . . 30
8.5 Registration template for LIST-EXTENDED extended data item . . 35 8.5 Registration template for LIST-EXTENDED extended data item . . 32
8.6 Initial LIST-EXTENDED extended data item registrations . . . . 36 8.6 Initial LIST-EXTENDED extended data item registrations . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
10. Normative References . . . . . . . . . . . . . . . . . . . . . 37 10. Normative References . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . 36
1. Conventions used in this document 1. Conventions used in this document
In examples, "C:" indicates lines sent by a client that is connected 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. to a server. "S:" indicates lines sent by the server to the client.
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
used in this document as specified in RFC 2119 [Kwds]. used in this document as specified in RFC 2119 [Kwds].
The term "canonical LIST pattern" refers to the canonical pattern The term "canonical LIST pattern" refers to the canonical pattern
skipping to change at page 6, line 19 skipping to change at page 6, line 19
parentheses. A mailbox name matches a list of mailbox patterns if it parentheses. A mailbox name matches a list of mailbox patterns if it
matches at least one mailbox pattern. If a mailbox name matches matches at least one mailbox pattern. If a mailbox name matches
multiple mailbox patterns from the list, the server SHOULD return multiple mailbox patterns from the list, the server SHOULD return
only a single LIST response. only a single LIST response.
Note that the non-extended LIST command is required to treat an empty Note that the non-extended LIST command is required to treat an empty
("" string) mailbox name argument as a special request to return the ("" string) mailbox name argument as a special request to return the
hierarchy delimiter and the root name of the name given in the hierarchy delimiter and the root name of the name given in the
reference parameter (as per [IMAP4]). However ANY extended LIST reference parameter (as per [IMAP4]). However ANY extended LIST
command (extended in any of 3 ways specified in Section 2, or any 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 combination of thereof) MUST NOT treat the empty mailbox name as such
special request and any regular processing described in this document special request and any regular processing described in this document
applies. In particular, if an extended LIST command has multiple applies. In particular, if an extended LIST command has multiple
mailbox names and one (or more) of them is the empty string, the mailbox names and one (or more) of them is the empty string, the
empty string MUST be ignored for the purpose of matching. empty string MUST be ignored for the purpose of matching.
Some servers might restrict which patterns are allowed in a LIST Some servers might restrict which patterns are allowed in a LIST
command. If a server doesn't accept a particular pattern, it MUST command. If a server doesn't accept a particular pattern, it MUST
silently ignore it. silently ignore it.
The LIST command syntax is also extended in two additional ways: by The LIST command syntax is also extended in two additional ways: by
skipping to change at page 7, line 42 skipping to change at page 7, line 42
extended LIST responses (see below), don't need to advertise the extended LIST responses (see below), don't need to advertise the
"LIST-EXTENDED" capability string. "LIST-EXTENDED" capability string.
This extension also defines extensions to the LIST response, allowing This extension also defines extensions to the LIST response, allowing
a series of extended fields at the end, a parenthesized list of a series of extended fields at the end, a parenthesized list of
tagged data (also referred to as "extended data item"). The first tagged data (also referred to as "extended data item"). The first
element of an extended field is a tag, which identifies type of the 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 data. Tags MUST be registered with IANA, as described in Section 8.5
of this document. An example of such extended set might be of this document. An example of such extended set might be
((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text"))
"text"))
or... or...
((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more tablecloth ("edge" "lacy")) (X-Sample "text" "more text"))
text"))
See the formal syntax, in Section 6, for the full syntactic details. See the formal syntax, in Section 6, for the full syntactic details.
The server MUST NOT return any extended data item, unless the client The server MUST NOT return any extended data item, unless the client
has expressed its ability to support extended LIST responses, for has expressed its ability to support extended LIST responses, for
example by using an extended LIST command. The server MAY return example by using an extended LIST command. The server MAY return
data in the extended fields that was not solicited by the client. data in the extended fields that was not directly solicited by the
The client MUST ignore all extended fields it doesn't recognize. client in the corresponding LIST command. For example, the client
can enable extra extended fields by using another IMAP extension that
make use of the extended LIST responses. The client MUST ignore all
extended fields it doesn't recognize.
The LIST-EXTENDED capability also defines several new mailbox The LIST-EXTENDED capability also defines several new mailbox
attributes. attributes.
The "\NonExistent" attribute indicates that a mailbox does not The "\NonExistent" attribute indicates that a mailbox name does not
actually exist. Note that this attribute is not meaningful by refer to an existing mailbox. Note that this attribute is not
itself, as mailboxes that match the canonical LIST pattern but don't meaningful by itself, as mailbox names that match the canonical LIST
exist must not be returned unless one of the two conditions listed pattern but don't exist must not be returned unless one of the two
below is also satisfied: conditions listed below is also satisfied:
a. the mailbox also satisfies the selection criteria (for example, a. the mailbox name also satisfies the selection criteria (for
its name is subscribed and the "SUBSCRIBED" selection option has example, it is subscribed and the "SUBSCRIBED" selection option
been specified) has been specified)
b. "RECURSIVEMATCH" has been specified, and the mailbox has at least b. "RECURSIVEMATCH" has been specified, and the mailbox name has at
one descendant mailbox that does not match the LIST pattern and least one descendant mailbox name that does not match the LIST
does match the selection criteria. pattern and does match the selection criteria.
In practice this means that the "\NonExistent" attribute is usually In practice this means that the "\NonExistent" attribute is usually
returned with one or more of "\Subscribed", "\Remote" or the returned with one or more of "\Subscribed", "\Remote" or the
CHILDINFO extended data item (see their description below). CHILDINFO extended data item (see their description below).
The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent"
attribute MUST be supported and MUST be accurately computed. attribute MUST be supported and MUST be accurately computed.
The selection options defined in this specification are The selection options defined in this specification are
skipping to change at page 10, line 6 skipping to change at page 10, line 4
Section 3.3. Section 3.3.
Note 1: In order for a parent mailbox to be returned, it still has Note 1: In order for a parent mailbox to be returned, it still has
to match the canonical LIST pattern. to match the canonical LIST pattern.
Note 2: When returning the CHILDINFO extended data item, it Note 2: When returning the CHILDINFO extended data item, it
doesn't matter if the submailbox matches the canonical LIST doesn't matter if the submailbox matches the canonical LIST
pattern or not. See also example 9 in Section 5. pattern or not. See also example 9 in Section 5.
The RECURSIVEMATCH option MUST NOT occur as the only selection The RECURSIVEMATCH option MUST NOT occur as the only selection
option, as it only makes sense when other selection options are option (nor only with REMOTE), as it only makes sense when other
also used. The server MUST return BAD tagged response in such selection options are also used. The server MUST return BAD
case. tagged response in such case.
Note that even if RECURSIVEMATCH option is specified, the client Note that even if RECURSIVEMATCH option is specified, the client
MUST still be able to handle a case when a CHILDINFO extended data MUST still be able to handle a case when a CHILDINFO extended data
item is returned and there are no submailboxes that meet the item is returned and there are no submailboxes that meet the
selection criteria of the given LIST command, as they can be selection criteria of the given LIST command, as they can be
deleted/renamed after the LIST response was sent, but before the deleted/renamed after the LIST response was sent, but before the
client had a chance to access them. client had a chance to access them.
The return options defined in this specification are The return options defined in this specification are
skipping to change at page 14, line 43 skipping to change at page 14, line 43
option is present, the server MUST return these attributes even if option is present, the server MUST return these attributes even if
their computation is expensive. their computation is expensive.
\HasChildren \HasChildren
The presence of this attribute indicates that the mailbox has The presence of this attribute indicates that the mailbox has
child mailboxes. A server SHOULD NOT set this attribute if child mailboxes. A server SHOULD NOT set this attribute if
there are child mailboxes, and the user does not have there are child mailboxes, and the user does not have
permissions to access any of them. In this case, \HasNoChildren permissions to access any of them. In this case, \HasNoChildren
SHOULD be used. In many cases, however, a server may not be SHOULD be used. In many cases, however, a server may not be
able to efficiently compute whether a user has access to all able to efficiently compute whether a user has access to any
child mailboxes. As such a client MUST be prepared to accept child mailbox. Note that even though the \HasChildren attribute
the \HasChildren attribute as a hint. That is, a mailbox MAY be for a mailbox must be correct at the time of processing of the
flagged with the \HasChildren attribute, but no child mailboxes mailbox, a client must be prepared to deal with a situation when
will appear in the LIST response. a mailbox is marked with the \HasChildren attribute, but no
child mailbox appears in the response to the LIST command. This
might happen, for example, due to children mailboxes beig
deleted or made inaccessible to the user (using access control)
by another client before the server is able to list them.
\HasNoChildren \HasNoChildren
The presence of this attribute indicates that the mailbox has NO The presence of this attribute indicates that the mailbox has NO
child mailboxes that are accessible to the currently child mailboxes that are accessible to the currently
authenticated user. authenticated user.
[[anchor2: Alexey: I don't like this optionality:]]
In some instances a server that supports the LIST-EXTENDED extension In some instances a server that supports the LIST-EXTENDED extension
might not be able to determine whether a mailbox has children. For might not be able to determine whether a mailbox has children. For
example it may have difficulty determining whether there are child example it may have difficulty determining whether there are child
mailboxes when LISTing mailboxes while operating in a particular mailboxes when LISTing mailboxes while operating in a particular
namespace. In these cases, a server MAY exclude both the namespace. In these cases, a server MAY exclude both the
\HasChildren and \HasNoChildren attributes in the LIST response. As \HasChildren and \HasNoChildren attributes in the LIST response. As
such, a client can not make any assumptions about whether a mailbox such, a client can not make any assumptions about whether a mailbox
has children based upon the absence of a single attribute. In has children based upon the absence of a single attribute. In
particular, some servers may not be able to combine the SUBSCRIBED particular, some servers may not be able to combine the SUBSCRIBED
selection option and CHILDREN return option. Such servers MUST selection option and CHILDREN return option. Such servers MUST
honour the SUBSCRIBED selection option, and they will simply ignore honour the SUBSCRIBED selection option, and they will simply ignore
the CHILDREN return option if both are requested. It is an error for the CHILDREN return option if both are requested. It is an error for
the server to return both a \HasChildren and a \HasNoChildren the server to return both a \HasChildren and a \HasNoChildren
attribute in a LIST response. attribute for the same mailbox.
Note: the \HasNoChildren attribute should not be confused with the Note: the \HasNoChildren attribute should not be confused with the
IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
child mailboxes exist now and none can be created in the future. child mailboxes exist now and none can be created in the future.
5. Examples 5. Examples
1: The first example shows the complete local hierarchy that will be 1: The first example shows the complete local hierarchy that will be
used for the other examples. used for the other examples.
skipping to change at page 16, line 11 skipping to change at page 16, line 11
Note: the \HasNoChildren attribute should not be confused with the Note: the \HasNoChildren attribute should not be confused with the
IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
child mailboxes exist now and none can be created in the future. child mailboxes exist now and none can be created in the future.
5. Examples 5. Examples
1: The first example shows the complete local hierarchy that will be 1: The first example shows the complete local hierarchy that will be
used for the other examples. used for the other examples.
C: A01 LIST "" "*" C: A01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Apple"
S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Fruit/Banana"
S: * LIST () "/" "Tofu" S: * LIST () "/" "Tofu"
S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable"
S: * LIST () "/" "Vegetable/Broccoli" S: * LIST () "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn" S: * LIST () "/" "Vegetable/Corn"
S: A01 OK done S: A01 OK done
2: In the next example, we'll see the subscribed mailboxes. This is 2: In the next example we'll see the subscribed mailboxes. This is
similar to, but not equivalent with, <LSUB "" "*">. Note that similar to, but not equivalent with, <LSUB "" "*">. Note that
the mailbox called "Fruit/Peach" is subscribed to, but does not the mailbox called "Fruit/Peach" is subscribed to, but does not
actually exist (perhaps it was deleted while still subscribed). actually exist (perhaps it was deleted while still subscribed).
The "Fruit" mailbox is not subscribed to, but it has two The "Fruit" mailbox is not subscribed to, but it has two
subscribed children. The "Vegetable" mailbox is subscribed and subscribed children. The "Vegetable" mailbox is subscribed and
has two children, one of them is subscribed as well. has two children, one of them is subscribed as well.
C: A02 LIST (SUBSCRIBED) "" "*" C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable" S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: A02 OK done S: A02 OK done
3: The next example shows the use of the CHILDREN option. The 3: The next example shows the use of the CHILDREN option. The
client, without having to list the second level of hierarchy, now client, without having to list the second level of hierarchy, now
knows which of the top-level mailboxes have submailboxes knows which of the top-level mailboxes have submailboxes
(children) and which do not. Note that it's not necessary for (children) and which do not. Note that it's not necessary for
the server to return the \HasNoChildren attribute for the inbox, the server to return the \HasNoChildren attribute for the inbox,
because the \NoInferiors attribute already implies that, and has because the \NoInferiors attribute already implies that, and has
a stronger meaning. a stronger meaning.
skipping to change at page 17, line 17 skipping to change at page 16, line 46
3: The next example shows the use of the CHILDREN option. The 3: The next example shows the use of the CHILDREN option. The
client, without having to list the second level of hierarchy, now client, without having to list the second level of hierarchy, now
knows which of the top-level mailboxes have submailboxes knows which of the top-level mailboxes have submailboxes
(children) and which do not. Note that it's not necessary for (children) and which do not. Note that it's not necessary for
the server to return the \HasNoChildren attribute for the inbox, the server to return the \HasNoChildren attribute for the inbox,
because the \NoInferiors attribute already implies that, and has because the \NoInferiors attribute already implies that, and has
a stronger meaning. a stronger meaning.
C: A03 LIST () "" "%" RETURN (CHILDREN) C: A03 LIST () "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST (\HasChildren) "/" "Vegetable"
S: A03 OK done S: A03 OK done
4: In this example we see more mailboxes that reside on another
4: In this example we see more mailboxes, which reside on another
server to which we may obtain referrals. This is similar to the server to which we may obtain referrals. This is similar to the
command <RLIST "" "%">. Note that in the case of the remote command <RLIST "" "%">. Note that in the case of the remote
mailboxes, the server might or might not be able to include mailboxes, the server might or might not be able to include
CHILDREN information; it includes it if it can, and omits it if CHILDREN information; it includes it if it can, and omits it if
it can't. it can't.
C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread" S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat" S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done S: A04 OK done
5: The following example also requests the server to include 5: The following example also requests the server to include
mailboxes, which reside on another server. The server returns mailboxes that reside on another server. The server returns
information about all mailboxes which are subscribed. This is information about all mailboxes which are subscribed. This is
similar to the command <RLSUB "" "%">. We also see the use of similar to the command <RLSUB "" "*">. We also see the use of
two selection options. two selection options.
C: A05 LIST (REMOTE SUBSCRIBED) "" "*" C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable" S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST (\Remote \Subscribed) "/" "Bread" S: * LIST (\Remote \Subscribed) "/" "Bread"
S: A05 OK done S: A05 OK done
6: The following example requests the server to include mailboxes, 6: The following example requests the server to include mailboxes
which reside on another server. The server is requested to that reside on another server. The server is asked to return
return subscription information for all returned mailboxes. This subscription information for all returned mailboxes. This is
is different from the example above. different from the example above.
Note that the output of this command is not a superset of the Note that the output of this command is not a superset of the
output in the previous example, as it doesn't include LIST output in the previous example, as it doesn't include LIST
response for the non-existent "Fruit/Peach". response for the non-existent "Fruit/Peach".
C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Apple"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST () "/" "Tofu" S: * LIST () "/" "Tofu"
S: * LIST (\Subscribed) "/" "Vegetable" S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn" S: * LIST () "/" "Vegetable/Corn"
S: * LIST (\Remote \Subscribed) "/" "Bread" S: * LIST (\Remote \Subscribed) "/" "Bread"
S: * LIST (\Remote) "/" "Meat" S: * LIST (\Remote) "/" "Meat"
S: A06 OK done S: A06 OK done
7: In the following example the client has specified multiple 7: In the following example the client has specified multiple
mailbox patterns. Note that this example doesn't use the mailbox mailbox patterns. Note that this example does not use the
hierarchy used in the previous examples. mailbox hierarchy used in the previous examples.
C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
S: * LIST () "/" "INBOX" S: * LIST () "/" "INBOX"
S: * LIST (\NoInferiors) "/" "Drafts" S: * LIST (\NoInferiors) "/" "Drafts"
S: * LIST () "/" "Sent/March2004" S: * LIST () "/" "Sent/March2004"
S: * LIST (\Marked) "/" "Sent/December2003" S: * LIST (\Marked) "/" "Sent/December2003"
S: * LIST () "/" "Sent/August2004" S: * LIST () "/" "Sent/August2004"
S: BBB OK done S: BBB OK done
8: The following example demonstates the difference between 8: The following example demonstrates the difference between the
\HasChildren attribute and CHILDINFO extended data item. \HasChildren attribute and the CHILDINFO extended data item.
Let's assume there is the following hierarchy: Let's assume there is the following hierarchy:
C: C01 LIST "" "*" C: C01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Foo" S: * LIST () "/" "Foo"
S: * LIST () "/" "Foo/Bar" S: * LIST () "/" "Foo/Bar"
S: * LIST () "/" "Foo/Baz" S: * LIST () "/" "Foo/Baz"
S: * LIST () "/" "Moo" S: * LIST () "/" "Moo"
S: C01 OK done S: C01 OK done
If the client asks RETURN (CHILDREN) it will get this: If the client asks RETURN (CHILDREN) it will get this:
C: CA3 LIST "" "%" RETURN (CHILDREN) C: CA3 LIST "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Foo" S: * LIST (\HasChildren) "/" "Foo"
S: * LIST (\HasNoChildren) "/" "Moo" S: * LIST (\HasNoChildren) "/" "Moo"
S: CA3 OK done S: CA3 OK done
A) Let's also assume that the mailbox "Foo/Baz" is the only A) Let's also assume that the mailbox "Foo/Baz" is the only
subscribed mailbox. Then we get this result: subscribed mailbox. Then we get this result:
C: C02 LIST (SUBSCRIBED) "" "*" C: C02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "Foo/Baz" S: * LIST (\Subscribed) "/" "Foo/Baz"
S: C02 OK done S: C02 OK done
Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
will return no mailboxes (as the mailboxes "Moo", "Foo" and will return no mailboxes (as the mailboxes "Moo", "Foo" and
"Inbox" are NOT subscribed). However, if the client issues this: "Inbox" are NOT subscribed). However, if the client issues this:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED"))) S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done S: C04 OK done
i.e. the mailbox "Foo" is not subscribed, but it has a child that i.e. the mailbox "Foo" is not subscribed, but it has a child that
is. is.
A1) If the mailbox "Foo" had been subscribed instead, the last A1) If the mailbox "Foo" had also been subscribed, the last
command would return this: command would return this:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
("SUBSCRIBED")))
S: C04 OK done S: C04 OK done
or even this: or even this:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO"
S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO" ("SUBSCRIBED"))
("SUBSCRIBED")))
S: C04 OK done S: C04 OK done
A2) If we assume instead that the mailbox "Foo" is not part of A2) If we assume instead that the mailbox "Foo" is not part of
the original hierarchy and is not subscribed, the last command the original hierarchy and is not subscribed, the last command
will give this result: will give this result:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO"
("SUBSCRIBED")))
S: C04 OK done S: C04 OK done
B) Now, let's assume that no mailbox is subscribed. In this case B) Now, let's assume that no mailbox is subscribed. In this case
the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will return the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will return
no responses, as there are no subscribed children (even though no responses, as there are no subscribed children (even though
"Foo" has children). "Foo" has children).
C) And finally, suppose that only the mailboxes "Foo" and "Moo" C) And finally, suppose that only the mailboxes "Foo" and "Moo"
are subscribed. In that case we see this result: are subscribed. In that case we see this result:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
(CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo" S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done S: C04 OK done
(which means that the mailbox "Foo" has children, but none of (which means that the mailbox "Foo" has children, but none of
them is subscribed). them is subscribed).
9: The following example demonstrates that the CHILDINFO extended 9: The following example demonstrates that the CHILDINFO extended
data item is returned whether children mailboxes match the data item is returned whether children mailboxes match the
canonical LIST pattern or not. canonical LIST pattern or not.
Let's assume there is the following hierarchy: Let's assume there is the following hierarchy:
skipping to change at page 22, line 27 skipping to change at page 20, line 20
(which means that the mailbox "Foo" has children, but none of (which means that the mailbox "Foo" has children, but none of
them is subscribed). them is subscribed).
9: The following example demonstrates that the CHILDINFO extended 9: The following example demonstrates that the CHILDINFO extended
data item is returned whether children mailboxes match the data item is returned whether children mailboxes match the
canonical LIST pattern or not. canonical LIST pattern or not.
Let's assume there is the following hierarchy: Let's assume there is the following hierarchy:
C: D01 LIST "" "*" C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2" S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1" S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2" S: * LIST () "/" "foo2/bar2"
S: * LIST () "/" "baz2" S: * LIST () "/" "baz2"
S: * LIST () "/" "baz2/bar2" S: * LIST () "/" "baz2/bar2"
S: * LIST () "/" "baz2/bar22" S: * LIST () "/" "baz2/bar22"
S: * LIST () "/" "baz2/bar222" S: * LIST () "/" "baz2/bar222"
S: * LIST () "/" "eps2" S: * LIST () "/" "eps2"
S: * LIST () "/" "eps2/mamba" S: * LIST () "/" "eps2/mamba"
S: * LIST () "/" "quux2/bar2" S: * LIST () "/" "qux2/bar2"
S: D01 OK done S: D01 OK done
And that the following mailboxes are subscribed: And that the following mailboxes are subscribed:
C: D02 LIST (SUBSCRIBED) "" "*" C: D02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "foo2/bar1" S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2" S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2" S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22" S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222" S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" S: * LIST (\Subscribed) "/" "eps2"
S: * LIST (\Subscribed) "/" "eps2/mamba" S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: * LIST (\Subscribed) "/" "quux2/bar2"
S: D02 OK done S: D02 OK done
The client issues the following command first: The client issues the following command first:
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "foo2/bar2" S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "baz2/bar2" S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22" S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222" S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" S: * LIST (\Subscribed) "/" "qux2/bar2"
("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "quux2/bar2"
S: D03 OK done S: D03 OK done
and the server may also include and the server may also include
S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO" S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
("SUBSCRIBED")))
The CHILDINFO extended data item is returned for mailboxes The CHILDINFO extended data item is returned for mailboxes
"foo2", "baz2" and "eps2", because all of them have subscribed "foo2", "baz2" and "eps2", because all of them have subscribed
children, even though for the mailbox "foo2" only one of the two children, even though for the mailbox "foo2" only one of the two
subscribed children match the pattern, for the mailbox "baz2" all subscribed children match the pattern, for the mailbox "baz2" all
the subscribed children match the pattern and for the mailbox the subscribed children match the pattern and for the mailbox
"eps2" none of the subscribed children match the pattern. "eps2" none of the subscribed children matches the pattern.
Note that if the client issues Note that if the client issues
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*" C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "foo2/bar1" S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2" S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "baz2/bar2" S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22" S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222" S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "eps2/mamba" S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: * LIST (\Subscribed) "/" "quux2/bar2"
S: D03 OK done S: D03 OK done
the LIST responses for mailboxes "foo2", "baz2" and "eps2" still the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
have the CHILDINFO extended data item, even though this have the CHILDINFO extended data item, even though this
information is redundant and the client can determine it by information is redundant and the client can determine it by
itself. itself.
10: The following example shows usage of multiple mailbox patterns. 10: The following example shows usage of multiple mailbox patterns.
It also demonstrates that the presence of the CHILDINFO extended It also demonstrates that the presence of the CHILDINFO extended
data item doesn't necessarily imply \HasChildren. data item doesn't necessarily imply \HasChildren.
C: a1 LIST "" ("foo" "foo/*") C: a1 LIST "" ("foo" "foo/*")
skipping to change at page 25, line 14 skipping to change at page 22, line 6
the LIST responses for mailboxes "foo2", "baz2" and "eps2" still the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
have the CHILDINFO extended data item, even though this have the CHILDINFO extended data item, even though this
information is redundant and the client can determine it by information is redundant and the client can determine it by
itself. itself.
10: The following example shows usage of multiple mailbox patterns. 10: The following example shows usage of multiple mailbox patterns.
It also demonstrates that the presence of the CHILDINFO extended It also demonstrates that the presence of the CHILDINFO extended
data item doesn't necessarily imply \HasChildren. data item doesn't necessarily imply \HasChildren.
C: a1 LIST "" ("foo" "foo/*") C: a1 LIST "" ("foo" "foo/*")
S: * LIST () "/" foo S: * LIST () "/" foo
S: a1 OK done S: a1 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*" C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done S: a2 OK done
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
(CHILDREN) S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
("SUBSCRIBED")))
S: a3 OK done S: a3 OK done
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF]. Terms not defined here are taken Form (BNF) as described in [ABNF]. Terms not defined here are taken
from [IMAP4]. from [IMAP4]. In particular, note that the version of "mailbox-list"
below, which defines the payload of the LIST response, updates the
version defined in the IMAP specification. It is pointed to by
"mailbox-data", which is defined in [IMAP4].
"vendor-token" is defined in [ACAP]. Note that this normative "vendor-token" is defined in [ACAP]. Note that this normative
reference to ACAP is an issue in moving this spec forward, since ACAP reference to ACAP is an issue in moving this spec forward, since it
will never move to Draft Standard. The definitions of "vendor-token" introduces a dependency on ACAP. The definitions of "vendor-token"
and of the IANA registry must eventually go somewhere else, in a and of the IANA registry must eventually go somewhere else, in a
document that can be moved forward on the standards track. document that can be moved forward on the standards track
independently of ACAP.
childinfo-extended-item = "CHILDINFO" SP "(" childinfo-extended-item = "CHILDINFO" SP "("
list-select-base-opt-quoted list-select-base-opt-quoted
*(SP list-select-base-opt-quoted) ")" *(SP list-select-base-opt-quoted) ")"
; Extended data item returned when the RECURSIVEMATCH ; Extended data item (mbox-list-extended-item) ; returned
when the RECURSIVEMATCH
; selection option is specified. ; selection option is specified.
; Note 1: the CHILDINFO tag can be returned ; Note 1: the CHILDINFO tag can be returned
; with and without surrounding quotes, as per ; with and without surrounding quotes, as per
; mbox-list-extended-item-tag production. ; mbox-list-extended-item-tag production.
; Note 2: The selection options are returned quoted, ; Note 2: The selection options are always returned
quoted,
; unlike their specification in the extended LIST ; unlike their specification in the extended LIST
; command. ; command.
child-mbox-flag = "\HasChildren" / "\HasNoChildren" child-mbox-flag = "\HasChildren" / "\HasNoChildren"
; attributes for CHILDREN return option, at most one ; attributes for CHILDREN return option, at most one
; possible per LIST response ; possible per LIST response
eitem-standard-tag = atom eitem-standard-tag = atom
; a tag for extended list data defined in a Standard ; a tag for extended list data defined in a Standard
; Track or Experimental RFC. ; Track or Experimental RFC.
skipping to change at page 28, line 4 skipping to change at page 25, line 11
; (SUBSCRIBED REMOTE) ; (SUBSCRIBED REMOTE)
; (SUBSCRIBED RECURSIVEMATCH) ; (SUBSCRIBED RECURSIVEMATCH)
; (SUBSCRIBED REMOTE RECURSIVEMATCH) ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
; But does NOT allow these: ; But does NOT allow these:
; (RECURSIVEMATCH) ; (RECURSIVEMATCH)
; (REMOTE RECURSIVEMATCH) ; (REMOTE RECURSIVEMATCH)
mailbox-list = "(" [mbx-list-flags] ")" SP mailbox-list = "(" [mbx-list-flags] ")" SP
(DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
[SP mbox-list-extended] [SP mbox-list-extended]
; This is the list information pointed to by the ABNF
item ; "mailbox-data", which is defined in [IMAP4]
mbox-list-extended = "(" [mbox-list-extended-item mbox-list-extended = "(" [mbox-list-extended-item
*(SP mbox-list-extended-item)] ")" *(SP mbox-list-extended-item)] ")"
mbox-list-extended-item = "(" mbox-list-extended-item-data ")" mbox-list-extended-item = mbox-list-extended-item-tag SP tagged-ext-
val
mbox-list-extended-item-data = mbox-list-extended-item-tag SP
nstring-list
mbox-list-extended-item-tag = astring mbox-list-extended-item-tag = astring
; The content MUST conform to either "eitem-vendor-tag" ; The content MUST conform to either "eitem-vendor-tag"
; or "eitem-standard-tag" ABNF productions. ; or "eitem-standard-tag" ABNF productions.
; A tag registration template is described in this ; A tag registration template is described in this
; document in Section 8.5. ; document in Section 8.5.
mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\Subscribed" / mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\Subscribed" /
"\Remote" "\Remote"
mbox-or-pat = list-mailbox / patterns mbox-or-pat = list-mailbox / patterns
nstring-list = nstring /
"(" [nstring-list *(SP nstring-list)] ")"
; a recursive list definition
option-extension = (option-standard-tag / option-vendor-tag) option-extension = (option-standard-tag / option-vendor-tag)
[SP option-value] [SP option-value]
option-standard-tag = atom option-standard-tag = atom
; an option defined in a Standards Track or ; an option defined in a Standards Track or
; Experimental RFC ; Experimental RFC
option-val-comp = astring / option-val-comp = astring /
option-val-comp *(SP option-val-comp) / option-val-comp *(SP option-val-comp) /
"(" option-val-comp ")" "(" option-val-comp ")"
skipping to change at page 28, line 37 skipping to change at page 26, line 4
option-extension = (option-standard-tag / option-vendor-tag) option-extension = (option-standard-tag / option-vendor-tag)
[SP option-value] [SP option-value]
option-standard-tag = atom option-standard-tag = atom
; an option defined in a Standards Track or ; an option defined in a Standards Track or
; Experimental RFC ; Experimental RFC
option-val-comp = astring / option-val-comp = astring /
option-val-comp *(SP option-val-comp) / option-val-comp *(SP option-val-comp) /
"(" option-val-comp ")" "(" option-val-comp ")"
option-value = "(" option-val-comp ")" option-value = "(" option-val-comp ")"
option-vendor-tag = vendor-token "-" atom option-vendor-tag = vendor-token "-" atom
; a vendor specific option, non-standard ; a vendor specific option, non-standard
patterns = "(" list-mailbox *(SP list-mailbox) ")" patterns = "(" list-mailbox *(SP list-mailbox) ")"
return-option = "SUBSCRIBED" / "CHILDREN" / option-extension return-option = "SUBSCRIBED" / "CHILDREN" / option-extension
tagged-ext-comp = astring /
tagged-ext-comp *(SP tagged-ext-comp) /
"(" tagged-ext-comp ")"
;; Extensions that follow this general
;; syntax should use nstring instead of
;; astring when appropriate in the context
;; of the extension.
;; Note that a message set or a "number"
;; can always be represented as an "atom".
;; An URL should be represented as
;; a "quoted" string.
tagged-ext-simple = sequence-set / number
tagged-ext-val = tagged-ext-simple /
"(" [tagged-ext-comp] ")"
7. Security Considerations 7. Security Considerations
This document describes syntactic changes to the specification of the This document describes syntactic changes to the specification of the
IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
command has the same security considerations as those commands. They command has the same security considerations as those commands. They
are described in [IMAP4] and [MBRef]. are described in [IMAP4] and [MBRef].
The Child Mailbox Extension provides a client a more efficient means The Child Mailbox Extension provides a client a more efficient means
of determining whether a particular mailbox has children. If a of determining whether a particular mailbox has children. If a
mailbox has children, but the currently authenticated user does not mailbox has children, but the currently authenticated user does not
have access to any of them, the server SHOULD respond with a have access to any of them, the server SHOULD respond with a
\HasNoChildren attribute. In many cases, however, a server may not \HasNoChildren attribute. In many cases, however, a server may not
be able to efficiently compute whether a user has access to all child be able to efficiently compute whether a user has access to any child
mailboxes. If such a server responds with a \HasChildren attribute, mailbox. If such a server responds with a \HasChildren attribute,
when in fact the currently authenticated user does not have access to when in fact the currently authenticated user does not have access to
any child mailboxes, potentially more information is conveyed about any child mailboxes, potentially more information is conveyed about
the mailbox than intended. In most situations this will not be a the mailbox than intended. In most situations this will not be a
security concern, because if information regarding whether a mailbox security concern, because if information regarding whether a mailbox
has children is considered sensitive, a user would not be granted has children is considered sensitive, a user would not be granted
access to that mailbox in the first place. access to that mailbox in the first place.
The CHILDINFO extended data item has the same security considerations The CHILDINFO extended data item has the same security considerations
as the \HasChildren attribute described above. as the \HasChildren attribute described above.
skipping to change at page 35, line 4 skipping to change at page 32, line 4
4. To: iana@iana.org 4. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH
LIST-EXTENDED option name: RECURSIVEMATCH LIST-EXTENDED option name: RECURSIVEMATCH
LIST-EXTENDED option type: SELECTION LIST-EXTENDED option type: SELECTION
Implied return options(s): (none) Implied return options(s): (none)
LIST-EXTENDED option description: Requests that CHILDINFO LIST-EXTENDED option description: Requests that CHILDINFO
extended data item is to be returned. extended data item (childinfo-extended-item) is to be returned.
Published specification : XXXX, Section 3. Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
skipping to change at page 39, line 41 skipping to change at page 36, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 152 change blocks. 
221 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/