draft-ietf-imapext-list-extensions-16.txt   draft-ietf-imapext-list-extensions-17.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: September 5, 2006 March 4, 2006 Expires: October 28, 2006 April 26, 2006
IMAP4 LIST Command Extensions IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-16 draft-ietf-imapext-list-extensions-17
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 September 5, 2006. This Internet-Draft will expire on October 28, 2006.
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 2, line 20
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 . . . . . . . . . . . . . . 3 1. Conventions used in this document . . . . . . . . . . . . . 4
2. Introduction and overview . . . . . . . . . . . . . . . . . . 4 2. Introduction and overview . . . . . . . . . . . . . . . . . 5
3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 6 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . 7
3.1 General principles for returning LIST responses . . . . . . . 10 3.1 Initial list of selection options . . . . . . . . . . . . . 9
3.2 Additional requirements on LIST-EXTENDED clients . . . . . . . 11 3.2 Initial list of return options . . . . . . . . . . . . . . . 11
3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 14 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . 15
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Internationalization Considerations . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . 29
8.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . . 28
8.2 Registration procedure and Change control . . . . . . . . . . 28
8.3 Registration template for LIST-EXTENDED options . . . . . . . 29
8.4 Initial LIST-EXTENDED option registrations . . . . . . . . . . 30
8.5 Registration template for LIST-EXTENDED extended data item . . 32
8.6 Initial LIST-EXTENDED extended data item registrations . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
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. Normative References . . . . . . . . . . . . . . . . . . . . . 34 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
11.2 informative References . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . 39
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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
used in this document as specified in RFC 2119 [Kwds]. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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 7, line 39 skipping to change at page 8, line 39
extensions MUST refer to this document and MUST add their function extensions MUST refer to this document and MUST add their function
through command options as described herein. Note that extensions through command options as described herein. Note that extensions
that don't require support for an extended LIST command, but use that don't require support for an extended LIST command, but use
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 9.5
of this document. An example of such extended set might be of this document. An example of such extended set might be
tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text")) tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text"))
or... or...
tablecloth ("edge" "lacy")) (X-Sample "text" "more text")) tablecloth ("edge" "lacy")) (X-Sample "text" "more 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
skipping to change at page 8, line 28 skipping to change at page 9, line 28
a. the mailbox name also satisfies the selection criteria (for a. the mailbox name also satisfies the selection criteria (for
example, it is subscribed and the "SUBSCRIBED" selection option example, it is subscribed and the "SUBSCRIBED" selection option
has been specified) has been specified)
b. "RECURSIVEMATCH" has been specified, and the mailbox name has at b. "RECURSIVEMATCH" has been specified, and the mailbox name has at
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" or the returned with one or more of "\Subscribed", "\Remote", "\HasChildren"
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
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, rather
than the existing mailboxes. This will often be a subset of the than the existing mailboxes. This will often be a subset of the
actual mailboxes. It's also possible for this list to contain the actual mailboxes. It's also possible for this list to contain the
names of mailboxes that don't exist. In any case, the list MUST names of mailboxes that don't exist. In any case, the list MUST
include exactly those mailbox names that match the canonical list include exactly those mailbox names that match the canonical list
pattern and are subscribed to. This option is intended to pattern and are subscribed to. This option is intended to
supplement the LSUB command. Of particular note are the mailbox supplement the LSUB command. Of particular note are the mailbox
attributes as returned by this option, compared with what is attributes as returned by this option, compared with what is
returned by LSUB. With the latter, the attributes returned may returned by LSUB. With the latter, the attributes returned may
not reflect the actual attribute status on the mailbox name, and not reflect the actual attribute status on the mailbox name, and
the \NoSelect attribute has a special meaning (it indicates that the \NoSelect attribute has a second special meaning (it indicates
this mailbox is not, itself, subscribed, but that it has that this mailbox is not, itself, subscribed, but that it has
descendant mailboxes that are). With the SUBSCRIBED selection descendant mailboxes that are). With the SUBSCRIBED selection
option described here, the attributes are accurate, complete, and option described here, the attributes are accurate, complete, and
have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are,
thus, not the same thing, and some servers must do significant thus, not the same thing, and some servers must do significant
extra work to respond to "LIST (SUBSCRIBED)". Because of this, extra work to respond to "LIST (SUBSCRIBED)". Because of this,
clients SHOULD continue to use "LSUB" unless they specifically clients SHOULD continue to use "LSUB" unless they specifically
want the additional information offered by "LIST (SUBSCRIBED)". 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"
skipping to change at page 9, line 40 skipping to change at page 10, line 42
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.3. 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
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 (nor only with REMOTE), as it only makes sense when other option (nor only with REMOTE), as it only makes sense when other
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 RECURSIVEMATCH option is specified, the client Note that even if the RECURSIVEMATCH option is specified, the
MUST still be able to handle a case when a CHILDINFO extended data client MUST still be able to handle a case when a CHILDINFO
item is returned and there are no submailboxes that meet the extended data item is returned and there are no submailboxes that
selection criteria of the given LIST command, as they can be meet the selection criteria of the subsequent LIST command, as
deleted/renamed after the LIST response was sent, but before the they can be deleted/renamed after the LIST response was sent, but
client had a chance to access them. before the client had a chance to access them.
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 for
all matching mailbox names. The "\Subscribed" attribute MUST be all matching mailbox names. The "\Subscribed" attribute MUST be
supported and MUST be accurately computed when the SUBSCRIBED 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.1 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 11, line 4 skipping to change at page 12, line 6
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
multiple LIST responses. multiple LIST responses.
2. There are only two reasons for including a matching mailbox name 2. There are only two reasons for including a matching mailbox name
in the responses to the LIST command (Note that the server is in the responses to the LIST command (Note that the server is
allowed to return unsolicited responses at any time. Such allowed to return unsolicited responses at any time. Such
responses are not governed by this rule): responses are not governed by this rule):
A. the mailbox name also satisfies the selection criteria; A. the mailbox name also satisfies the selection criteria;
B. the mailbox name doesn't satisfy the selection criteria, but B. the mailbox name doesn't satisfy the selection criteria, but
it has at least one descendant mailbox name that satisfies it has at least one descendant mailbox name that satisfies
the selection criteria and that doesn't match the canonical the selection criteria and that doesn't match the canonical
LIST pattern. LIST pattern.
For more information on this case see the CHILDINFO extended For more information on this case see the CHILDINFO extended
data item described in Section 3.3. Note that the CHILDINFO data item described in Section 3.5. Note that the CHILDINFO
extended data item can only be returned when the extended data item can only be returned when the
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.2 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.3 CHILDINFO extended data item 3.5 CHILDINFO extended data item
The CHILDINFO extended data item MUST only be returned when 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"
attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
"\NoSelect" retains its original meaning here. Further, the "\NoSelect" retains its original meaning here. Further, the
CHILDINFO extended data item is more general, in that it can be used CHILDINFO extended data item is more general, in that it can be used
with any extended set of selection criteria. with any extended set of selection criteria.
Note: Some servers allow for mailboxes to exist without requiring
their parent to exist. For example, a mailbox "Customers/ABC" can
exist while the mailbox "Customers" does not. As CHILDINFO extended
data item is not allowed if the RECURSIVEMATCH selection option is
not specified, such servers SHOULD use the "\NonExistent
\HasChildren" attribute pair to signal to the client that there is a
descendant mailbox that matches the selection criteria. See example
11 in Section 5.
The returned selection criteria allow the client to distinguish a The returned selection criteria allow the client to distinguish a
solicited response from an unsolicited one, as well as to distinguish solicited response from an unsolicited one, as well as to distinguish
among solicited responses caused by multiple pipelined LIST commands among solicited responses caused by multiple pipelined LIST commands
that specify different criteria. that specify different criteria.
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
skipping to change at page 14, line 28 skipping to change at page 15, line 28
preferable to show to the user a collapsed outline list of the preferable to show to the user a collapsed outline list of the
mailbox hierarchy (particularly if there is a large number of mailbox hierarchy (particularly if there is a large number of
mailboxes). The user can then expand the collapsed outline hierarchy mailboxes). The user can then expand the collapsed outline hierarchy
as needed. It is common to include within the collapsed hierarchy a as needed. It is common to include within the collapsed hierarchy a
visual clue (such as a ''+'') to indicate that there are child visual clue (such as a ''+'') to indicate that there are child
mailboxes under a particular mailbox. When the visual clue is mailboxes under a particular mailbox. When the visual clue is
clicked the hierarchy list is expanded to show the child mailboxes. clicked the hierarchy list is expanded to show the child mailboxes.
The CHILDREN return option provides a mechanism for a client to The CHILDREN return option provides a mechanism for a client to
efficiently determine if a particular mailbox has children, without efficiently determine if a particular mailbox has children, without
issuing a LIST "" * or a LIST "" % for each mailbox name. The issuing a LIST "" * or a LIST "" % for each mailbox name. The
CHILDREN return option defines two new attributes that MAY be CHILDREN return option defines two new attributes that MUST be
returned within a LIST response: \HasChildren and \HasNoChildren. returned within a LIST response: \HasChildren and \HasNoChildren.
While these attributes MAY be returned in response to any LIST While these attributes MAY be returned in response to any LIST
command, the CHILDREN return option is provided to indicate that the command, the CHILDREN return option is provided to indicate that the
client particularly wants this information. If the CHILDREN return client particularly wants this information. If the CHILDREN return
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
skipping to change at page 15, line 11 skipping to change at page 16, line 11
might happen, for example, due to children mailboxes beig might happen, for example, due to children mailboxes beig
deleted or made inaccessible to the user (using access control) deleted or made inaccessible to the user (using access control)
by another client before the server is able to list them. 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:]] It is an error for the server to return both a \HasChildren and a
\HasNoChildren attribute in the same LIST response.
In some instances a server that supports the LIST-EXTENDED extension
might not be able to determine whether a mailbox has children. For
example it may have difficulty determining whether there are child
mailboxes when LISTing mailboxes while operating in a particular
namespace. In these cases, a server MAY exclude both the
\HasChildren and \HasNoChildren attributes in the LIST response. As
such, a client can not make any assumptions about whether a mailbox
has children based upon the absence of a single attribute. In
particular, some servers may not be able to combine the SUBSCRIBED
selection option and CHILDREN return option. Such servers MUST
honour the SUBSCRIBED selection option, and they will simply ignore
the CHILDREN return option if both are requested. It is an error for
the server to return both a \HasChildren and a \HasNoChildren
attribute 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 17, line 5 skipping to change at page 18, line 5
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 to which we may obtain referrals. This is similar to the server. This is similar to the command <RLIST "" "%">.
command <RLIST "" "%">. Note that in the case of the remote
mailboxes, the server might or might not be able to include
CHILDREN information; it includes it if it can, and omits it if
it can't.
C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) 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
skipping to change at page 23, line 5 skipping to change at page 23, line 17
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
mailbox hierarchy elements can signal to a client that didn't
specify the RECURSIVEMATH selection option that there is a child
mailbox that matches the selection criteria.
C: a1 LIST (REMOTE) "" *
S: * LIST () "/" music/rock
S: * LIST (\Remote) "/" also/jazz
S: a1 OK done
C: a2 LIST () "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: a2 OK done
C: a3 LIST (REMOTE) "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: * LIST (\NonExistent \HasChildren) "/" also
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]. In particular, note that the version of "mailbox-list" from [IMAP4]. In particular, note that the version of "mailbox-list"
below, which defines the payload of the LIST response, updates the below, which defines the payload of the LIST response, updates the
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 is an issue in moving this spec forward, since it reference to ACAP will be an issue in moving this spec forward, since
introduces a dependency on ACAP. The definitions of "vendor-token" it introduces a dependency on ACAP. The definitions of "vendor-
and of the IANA registry must eventually go somewhere else, in a token" and of the IANA registry must eventually go somewhere else, in
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) ; returned
when the RECURSIVEMATCH 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
skipping to change at page 24, line 27 skipping to change at page 25, line 27
; 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 8.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.
skipping to change at page 25, line 24 skipping to change at page 26, line 24
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 tagged-ext-
val 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 8.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
skipping to change at page 27, line 5 skipping to change at page 28, line 5
;; An URL should be represented as ;; An URL should be represented as
;; a "quoted" string. ;; a "quoted" string.
tagged-ext-simple = sequence-set / number 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. Security Considerations 7. Internationalization Considerations
The LIST command selection option types defined in this specification
involve simple tests of mailbox properties. However, future
extensions to LIST-EXTENDED may define selection options that do more
sophisticated tests. In the case of a test that requires matching
text, in the presence of the COMPARATOR [I18N] extension, the active
comparator must be used to do comparisons. Such LIST-EXTENDED
extensions MUST indicate in their specification the interaction with
the COMPARATOR [I18N] extension.
8. 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
skipping to change at page 28, line 5 skipping to change at page 30, line 5
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.
8. IANA Considerations 9. IANA Considerations
8.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.
8.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 8.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 8.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-"
is reserved for vendor specific options/extended data items. All is reserved for vendor specific options/extended data items. All
options, whether they are vendor specific or global, should be options, whether they are vendor specific or global, should be
registered with IANA. If a LIST-EXTENDED extended data item is registered with IANA. If a LIST-EXTENDED extended data item is
returned as a result of requesting a particular LIST-EXTENDED option, returned as a result of requesting a particular LIST-EXTENDED option,
the name of the option SHOULD be used as the name of the LIST- the name of the option SHOULD be used as the name of the LIST-
skipping to change at page 29, line 31 skipping to change at page 31, 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.
8.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 30, line 11 skipping to change at page 32, 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.)
8.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
Implied return options(s): SUBSCRIBED Implied return options(s): SUBSCRIBED
LIST-EXTENDED option description: Causes the LIST command to list LIST-EXTENDED option description: Causes the LIST command to list
subscribed mailboxes, rather than the actual mailboxes. subscribed mailboxes, rather than the actual mailboxes.
Published specification : XXXX, Section 3. Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 7. 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
2. To: iana@iana.org 2. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option REMOTE Subject: Registration of LIST-EXTENDED option REMOTE
skipping to change at page 31, line 8 skipping to change at page 33, line 8
LIST-EXTENDED option type: SELECTION LIST-EXTENDED option type: SELECTION
Implied return options(s): (none) Implied return options(s): (none)
LIST-EXTENDED option description: causes the LIST command to LIST-EXTENDED option description: causes the LIST command to
return remote mailboxes as well as local ones, as described in return remote mailboxes as well as local ones, as described in
RFC 2193. RFC 2193.
Published specification : XXXX, Section 3. Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 7. 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
3. To: iana@iana.org 3. 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: RETURN LIST-EXTENDED option type: RETURN
LIST-EXTENDED option description: Causes the LIST command to LIST-EXTENDED option description: Causes the LIST command to
return subscription state. return subscription state.
Published specification : XXXX, Section 3. Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 7. 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
4. To: iana@iana.org 4. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH
skipping to change at page 32, line 8 skipping to change at page 34, line 8
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 (childinfo-extended-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 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
5. To: iana@iana.org 5. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option CHILDREN Subject: Registration of LIST-EXTENDED option CHILDREN
LIST-EXTENDED option name: CHILDREN LIST-EXTENDED option name: CHILDREN
LIST-EXTENDED option type: RETURN LIST-EXTENDED option type: RETURN
LIST-EXTENDED option description: Requests mailbox child LIST-EXTENDED option description: Requests mailbox child
information. information.
Published specification : XXXX, Section 3 and Section 4. Published specification : XXXX, Section 3 and Section 4.
Security considerations: XXXX, Section 7. 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
8.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 33, line 19 skipping to change at page 35, 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.)
8.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
LIST-EXTENDED extended data item description: The CHILDINFO LIST-EXTENDED extended data item description: The CHILDINFO
extended data item describes the selection criteria that has extended data item describes the selection criteria that has
caused it to be returned and indicates that the mailbox has one caused it to be returned and indicates that the mailbox has one
or more child mailbox that match the selection criteria. or more child mailbox that match the selection criteria.
Which LIST-EXTENDED option(s) (and their types) causes this Which LIST-EXTENDED option(s) (and their types) causes this
extended data item to be returned (if any): RECURSIVEMATCH extended data item to be returned (if any): RECURSIVEMATCH
selection option selection option
Published specification : XXXX, Section 3.3. Published specification : XXXX, Section 3.5.
Security considerations: XXXX, Section 7. 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. Acknowledgements 10. Acknowledgements
Mike Gahrns and Raymond Cheng of Microsoft Corporation originally Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
devised the Child Mailbox Extension and proposed it in 1997; the devised the Child Mailbox Extension and proposed it in 1997; the
idea, as well as most of the text in Section 4, is theirs. idea, as well as most of the text in Section 4, is theirs.
This document is the result of discussions on the IMAP4 and IMAPEXT 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.
10. Normative References 11. 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.
[CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002. [I18N] Newman, C. and A. Gulbrandsen, "ACAP -- Application
Configuration Access Protocol", draft-ietf-imapext-i18n
(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
[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
Phone: +1 914 784 7941 Phone: +1 914 784 7941
Email: leiba@watson.ibm.com Email: leiba@watson.ibm.com
 End of changes. 57 change blocks. 
91 lines changed or deleted 132 lines changed or added

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