diff options
Diffstat (limited to 'imap/docs/rfc/rfc5258.txt')
| -rw-r--r-- | imap/docs/rfc/rfc5258.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/imap/docs/rfc/rfc5258.txt b/imap/docs/rfc/rfc5258.txt new file mode 100644 index 00000000..a80ec156 --- /dev/null +++ b/imap/docs/rfc/rfc5258.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group B. Leiba +Request for Comments: 5258 IBM T.J. Watson Research Center +Obsoletes: 3348 A. Melnikov +Updates: 2193 Isode Limited +Category: Standards Track June 2008 + + + Internet Message Access Protocol version 4 - LIST Command Extensions + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we + have added extensions, such as Mailbox Referrals, that have required + specialized lists we have had to expand the number of list commands, + since each extension must add its function to both LIST and LSUB, and + these commands are not, as they are defined, extensible. If we've + needed the extensions to work together, we've had to add a set of + commands to mix the different options, the set increasing in size + with each new extension. This document describes an extension to the + base LIST command that will allow these additions to be done with + mutually compatible options to the LIST command, avoiding the + exponential increase in specialized list commands. + + + + + + + + + + + + + + + + + + + + + +Leiba & Melnikov Standards Track [Page 1] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + +Table of Contents + + 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 + 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Initial List of Selection Options . . . . . . . . . . . . 7 + 3.2. Initial List of Return Options . . . . . . . . . . . . . . 8 + 3.3. General Principles for Returning LIST Responses . . . . . 9 + 3.4. Additional Requirements on LIST-EXTENDED Clients . . . . . 9 + 3.5. CHILDINFO Extended Data Item . . . . . . . . . . . . . . . 10 + 4. The CHILDREN Return Option . . . . . . . . . . . . . . . . . . 11 + 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7. Internationalization Considerations . . . . . . . . . . . . . 22 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 9.1. Guidelines for IANA . . . . . . . . . . . . . . . . . . . 23 + 9.2. Registration Procedure and Change Control . . . . . . . . 23 + 9.3. Registration Template for LIST-EXTENDED Options . . . . . 25 + 9.4. Initial LIST-EXTENDED Option Registrations . . . . . . . . 25 + 9.5. Registration Template for LIST-EXTENDED Extended Data + Item . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.6. Initial LIST-EXTENDED Extended Data Item Registrations . . 28 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 30 + + + + + + + + + + + + + + + + + + + + + + + + +Leiba & Melnikov Standards Track [Page 2] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + +1. Introduction and Overview + + The LIST command is extended by amending the syntax to allow options + and multiple patterns to be specified. The list of options replaces + the several commands that are currently used to mix and match the + information requested. The new syntax is backward compatible, with + no ambiguity: the new syntax is being used if one of the following + conditions is true: + + 1. if the first word after the command name begins with a + parenthesis ("LIST selection options") + + 2. if the second word after the command name begins with a + parenthesis ("multiple mailbox patterns") + + 3. if the LIST command has more than 2 parameters ("LIST return + options") + + Otherwise the original syntax is used. + + By adding options to the LIST command, we are announcing the intent + to phase out and eventually to deprecate the RLIST and RLSUB commands + described in [MBRef]. We are also defining the mechanism to request + extended mailbox information, such as is described in the Child + Mailbox Extension [CMbox]. The base LSUB command is not deprecated + by this extension; rather, this extension adds a way to obtain + subscription information with more options, with those server + implementations that support it. Clients that simply need a list of + subscribed mailboxes, as provided by the LSUB command, SHOULD + continue to use that command. + + This document defines an IMAP4 extension that is identified by the + capability string "LIST-EXTENDED". The LIST-EXTENDED extension makes + the following changes to the IMAP4 protocol, which are described in + more detail in Section 3 and Section 4: + + a. defines new syntax for LIST command options. + + b. extends LIST to allow for multiple mailbox patterns. + + c. adds LIST command selection options: SUBSCRIBED, REMOTE, and + RECURSIVEMATCH. + + d. adds LIST command return options: SUBSCRIBED and CHILDREN. + + e. adds new mailbox attributes: "\NonExistent", "\Subscribed", + "\Remote", "\HasChildren", and "\HasNoChildren". + + + + +Leiba & Melnikov Standards Track [Page 3] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + f. adds CHILDINFO extended data item. + +2. Conventions Used in This Document + + In examples, "C:" indicates lines sent by a client that is connected + to a server. "S:" indicates lines sent by the server to the client. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + are used in this document as specified in RFC 2119 [Kwds]. + + The term "canonical LIST pattern" refers to the canonical pattern + constructed internally by the server from the reference and mailbox + name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command + returns only mailboxes that match the canonical LIST pattern. + + Other terms are introduced where they are referenced for the first + time. + +3. Extended LIST Command + + This extension updates the syntax of the LIST command to allow for + multiple mailbox patterns to be specified, if they are enclosed in + parentheses. A mailbox name matches a list of mailbox patterns if it + matches at least one mailbox pattern. If a mailbox name matches + multiple mailbox patterns from the list, the server SHOULD return + only a single LIST response. + + Note that the non-extended LIST command is required to treat an empty + ("" string) mailbox name argument as a special request to return the + hierarchy delimiter and the root name of the name given in the + reference parameter (as per [IMAP4]). However, ANY extended LIST + command (extended in any of 3 ways specified in Section 1, or any + combination thereof) MUST NOT treat the empty mailbox name as such a + special request, and any regular processing described in this + document applies. In particular, if an extended LIST command has + multiple mailbox names and one (or more) of them is the empty string, + the empty string MUST be ignored for the purpose of matching. + + Some servers might restrict which patterns are allowed in a LIST + command. If a server doesn't accept a particular pattern, it MUST + silently ignore it. + + The LIST command syntax is also extended in two additional ways: by + adding a parenthesized list of command options between the command + name and the reference name (LIST selection options) and an optional + + + + + + +Leiba & Melnikov Standards Track [Page 4] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + list of options at the end that control what kind of information + should be returned (LIST return options). See the formal syntax in + Section 6 for specific details. + + A LIST selection option tells the server which mailbox names should + be selected by the LIST operation. The server should return + information about all mailbox names that match any of the "canonical + LIST pattern" (as described above) and satisfy additional selection + criteria (if any) specified by the LIST selection options. Let's + call any such mailbox name a "matched mailbox name". When multiple + selection options are specified, the server MUST return information + about mailbox names that satisfy every selection option, unless a + description of a particular specified option prescribes special + rules. An example of an option prescribing special rules is the + RECURSIVEMATCH selection option described later in this section. We + will use the term "selection criteria" when referring collectively to + all selection options specified in a LIST command. + + A LIST return option controls which information is returned for each + matched mailbox name. Note that return options MUST NOT cause the + server to report information about additional mailbox names. If the + client has not specified any return option, only information about + attributes should be returned by the server. (Of course, the server + is allowed to include any other information at will.) + + Both selection and return command options will be defined in this + document and in approved extension documents; each option will be + enabled by a capability string (one capability may enable multiple + options), and a client MUST NOT send an option for which the server + has not advertised support. A server MUST respond to options it does + not recognize with a BAD response. The client SHOULD NOT specify any + option more than once; however, if the client does this, the server + MUST act as if it received the option only once. The order in which + options are specified by the client is not significant. + + In general, each selection option except RECURSIVEMATCH will have a + corresponding return option. The REMOTE selection option is an + anomaly in this regard, and does not have a corresponding return + option. That is because it expands, rather than restricts, the set + of mailboxes that are returned. Future extensions to this + specification should keep parallelism in mind and define a pair of + corresponding options. + + This extension is identified by the capability string + "LIST-EXTENDED", and support for it is a prerequisite for any future + extensions that require specialized forms of the LIST command. Such + extensions MUST refer to this document and MUST add their function + through command options as described herein. Note that extensions + + + +Leiba & Melnikov Standards Track [Page 5] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + that don't require support for an extended LIST command, but use + 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 + a series of extended fields at the end, a parenthesized list of + tagged data (also referred to as "extended data item"). The first + element of an extended field is a tag, which identifies the type of + data. Tags MUST be registered with IANA, as described in Section 9.5 + of this document. An example of such an extended set might be + + tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text")) + + or + + tablecloth ("edge" "lacy")) (X-Sample "text" "more text")) + + See the formal syntax, in Section 6, for the full syntactic details. + The server MUST NOT return any extended data item unless the client + has expressed its ability to support extended LIST responses, for + example, by using an extended LIST command. The server MAY return + data in the extended fields that was not directly solicited by the + client in the corresponding LIST command. For example, the client + can enable extra extended fields by using another IMAP extension that + make use of the extended LIST responses. The client MUST ignore all + extended fields it doesn't recognize. + + The LIST-EXTENDED capability also defines several new mailbox + attributes. + + The "\NonExistent" attribute indicates that a mailbox name does not + refer to an existing mailbox. Note that this attribute is not + meaningful by itself, as mailbox names that match the canonical LIST + pattern but don't exist must not be returned unless one of the two + conditions listed below is also satisfied: + + a. The mailbox name also satisfies the selection criteria (for + example, it is subscribed and the "SUBSCRIBED" selection option + has been specified). + + b. "RECURSIVEMATCH" has been specified, and the mailbox name has at + least one descendant mailbox name that does not match the LIST + pattern and does match the selection criteria. + + In practice, this means that the "\NonExistent" attribute is usually + returned with one or more of "\Subscribed", "\Remote", + "\HasChildren", or the CHILDINFO extended data item (see their + description below). + + + +Leiba & Melnikov Standards Track [Page 6] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" + attribute MUST be supported and MUST be accurately computed. + +3.1. Initial List of Selection Options + + The selection options defined in this specification are as follows: + + SUBSCRIBED - causes the LIST command to list subscribed names, + rather than the existing mailboxes. This will often be a subset + of the actual mailboxes. It's also possible for this list to + contain the names of mailboxes that don't exist. In any case, the + list MUST include exactly those mailbox names that match the + canonical list pattern and are subscribed to. This option is + intended to supplement the LSUB command. Of particular note are + the mailbox attributes as returned by this option, compared with + what is returned by LSUB. With the latter, the attributes + returned may not reflect the actual attribute status on the + mailbox name, and the \NoSelect attribute has a second special + meaning (it indicates that this mailbox is not, itself, + subscribed, but that it has descendant mailboxes that are). With + the SUBSCRIBED selection option described here, the attributes are + accurate and complete, and have no special meanings. "LSUB" and + "LIST (SUBSCRIBED)" are, thus, not the same thing, and some + servers must do significant extra work to respond to "LIST + (SUBSCRIBED)". Because of this, clients SHOULD continue to use + "LSUB" unless they specifically want the additional information + offered by "LIST (SUBSCRIBED)". + + This option defines a new mailbox attribute, "\Subscribed", that + indicates that a mailbox name is subscribed to. The "\Subscribed" + attribute MUST be supported and MUST be accurately computed when + the SUBSCRIBED selection option is specified. + + Note that the SUBSCRIBED selection option implies the SUBSCRIBED + return option (see below). + + REMOTE - causes the LIST command to show remote mailboxes as well as + local ones, as described in [MBRef]. This option is intended to + replace the RLIST command and, in conjunction with the SUBSCRIBED + selection option, the RLSUB command. + + This option defines a new mailbox attribute, "\Remote", that + indicates that a mailbox is a remote mailbox. The "\Remote" + attribute MUST be accurately computed when the REMOTE option is + specified. + + The REMOTE selection option has no interaction with other options. + Its effect is to tell the server to apply the other options, if + + + +Leiba & Melnikov Standards Track [Page 7] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + any, to remote mailboxes, in addition to local ones. In + particular, it has no interaction with RECURSIVEMATCH (see below). + A request for (REMOTE RECURSIVEMATCH) is invalid, because a + request for (RECURSIVEMATCH) is. A request for (REMOTE + RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes, + both local and remote. + + RECURSIVEMATCH - this option forces the server to return information + about parent mailboxes that don't match other selection options, + but have some submailboxes that do. Information about children is + returned in the CHILDINFO extended data item, as described in + Section 3.5. + + Note 1: In order for a parent mailbox to be returned, it still has + to match the canonical LIST pattern. + + Note 2: When returning the CHILDINFO extended data item, it + doesn't matter whether or not the submailbox matches the canonical + LIST pattern. See also example 9 in Section 5. + + The RECURSIVEMATCH option MUST NOT occur as the only selection + option (or only with REMOTE), as it only makes sense when other + selection options are also used. The server MUST return BAD + tagged response in such case. + + Note that even if the RECURSIVEMATCH option is specified, the + client MUST still be able to handle a case when a CHILDINFO + extended data item is returned and there are no submailboxes that + meet the selection criteria of the subsequent LIST command, as + they can be deleted/renamed after the LIST response was sent, but + before the client had a chance to access them. + +3.2. Initial List of Return Options + + The return options defined in this specification are as follows: + + SUBSCRIBED - causes the LIST command to return subscription state + for all matching mailbox names. The "\Subscribed" attribute MUST + be supported and MUST be accurately computed when the SUBSCRIBED + return option is specified. Further, all mailbox flags MUST be + accurately computed (this differs from the behavior of the LSUB + command). + + CHILDREN - requests mailbox child information as originally proposed + in [CMbox]. See Section 4, below, for details. This option MUST + be supported by all servers. + + + + + +Leiba & Melnikov Standards Track [Page 8] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + +3.3. General Principles for Returning LIST Responses + + This section outlines several principles that can be used by server + implementations of this document to decide whether a LIST response + should be returned, as well as how many responses and what kind of + information they may contain. + + 1. At most one LIST response should be returned for each mailbox + name that matches the canonical LIST pattern. Server + implementors must not assume that clients will be able to + assemble mailbox attributes and other information returned in + multiple LIST responses. + + 2. There are only two reasons for including a matching mailbox name + in the responses to the LIST command (note that the server is + allowed to return unsolicited responses at any time, and such + responses are not governed by this rule): + + A. The mailbox name also satisfies the selection criteria. + + B. The mailbox name doesn't satisfy the selection criteria, but + it has at least one descendant mailbox name that satisfies + the selection criteria and that doesn't match the canonical + LIST pattern. + + For more information on this case, see the CHILDINFO extended + data item described in Section 3.5. Note that the CHILDINFO + extended data item can only be returned when the + RECURSIVEMATCH selection option is specified. + + 3. Attributes returned in the same LIST response must be treated + additively. For example, the following response + + S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" + + means that the "Fruit/Peach" mailbox doesn't exist, but it is + subscribed. + +3.4. Additional Requirements on LIST-EXTENDED Clients + + All clients that support this extension MUST treat an attribute with + a stronger meaning as implying any attribute that can be inferred + from it. For example, the client must treat the presence of the + \NoInferiors attribute as if the \HasNoChildren attribute was also + sent by the server. + + + + + + +Leiba & Melnikov Standards Track [Page 9] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + The following table summarizes inference rules described in + Section 3. + + +--------------------+-------------------+ + | returned attribute | implied attribute | + +--------------------+-------------------+ + | \NoInferiors | \HasNoChildren | + | \NonExistent | \NoSelect | + +--------------------+-------------------+ + +3.5. CHILDINFO Extended Data Item + + The CHILDINFO extended data item MUST NOT be returned unless the + client has specified the RECURSIVEMATCH selection option. + + The CHILDINFO extended data item in a LIST response describes the + selection criteria that has caused it to be returned and indicates + that the mailbox has at least one descendant mailbox that matches the + selection criteria. + + The LSUB command indicates this condition by using the "\NoSelect" + attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since + "\NoSelect" retains its original meaning here. Further, the + CHILDINFO extended data item is more general, in that it can be used + with any extended set of selection criteria. + + 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 + solicited response from an unsolicited one, as well as to distinguish + among solicited responses caused by multiple pipelined LIST commands + that specify different criteria. + + Servers SHOULD ONLY return a non-matching mailbox name along with + CHILDINFO if at least one matching child is not also being returned. + That is, servers SHOULD suppress redundant CHILDINFO responses. + + Examples 8 and 10 in Section 5 demonstrate the difference between + present CHILDINFO extended data item and the "\HasChildren" + attribute. + + + + +Leiba & Melnikov Standards Track [Page 10] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + The following table summarizes interaction between the "\NonExistent" + attribute and CHILDINFO (the first column indicates whether the + parent mailbox exists): + + +--------+--------------+--------------------+----------------------+ + | exists | meets the | has a child that | returned | + | | selection | meets the | LIST-EXTENDED | + | | criteria | selection criteria | attributes and | + | | | | CHILDINFO | + +--------+--------------+--------------------+----------------------+ + | no | no | no | no LIST response | + | | | | returned | + | yes | no | no | no LIST response | + | | | | returned | + | no | yes | no | (\NonExistent | + | | | | <attr>) | + | yes | yes | no | (<attr>) | + | no | no | yes | (\NonExistent) + | + | | | | CHILDINFO | + | yes | no | yes | () + CHILDINFO | + | no | yes | yes | (\NonExistent | + | | | | <attr>) + CHILDINFO | + | yes | yes | yes | (<attr>) + CHILDINFO | + +--------+--------------+--------------------+----------------------+ + + where <attr> is one or more attributes that correspond to the + selection criteria; for example, for the SUBSCRIBED option the <attr> + is \Subscribed. + +4. The CHILDREN Return Option + + The CHILDREN return option implements the Child Mailbox Extension, + originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft + Corporation. Most of the information in this section is taken + directly from their original specification [CMbox]. The CHILDREN + return option is simply an indication that the client wants this + information; a server MAY provide it even if the option is not + specified. + + Many IMAP4 [IMAP4] clients present to the user a hierarchical view of + the mailboxes that a user has access to. Rather than initially + presenting to the user the entire mailbox hierarchy, it is often + preferable to show to the user a collapsed outline list of the + mailbox hierarchy (particularly if there is a large number of + mailboxes). The user can then expand the collapsed outline hierarchy + as needed. It is common to include within the collapsed hierarchy a + visual clue (such as a ''+'') to indicate that there are child + mailboxes under a particular mailbox. When the visual clue is + + + +Leiba & Melnikov Standards Track [Page 11] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + clicked, the hierarchy list is expanded to show the child mailboxes. + The CHILDREN return option provides a mechanism for a client to + efficiently determine whether a particular mailbox has children, + without issuing a LIST "" * or a LIST "" % for each mailbox name. + The CHILDREN return option defines two new attributes that MUST be + returned within a LIST response: \HasChildren and \HasNoChildren. + Although these attributes MAY be returned in response to any LIST + command, the CHILDREN return option is provided to indicate that the + client particularly wants this information. If the CHILDREN return + option is present, the server MUST return these attributes even if + their computation is expensive. + + \HasChildren + + The presence of this attribute indicates that the mailbox has child + mailboxes. A server SHOULD NOT set this attribute if there are + child mailboxes and the user does not have permission to access + any of them. In this case, \HasNoChildren SHOULD be used. In + many cases, however, a server may not be able to efficiently + compute whether a user has access to any child mailbox. Note + that even though the \HasChildren attribute for a mailbox must + be correct at the time of processing of the mailbox, a client + must be prepared to deal with a situation when a mailbox is + marked with the \HasChildren attribute, but no child mailbox + appears in the response to the LIST command. This might happen, + for example, due to children mailboxes being deleted or made + inaccessible to the user (using access control) by another + client before the server is able to list them. + + \HasNoChildren + + The presence of this attribute indicates that the mailbox has NO + child mailboxes that are accessible to the currently + authenticated user. + + It is an error for the server to return both a \HasChildren and a + \HasNoChildren attribute in the same LIST response. + + Note: the \HasNoChildren attribute should not be confused with the + IMAP4 [IMAP4] defined attribute \NoInferiors, which indicates that no + child mailboxes exist now and none can be created in the future. + + + + + + + + + + +Leiba & Melnikov Standards Track [Page 12] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + +5. Examples + + 1: The first example shows the complete local hierarchy that will + be used for the other examples. + + C: A01 LIST "" "*" + S: * LIST (\Marked \NoInferiors) "/" "inbox" + S: * LIST () "/" "Fruit" + S: * LIST () "/" "Fruit/Apple" + S: * LIST () "/" "Fruit/Banana" + S: * LIST () "/" "Tofu" + S: * LIST () "/" "Vegetable" + S: * LIST () "/" "Vegetable/Broccoli" + S: * LIST () "/" "Vegetable/Corn" + S: A01 OK done + + 2: In the next example, we will see the subscribed mailboxes. This + is similar to, but not equivalent with, <LSUB "" "*">. Note + that the mailbox called "Fruit/Peach" is subscribed to, but does + not actually exist (perhaps it was deleted while still + subscribed). The "Fruit" mailbox is not subscribed to, but it + has two subscribed children. The "Vegetable" mailbox is + subscribed and has two children; one of them is subscribed as + well. + + C: A02 LIST (SUBSCRIBED) "" "*" + S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" + S: * LIST (\Subscribed) "/" "Fruit/Banana" + S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" + S: * LIST (\Subscribed) "/" "Vegetable" + S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" + S: A02 OK done + + 3: The next example shows the use of the CHILDREN option. The + client, without having to list the second level of hierarchy, + now knows which of the top-level mailboxes have submailboxes + (children) and which do not. Note that it's not necessary for + the server to return the \HasNoChildren attribute for the inbox, + because the \NoInferiors attribute already implies that, and has + a stronger meaning. + + C: A03 LIST () "" "%" RETURN (CHILDREN) + S: * LIST (\Marked \NoInferiors) "/" "inbox" + S: * LIST (\HasChildren) "/" "Fruit" + S: * LIST (\HasNoChildren) "/" "Tofu" + S: * LIST (\HasChildren) "/" "Vegetable" + S: A03 OK done + + + + +Leiba & Melnikov Standards Track [Page 13] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + 4: In this example, we see more mailboxes that reside on another + server. This is similar to the command <RLIST "" "%">. + + C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) + S: * LIST (\Marked \NoInferiors) "/" "inbox" + S: * LIST (\HasChildren) "/" "Fruit" + S: * LIST (\HasNoChildren) "/" "Tofu" + S: * LIST (\HasChildren) "/" "Vegetable" + S: * LIST (\Remote) "/" "Bread" + S: * LIST (\HasChildren \Remote) "/" "Meat" + S: A04 OK done + + 5: The following example also requests the server to include + mailboxes that reside on another server. The server returns + information about all mailboxes that are subscribed. This is + similar to the command <RLSUB "" "*">. We also see the use of + two selection options. + + C: A05 LIST (REMOTE SUBSCRIBED) "" "*" + S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" + S: * LIST (\Subscribed) "/" "Fruit/Banana" + S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" + S: * LIST (\Subscribed) "/" "Vegetable" + S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" + S: * LIST (\Remote \Subscribed) "/" "Bread" + S: A05 OK done + + 6: The following example requests the server to include mailboxes + that reside on another server. The server is asked to return + subscription information for all returned mailboxes. This is + different from the example above. + + Note that the output of this command is not a superset of the + output in the previous example, as it doesn't include LIST + response for the non-existent "Fruit/Peach". + + C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED) + S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" + S: * LIST () "/" "Fruit" + S: * LIST () "/" "Fruit/Apple" + S: * LIST (\Subscribed) "/" "Fruit/Banana" + S: * LIST () "/" "Tofu" + S: * LIST (\Subscribed) "/" "Vegetable" + S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" + S: * LIST () "/" "Vegetable/Corn" + S: * LIST (\Remote \Subscribed) "/" "Bread" + S: * LIST (\Remote) "/" "Meat" + S: A06 OK done + + + +Leiba & Melnikov Standards Track [Page 14] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + 7: In the following example, the client has specified multiple + mailbox patterns. Note that this example does not use the + mailbox hierarchy used in the previous examples. + + C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") + S: * LIST () "/" "INBOX" + S: * LIST (\NoInferiors) "/" "Drafts" + S: * LIST () "/" "Sent/March2004" + S: * LIST (\Marked) "/" "Sent/December2003" + S: * LIST () "/" "Sent/August2004" + S: BBB OK done + + 8: The following example demonstrates the difference between the + \HasChildren attribute and the CHILDINFO extended data item. + + Let's assume there is the following hierarchy: + + C: C01 LIST "" "*" + S: * LIST (\Marked \NoInferiors) "/" "inbox" + S: * LIST () "/" "Foo" + S: * LIST () "/" "Foo/Bar" + S: * LIST () "/" "Foo/Baz" + S: * LIST () "/" "Moo" + S: C01 OK done + + If the client asks RETURN (CHILDREN), it will get this: + + C: CA3 LIST "" "%" RETURN (CHILDREN) + S: * LIST (\Marked \NoInferiors) "/" "inbox" + S: * LIST (\HasChildren) "/" "Foo" + S: * LIST (\HasNoChildren) "/" "Moo" + S: CA3 OK done + + A) Let's also assume that the mailbox "Foo/Baz" is the only + subscribed mailbox. Then we get this result: + + C: C02 LIST (SUBSCRIBED) "" "*" + S: * LIST (\Subscribed) "/" "Foo/Baz" + S: C02 OK done + + Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server will + return no mailboxes (as the mailboxes "Moo", "Foo", and "Inbox" are + NOT subscribed). However, if the client issues this: + + C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" + S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) + S: C04 OK done + + + + +Leiba & Melnikov Standards Track [Page 15] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + (i.e., the mailbox "Foo" is not subscribed, but it has a child that + is.) + + A1) If the mailbox "Foo" had also been subscribed, the last command + would return this: + + C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" + S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) + S: C04 OK done + + or even this: + + C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" + S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO" + ("SUBSCRIBED")) + S: C04 OK done + + A2) If we assume instead that the mailbox "Foo" is not part of the + original hierarchy and is not subscribed, the last command will give + this result: + + C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" + S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) + S: C04 OK done + + B) Now, let's assume that no mailbox is subscribed. In this case, + the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will return no + responses, as there are no subscribed children (even though "Foo" has + children). + + C) And finally, suppose that only the mailboxes "Foo" and "Moo" are + subscribed. In that case, we see this result: + + C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN) + S: * LIST (\HasChildren \Subscribed) "/" "Foo" + S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" + S: C04 OK done + + (which means that the mailbox "Foo" has children, but none of them is + subscribed). + + 9: The following example demonstrates that the CHILDINFO extended + data item is returned whether or not children mailboxes match + the canonical LIST pattern. + + + + + + + +Leiba & Melnikov Standards Track [Page 16] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + Let's assume there is the following hierarchy: + + C: D01 LIST "" "*" + S: * LIST (\Marked \NoInferiors) "/" "inbox" + S: * LIST () "/" "foo2" + S: * LIST () "/" "foo2/bar1" + S: * LIST () "/" "foo2/bar2" + S: * LIST () "/" "baz2" + S: * LIST () "/" "baz2/bar2" + S: * LIST () "/" "baz2/bar22" + S: * LIST () "/" "baz2/bar222" + S: * LIST () "/" "eps2" + S: * LIST () "/" "eps2/mamba" + S: * LIST () "/" "qux2/bar2" + S: D01 OK done + + And that the following mailboxes are subscribed: + + C: D02 LIST (SUBSCRIBED) "" "*" + S: * LIST (\Subscribed) "/" "foo2/bar1" + S: * LIST (\Subscribed) "/" "foo2/bar2" + S: * LIST (\Subscribed) "/" "baz2/bar2" + S: * LIST (\Subscribed) "/" "baz2/bar22" + S: * LIST (\Subscribed) "/" "baz2/bar222" + S: * LIST (\Subscribed) "/" "eps2" + S: * LIST (\Subscribed) "/" "eps2/mamba" + S: * LIST (\Subscribed) "/" "qux2/bar2" + S: D02 OK done + + The client issues the following command first: + + C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" + S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) + S: * LIST (\Subscribed) "/" "foo2/bar2" + S: * LIST (\Subscribed) "/" "baz2/bar2" + S: * LIST (\Subscribed) "/" "baz2/bar22" + S: * LIST (\Subscribed) "/" "baz2/bar222" + S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) + S: * LIST (\Subscribed) "/" "qux2/bar2" + S: D03 OK done + + and the server may also include (but this would violate a SHOULD NOT + in Section 3.5, because CHILDINFO is redundant) + + S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) + S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED")) + + + + + +Leiba & Melnikov Standards Track [Page 17] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + The CHILDINFO extended data item is returned for mailboxes "foo2", + "baz2", and "eps2", because all of them have subscribed children, + even though for the mailbox "foo2" only one of the two subscribed + children matches the pattern, for the mailbox "baz2" all the + subscribed children match the pattern, and for the mailbox "eps2" + none of the subscribed children matches the pattern. + + Note that if the client issues + + C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*" + S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) + S: * LIST (\Subscribed) "/" "foo2/bar1" + S: * LIST (\Subscribed) "/" "foo2/bar2" + S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) + S: * LIST (\Subscribed) "/" "baz2/bar2" + S: * LIST (\Subscribed) "/" "baz2/bar22" + S: * LIST (\Subscribed) "/" "baz2/bar222" + S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) + S: * LIST (\Subscribed) "/" "eps2/mamba" + S: * LIST (\Subscribed) "/" "qux2/bar2" + S: D03 OK done + + The LIST responses for mailboxes "foo2", "baz2", and "eps2" still + have the CHILDINFO extended data item, even though this information + is redundant and the client can determine it by itself. + + 10: The following example shows usage of multiple mailbox patterns. + It also demonstrates that the presence of the CHILDINFO extended + data item doesn't necessarily imply \HasChildren. + + C: a1 LIST "" ("foo" "foo/*") + S: * LIST () "/" foo + S: a1 OK done + + C: a2 LIST (SUBSCRIBED) "" "foo/*" + S: * LIST (\Subscribed \NonExistent) "/" foo/bar + S: a2 OK done + + C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN) + S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED")) + S: a3 OK done + + 11: The following example shows how a server that supports missing + mailbox hierarchy elements can signal to a client that didn't + specify the RECURSIVEMATCH selection option that there is a + child mailbox that matches the selection criteria. + + + + + +Leiba & Melnikov Standards Track [Page 18] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + 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 + + C: a3.1 LIST "" (% music/rock) + S: * LIST () "/" music/rock + S: a3.1 OK done + + Because "music/rock" is the only mailbox under "music", there's no + need for the server to also return "music". However clients must + handle both cases. + +6. Formal Syntax + + The following syntax specification uses the Augmented Backus-Naur + Form (ABNF) as described in [ABNF]. Terms not defined here are taken + from [IMAP4]. In particular, note that the version of "mailbox-list" + below, which defines the payload of the LIST response, updates the + version defined in the IMAP specification. It is pointed to by + "mailbox-data", which is defined in [IMAP4]. + + "vendor-token" is defined in [ACAP]. Note that this normative + reference to ACAP will be an issue in moving this spec forward, since + it introduces a dependency on ACAP. The definitions of + "vendor-token" and of the IANA registry must eventually go somewhere + else, in a document that can be moved forward on the standards track + independently of ACAP. + + + + + + + + + + + + + + +Leiba & Melnikov Standards Track [Page 19] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + childinfo-extended-item = "CHILDINFO" SP "(" + list-select-base-opt-quoted + *(SP list-select-base-opt-quoted) ")" + ; Extended data item (mbox-list-extended-item) + ; returned when the RECURSIVEMATCH + ; selection option is specified. + ; Note 1: the CHILDINFO tag can be returned + ; with and without surrounding quotes, as per + ; mbox-list-extended-item-tag production. + ; Note 2: The selection options are always returned + ; quoted, unlike their specification in + ; the extended LIST command. + + child-mbox-flag = "\HasChildren" / "\HasNoChildren" + ; attributes for CHILDREN return option, at most one + ; possible per LIST response + + eitem-standard-tag = atom + ; a tag for extended list data defined in a Standard + ; Track or Experimental RFC. + + eitem-vendor-tag = vendor-token "-" atom + ; a vendor-specific tag for extended list data + + list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat + [SP list-return-opts] + + list-return-opts = "RETURN" SP + "(" [return-option *(SP return-option)] ")" + ; list return options, e.g., CHILDREN + + list-select-base-opt = "SUBSCRIBED" / option-extension + ; options that can be used by themselves + + list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE + + list-select-independent-opt = "REMOTE" / option-extension + ; options that do not syntactically interact with + ; other options + + list-select-mod-opt = "RECURSIVEMATCH" / option-extension + ; options that require a list-select-base-opt + ; to also be present + + list-select-opt = list-select-base-opt / list-select-independent-opt + / list-select-mod-opt + ; An option registration template is described in + ; Section 9.3 of this document. + + + +Leiba & Melnikov Standards Track [Page 20] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + list-select-opts = "(" [ + (*(list-select-opt SP) list-select-base-opt + *(SP list-select-opt)) + / (list-select-independent-opt + *(SP list-select-independent-opt)) + ] ")" + ; Any number of options may be in any order. + ; If a list-select-mod-opt appears, then a + ; list-select-base-opt must also appear. + ; This allows these: + ; () + ; (REMOTE) + ; (SUBSCRIBED) + ; (SUBSCRIBED REMOTE) + ; (SUBSCRIBED RECURSIVEMATCH) + ; (SUBSCRIBED REMOTE RECURSIVEMATCH) + ; But does NOT allow these: + ; (RECURSIVEMATCH) + ; (REMOTE RECURSIVEMATCH) + + mailbox-list = "(" [mbx-list-flags] ")" SP + (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox + [SP mbox-list-extended] + ; This is the list information pointed to by the ABNF + ; item "mailbox-data", which is defined in [IMAP4] + + mbox-list-extended = "(" [mbox-list-extended-item + *(SP mbox-list-extended-item)] ")" + + mbox-list-extended-item = mbox-list-extended-item-tag SP + tagged-ext-val + + mbox-list-extended-item-tag = astring + ; The content MUST conform to either "eitem-vendor-tag" + ; or "eitem-standard-tag" ABNF productions. + ; A tag registration template is described in this + ; document in Section 9.5. + + mbx-list-oflag =/ child-mbox-flag / "\Subscribed" / "\Remote" + + mbx-list-sflag =/ "\NonExistent" + + mbox-or-pat = list-mailbox / patterns + + option-extension = (option-standard-tag / option-vendor-tag) + [SP option-value] + + + + + +Leiba & Melnikov Standards Track [Page 21] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + option-standard-tag = atom + ; an option defined in a Standards Track or + ; Experimental RFC + + option-val-comp = astring / + option-val-comp *(SP option-val-comp) / + "(" option-val-comp ")" + + option-value = "(" option-val-comp ")" + + option-vendor-tag = vendor-token "-" atom + ; a vendor-specific option, non-standard + + patterns = "(" list-mailbox *(SP list-mailbox) ")" + + return-option = "SUBSCRIBED" / "CHILDREN" / option-extension + + tagged-ext-comp = astring / + tagged-ext-comp *(SP tagged-ext-comp) / + "(" tagged-ext-comp ")" + ; Extensions that follow this general + ; syntax should use nstring instead of + ; astring when appropriate in the context + ; of the extension. + ; Note that a message set or a "number" + ; can always be represented as an "atom". + ; A URL should be represented as + ; a "quoted" string. + + tagged-ext-simple = sequence-set / number + + tagged-ext-val = tagged-ext-simple / + "(" [tagged-ext-comp] ")" + +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. + + + + + + + +Leiba & Melnikov Standards Track [Page 22] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + +8. Security Considerations + + This document describes syntactic changes to the specification of the + IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST + command has the same security considerations as those commands. They + are described in [IMAP4] and [MBRef]. + + The Child Mailbox Extension provides a client a more efficient means + of determining whether a particular mailbox has children. If a + mailbox has children, but the currently authenticated user does not + have access to any of them, the server SHOULD respond with a + \HasNoChildren attribute. In many cases, however, a server may not + be able to efficiently compute whether a user has access to any child + mailbox. If such a server responds with a \HasChildren attribute, + when in fact the currently authenticated user does not have access to + any child mailboxes, potentially more information is conveyed about + the mailbox than intended. In most situations, this will not be a + security concern, because if information regarding whether a mailbox + has children is considered sensitive, a user would not be granted + access to that mailbox in the first place. + + The CHILDINFO extended data item has the same security considerations + as the \HasChildren attribute described above. + +9. IANA Considerations + +9.1. Guidelines for IANA + + IANA has created two new registries for LIST-EXTENDED options and + LIST-EXTENDED response data. The templates and the initial + registrations are detailed below. + +9.2. Registration Procedure and Change Control + + Registration of a LIST-EXTENDED option is done by filling in the + template in Section 9.3 and sending it via electronic mail to + iana@iana.org. Registration of a LIST-EXTENDED extended data item is + done by filling in the template in Section 9.5 and sending it via + electronic mail to iana@iana.org. IANA has the right to reject + obviously bogus registrations, but will perform no review of claims + made in the registration form. + + A LIST-EXTENDED option/extended data item name that starts with "V-" + is reserved for vendor-specific options/extended data items. All + options, whether they are vendor specific or global, should be + registered with IANA. If a LIST-EXTENDED extended data item is + returned as a result of requesting a particular LIST-EXTENDED option, + + + + +Leiba & Melnikov Standards Track [Page 23] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + the name of the option SHOULD be used as the name of the + LIST-EXTENDED extended data item. + + Each vendor-specific option/extended data item MUST start with its + vendor-token ("vendor prefix"). The vendor-token MUST be registered + with IANA, using the [ACAP] vendor subtree registry. + + Standard LIST-EXTENDED option/extended data item names are case + insensitive. If the vendor prefix is omitted from a vendor-specific + LIST-EXTENDED option/extended data item name, the rest is case + insensitive. The vendor prefix itself is not case sensitive, as it + might contain non-ASCII characters. While the registration + procedures do not require it, authors of + LIST-EXTENDED options/extended data items are encouraged to seek + community review and comment whenever that is feasible. Authors may + seek community review by posting a specification of their proposed + mechanism as an + Internet-Draft. LIST-EXTENDED option/extended data items intended + for widespread use should be standardized through the normal IETF + process, when appropriate. + + Comments on registered LIST-EXTENDED options/extended response data + should first be sent to the "owner" of the mechanism and/or to the + IMAPEXT WG mailing list. Submitters of comments may, after a + reasonable attempt to contact the owner, request IANA to attach their + comment to the registration itself. If IANA approves of this, the + comment will be made accessible in conjunction with the registration + LIST-EXTENDED options/extended response data itself. + + Once a LIST-EXTENDED registration has been published by IANA, the + author may request a change to its definition. The change request + follows the same procedure as the registration request. + + The owner of a LIST-EXTENDED registration may pass responsibility for + the registered option/extended data item to another person or agency + by informing IANA; this can be done without discussion or review. + + The IESG may reassign responsibility for a LIST-EXTENDED + option/extended data item. The most common case of this will be to + enable changes to be made to mechanisms where the author of the + registration has died, has moved out of contact, or is otherwise + unable to make changes that are important to the community. + + LIST-EXTENDED registrations may not be deleted; mechanisms that are + no longer believed appropriate for use can be declared OBSOLETE by a + change to their "intended use" field. Such LIST-EXTENDED + options/extended data items will be clearly marked in the lists + published by IANA. + + + +Leiba & Melnikov Standards Track [Page 24] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + The IESG is considered to be the owner of all LIST-EXTENDED + options/extended data items that are on the IETF standards track. + +9.3. Registration Template for LIST-EXTENDED Options + + To: iana@iana.org + Subject: Registration of LIST-EXTENDED option X + + LIST-EXTENDED option name: + + LIST-EXTENDED option type: (One of SELECTION or RETURN) + + Implied return options(s), if the option type is SELECTION: (zero or + more) + + LIST-EXTENDED option description: + + Published specification (optional, recommended): + + Security considerations: + + Intended usage: + (One of COMMON, LIMITED USE, or OBSOLETE) + + Person and email address to contact for further information: + + Owner/Change controller: + + (Any other information that the author deems interesting may be added + below this line.) + +9.4. Initial LIST-EXTENDED Option Registrations + + The LIST-EXTENDED option registry has been populated with the + following entries: + + 1. To: iana@iana.org + Subject: Registration of LIST-EXTENDED option SUBSCRIBED + + LIST-EXTENDED option name: SUBSCRIBED + + LIST-EXTENDED option type: SELECTION + + Implied return options(s): SUBSCRIBED + + LIST-EXTENDED option description: Causes the LIST command to list + subscribed mailboxes, rather than the actual mailboxes. + + + + +Leiba & Melnikov Standards Track [Page 25] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + Published specification: RFC 5258, Section 3. + + Security considerations: RFC 5258, Section 8. + + Intended usage: COMMON + + Person and email address to contact for further information: + Alexey Melnikov <Alexey.Melnikov@isode.com> + + Owner/Change controller: iesg@ietf.org + + 2. To: iana@iana.org + Subject: Registration of LIST-EXTENDED option REMOTE + + LIST-EXTENDED option name: REMOTE + + LIST-EXTENDED option type: SELECTION + + Implied return options(s): (none) + + LIST-EXTENDED option description: Causes the LIST command to + return remote mailboxes as well as local ones, as described in + RFC 2193. + + Published specification: RFC 5258, Section 3. + + Security considerations: RFC 5258, Section 8. + + Intended usage: COMMON + + Person and email address to contact for further information: + Alexey Melnikov <Alexey.Melnikov@isode.com> + + Owner/Change controller: iesg@ietf.org + + 3. To: iana@iana.org + Subject: Registration of LIST-EXTENDED option SUBSCRIBED + + LIST-EXTENDED option name: SUBSCRIBED + + LIST-EXTENDED option type: RETURN + + LIST-EXTENDED option description: Causes the LIST command to + return subscription state. + + Published specification: RFC 5258, Section 3. + + Security considerations: RFC 5258, Section 8. + + + +Leiba & Melnikov Standards Track [Page 26] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + Intended usage: COMMON + + Person and email address to contact for further information: + Alexey Melnikov <Alexey.Melnikov@isode.com> + + Owner/Change controller: iesg@ietf.org + + 4. To: iana@iana.org + Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH + + LIST-EXTENDED option name: RECURSIVEMATCH + + LIST-EXTENDED option type: SELECTION + + Implied return options(s): (none) + + LIST-EXTENDED option description: Requests that CHILDINFO + extended data item (childinfo-extended-item) is to be returned. + + Published specification: RFC 5258, Section 3. + + Security considerations: RFC 5258, Section 8. + + Intended usage: COMMON + + Person and email address to contact for further information: + Alexey Melnikov <Alexey.Melnikov@isode.com> + + Owner/Change controller: iesg@ietf.org + + 5. To: iana@iana.org + Subject: Registration of LIST-EXTENDED option CHILDREN + + LIST-EXTENDED option name: CHILDREN + + LIST-EXTENDED option type: RETURN + + LIST-EXTENDED option description: Requests mailbox child + information. + + Published specification: RFC 5258, Section 3 and Section 4. + + Security considerations: RFC 5258, Section 8. + + Intended usage: COMMON + + Person and email address to contact for further information: + Alexey Melnikov <Alexey.Melnikov@isode.com> + + + +Leiba & Melnikov Standards Track [Page 27] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + Owner/Change controller: iesg@ietf.org + +9.5. Registration Template for LIST-EXTENDED Extended Data Item + + To: iana@iana.org + Subject: Registration of X LIST-EXTENDED extended data item + + LIST-EXTENDED extended data item tag: + + LIST-EXTENDED extended data item description: + + Which LIST-EXTENDED option(s) (and their types) causes this extended + data item to be returned (if any): + + Published specification (optional, recommended): + + Security considerations: + + Intended usage: + (One of COMMON, LIMITED USE, or OBSOLETE) + + Person and email address to contact for further information: + + Owner/Change controller: + + (Any other information that the author deems interesting may be added + below this line.) + +9.6. Initial LIST-EXTENDED Extended Data Item Registrations + + The LIST-EXTENDED extended data item registry has been populated with + the following entries: + + 1. To: iana@iana.org + Subject: Registration of CHILDINFO LIST-EXTENDED extended data + item + + LIST-EXTENDED extended data item tag: CHILDINFO + + LIST-EXTENDED extended data item description: The CHILDINFO + extended data item describes the selection criteria that has + caused it to be returned and indicates that the mailbox has one + or more child mailboxes that match the selection criteria. + + Which LIST-EXTENDED option(s) (and their types) causes this + extended data item to be returned (if any): RECURSIVEMATCH + selection option + + + + +Leiba & Melnikov Standards Track [Page 28] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + + Published specification: RFC 5258, Section 3.5. + + Security considerations: RFC 5258, Section 8. + + Intended usage: COMMON + + Person and email address to contact for further information: + Alexey Melnikov <Alexey.Melnikov@isode.com> + + Owner/Change controller: iesg@ietf.org + +10. Acknowledgements + + Mike Gahrns and Raymond Cheng of Microsoft Corporation originally + devised the Child Mailbox Extension and proposed it in 1997; the + idea, as well as most of the text in Section 4, is theirs. + + This document is the result of discussions on the IMAP4 and IMAPEXT + mailing lists and is meant to reflect consensus of those groups. In + particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo + Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt + Gulbrandsen, Larry Greenfield, Dave Cridland, and Pete Maclean were + active participants in those discussions or made suggestions to this + document. + +11. References + +11.1. Normative References + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration + Access Protocol", RFC 2244, November 1997. + + [I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet + Message Access Protocol Internationalization", RFC 5255, + June 2008. + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 3501, March 2003. + + [Kwds] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, + September 1997. + + + + +Leiba & Melnikov Standards Track [Page 29] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + +11.2. Informative References + + [CMbox] Gahrns, M. and R. Cheng, "The Internet Message Action + Protocol (IMAP4) Child Mailbox Extension", RFC 3348, + July 2002. + +Authors' Addresses + + Barry Leiba + IBM T.J. Watson Research Center + 19 Skyline Drive + Hawthorne, NY 10532 + US + + Phone: +1 914 784 7941 + EMail: leiba@watson.ibm.com + + + Alexey Melnikov + Isode Limited + 5 Castle Business Village + 36 Station Road + Hampton, Middlesex TW12 2BX + UK + + EMail: Alexey.Melnikov@isode.com + URI: http://www.melnikov.ca/ + + + + + + + + + + + + + + + + + + + + + + + + +Leiba & Melnikov Standards Track [Page 30] + +RFC 5258 IMAP4 LIST Command Extensions June 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Leiba & Melnikov Standards Track [Page 31] + |