draft-ietf-imapext-list-extensions-12.txt   draft-ietf-imapext-list-extensions-13.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 2, 2005 March 2005 Expires: November 17, 2005 May 16, 2005
IMAP4 LIST Command Extensions IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-12 draft-ietf-imapext-list-extensions-13
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 2, 2005. This Internet-Draft will expire on November 17, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 3, line 7 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 an Proposed Standard for the Internet Community. editor as an Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested, and should Discussion and suggestions for improvement are requested, and should
be sent to ietf-imapext@imc.org. be sent to 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 . . . . . . . . . . . . . . 3
2. Introduction and overview . . . . . . . . . . . . . . . . . . 5 2. Introduction and overview . . . . . . . . . . . . . . . . . . 4
3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 6 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 6
3.1 General principles for returning LIST responses . . . . . . . 10 3.1 General principles for returning LIST responses . . . . . . . 10
3.2 Additional requirements on LISTEXT clients . . . . . . . . . . 11 3.2 Additional requirements on LIST-EXTENDED clients . . . . . . . 11
3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . 11 3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . 11
4. The CHILDREN return Option . . . . . . . . . . . . . . . . . . 13 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . . 14
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . . 26 8.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . . 30
8.2 Registration procedure and Change control . . . . . . . . . . 26 8.2 Registration procedure and Change control . . . . . . . . . . 30
8.3 Registration template for LISTEXT options . . . . . . . . . . 27 8.3 Registration template for LIST-EXTENDED options . . . . . . . 31
8.4 Initial LISTEXT option registrations . . . . . . . . . . . . . 28 8.4 Initial LIST-EXTENDED option registrations . . . . . . . . . . 32
8.5 Registration template for LISTEXT extended data item . . . . . 30 8.5 Registration template for LIST-EXTENDED extended data item . . 34
8.6 Initial LISTEXT extended data item registrations . . . . . . . 31 8.6 Initial LIST-EXTENDED extended data item registrations . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
10. Normative References . . . . . . . . . . . . . . . . . . . . . 32 10. Normative References . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . 38
1. Conventions used in this document 1. Conventions used in this document
In examples, "C:" indicates lines sent by a client that is connected In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client. to a server. "S:" indicates lines sent by the server to the client.
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
used in this document as specified in RFC 2119 [Kwds]. used in this document as specified in RFC 2119 [Kwds].
The term "canonical LIST pattern" refers to the canonical pattern The term "canonical LIST pattern" refers to the canonical pattern
skipping to change at page 5, line 34 skipping to change at page 4, line 37
described in [MBRef]. We are also defining the mechanism to request described in [MBRef]. We are also defining the mechanism to request
extended mailbox information, such as is described in the "Child extended mailbox information, such as is described in the "Child
Mailbox Extension" [CMbox]. The base LSUB command is not deprecated Mailbox Extension" [CMbox]. The base LSUB command is not deprecated
by this extension; rather, this extension adds a way to obtain by this extension; rather, this extension adds a way to obtain
subscription information with more options, with those server subscription information with more options, with those server
implementations that support it. Clients that simply need a list of implementations that support it. Clients that simply need a list of
subscribed mailboxes, as provided by the LSUB command, SHOULD subscribed mailboxes, as provided by the LSUB command, SHOULD
continue to use that command. continue to use that command.
This document defines an IMAP4 extension that is identified by the This document defines an IMAP4 extension that is identified by the
capability string "LISTEXT". The X-DRAFT-W12-LISTEXT extension makes capability string "LIST-EXTENDED". The LIST-EXTENDED extension makes
the following changes to the IMAP4 protocol, which are described in the following changes to the IMAP4 protocol, which are described in
more detail in Section 3 and Section 4: more detail in Section 3 and Section 4:
a. defines new syntax for LIST command options. a. defines new syntax for LIST command options.
b. extends LIST to allow for multiple mailbox patterns. b. extends LIST to allow for multiple mailbox patterns.
c. adds LIST command selection options: SUBSCRIBED, REMOTE and c. adds LIST command selection options: SUBSCRIBED, REMOTE and
RECURSIVEMATCH. RECURSIVEMATCH.
d. adds LIST command return options: SUBSCRIBED and CHILDREN. d. adds LIST command return options: SUBSCRIBED and CHILDREN.
e. adds new mailbox attributes: "\NonExistent", "\Subscribed", e. adds new mailbox attributes: "\NonExistent", "\Subscribed",
"\Remote", "\HasChildren" and "\HasNoChildren". "\Remote", "\HasChildren" and "\HasNoChildren".
f. adds CHILDINFO extended data item. f. adds CHILDINFO extended data item.
3. Extended LIST Command 3. Extended LIST Command
This extension updates the syntax of the LIST command to allow for This extension updates the syntax of the LIST command to allow for
multiple mailbox patterns to be specified, if they are enclosed in multiple mailbox patterns to be specified, if they are enclosed in
parantheses. A mailbox name match a list of mailbox patterns if it parantheses. A mailbox name match a list of mailbox patterns if it
matches at least one mailbox pattern. Note that if a mailbox name matches at least one mailbox pattern. Note that if a mailbox name
matches multiple mailbox patterns from the list, the server should matches multiple mailbox patterns from the list, the server should
return only a single LIST response. return only a single LIST response.
skipping to change at page 7, line 26 skipping to change at page 7, line 26
options are specified by the client is not significant. options are specified by the client is not significant.
In general, each selection option except for RECURSIVEMATCH will have In general, each selection option except for RECURSIVEMATCH will have
a corresponding return option. The REMOTE selection option is an a corresponding return option. The REMOTE selection option is an
anomaly in this regard, and does not have a corresponding return anomaly in this regard, and does not have a corresponding return
option. That is because it expands, rather than restricts, the set option. That is because it expands, rather than restricts, the set
of mailboxes that are returned. Future extensions to this of mailboxes that are returned. Future extensions to this
specification should keep parallelism in mind, and define a pair of specification should keep parallelism in mind, and define a pair of
corresponding options. corresponding options.
This extension is identified by the capability string "LISTEXT", and This extension is identified by the capability string "LIST-
support for it is a prerequisite for any future extensions that EXTENDED", and support for it is a prerequisite for any future
require specialized forms of the LIST command. Such extensions MUST extensions that require specialized forms of the LIST command. Such
refer to this document and MUST add their function through command extensions MUST refer to this document and MUST add their function
options as described herein. Note that extensions that don't require through command options as described herein. Note that extensions
support for an extended LIST command, but use extended LIST responses that don't require support for an extended LIST command, but use
(see below), don't need to advertise the "LISTEXT" capability string. extended LIST responses (see below), don't need to advertise the
"LIST-EXTENDED" capability string.
This extension also defines extensions to the LIST response, allowing This extension also defines extensions to the LIST response, allowing
a series of extended fields at the end, a parenthesized list of a series of extended fields at the end, a parenthesized list of
tagged data (also referred to as "extended data item"). The first tagged data (also referred to as "extended data item"). The first
element of an extended field is a tag, which identifies type of the element of an extended field is a tag, which identifies type of the
data. Tags MUST be registered with IANA, as described in Section 8.5 data. Tags MUST be registered with IANA, as described in Section 8.5
of this document. An example of such extended set might be of this document. An example of such extended set might be
((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample
"text")) "text"))
skipping to change at page 7, line 48 skipping to change at page 8, line 4
data. Tags MUST be registered with IANA, as described in Section 8.5 data. Tags MUST be registered with IANA, as described in Section 8.5
of this document. An example of such extended set might be of this document. An example of such extended set might be
((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample
"text")) "text"))
or... or...
((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more
text")) text"))
See the formal grammar, below, for the full syntactic details. The See the formal grammar, below, for the full syntactic details. The
server MUST NOT return any extended data item, unless the client has server MUST NOT return any extended data item, unless the client has
expressed its ability to support extended LIST responses, for example expressed its ability to support extended LIST responses, for example
by using an extended LIST command. The server MAY return data in the by using an extended LIST command. The server MAY return data in the
extended fields that was not solicited by the client. The client extended fields that was not solicited by the client. The client
MUST ignore all extended fields it doesn't recognize. MUST ignore all extended fields it doesn't recognize.
The LISTEXT capability also defines several new mailbox attributes. The LIST-EXTENDED capability also defines several new mailbox
attributes.
The "\NonExistent" attribute indicates that a mailbox does not The "\NonExistent" attribute indicates that a mailbox does not
actually exist. Note that this attribute is not meaningful by actually exist. Note that this attribute is not meaningful by
itself, as mailboxes that match the canonical LIST pattern but don't itself, as mailboxes that match the canonical LIST pattern but don't
exist must not be returned unless one of the two conditions listed exist must not be returned unless one of the two conditions listed
below is also satisfied: below is also satisfied:
a. the mailbox also satisfies the selection criteria (for example, a. the mailbox also satisfies the selection criteria (for example,
its name is subscribed and the "SUBSCRIBED" selection option has its name is subscribed and the "SUBSCRIBED" selection option has
been specified) been specified)
skipping to change at page 9, line 42 skipping to change at page 9, line 47
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.3.
Note 1: In order for a parent mailbox to be returned, it still has Note 1: In order for a parent mailbox to be returned, it still has
to match the canonical LIST pattern. to match the canonical LIST pattern.
Note 2: When returning the CHILDINFO extended data item, it Note 2: When returning the CHILDINFO extended data item, it
doesn't matter if the submailbox matches the canonical LIST doesn't matter if the submailbox matches the canonical LIST
pattern or not. See also example 9 in Section 5. [[anchor2: Is pattern or not. See also example 9 in Section 5.
this really what we want? Why?]]
The RECURSIVEMATCH option MUST NOT occur as the only selection The RECURSIVEMATCH option MUST NOT occur as the only selection
option, as it only makes sense when other selection options are option, as it only makes sense when other selection options are
also used. The server MUST return BAD tagged response in such also used. The server MUST return BAD tagged response in such
case. case.
Note that even if RECURSIVEMATCH option is specified, the client Note that even if RECURSIVEMATCH option is specified, the client
MUST still be able to handle a case when a CHILDINFO extended data MUST still be able to handle a case when a CHILDINFO extended data
item is returned and there are no submailboxes that meet the item is returned and there are no submailboxes that meet the
selection criteria of the given LIST command, as they can be selection criteria of the given LIST command, as they can be
skipping to change at page 11, line 4 skipping to change at page 11, line 15
it has at least one child mailbox name that satisfies the it has at least one child mailbox name that satisfies the
selection criteria and that doesn't match the canonical LIST selection criteria and that doesn't match the canonical LIST
pattern. 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.3. 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 LISTEXT clients 3.2 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.
skipping to change at page 12, line 4 skipping to change at page 12, line 20
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.
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.
[[anchor3: Should this be a MUST?]]
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 | returned |
| | selection | that meets the | LISTEXT | | | selection | that meets the | LIST-EXTENDED |
| | criteria | selection | attributes and | | | criteria | selection | attributes and |
| | | criteria | CHILDINFO | | | | criteria | CHILDINFO |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| no | no | no | no LIST | | no | no | no | no LIST |
| | | | response | | | | | response |
| | | | returned | | | | | returned |
| | | | | | | | | |
| yes | no | no | no LIST | | yes | no | no | no LIST |
| | | | response | | | | | response |
| | | | returned | | | | | returned |
skipping to change at page 14, line 5 skipping to change at page 15, line 8
child mailboxes. As such a client MUST be prepared to accept child mailboxes. As such a client MUST be prepared to accept
the \HasChildren attribute as a hint. That is, a mailbox MAY be the \HasChildren attribute as a hint. That is, a mailbox MAY be
flagged with the \HasChildren attribute, but no child mailboxes flagged with the \HasChildren attribute, but no child mailboxes
will appear in the LIST response. will appear in the LIST response.
\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.
In some instances a server that supports the LISTEXT extension might In some instances a server that supports the LIST-EXTENDED extension
not be able to determine whether a mailbox has children. For example might not be able to determine whether a mailbox has children. For
it may have difficulty determining whether there are child mailboxes example it may have difficulty determining whether there are child
when LISTing mailboxes while operating in a particular namespace. In mailboxes when LISTing mailboxes while operating in a particular
these cases, a server MAY exclude both the \HasChildren and namespace. In these cases, a server MAY exclude both the
\HasNoChildren attributes in the LIST response. As such, a client \HasChildren and \HasNoChildren attributes in the LIST response. As
can not make any assumptions about whether a mailbox has children such, a client can not make any assumptions about whether a mailbox
based upon the absence of a single attribute. In particular, some has children based upon the absence of a single attribute. In
servers may not be able to combine the SUBSCRIBED selection option particular, some servers may not be able to combine the SUBSCRIBED
and CHILDREN return option. Such servers MUST honour the SUBSCRIBED selection option and CHILDREN return option. Such servers MUST
selection option, and they will simply ignore the CHILDREN return honour the SUBSCRIBED selection option, and they will simply ignore
option if both are requested. It is an error for the server to the CHILDREN return option if both are requested. It is an error for
return both a \HasChildren and a \HasNoChildren attribute in a LIST the server to return both a \HasChildren and a \HasNoChildren
response. attribute in a 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 be
used for the other examples. used for the other examples.
skipping to change at page 16, line 45 skipping to change at page 18, line 40
6: The following example requests the server to include mailboxes, 6: The following example requests the server to include mailboxes,
which reside on another server. The server is requested to which reside on another server. The server is requested to
return subscription information for all returned mailboxes. This return subscription information for all returned mailboxes. This
is different from the example above. is different from the example above.
Note that the output of this command is not a superset of the Note that the output of this command is not a superset of the
output in the previous example, as it doesn't include LIST output in the previous example, as it doesn't include LIST
response for the non-existent "Fruit/Peach". response for the non-existent "Fruit/Peach".
C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Apple"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST () "/" "Tofu" S: * LIST () "/" "Tofu"
S: * LIST (\Subscribed) "/" "Vegetable" S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn" S: * LIST () "/" "Vegetable/Corn"
S: * LIST (\Remote \Subscribed) "/" "Bread" S: * LIST (\Remote \Subscribed) "/" "Bread"
S: * LIST (\Remote) "/" "Meat" S: * LIST (\Remote) "/" "Meat"
S: A06 OK done S: A06 OK done
7: In the following example the client has specified multiple 7: In the following example the client has specified multiple
mailbox patterns. Note that this example doesn't use the mailbox mailbox patterns. Note that this example doesn't use the mailbox
hierarchy used in the previous examples. hierarchy used in the previous examples.
C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
S: * LIST () "/" "INBOX" S: * LIST () "/" "INBOX"
S: * LIST (\NoInferiors) "/" "Drafts" S: * LIST (\NoInferiors) "/" "Drafts"
S: * LIST () "/" "Sent/March2004" S: * LIST () "/" "Sent/March2004"
S: * LIST (\Marked) "/" "Sent/December2003" S: * LIST (\Marked) "/" "Sent/December2003"
S: * LIST () "/" "Sent/August2004" S: * LIST () "/" "Sent/August2004"
S: BBB OK done S: BBB OK done
8: The following example demonstates the difference between 8: The following example demonstates the difference between
\HasChildren attribute and CHILDINFO extended data item. \HasChildren attribute and 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 i.e. the mailbox "Foo" is not subscribed, but it has a child that
that is. is.
A1) If the mailbox "Foo" had been subscribed instead, the last A1) If the mailbox "Foo" had been subscribed instead, 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" S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
("SUBSCRIBED"))) ("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" S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO"
("SUBSCRIBED"))) ("SUBSCRIBED")))
S: C04 OK done S: C04 OK done
B) Now, let's assume that no mailbox is subscribed. In this case B) Now, let's assume that no mailbox is subscribed. In this case
the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will return the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will return
no responses, as there are no subscribed children (even though no responses, as there are no subscribed children (even though
"Foo" has children). "Foo" has children).
C) And finally, suppose that only the mailboxes "Foo" and "Moo" C) And finally, suppose that only the mailboxes "Foo" and "Moo"
are subscribed. In that case we see this result: are subscribed. In that case we see this result:
skipping to change at page 20, line 26 skipping to change at page 24, line 23
The CHILDINFO extended data item is returned for mailboxes The CHILDINFO extended data item is returned for mailboxes
"foo2", "baz2" and "eps2", because all of them have subscribed "foo2", "baz2" and "eps2", because all of them have subscribed
children, even though for the mailbox "foo2" only one of the two children, even though for the mailbox "foo2" only one of the two
subscribed children match the pattern, for the mailbox "baz2" all subscribed children match the pattern, for the mailbox "baz2" all
the subscribed children match the pattern and for the mailbox the subscribed children match the pattern and for the mailbox
"eps2" none of the subscribed children match the pattern. "eps2" none of the subscribed children match 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" S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
("SUBSCRIBED"))) ("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "eps2/mamba" S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "quux2/bar2" S: * LIST (\Subscribed) "/" "quux2/bar2"
S: D03 OK done
S: D03 OK done
the LIST responses for mailboxes "foo2", "baz2" and "eps2" still the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
have the CHILDINFO extended data item, even though this have the CHILDINFO extended data item, even though this
information is redundant and the client can determine it by information is redundant and the client can determine it by
itself. itself.
10: The following example shows usage of multiple mailbox patterns. 10: The following example shows usage of multiple mailbox patterns.
It also demonstrates that the presence of the CHILDINFO extended It also demonstrates that the presence of the CHILDINFO extended
data item doesn't necessarily imply \HasChildren. data item doesn't necessarily imply \HasChildren.
C: a1 LIST "" ("foo" "foo/*") C: a1 LIST "" ("foo" "foo/*")
skipping to change at page 20, line 49 skipping to change at page 25, line 14
the LIST responses for mailboxes "foo2", "baz2" and "eps2" still the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
have the CHILDINFO extended data item, even though this have the CHILDINFO extended data item, even though this
information is redundant and the client can determine it by information is redundant and the client can determine it by
itself. itself.
10: The following example shows usage of multiple mailbox patterns. 10: The following example shows usage of multiple mailbox patterns.
It also demonstrates that the presence of the CHILDINFO extended It also demonstrates that the presence of the CHILDINFO extended
data item doesn't necessarily imply \HasChildren. data item doesn't necessarily imply \HasChildren.
C: a1 LIST "" ("foo" "foo/*") C: a1 LIST "" ("foo" "foo/*")
S: * LIST () "/" foo S: * LIST () "/" foo
S: a1 OK done S: a1 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*" C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done S: a2 OK done
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN
(CHILDREN) (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO" S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
("SUBSCRIBED"))) ("SUBSCRIBED")))
S: a3 OK done S: a3 OK done
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF]. Terms not defined here are taken Form (BNF) as described in [ABNF]. Terms not defined here are taken
from [IMAP4]. from [IMAP4].
"vendor-token" is defined in [ACAP]. [[anchor4: This is an issue in "vendor-token" is defined in [ACAP]. Note that this normative
moving forward, since ACAP will never move to Draft Standard. Should reference to ACAP is an issue in moving this spec forward, since ACAP
we define vendor-token here, and also define the IANA registry here? will never move to Draft Standard. The definitions of "vendor-token"
Should we put it into another document? Is there someplace else we and of the IANA registry must eventually go somewhere else, in a
can get the same definition?]] document that can be moved forward on the standards track.
childinfo-extended-item = "CHILDINFO" SP "(" childinfo-extended-item = "CHILDINFO" SP "(" list-select-base-opt-
list-select-base-opt-quoted quoted
*( SP list-select-base-opt-quoted ) ")" *( SP list-select-base-opt-quoted ) ")"
; Extended data item returned when the RECURSIVEMATCH ; Extended data item returned when the RECURSIVEMATCH
; selection option is specified. ; selection option is specified.
; Note 1: the CHILDINFO tag can be returned ; Note 1: the CHILDINFO tag can be returned
; with and without surrounding quotes, as per ; with and without surrounding quotes, as per
; mbox-list-extended-item-tag production. ; mbox-list-extended-item-tag production.
; Note 2: The selection options are returned quoted, ; Note 2: The selection options are returned quoted,
; unlike their specification in the extended LIST ; unlike their specification in the extended LIST
; command. ; command.
skipping to change at page 22, line 43 skipping to change at page 26, line 43
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-select-opts = "(" [*(list-select-mod-opt SP) list-select-opts = "(" [*(list-select-mod-opt SP) list-select-base-
list-select-base-opt opt
*(SP list-select-opt)] ")" *(SP list-select-opt)] ")"
; list selection options, e.g. REMOTE ; list selection options, e.g. REMOTE
list-select-opt = list-select-mod-opt / list-select-base-opt list-select-opt = list-select-mod-opt / list-select-base-opt
; An option registration template is described in ; An option registration template is described in
; Section 8.3 of this document. ; Section 8.3 of this document.
list-select-base-opt = "SUBSCRIBED" / "REMOTE" / option-extension list-select-base-opt = "SUBSCRIBED" / "REMOTE" / 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 = <"> list-select-base-opt <">
list-select-mod-opt = "RECURSIVEMATCH" / option-extension list-select-mod-opt = "RECURSIVEMATCH" / option-extension
skipping to change at page 23, line 14 skipping to change at page 27, line 17
list-select-base-opt = "SUBSCRIBED" / "REMOTE" / option-extension list-select-base-opt = "SUBSCRIBED" / "REMOTE" / 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 = <"> list-select-base-opt <">
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-return-opts = "RETURN" SP "(" [return-option *(SP list-return-opts = "RETURN" SP "(" [return-option *(SP return-
return-option)] ")" option)] ")"
; list return options, e.g. CHILDREN ; list return options, e.g. CHILDREN
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]
mbox-list-extended = "(" [mbox-list-extended-item mbox-list-extended = "(" [mbox-list-extended-item
*(SP mbox-list-extended-item)] ")" *(SP mbox-list-extended-item)] ")"
mbox-list-extended-item = "(" mbox-list-extended-item-data ")" mbox-list-extended-item = "(" mbox-list-extended-item-data ")"
skipping to change at page 26, line 9 skipping to change at page 30, line 9
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 8. IANA Considerations
8.1 Guidelines for IANA 8.1 Guidelines for IANA
It is requested that IANA creates two new registries for LISTEXT It is requested that IANA creates two new registries for LIST-
options and LISTEXT extended response data. The templates and the EXTENDED options and LIST-EXTENDED response data. The templates and
initial registrations are detailed below. the initial registrations are detailed below.
8.2 Registration procedure and Change control 8.2 Registration procedure and Change control
Registration of a LISTEXT option is done by filling in the template Registration of a LIST-EXTENDED option is done by filling in the
in Section 8.3 and sending it via electronic mail to iana@iana.org. template in Section 8.3 and sending it via electronic mail to
Registration of a LISTEXT extended data item is done by filling in iana@iana.org. Registration of a LIST-EXTENDED extended data item is
the template in Section 8.5 and sending it via electronic mail to done by filling in the template in Section 8.5 and sending it via
iana@iana.org. IANA has the right to reject obviously bogus electronic mail to iana@iana.org. IANA has the right to reject
registrations, but will perform no review of claims made in the obviously bogus registrations, but will perform no review of claims
registration form. made in the registration form.
A LISTEXT option/extended data item name that starts with "V-" is A LIST-EXTENDED option/extended data item name that starts with "V-"
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 LISTEXT extended data item is returned as registered with IANA. If a LIST-EXTENDED extended data item is
a result of requesting a particular LISTEXT option, the name of the returned as a result of requesting a particular LIST-EXTENDED option,
option SHOULD be used as the name of the LISTEXT extended data item. the name of the option SHOULD be used as the name of the LIST-
EXTENDED extended data item.
Each vendor specific options/extended data item MUST start with their Each vendor specific options/extended data item MUST start with their
vendor-token ("vendor prefix"). The vendor-token MUST be registered vendor-token ("vendor prefix"). The vendor-token MUST be registered
with IANA, using the [ACAP] vendor subtree registry. with IANA, using the [ACAP] vendor subtree registry.
Standard LISTEXT option/extended data item names are case Standard LIST-EXTENDED option/extended data item names are case
insensitive. If the vendor prefix is omitted from a vendor specific insensitive. If the vendor prefix is omitted from a vendor specific
LISTEXT option/extended data item name, the rest is case insensitive. LIST-EXTENDED option/extended data item name, the rest is case
The vendor prefix itself is not case-sensitive, as it might contain insensitive. The vendor prefix itself is not case-sensitive, as it
non-ASCII characters. might contain non-ASCII characters.
While the registration procedures do not require it, authors of While the registration procedures do not require it, authors of LIST-
LISTEXT options/extended data items are encouraged to seek community EXTENDED options/extended data items are encouraged to seek community
review and comment whenever that is feasible. Authors may seek review and comment whenever that is feasible. Authors may seek
community review by posting a specification of their proposed community review by posting a specification of their proposed
mechanism as an Internet- Draft. LISTEXT options/extended data items mechanism as an Internet- Draft. LIST-EXTENDED options/extended data
intended for widespread use should be standardized through the normal items intended for widespread use should be standardized through the
IETF process, when appropriate. normal IETF process, when appropriate.
Comments on registered LISTEXT options/extended response data should Comments on registered LIST-EXTENDED options/extended response data
first be sent to the "owner" of the mechanism and/or to the IMAPEXT should first be sent to the "owner" of the mechanism and/or to the
WG mailing list. Submitters of comments may, after a reasonable IMAPEXT WG mailing list. Submitters of comments may, after a
attempt to contact the owner, request IANA to attach their comment to reasonable attempt to contact the owner, request IANA to attach their
the registration itself. If IANA approves of this, the comment will comment to the registration itself. If IANA approves of this, the
be made accessible in conjunction with the registration LISTEXT comment will be made accessible in conjunction with the registration
options/ extended response data itself. LIST-EXTENDED options/ extended response data itself.
Once a LISTEXT registration has been published by IANA, the author Once a LIST-EXTENDED registration has been published by IANA, the
may request a change to its definition. The change request follows author may request a change to its definition. The change request
the same procedure as the registration request. follows the same procedure as the registration request.
The owner of a LISTEXT registration may pass responsibility for the The owner of a LIST-EXTENDED registration may pass responsibility for
registered option/extended data item to another person or agency by the registered option/extended data item to another person or agency
informing IANA; this can be done without discussion or review. by informing IANA; this can be done without discussion or review.
The IESG may reassign responsibility for a LISTEXT option/extended The IESG may reassign responsibility for a LIST-EXTENDED option/
data item. The most common case of this will be to enable changes to extended data item. The most common case of this will be to enable
be made to mechanisms where the author of the registration has died, changes to be made to mechanisms where the author of the registration
moved out of contact or is otherwise unable to make changes that are has died, moved out of contact or is otherwise unable to make changes
important to the community. that are important to the community.
LISTEXT registrations may not be deleted; mechanisms which are no LIST-EXTENDED registrations may not be deleted; mechanisms which are
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 LISTEXT options/extended change to their "intended use" field; such LIST-EXTENDED options/
data items will be clearly marked in the lists published by IANA. extended data items will be clearly marked in the lists published by
IANA.
The IESG is considered to be the owner of all LISTEXT The IESG is considered to be the owner of all LIST-EXTENDED options/
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 LISTEXT options 8.3 Registration template for LIST-EXTENDED options
To: iana@iana.org To: iana@iana.org
Subject: Registration of LISTEXT option X Subject: Registration of LIST-EXTENDED option X
LISTEXT option name: LIST-EXTENDED option name:
LISTEXT 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)
LISTEXT option description: LIST-EXTENDED option description:
Published specification (optional, recommended): Published specification (optional, recommended):
Security considerations: Security considerations:
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 LISTEXT option registrations 8.4 Initial LIST-EXTENDED option registrations
It is requested that the LISTEXT option registry be populated with It is requested that the LIST-EXTENDED option registry be populated
the following entries: with the following entries:
1. To: iana@iana.org 1. To: iana@iana.org
Subject: Registration of LISTEXT option SUBSCRIBED Subject: Registration of LIST-EXTENDED option SUBSCRIBED
LISTEXT option name: SUBSCRIBED LIST-EXTENDED option name: SUBSCRIBED
LISTEXT option type: SELECTION LIST-EXTENDED option type: SELECTION
Implied return options(s): SUBSCRIBED Implied return options(s): SUBSCRIBED
LISTEXT 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 7.
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
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 LISTEXT option REMOTE Subject: Registration of LIST-EXTENDED option REMOTE
LISTEXT option name: REMOTE LIST-EXTENDED option name: REMOTE
LISTEXT option type: SELECTION LIST-EXTENDED option type: SELECTION
Implied return options(s): (none) Implied return options(s): (none)
LISTEXT option description: causes the LIST command to return LIST-EXTENDED option description: causes the LIST command to
remote mailboxes as well as local ones, as described in RFC 2193. return remote mailboxes as well as local ones, as described in
RFC 2193.
Published specification : XXXX, Section 3. Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
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 LISTEXT option SUBSCRIBED Subject: Registration of LIST-EXTENDED option SUBSCRIBED
LISTEXT option name: SUBSCRIBED LIST-EXTENDED option name: SUBSCRIBED
LISTEXT option type: RETURN LIST-EXTENDED option type: RETURN
LISTEXT option description: Causes the LIST command to return LIST-EXTENDED option description: Causes the LIST command to
subscription state. return subscription state.
Published specification : XXXX, Section 3. Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
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 LISTEXT option RECURSIVEMATCH Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH
LISTEXT option name: RECURSIVEMATCH LIST-EXTENDED option name: RECURSIVEMATCH
LISTEXT option type: SELECTION LIST-EXTENDED option type: SELECTION
Implied return options(s): (none) Implied return options(s): (none)
LISTEXT option description: Requests that CHILDINFO extended data LIST-EXTENDED option description: Requests that CHILDINFO
item is to be returned. extended data item is to be returned.
Published specification : XXXX, Section 3. Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
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 LISTEXT option CHILDREN Subject: Registration of LIST-EXTENDED option CHILDREN
LISTEXT option name: CHILDREN LIST-EXTENDED option name: CHILDREN
LISTEXT option type: RETURN LIST-EXTENDED option type: RETURN
LISTEXT option description: Requests mailbox child information. LIST-EXTENDED option description: Requests mailbox child
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 7.
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org Owner/Change controller: iesg@ietf.org
8.5 Registration template for LISTEXT extended data item 8.5 Registration template for LIST-EXTENDED extended data item
To: iana@iana.org To: iana@iana.org
Subject: Registration of X LISTEXT extended data item Subject: Registration of X LIST-EXTENDED extended data item
LISTEXT extended data item tag: LIST-EXTENDED extended data item tag:
LISTEXT extended data item description: LIST-EXTENDED extended data item description:
Which LISTEXT option(s) (and their types) causes this extended data Which LIST-EXTENDED option(s) (and their types) causes this extended
item to be returned (if any): data item to be returned (if any):
Published specification (optional, recommended): Published specification (optional, recommended):
Security considerations: Security considerations:
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 LISTEXT extended data item registrations 8.6 Initial LIST-EXTENDED extended data item registrations
It is requested that the LISTEXT 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 LISTEXT extended data item Subject: Registration of CHILDINFO LIST-EXTENDED extended data
item
LISTEXT extended data item tag: CHILDINFO LIST-EXTENDED extended data item tag: CHILDINFO
LISTEXT extended data item description: The CHILDINFO extended LIST-EXTENDED extended data item description: The CHILDINFO
data item describes the selection criteria that has caused it to extended data item describes the selection criteria that has
be returned and indicates that the mailbox has one or more child caused it to be returned and indicates that the mailbox has one
mailbox that match the selection criteria. or more child mailbox that match the selection criteria.
Which LISTEXT option(s) (and their types) causes this extended Which LIST-EXTENDED option(s) (and their types) causes this
data item to be returned (if any): RECURSIVEMATCH selection extended data item to be returned (if any): RECURSIVEMATCH
option selection option
Published specification : XXXX, Section 3.3. Published specification : XXXX, Section 3.3.
Security considerations: XXXX, Section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
skipping to change at page 32, line 35 skipping to change at page 36, line 35
Access Protocol", RFC 2244, November 1997. Access Protocol", RFC 2244, November 1997.
[CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002. [CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.
[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, September [MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
1997. September 1997.
Authors' Addresses Authors' Addresses
Barry Leiba Barry Leiba
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
30 Saw Mill River Road 30 Saw Mill River Road
Hawthorne, NY 10532 Hawthorne, NY 10532
US US
Phone: +1 914 784 7941 Phone: +1 914 784 7941
 End of changes. 

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