< draft-ietf-imapext-list-extensions-17.txt   draft-ietf-imapext-list-extensions-18.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 Obsoletes: 3348 (if approved) A. Melnikov
Obsoletes: 3348 (if approved) Isode Limited Updates: 2193 (if approved) Isode Limited
Expires: October 28, 2006 April 26, 2006 Intended status: Standards Track September 21, 2006
Expires: March 25, 2007
IMAP4 LIST Command Extensions IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-17 draft-ietf-imapext-list-extensions-18
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 36
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 October 28, 2006. This Internet-Draft will expire on March 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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,
skipping to change at page 2, line 20 skipping to change at page 3, line 16
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to and suggestions for improvement are requested, and should be sent to
ietf-imapext@imc.org. ietf-imapext@imc.org.
This document obsoletes RFC 3348 and updates RFC 2193. This document obsoletes RFC 3348 and updates RFC 2193.
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . 4 1. Conventions used in this document . . . . . . . . . . . . . 5
2. Introduction and overview . . . . . . . . . . . . . . . . . 5
3. Extended LIST Command . . . . . . . . . . . . . . . . . . . 7
3.1 Initial list of selection options . . . . . . . . . . . . . 9
3.2 Initial list of return options . . . . . . . . . . . . . . . 11
3.3 General principles for returning LIST responses . . . . . . 11
3.4 Additional requirements on LIST-EXTENDED clients . . . . . . 12
3.5 CHILDINFO extended data item . . . . . . . . . . . . . . . . 12
4. The CHILDREN return Option . . . . . . . . . . . . . . . . . 15 2. Introduction and overview . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . 8
3.1. Initial list of selection options . . . . . . . . . . . . . 10
3.2. Initial list of return options . . . . . . . . . . . . . . . 12
3.3. General principles for returning LIST responses . . . . . . 12
3.4. Additional requirements on LIST-EXTENDED clients . . . . . . 13
3.5. CHILDINFO extended data item . . . . . . . . . . . . . . . . 13
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 24 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . 16
7. Internationalization Considerations . . . . . . . . . . . . 28 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . 29 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 7. Internationalization Considerations . . . . . . . . . . . . 29
9.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . 30
9.2 Registration procedure and Change control . . . . . . . . . 30
9.3 Registration template for LIST-EXTENDED options . . . . . . 31
9.4 Initial LIST-EXTENDED option registrations . . . . . . . . . 32
9.5 Registration template for LIST-EXTENDED extended data item . 34
9.6 Initial LIST-EXTENDED extended data item registrations . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 9.1. Guidelines for IANA . . . . . . . . . . . . . . . . . . . . 31
11.2 informative References . . . . . . . . . . . . . . . . . . . 37 9.2. Registration procedure and Change control . . . . . . . . . 31
9.3. Registration template for LIST-EXTENDED options . . . . . . 32
9.4. Initial LIST-EXTENDED option registrations . . . . . . . . . 33
9.5. Registration template for LIST-EXTENDED extended data
item . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.6. Initial LIST-EXTENDED extended data item registrations . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . 39 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . . . 38
11.2. informative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . 40
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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this used in this document as specified in RFC 2119 [Kwds].
document are to be interpreted as described in RFC 2119 [Kwds].
The term "canonical LIST pattern" refers to the canonical pattern The term "canonical LIST pattern" refers to the canonical pattern
constructed internally by the server from the reference and mailbox constructed internally by the server from the reference and mailbox
name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command
returns only mailboxes that match the canonical LIST pattern. returns only mailboxes that match the canonical LIST pattern.
Other terms are introduced where they are referenced for the first Other terms are introduced where they are referenced for the first
time. time.
2. Introduction and overview 2. Introduction and overview
skipping to change at page 9, line 34 skipping to change at page 10, line 34
least one descendant mailbox name that does not match the LIST least one descendant mailbox name that does not match the LIST
pattern and 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", "\HasChildren" returned with one or more of "\Subscribed", "\Remote", "\HasChildren"
or the CHILDINFO extended data item (see their description below). or the 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.
3.1 Initial list of selection options 3.1. Initial list of selection options
The selection options defined in this specification are The selection options defined in this specification are
SUBSCRIBED - causes the LIST command to list subscribed names, rather SUBSCRIBED - causes the LIST command to list subscribed names,
than the existing mailboxes. This will often be a subset of the rather than the existing mailboxes. This will often be a subset
actual mailboxes. It's also possible for this list to contain the of the actual mailboxes. It's also possible for this list to
names of mailboxes that don't exist. In any case, the list MUST contain the names of mailboxes that don't exist. In any case, the
include exactly those mailbox names that match the canonical list list MUST include exactly those mailbox names that match the
pattern and are subscribed to. This option is intended to canonical list pattern and are subscribed to. This option is
supplement the LSUB command. Of particular note are the mailbox intended to supplement the LSUB command. Of particular note are
attributes as returned by this option, compared with what is the mailbox attributes as returned by this option, compared with
returned by LSUB. With the latter, the attributes returned may what is returned by LSUB. With the latter, the attributes
not reflect the actual attribute status on the mailbox name, and returned may not reflect the actual attribute status on the
the \NoSelect attribute has a second special meaning (it indicates mailbox name, and the \NoSelect attribute has a second special
that this mailbox is not, itself, subscribed, but that it has meaning (it indicates that this mailbox is not, itself,
descendant mailboxes that are). With the SUBSCRIBED selection subscribed, but that it has descendant mailboxes that are). With
option described here, the attributes are accurate, complete, and the SUBSCRIBED selection option described here, the attributes are
have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, accurate, complete, and have no special meanings. "LSUB" and
thus, not the same thing, and some servers must do significant "LIST (SUBSCRIBED)" are, thus, not the same thing, and some
extra work to respond to "LIST (SUBSCRIBED)". Because of this, servers must do significant extra work to respond to "LIST
clients SHOULD continue to use "LSUB" unless they specifically (SUBSCRIBED)". Because of this, clients SHOULD continue to use
want the additional information offered by "LIST (SUBSCRIBED)". "LSUB" unless they specifically want the additional information
offered by "LIST (SUBSCRIBED)".
This option defines a new mailbox attribute, "\Subscribed", that This option defines a new mailbox attribute, "\Subscribed", that
indicates that a mailbox name is subscribed to. The "\Subscribed" indicates that a mailbox name is subscribed to. The "\Subscribed"
attribute MUST be supported and MUST be accurately computed when attribute MUST be supported and MUST be accurately computed when
the SUBSCRIBED selection option is specified. the SUBSCRIBED selection option is specified.
Note that the SUBSCRIBED selection option implies the SUBSCRIBED Note that the SUBSCRIBED selection option implies the SUBSCRIBED
return option (see below). return option (see below).
REMOTE - causes the LIST command to show remote mailboxes as well as REMOTE - causes the LIST command to show remote mailboxes as well as
local ones, as described in [MBRef]. This option is intended to local ones, as described in [MBRef]. This option is intended to
replace the RLIST command and, in conjunction with the SUBSCRIBED replace the RLIST command and, in conjunction with the SUBSCRIBED
selection option, the RLSUB command. selection option, the RLSUB command.
This option defines a new mailbox attribute, "\Remote", that This option defines a new mailbox attribute, "\Remote", that
indicates that a mailbox is a remote mailbox. The "\Remote" indicates that a mailbox is a remote mailbox. The "\Remote"
attribute MUST be accurately computed when the REMOTE option is attribute MUST be accurately computed when the REMOTE option is
specified. specified.
The REMOTE selection option has no interaction with other options. The REMOTE selection option has no interaction with other options.
Its effect is to tell the server to apply the other options, if Its effect is to tell the server to apply the other options, if
any, to remote mailboxes, in addition to local ones. In any, to remote mailboxes, in addition to local ones. In
particular, it has no interaction with RECURSIVEMATCH (see below). particular, it has no interaction with RECURSIVEMATCH (see below).
A request for (REMOTE RECURSIVEMATCH) is invalid, because a A request for (REMOTE RECURSIVEMATCH) is invalid, because a
request for (RECURSIVEMATCH) is. A request for (REMOTE request for (RECURSIVEMATCH) is. A request for (REMOTE
RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes, RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes,
both local and remote. both local and remote.
RECURSIVEMATCH - this option forces the server to return information RECURSIVEMATCH - this option forces the server to return information
about parent mailboxes that don't match other selection options, about parent mailboxes that don't match other selection options,
but have some submailboxes that do. Information about children is but have some submailboxes that do. Information about children is
returned in the CHILDINFO extended data item, as described in returned in the CHILDINFO extended data item, as described in
Section 3.5. Section 3.5.
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
skipping to change at page 11, line 17 skipping to change at page 12, line 18
selection options are also used. The server MUST return BAD selection options are also used. The server MUST return BAD
tagged response in such case. tagged response in such case.
Note that even if the RECURSIVEMATCH option is specified, the Note that even if the RECURSIVEMATCH option is specified, the
client MUST still be able to handle a case when a CHILDINFO client MUST still be able to handle a case when a CHILDINFO
extended data item is returned and there are no submailboxes that extended data item is returned and there are no submailboxes that
meet the selection criteria of the subsequent LIST command, as meet the selection criteria of the subsequent LIST command, as
they can be deleted/renamed after the LIST response was sent, but they can be deleted/renamed after the LIST response was sent, but
before the client had a chance to access them. before the client had a chance to access them.
3.2 Initial list of return options 3.2. Initial list of return options
The return options defined in this specification are The return options defined in this specification are
SUBSCRIBED - causes the LIST command to return subscription state for SUBSCRIBED - causes the LIST command to return subscription state
all matching mailbox names. The "\Subscribed" attribute MUST be for all matching mailbox names. The "\Subscribed" attribute MUST
supported and MUST be accurately computed when the SUBSCRIBED be supported and MUST be accurately computed when the SUBSCRIBED
return option is specified. Further, all mailbox flags MUST be return option is specified. Further, all mailbox flags MUST be
accurately computed (this differs from the behaviour of the LSUB accurately computed (this differs from the behaviour of the LSUB
command). command).
CHILDREN - Requests mailbox child information as originally proposed CHILDREN - Requests mailbox child information as originally proposed
in [CMbox]. See Section 4, below, for details. This option MUST in [CMbox]. See Section 4, below, for details. This option MUST
be supported by all servers. be supported by all servers.
3.3 General principles for returning LIST responses 3.3. General principles for returning LIST responses
This section outlines several principles that can be used by server This section outlines several principles that can be used by server
implementations of this document to decide if a LIST response should implementations of this document to decide if a LIST response should
be returned, as well as how many responses and what kind of be returned, as well as how many responses and what kind of
information they may contain. information they may contain.
1. Exactly one LIST response should be returned for each mailbox 1. Exactly one LIST response should be returned for each mailbox
name which matches the canonical LIST pattern. Server name which matches the canonical LIST pattern. Server
implementors must not assume that clients will be able to implementors must not assume that clients will be able to
assemble mailbox attributes and other information returned in assemble mailbox attributes and other information returned in
skipping to change at page 12, line 24 skipping to change at page 13, line 24
RECURSIVEMATCH selection option is specified. RECURSIVEMATCH selection option is specified.
3. Attributes returned in the same LIST response must be treated 3. Attributes returned in the same LIST response must be treated
additively. For example the following response additively. For example the following response
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed. subscribed.
3.4 Additional requirements on LIST-EXTENDED clients 3.4. Additional requirements on LIST-EXTENDED clients
All clients that support this extension MUST treat an attribute with All clients that support this extension MUST treat an attribute with
a stronger meaning, as implying any attribute that can be inferred a stronger meaning, as implying any attribute that can be inferred
from it. For example, the client must treat presence of the from it. For example, the client must treat presence of the
\NoInferiors attribute as if the \HasNoChildren attribute was also \NoInferiors attribute as if the \HasNoChildren attribute was also
sent by the server. sent by the server.
The following table summarizes inference rules described in The following table summarizes inference rules described in
Section 3. Section 3.
+--------------------+-------------------+ +--------------------+-------------------+
| returned attribute | implied attribute | | returned attribute | implied attribute |
+--------------------+-------------------+ +--------------------+-------------------+
| \NoInferiors | \HasNoChildren | | \NoInferiors | \HasNoChildren |
| | | | | |
| \NonExistent | \NoSelect | | \NonExistent | \NoSelect |
+--------------------+-------------------+ +--------------------+-------------------+
3.5 CHILDINFO extended data item 3.5. CHILDINFO extended data item
The CHILDINFO extended data item MUST NOT be returned unless the The CHILDINFO extended data item MUST NOT be returned unless the
client has specified the RECURSIVEMATCH selection option. client has specified the RECURSIVEMATCH selection option.
The CHILDINFO extended data item in a LIST response describes the The CHILDINFO extended data item in a LIST response describes the
selection criteria that has caused it to be returned and indicates selection criteria that has caused it to be returned and indicates
that the mailbox has at least one descendant mailbox that matches the that the mailbox has at least one descendant mailbox that matches the
selection criteria. selection criteria.
The LSUB command indicates this condition by using the "\NoSelect" The LSUB command indicates this condition by using the "\NoSelect"
skipping to change at page 14, line 6 skipping to change at page 15, line 6
Servers SHOULD ONLY return a non-matching mailbox name along with Servers SHOULD ONLY return a non-matching mailbox name along with
CHILDINFO if at least one matching child is not also being returned. CHILDINFO if at least one matching child is not also being returned.
That is, servers SHOULD suppress redundant CHILDINFO responses. That is, servers SHOULD suppress redundant CHILDINFO responses.
Examples 8 and 10 in Section 5 demonstrate the difference between Examples 8 and 10 in Section 5 demonstrate the difference between
present CHILDINFO extended data item and the "\HasChildren" present CHILDINFO extended data item and the "\HasChildren"
attribute. attribute.
The following table summarizes interaction between the "\NonExistent" The following table summarizes interaction between the "\NonExistent"
attribute and CHILDINFO (the first collumn describes if the parent attribute and CHILDINFO (the first collumn describes if the parent
mailbox exists): mailbox exists):
+----------------+----------------+----------------+----------------+ +--------+--------------+--------------------+----------------------+
| exists | meets the | has a child | returned | | exists | meets the | has a child that | returned |
| | selection | that meets the | LIST-EXTENDED | | | selection | meets the | LIST-EXTENDED |
| | criteria | selection | attributes and | | | criteria | selection criteria | attributes and |
| | | criteria | CHILDINFO | | | | | CHILDINFO |
+----------------+----------------+----------------+----------------+ +--------+--------------+--------------------+----------------------+
| no | no | no | no LIST | | no | no | no | no LIST response |
| | | | response | | | | | returned |
| | | | returned | | | | | |
| | | | | | yes | no | no | no LIST response |
| yes | no | no | no LIST | | | | | returned |
| | | | response | | | | | |
| | | | returned | | no | yes | no | (\NonExistent |
| | | | | | | | | <attr>) |
| no | yes | no | (\NonExistent | | | | | |
| | | | <attr>) | | yes | yes | no | (<attr>) |
| | | | | | | | | |
| yes | yes | no | (<attr>) | | no | no | yes | (\NonExistent) + |
| | | | | | | | | CHILDINFO |
| no | no | yes | (\NonExistent) | | | | | |
| | | | + CHILDINFO | | yes | no | yes | () + CHILDINFO |
| | | | | | | | | |
| yes | no | yes | () + CHILDINFO | | no | yes | yes | (\NonExistent |
| | | | | | | | | <attr>) + CHILDINFO |
| no | yes | yes | (\NonExistent | | | | | |
| | | | <attr>) + | | yes | yes | yes | (<attr>) + CHILDINFO |
| | | | CHILDINFO | +--------+--------------+--------------------+----------------------+
| | | | |
| yes | yes | yes | (<attr>) + |
| | | | CHILDINFO |
+----------------+----------------+----------------+----------------+
where <attr> is one or more attributes that correspond to the where <attr> is one or more attributes that correspond to the
selection criteria, for example for the SUBSCRIBED option the <attr> selection criteria, for example for the SUBSCRIBED option the <attr>
is \Subscribed. is \Subscribed.
4. The CHILDREN return Option 4. The CHILDREN return Option
The CHILDREN return option implements the Child Mailbox Extension, The CHILDREN return option implements the Child Mailbox Extension,
originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
Corporation. Most of the information in this section is taken Corporation. Most of the information in this section is taken
directly from their original specification [CMbox]. The CHILDREN directly from their original specification [CMbox]. The CHILDREN
return option is simply an indication that the client wants this return option is simply an indication that the client wants this
information; a server MAY provide it even if the option is not information; a server MAY provide it even if the option is not
specified. specified.
skipping to change at page 17, line 7 skipping to change at page 18, line 7
It is an error for the server to return both a \HasChildren and a It is an error for the server to return both a \HasChildren and a
\HasNoChildren attribute in the same LIST response. \HasNoChildren attribute in the same LIST response.
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
used for the other examples. be 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,
knows which of the top-level mailboxes have submailboxes now 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 that reside on another
server. This is similar to the command <RLIST "" "%">. server. This is similar to the command <RLIST "" "%">.
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 that 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
that reside on another server. The server is asked to return that reside on another server. The server is asked to return
subscription information for all returned mailboxes. This is subscription information for all returned mailboxes. This 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 does not use the mailbox patterns. Note that this example does not use the
mailbox 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 demonstrates the difference between the 8: The following example demonstrates the difference between the
\HasChildren attribute and the 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
is. that is.
A1) If the mailbox "Foo" had also been subscribed, 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
the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will return case the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will
no responses, as there are no subscribed children (even though return no responses, as there are no subscribed children (even
"Foo" has children). though "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 (CHILDREN) C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (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:
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 () "/" "qux2/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) "/" "qux2/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" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "qux2/bar2" S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done S: D03 OK done
and the server may also include and the server may also include
S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED")) S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("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"
the subscribed children match the pattern and for the mailbox all the subscribed children match the pattern and for the
"eps2" none of the subscribed children matches the pattern. mailbox "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) "/" "qux2/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/*")
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 (CHILDREN) C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED")) S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: a3 OK done S: a3 OK done
11: The following example shows how a server that supports missing 11: The following example shows how a server that supports missing
mailbox hierarchy elements can signal to a client that didn't mailbox hierarchy elements can signal to a client that didn't
specify the RECURSIVEMATH selection option that there is a child specify the RECURSIVEMATH selection option that there is a child
mailbox that matches the selection criteria. mailbox that matches the selection criteria.
C: a1 LIST (REMOTE) "" * C: a1 LIST (REMOTE) "" *
S: * LIST () "/" music/rock S: * LIST () "/" music/rock
S: * LIST (\Remote) "/" also/jazz S: * LIST (\Remote) "/" also/jazz
S: a1 OK done S: a1 OK done
C: a2 LIST () "" % C: a2 LIST () "" %
S: * LIST (\NonExistent \HasChildren) "/" music S: * LIST (\NonExistent \HasChildren) "/" music
S: a2 OK done S: a2 OK done
skipping to change at page 24, line 21 skipping to change at page 25, line 21
version defined in the IMAP specification. It is pointed to by version defined in the IMAP specification. It is pointed to by
"mailbox-data", which is defined in [IMAP4]. "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 will be an issue in moving this spec forward, since reference to ACAP will be an issue in moving this spec forward, since
it introduces a dependency on ACAP. The definitions of "vendor- it introduces a dependency on ACAP. The definitions of "vendor-
token" and of the IANA registry must eventually go somewhere else, in token" and of the IANA registry must eventually go somewhere else, in
a document that can be moved forward on the standards track a document that can be moved forward on the standards track
independently of ACAP. 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 (mbox-list-extended-item) ; returned ; Extended data item (mbox-list-extended-item)
when the RECURSIVEMATCH ; 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 always returned ; Note 2: The selection options are always returned
quoted, ; quoted, unlike their specification in
; unlike their specification in the extended LIST ; 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.
eitem-vendor-tag = vendor-tag eitem-vendor-tag = vendor-tag
; a vendor specific tag for extended list data ; a vendor specific tag for extended list data
list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
[SP list-return-opts] [SP list-return-opts]
list-return-opts = "RETURN" SP list-return-opts = "RETURN" SP
"(" [return-option *(SP return-option)] ")" "(" [return-option *(SP return-option)] ")"
; list return options, e.g. CHILDREN ; list return options, e.g. CHILDREN
list-select-base-opt = "SUBSCRIBED" / option-extension list-select-base-opt = "SUBSCRIBED" / option-extension
; options that can be used by themselves ; options that can be used by themselves
list-select-base-opt-quoted = <"> list-select-base-opt <"> list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
list-select-independent-opt = "REMOTE" / option-extension list-select-independent-opt = "REMOTE" / option-extension
; options that do not syntactically interact with ; options that do not syntactically interact with
; other options ; other options
list-select-mod-opt = "RECURSIVEMATCH" / option-extension list-select-mod-opt = "RECURSIVEMATCH" / option-extension
; options that require a list-select-base-opt ; options that require a list-select-base-opt
; to also be present ; to also be present
list-select-opt = list-select-base-opt / list-select-independent-opt list-select-opt = list-select-base-opt / list-select-independent-opt
/ list-select-mod-opt / list-select-mod-opt
; An option registration template is described in ; An option registration template is described in
; Section 9.3 of this document. ; Section 9.3 of this document.
list-select-opts = "(" [ list-select-opts = "(" [
(*(list-select-opt SP) list-select-base-opt (*(list-select-opt SP) list-select-base-opt
*(SP list-select-opt)) *(SP list-select-opt))
/ (list-select-independent-opt / (list-select-independent-opt
*(SP list-select-independent-opt)) *(SP list-select-independent-opt))
] ")" ] ")"
; Any number of options may be in any order. ; Any number of options may be in any order.
; If a list-select-mod-opt appears, then a ; If a list-select-mod-opt appears, then a
; list-select-base-opt must also appear. ; list-select-base-opt must also appear.
; This allows these: ; This allows these:
; () ; ()
; (REMOTE) ; (REMOTE)
; (SUBSCRIBED) ; (SUBSCRIBED)
; (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 ; This is the list information pointed to by the ABNF
item ; "mailbox-data", which is defined in [IMAP4] ; 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-tag SP tagged-ext- mbox-list-extended-item = mbox-list-extended-item-tag SP
val tagged-ext-val
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 9.5. ; document in Section 9.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
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 = astring /
tagged-ext-comp *(SP tagged-ext-comp) / tagged-ext-comp *(SP tagged-ext-comp) /
"(" 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.
;; Extensions that follow this general tagged-ext-simple = sequence-set / number
;; 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-val = tagged-ext-simple /
"(" [tagged-ext-comp] ")" "(" [tagged-ext-comp] ")"
7. Internationalization Considerations 7. Internationalization Considerations
The LIST command selection option types defined in this specification The LIST command selection option types defined in this specification
involve simple tests of mailbox properties. However, future involve simple tests of mailbox properties. However, future
extensions to LIST-EXTENDED may define selection options that do more extensions to LIST-EXTENDED may define selection options that do more
sophisticated tests. In the case of a test that requires matching sophisticated tests. In the case of a test that requires matching
text, in the presence of the COMPARATOR [I18N] extension, the active text, in the presence of the COMPARATOR [I18N] extension, the active
comparator must be used to do comparisons. Such LIST-EXTENDED comparator must be used to do comparisons. Such LIST-EXTENDED
skipping to change at page 30, line 7 skipping to change at page 31, line 7
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.
9. IANA Considerations 9. IANA Considerations
9.1 Guidelines for IANA 9.1. Guidelines for IANA
It is requested that IANA creates two new registries for LIST- It is requested that IANA creates two new registries for LIST-
EXTENDED options and LIST-EXTENDED response data. The templates and EXTENDED options and LIST-EXTENDED response data. The templates and
the initial registrations are detailed below. the initial registrations are detailed below.
9.2 Registration procedure and Change control 9.2. Registration procedure and Change control
Registration of a LIST-EXTENDED option is done by filling in the Registration of a LIST-EXTENDED option is done by filling in the
template in Section 9.3 and sending it via electronic mail to template in Section 9.3 and sending it via electronic mail to
iana@iana.org. Registration of a LIST-EXTENDED extended data item is iana@iana.org. Registration of a LIST-EXTENDED extended data item is
done by filling in the template in Section 9.5 and sending it via done by filling in the template in Section 9.5 and sending it via
electronic mail to iana@iana.org. IANA has the right to reject electronic mail to iana@iana.org. IANA has the right to reject
obviously bogus registrations, but will perform no review of claims obviously bogus registrations, but will perform no review of claims
made in the registration form. made in the registration form.
A LIST-EXTENDED option/extended data item name that starts with "V-" A LIST-EXTENDED option/extended data item name that starts with "V-"
skipping to change at page 31, line 31 skipping to change at page 32, line 31
LIST-EXTENDED registrations may not be deleted; mechanisms which are LIST-EXTENDED registrations may not be deleted; mechanisms which are
no longer believed appropriate for use can be declared OBSOLETE by a no longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended use" field; such LIST-EXTENDED options/ change to their "intended use" field; such LIST-EXTENDED options/
extended data items will be clearly marked in the lists published by extended data items will be clearly marked in the lists published by
IANA. IANA.
The IESG is considered to be the owner of all LIST-EXTENDED options/ The IESG is considered to be the owner of all LIST-EXTENDED options/
extended data items which are on the IETF standards track. extended data items which are on the IETF standards track.
9.3 Registration template for LIST-EXTENDED options 9.3. Registration template for LIST-EXTENDED options
To: iana@iana.org To: iana@iana.org
Subject: Registration of LIST-EXTENDED option X Subject: Registration of LIST-EXTENDED option X
LIST-EXTENDED option name: LIST-EXTENDED option name:
LIST-EXTENDED option type: (One of SELECTION or RETURN) LIST-EXTENDED option type: (One of SELECTION or RETURN)
Implied return options(s), if the option type is SELECTION: (zero or Implied return options(s), if the option type is SELECTION: (zero or
more) more)
skipping to change at page 32, line 11 skipping to change at page 33, line 11
Intended usage: Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE) (One of COMMON, LIMITED USE or OBSOLETE)
Person and email address to contact for further information: Person and email address to contact for further information:
Owner/Change controller: Owner/Change controller:
(Any other information that the author deems interesting may be added (Any other information that the author deems interesting may be added
below this line.) below this line.)
9.4 Initial LIST-EXTENDED option registrations 9.4. Initial LIST-EXTENDED option registrations
It is requested that the LIST-EXTENDED option registry be populated It is requested that the LIST-EXTENDED option registry be populated
with the following entries: with the following entries:
1. To: iana@iana.org 1. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option SUBSCRIBED Subject: Registration of LIST-EXTENDED option SUBSCRIBED
LIST-EXTENDED option name: SUBSCRIBED LIST-EXTENDED option name: SUBSCRIBED
LIST-EXTENDED option type: SELECTION LIST-EXTENDED option type: SELECTION
skipping to change at page 34, line 38 skipping to change at page 35, line 38
Security considerations: XXXX, Section 8. Security considerations: XXXX, Section 8.
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>
Owner/Change controller: iesg@ietf.org Owner/Change controller: iesg@ietf.org
9.5 Registration template for LIST-EXTENDED extended data item 9.5. Registration template for LIST-EXTENDED extended data item
To: iana@iana.org To: iana@iana.org
Subject: Registration of X LIST-EXTENDED extended data item Subject: Registration of X LIST-EXTENDED extended data item
LIST-EXTENDED extended data item tag: LIST-EXTENDED extended data item tag:
LIST-EXTENDED extended data item description: LIST-EXTENDED extended data item description:
Which LIST-EXTENDED option(s) (and their types) causes this extended Which LIST-EXTENDED option(s) (and their types) causes this extended
data item to be returned (if any): data item to be returned (if any):
skipping to change at page 35, line 19 skipping to change at page 36, line 19
Intended usage: Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE) (One of COMMON, LIMITED USE or OBSOLETE)
Person and email address to contact for further information: Person and email address to contact for further information:
Owner/Change controller: Owner/Change controller:
(Any other information that the author deems interesting may be added (Any other information that the author deems interesting may be added
below this line.) below this line.)
9.6 Initial LIST-EXTENDED extended data item registrations 9.6. Initial LIST-EXTENDED extended data item registrations
It is requested that the LIST-EXTENDED extended data item registry be It is requested that the LIST-EXTENDED extended data item registry be
populated with the following entries: populated with the following entries:
1. To: iana@iana.org 1. To: iana@iana.org
Subject: Registration of CHILDINFO LIST-EXTENDED extended data Subject: Registration of CHILDINFO LIST-EXTENDED extended data
item item
LIST-EXTENDED extended data item tag: CHILDINFO LIST-EXTENDED extended data item tag: CHILDINFO
skipping to change at page 37, line 7 skipping to change at page 38, line 7
This document is the result of discussions on the IMAP4 and IMAPEXT This document is the result of discussions on the IMAP4 and IMAPEXT
mailing lists and is meant to reflect consensus of those groups. In mailing lists and is meant to reflect consensus of those groups. In
particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo
Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt
Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were
active participants in those discussions or made suggestions to this active participants in those discussions or made suggestions to this
document. document.
11. References 11. References
11.1 Normative References 11.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997. Access Protocol", RFC 2244, November 1997.
[I18N] Newman, C. and A. Gulbrandsen, "ACAP -- Application [I18N] Newman, C. and A. Gulbrandsen, "ACAP -- Application
Configuration Access Protocol", draft-ietf-imapext-i18n Configuration Access Protocol", draft-ietf-imapext-i18n
(work in progress), February 2006. (work in progress), February 2006.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate [Kwds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, [MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
September 1997. September 1997.
11.2 informative References 11.2. informative References
[CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002. [CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.
Authors' Addresses Authors' Addresses
Barry Leiba Barry Leiba
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
19 Skyline Drive 19 Skyline Drive
Hawthorne, NY 10532 Hawthorne, NY 10532
US US
skipping to change at page 38, line 4 skipping to change at page 39, line 15
Authors' Addresses Authors' Addresses
Barry Leiba Barry Leiba
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
19 Skyline Drive 19 Skyline Drive
Hawthorne, NY 10532 Hawthorne, NY 10532
US US
Phone: +1 914 784 7941 Phone: +1 914 784 7941
Email: leiba@watson.ibm.com Email: leiba@watson.ibm.com
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/ URI: http://www.melnikov.ca/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 39, line 29 skipping to change at page 40, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
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 (2006). 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 107 change blocks. 
283 lines changed or deleted 269 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/