draft-ietf-imapext-list-extensions-11.txt   draft-ietf-imapext-list-extensions-12.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
A. Melnikov Updates: 2193 (if approved) A. Melnikov
Isode Limited Obsoletes: 3348 (if approved) Isode Limited
Expires August 2005 February 2005 Expires: September 2, 2005 March 2005
IMAP4 LIST Command Extensions IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-11.txt draft-ietf-imapext-list-extensions-12
Status of this Document Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, or of Section 3 of RFC 3667. By submitting this Internet-Draft, each
will be disclosed, and any of which I become aware will be disclosed, author represents that any applicable patent or other IPR claims of
in accordance with RFC 3668. which he or she is aware have been or will be disclosed, and any of
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-Drafts. Internet-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.
Copyright Notice
Copyright (C) The Internet Society (2005).
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.
Note
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 documents obsoletes RFC 3348 and updates RFC 2193. This document obsoletes RFC 3348 and updates RFC 2193.
Abstract Table of Contents
IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 1. Conventions used in this document . . . . . . . . . . . . . . 4
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list 2. Introduction and overview . . . . . . . . . . . . . . . . . . 5
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible. 3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 6
If we've needed the extensions to work together, we've had to add a 3.1 General principles for returning LIST responses . . . . . . . 10
set of commands to mix the different options, the set increasing in 3.2 Additional requirements on LISTEXT clients . . . . . . . . . . 11
size with each new extension. This document describes an extension 3.3 CHILDINFO extended data item . . . . . . . . . . . . . . . . . 11
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the 4. The CHILDREN return Option . . . . . . . . . . . . . . . . . . 13
exponential increase in specialized list commands.
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8.1 Guidelines for IANA . . . . . . . . . . . . . . . . . . . . . 26
8.2 Registration procedure and Change control . . . . . . . . . . 26
8.3 Registration template for LISTEXT options . . . . . . . . . . 27
8.4 Initial LISTEXT option registrations . . . . . . . . . . . . . 28
8.5 Registration template for LISTEXT extended data item . . . . . 30
8.6 Initial LISTEXT extended data item registrations . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. Normative References . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 34
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 [Keywords]. 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. 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 editorial comments/questions are enclosed like this.>> Other terms are introduced where they are referenced for the first
time.
2. Introduction and overview 2. Introduction and overview
The LIST command is extended by amending the syntax to allow The LIST command is extended by amending the syntax to allow options
options and multiple patterns to be specified. The list of options and multiple patterns to be specified. The list of options replaces
replaces the several commands that are currently used to mix and the several commands that are currently used to mix and match the
match the information requested. The new syntax is backward- information requested. The new syntax is backward- compatible, with
compatible, with no ambiguity: the new syntax is being used if one of no ambiguity: the new syntax is being used if one of the following
the following conditions is true: conditions is true:
1). if the first word after the command name begins with a 1. if the first word after the command name begins with a
parenthesis ("LIST selection options"); parenthesis ("LIST selection options");
2). if the second word after the command name begins with a 2. if the second word after the command name begins with a
parenthesis ("multiple mailbox patterns"); parenthesis ("multiple mailbox patterns");
3). if the LIST command has more than 2 parameters 3. if the LIST command has more than 2 parameters ("LIST return
("LIST return options"); options");
Otherwise the original syntax is used. Otherwise the original syntax is used.
By adding options to the LIST command, we are announcing the intent By adding options to the LIST command, we are announcing the intent
to phase out and eventually to deprecate the RLIST and RLSUB commands to phase out and eventually to deprecate the RLIST and RLSUB commands
described in [MboxRefer]. We are also defining the mechanism to described in [MBRef]. We are also defining the mechanism to request
request extended mailbox information, such as is described in the extended mailbox information, such as is described in the "Child
"Child Mailbox Extension" [ChildMbox]. The base Mailbox Extension" [CMbox]. The base LSUB command is not deprecated
LSUB command is not deprecated by this extension; rather, this by this extension; rather, this extension adds a way to obtain
extension adds a way to obtain subscription information with more subscription information with more options, with those server
options, with those server implementations that support it. Clients implementations that support it. Clients that simply need a list of
that simply need a list of subscribed mailboxes, as provided by the subscribed mailboxes, as provided by the LSUB command, SHOULD
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 "X-DRAFT-W12-LISTEXT" <<Note to the RFC Editor: capability string "LISTEXT". The X-DRAFT-W12-LISTEXT extension makes
the capability name will change upon publication as an RFC>>. the following changes to the IMAP4 protocol, which are described in
The X-DRAFT-W12-LISTEXT extension makes the more detail in Section 3 and Section 4:
following changes to the IMAP4 protocol, which are described in
more details in sections 3 and 4 of this document:
a. defines new syntax for LIST command options. a. defines new syntax for LIST command options.
b. extend 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 multiple This extension updates the syntax of the LIST command to allow for
mailbox patterns to be specified, if they are enclosed in parantheses. multiple mailbox patterns to be specified, if they are enclosed in
A mailbox name match a list of mailbox patterns if it matches at least parantheses. A mailbox name match a list of mailbox patterns if it
one mailbox pattern. Note that if a mailbox name matches multiple mailbox matches at least one mailbox pattern. Note that if a mailbox name
patterns from the list, the server should return only a single LIST matches multiple mailbox patterns from the list, the server should
response. return only a single LIST response.
Note that the non-extended LIST command is required to treat an empty Note that the non-extended LIST command is required to treat an empty
("" string) mailbox name argument as a special request to return the ("" string) mailbox name argument as a special request to return the
hierarchy delimiter and the root name of the name given in the hierarchy delimiter and the root name of the name given in the
reference parameter (as per [IMAP4]). However ANY extended LIST command reference parameter (as per [IMAP4]). However ANY extended LIST
(extended in any of 3 ways specified in section 2, or any combination of command (extended in any of 3 ways specified in Section 2, or any
therof) MUST NOT treat the empty mailbox name as such special request combination of therof) MUST NOT treat the empty mailbox name as such
and any regular processing described in this document applies. special request and any regular processing described in this document
In particular, if an extended LIST command has multiple mailbox names applies. In particular, if an extended LIST command has multiple
and one (or more) of them is the empty string, the empty string MUST be mailbox names and one (or more) of them is the empty string, the
ignored for the purpose of matching. empty string MUST be ignored for the purpose of matching.
Some servers might restrict which patterns are allowed in a LIST command. Some servers might restrict which patterns are allowed in a LIST
If a server doesn't accept a particular pattern, it MUST silently ignore command. If a server doesn't accept a particular pattern, it MUST
it. silently ignore it.
The LIST command syntax is also extended in two additional ways: by adding a The LIST command syntax is also extended in two additional ways: by
parenthesized list of command options between the command name and the adding a parenthesized list of command options between the command
reference name (LIST selection options) and an optional list of options at name and the reference name (LIST selection options) and an optional
the end that control what kind of information should be returned (LIST return list of options at the end that control what kind of information
options). See the formal syntax in section 6 for specific details. 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 A LIST selection option tells the server which mailbox names should
selected by the LIST operation. be selected by the LIST operation. The server should return
The server should return information about all mailbox names that match any information about all mailbox names that match any of the "canonical
of the "canonical LIST pattern" (as described above) and satisfy additional LIST pattern" (as described above) and satisfy additional selection
selection criteria (if any) specified by the LIST selection options. Let's criteria (if any) specified by the LIST selection options. Let's
call any such mailbox name a "matched mailbox name". call any such mailbox name a "matched mailbox name". When multiple
When multiple selection options are specified, the server MUST return selection options are specified, the server MUST return information
information about mailbox names that satisfy every selection option, unless about mailbox names that satisfy every selection option, unless a
a description of a particular specified option prescribes special rules. description of a particular specified option prescribes special
An example of an option prescribing special rules is the RECURSIVEMATCH rules. An example of an option prescribing special rules is the
selection option described later in this section. RECURSIVEMATCH selection option described later in this section. We
We will use the term "selection criteria" when referring collectively to all will use the term "selection criteria" when referring collectively to
selection options specified in a LIST command. all selection options specified in a LIST command.
A LIST return option controls which information is returned for each matched A LIST return option controls which information is returned for each
mailbox name. Note that return options MUST NOT cause the server to report matched mailbox name. Note that return options MUST NOT cause the
information about additional mailbox names. If the client has not specified server to report information about additional mailbox names. If the
any return option, only information about attributes should be returned by client has not specified any return option, only information about
the server. (Of course the server is allowed to include any other information attributes should be returned by the server. (Of course the server
at will) is allowed to include any other information at will.)
Both selection and return command options will be defined in this document Both selection and return command options will be defined in this
and in approved extension documents; each option will be enabled by a document and in approved extension documents; each option will be
capability string (one capability may enable multiple options), and a client enabled by a capability string (one capability may enable multiple
MUST NOT send an option for which the server has not advertised support. options), and a client MUST NOT send an option for which the server
A server MUST respond to options it does not recognize with a BAD response. has not advertised support. A server MUST respond to options it does
The client SHOULD NOT specify any option more than once, however if the not recognize with a BAD response. The client SHOULD NOT specify any
client does this, the server MUST act as if it received the option only once. option more than once, however if the client does this, the server
The order in which options are specified by the client is not significant. MUST act as if it received the option only once. The order in which
options are specified by the client is not significant.
<<Each option (except for RECURSIVEMATCH) should have a corresponding In general, each selection option except for RECURSIVEMATCH will have
mailbox attribute?>> 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 "X-DRAFT-W12-LISTEXT" This extension is identified by the capability string "LISTEXT", and
<<Note to the RFC editor: please update upon publication as above>>, and
support for it is a prerequisite for any future extensions that support for it is a prerequisite for any future extensions that
require specialized forms of the LIST command. Such extensions MUST require specialized forms of the LIST command. Such extensions MUST
refer to this document and MUST add their function through command refer to this document and MUST add their function through command
options as described herein. options as described herein. Note that extensions that don't require
Note that extensions that don't require support for an extended LIST support for an extended LIST command, but use extended LIST responses
command, but use extended LIST responses (see below), don't need to advertise (see below), don't need to advertise the "LISTEXT" capability string.
the "X-DRAFT-W12-LISTEXT" capability string. <<Note to the RFC Editor: fix
upon publication as above>>
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 tagged a series of extended fields at the end, a parenthesized list of
data (also referred to as "extended data item"). The first element of tagged data (also referred to as "extended data item"). The first
an extended field is a tag, which identifies type of the data. Tags element of an extended field is a tag, which identifies type of the
MUST be registered with IANA, as described in section 8.5 of this data. Tags MUST be registered with IANA, as described in Section 8.5
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 text")) ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more
text"))
See the formal grammar, below, for the full syntactic details. See the formal grammar, below, for the full syntactic details. The
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 by expressed its ability to support extended LIST responses, for example
using an extended LIST command. by using an extended LIST command. The server MAY return data in the
The server MAY return data in the extended fields that was not solicited extended fields that was not solicited by the client. The client
by the client. The client MUST ignore all extended fields it doesn't MUST ignore all extended fields it doesn't recognize.
recognize.
The X-DRAFT-W12-LISTEXT <<Note to the RFC Editor: fix upon publication>> The LISTEXT capability also defines several new mailbox attributes.
capability also defines several new mailbox attributes.
The "\NonExistent" attribute indicates that a mailbox does not actually The "\NonExistent" attribute indicates that a mailbox does not
exist. Note that this attribute is not meaningful by itself, as mailboxes actually exist. Note that this attribute is not meaningful by
that match the canonical LIST pattern but don't exist must not be returned itself, as mailboxes that match the canonical LIST pattern but don't
unless one of the two conditions listed below is also satisfied: exist must not be returned unless one of the two conditions listed
below is also satisfied:
a) the mailbox also satisfies the selection criteria a. the mailbox also satisfies the selection criteria (for example,
its name is subscribed and the "SUBSCRIBED" selection option has
been specified)
b) the mailbox has at least one child mailbox that satisfies the selection b. "RECURSIVEMATCH" has been specified, and the mailbox has at least
criteria<<, but doesn't match the canonical LIST pattern.>> one child mailbox that matches the LIST pattern and selection
criteria.
In practice this means that the "\NonExistent" attribute is usually returned In practice this means that the "\NonExistent" attribute is usually
with one or more of "\Subscribed", "\Remote" or the CHILDINFO extended data returned with one or more of "\Subscribed", "\Remote" or the
item (see their description below). CHILDINFO extended data item (see their description below).
The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent"
attribute MUST be supported and MUST be accurately computed. attribute MUST be supported and MUST be accurately computed.
The selection options defined in this specification are The selection options defined in this specification are
SUBSCRIBED - causes the LIST command to list subscribed SUBSCRIBED - causes the LIST command to list subscribed names, rather
names, rather than the existing mailboxes. This will often than the existing mailboxes. This will often be a subset of the
be a subset of the actual mailboxes. It's also possible for actual mailboxes. It's also possible for this list to contain the
this list to contain the names of mailboxes that don't exist. names of mailboxes that don't exist. In any case, the list MUST
In any case, the list MUST include exactly those mailbox names include exactly those mailbox names that match the canonical list
that match the canonical list pattern and are subscribed to. This pattern and are subscribed to. This option is intended to
option is intended to supplement the LSUB command. supplement the LSUB command. Of particular note are the mailbox
Of particular note are the mailbox attributes as returned by this attributes as returned by this option, compared with what is
option, compared with what is returned by LSUB. With the returned by LSUB. With the latter, the attributes returned may
latter, the attributes returned may not reflect the actual attribute not reflect the actual attribute status on the mailbox name, and
status on the mailbox name, and the \NoSelect attribute has a special the \NoSelect attribute has a special meaning (it indicates that
meaning (it indicates that this mailbox is not, itself, this mailbox is not, itself, subscribed, but that it has child
subscribed, but that it has child mailboxes that are). With mailboxes that are). With the SUBSCRIBED selection option
the SUBSCRIBED selection option described here, the attributes are described here, the attributes are accurate, complete, and have no
accurate, complete, and have no special meanings. special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, thus, not
"LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, the same thing, and some servers must do significant extra work to
and some servers must do significant extra work to respond to respond to "LIST (SUBSCRIBED)". Because of this, clients SHOULD
"LIST (SUBSCRIBED)". Because of this, clients SHOULD continue continue to use "LSUB" unless they specifically want the
to use "LSUB" unless they specifically want the additional additional information offered by "LIST (SUBSCRIBED)".
information offered by "LIST (SUBSCRIBED)".
This option defines a new mailbox attribute, "\Subscribed", that This option defines a new mailbox attribute, "\Subscribed", that
indicates that a mailbox name is subscribed to. The "\Subscribed" indicates that a mailbox name is subscribed to. The "\Subscribed"
attribute MUST be supported and MUST be accurately computed attribute MUST be supported and MUST be accurately computed when
when the SUBSCRIBED selection option is specified. the SUBSCRIBED selection option is specified.
Note that the SUBSCRIBED selection option implies the SUBSCRIBED Note that the SUBSCRIBED selection option implies the SUBSCRIBED
return option (see below). return option (see below).
REMOTE - causes the LIST command to show remote mailboxes as REMOTE - causes the LIST command to show remote mailboxes as well as
well as local ones, as described in [MboxRefer]. This option local ones, as described in [MBRef]. This option is intended to
is intended to replace the RLIST command and, in conjunction replace the RLIST command and, in conjunction with the SUBSCRIBED
with the SUBSCRIBED selection option, the RLSUB command. selection option, the RLSUB command.
This option defines a new mailbox attribute, "\Remote", that This option defines a new mailbox attribute, "\Remote", that
indicates that a mailbox is a remote mailbox. The "\Remote" indicates that a mailbox is a remote mailbox. The "\Remote"
attribute MUST be accurately computed when the REMOTE option is attribute MUST be accurately computed when the REMOTE option is
specified. specified.
Note that a server implementation that doesn't support Note that a server implementation that doesn't support any remote
any remote mailboxes is compliant with this specification mailboxes is compliant with this specification as long as it
as long as it accepts and ignores the REMOTE selection option. accepts and ignores the REMOTE selection option. Note that if the
Note that if the server choses to ignore the REMOTE selection server choses to ignore the REMOTE selection option, it still has
option, it still has to treat RECURSIVEMATCH REMOTE as a valid to treat RECURSIVEMATCH REMOTE as a valid combination of selection
combination of selection options (see also the description of options (see also the description of the RECURSIVEMATCH option
the RECURSIVEMATCH option below). below).
RECURSIVEMATCH - this option forces the server to return RECURSIVEMATCH - this option forces the server to return information
information about parent mailboxes that don't match other about parent mailboxes that don't match other selection options,
selection options, but have some submailboxes that do. but have some submailboxes that do. Information about children is
Information about children is returned in the CHILDINFO returned in the CHILDINFO extended data item, as described in
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 Note 1: In order for a parent mailbox to be returned, it still has
has to match the canonical LIST pattern. to match the canonical LIST pattern.
Note 2: When returning the CHILDINFO extended data item, Note 2: When returning the CHILDINFO extended data item, it
it doesn't matter if the submailbox matches doesn't matter if the submailbox matches the canonical LIST
the canonical LIST pattern or not. See also example 9 in pattern or not. See also example 9 in Section 5. [[anchor2: Is
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 case. also used. The server MUST return BAD tagged response in such
case.
Note that even if RECURSIVEMATCH option is specified, the client Note that even if RECURSIVEMATCH option is specified, the client
MUST still be able to handle a case when a CHILDINFO extended MUST still be able to handle a case when a CHILDINFO extended data
data item is returned and there are no submailboxes item is returned and there are no submailboxes that meet the
that meet the selection criteria of the given LIST command, selection criteria of the given LIST command, as they can be
as they can be deleted/renamed after the LIST response was sent, deleted/renamed after the LIST response was sent, but before the
but before the client had a chance to access them. client had a chance to access them.
The return options defined in this specification are The return options defined in this specification are
SUBSCRIBED - causes the LIST command to return subscription SUBSCRIBED - causes the LIST command to return subscription state for
state for all matching mailbox names. The "\Subscribed" all matching mailbox names. The "\Subscribed" attribute MUST be
attribute MUST be supported and MUST be accurately computed supported and MUST be accurately computed when the SUBSCRIBED
when the SUBSCRIBED return option is specified. return option is specified. Further, all mailbox flags MUST be
accurately computed (this differs from the behaviour of the LSUB
command).
CHILDREN - Requests mailbox child information as originally CHILDREN - Requests mailbox child information as originally proposed
proposed in [ChildMbox]. See section 4, below, for details. in [CMbox]. See Section 4, below, for details. This option MUST
This option MUST be accepted by all servers. <<Should the last be supported by all servers.
sentence be deleted?>>
3.1. General principles for returning LIST responses 3.1 General principles for returning LIST responses
This section outlines several principles that can be used by server This section outlines several principles that can be used by server
implementations of this document to decide if a LIST response should be implementations of this document to decide if a LIST response should
returned, as well as how many responses and what kind of information be returned, as well as how many responses and what kind of
they may contain. information they may contain.
1) Exactly one LIST response should be returned for each mailbox 1. Exactly one LIST response should be returned for each mailbox
name which matches the canonical LIST pattern. name which matches the canonical LIST pattern. Server
Server implementors must not assume that clients will be able to implementors must not assume that clients will be able to
assemble mailbox attributes and other information returned in multiple assemble mailbox attributes and other information returned in
LIST responses. multiple LIST responses.
2) There are only two reasons for including a matching mailbox name 2. There are only two reasons for including a matching mailbox name
in the responses to the LIST command (Note that the server is allowed in the responses to the LIST command (Note that the server is
to return unsolicited responses at any time. Such responses are not allowed to return unsolicited responses at any time. Such
governed by this rule): responses are not governed by this rule):
a) the mailbox name also satisfies the selection criteria; A. the mailbox name also satisfies the selection criteria;
b) the mailbox name doesn't satisfy the selection criteria, but B. the mailbox name doesn't satisfy the selection criteria, but
it has at least one 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 data For more information on this case see the CHILDINFO extended
item described in section 3.3. Note that the CHILDINFO extended data item described in Section 3.3. Note that the CHILDINFO
data item can only be returned when the RECURSIVEMATCH selection extended data item can only be returned when the
option is specified. RECURSIVEMATCH selection option is specified.
3) Attributes returned in the same LIST response must be treated additively.
For example the following response
3. Attributes returned in the same LIST response must be treated
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 LISTEXT 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 from it. a stronger meaning, as implying any attribute that can be inferred
For example, the client must treat presence of the \NoInferiors attribute from it. For example, the client must treat presence of the
as if the \HasNoChildren attribute was also sent by the server. \NoInferiors attribute as if the \HasNoChildren attribute was also
sent by the server.
The following table summarizes inference rules described in section 3. The following table summarizes inference rules described in
Section 3.
+--------------------+-------------------+ +--------------------+-------------------+
| returned attribute | implied attribute | | returned attribute | implied attribute |
+--------------------+-------------------+ +--------------------+-------------------+
| \NoInferiors | \HasNoChildren | | \NoInferiors | \HasNoChildren |
| | |
| \NonExistent | \NoSelect | | \NonExistent | \NoSelect |
+--------------------+-------------------+ +--------------------+-------------------+
3.3. CHILDINFO extended data item 3.3 CHILDINFO extended data item
The CHILDINFO extended data item MUST only be returned when the client The CHILDINFO extended data item MUST only be returned when the
has specified the RECURSIVEMATCH selection option. client has specified the RECURSIVEMATCH selection option.
The CHILDINFO extended data item in a LIST response describes the The CHILDINFO extended data item in a LIST response describes the
selection criteria that has caused it to be returned and indicates that selection criteria that has caused it to be returned and indicates
the mailbox has one or more child mailbox that match the selection that the mailbox has st least one child mailbox that matches the
criteria. 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: When returning the CHILDINFO extended data item, The LSUB command indicates this condition by using the "\NoSelect"
it doesn't matter if a child mailbox matches attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
the canonical LIST pattern or not. See also example 9 in "\NoSelect" retains its original meaning here. Further, the
section 5. CHILDINFO extended data item is more general, in that it can be used
with any extended set of selection criteria.
The returned selection criteria allows the client to distinguish The returned selection criteria allow the client to distinguish a
a solicited response from an unsolicited, as well as distinguish solicited response from an unsolicited one, as well as to distinguish
between solicited responses caused by multiple different<<?>> LIST among solicited responses caused by multiple pipelined LIST commands
commands. that specify different criteria.
<<Suppressing redundant CHILDINFO when parent doesn't match the Servers SHOULD ONLY return a non-matching mailbox name along with
selection criteria but has a child that does AND the child also CHILDINFO if at least one matching child is not also being returned.
matches the canonical LIST pattern?>>
<<Add example for (REMOTE RECURSIVEMATCH), when REMOTE is ignored by That is, servers SHOULD suppress redundant CHILDINFO responses.
the server (i.e. the client has effectively specified CHILDREN)?>> [[anchor3: Should this be a MUST?]]
Examples 8 and 10 in section 5 demonstrates the difference between Examples 8 and 10 in Section 5 demonstrate the difference between
present CHILDINFO extended data item and the "\HasChildren" attribute. present CHILDINFO extended data item and the "\HasChildren"
attribute.
The following table summarizes interaction between "\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 that | returned | | exists | meets the | has a child | returned |
| | selection | that meets the | LISTEXT |
| | selection | meets the selection | LISTEXT attributes | | | criteria | selection | attributes and |
| | criteria | criteria | and CHILDINFO | | | | criteria | CHILDINFO |
+------+------------+---------------------+--------------------------+ +----------------+----------------+----------------+----------------+
| no | no | no |no LIST response returned | | no | no | no | no LIST |
| yes | no | no |no LIST response returned | | | | | response |
| no | yes | no |(\NonExistent <attr>) | | | | | returned |
| | | | |
| yes | no | no | no LIST |
| | | | response |
| | | | returned |
| | | | |
| no | yes | no | (\NonExistent |
| | | | <attr>) |
| | | | |
| yes | yes | no |(<attr>) | | yes | yes | no |(<attr>) |
| no | no | yes |(\NonExistent) + CHILDINFO| | | | | |
| no | no | yes | (\NonExistent) |
| | | | + CHILDINFO |
| | | | |
| yes | no | yes |() + CHILDINFO | | yes | no | yes |() + CHILDINFO |
| no | yes | yes |(\NonExistent <attr>) + | | | | | |
| no | yes | yes | (\NonExistent |
| | | | <attr>) + |
| | | | CHILDINFO | | | | | CHILDINFO |
| yes | yes | yes |(<attr>) + CHILDINFO | | | | | |
+------+------------+---------------------+--------------------------+ | yes | yes | yes | (<attr>) + |
| | | | CHILDINFO |
+----------------+----------------+----------------+----------------+
where <attr> is one or more attributes that correspond to the where <attr> is one or more attributes that correspond to the
selection criteria, for example for the SUBSCRIBED option the <attr> selection criteria, for example for the SUBSCRIBED option the <attr>
is \Subscribed. <<REMOTE is a special case?>> is \Subscribed.
<<Is this table still needed?>>
4. The CHILDREN return Option 4. The CHILDREN return Option
The CHILDREN return option implements the Child Mailbox Extension, The CHILDREN return option implements the Child Mailbox Extension,
originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
Corporation. Most of the information in this section is taken Corporation. Most of the information in this section is taken
directly from their original specification [ChildMbox]. The CHILDREN directly from their original specification [CMbox]. The CHILDREN
return option is simply an indication that the client wants this return option is simply an indication that the client wants this
information; a server MAY provide it even if the option is not information; a server MAY provide it even if the option is not
specified. specified.
Many IMAP4 [IMAP4] clients present to the user a hierarchical view of Many IMAP4 [IMAP4] clients present to the user a hierarchical view of
the mailboxes that a user has access to. Rather than initially the mailboxes that a user has access to. Rather than initially
presenting to the user the entire mailbox hierarchy, it is often presenting to the user the entire mailbox hierarchy, it is often
preferable to show to the user a collapsed outline list of the preferable to show to the user a collapsed outline list of the
mailbox hierarchy (particularly if there is a large number of mailbox hierarchy (particularly if there is a large number of
mailboxes). The user can then expand the collapsed outline hierarchy mailboxes). The user can then expand the collapsed outline hierarchy
as needed. It is common to include within the collapsed hierarchy a as needed. It is common to include within the collapsed hierarchy a
visual clue (such as a ''+'') to indicate that there are child visual clue (such as a ''+'') to indicate that there are child
mailboxes under a particular mailbox. When the visual clue is mailboxes under a particular mailbox. When the visual clue is
clicked the hierarchy list is expanded to show the child mailboxes. clicked the hierarchy list is expanded to show the child mailboxes.
skipping to change at line 455 skipping to change at page 13, line 27
presenting to the user the entire mailbox hierarchy, it is often presenting to the user the entire mailbox hierarchy, it is often
preferable to show to the user a collapsed outline list of the preferable to show to the user a collapsed outline list of the
mailbox hierarchy (particularly if there is a large number of mailbox hierarchy (particularly if there is a large number of
mailboxes). The user can then expand the collapsed outline hierarchy mailboxes). The user can then expand the collapsed outline hierarchy
as needed. It is common to include within the collapsed hierarchy a as needed. It is common to include within the collapsed hierarchy a
visual clue (such as a ''+'') to indicate that there are child visual clue (such as a ''+'') to indicate that there are child
mailboxes under a particular mailbox. When the visual clue is mailboxes under a particular mailbox. When the visual clue is
clicked the hierarchy list is expanded to show the child mailboxes. clicked the hierarchy list is expanded to show the child mailboxes.
The CHILDREN return option provides a mechanism for a client to The CHILDREN return option provides a mechanism for a client to
efficiently determine if a particular mailbox has children, without efficiently determine if a particular mailbox has children, without
issuing a LIST "" * or a LIST "" % for each mailbox name. issuing a LIST "" * or a LIST "" % for each mailbox name. The
The CHILDREN return option defines two new attributes that MAY be CHILDREN return option defines two new attributes that MAY be
returned within a LIST response: \HasChildren and \HasNoChildren. returned within a LIST response: \HasChildren and \HasNoChildren.
While these attributes MAY be returned in response to any LIST While these attributes MAY be returned in response to any LIST
command, the CHILDREN return option is provided to indicate that the command, the CHILDREN return option is provided to indicate that the
client particularly wants this information. If the CHILDREN return client particularly wants this information. If the CHILDREN return
option is present, the server MUST return these attributes even option is present, the server MUST return these attributes even if
if their computation is expensive. their computation is expensive.
\HasChildren - The presence of this attribute indicates that the \HasChildren
mailbox has child mailboxes. The presence of this attribute indicates that the mailbox has
A server SHOULD NOT set this attribute if there are child child mailboxes. A server SHOULD NOT set this attribute if
mailboxes, and the user does not have permissions to access any there are child mailboxes, and the user does not have
of them. In this case, \HasNoChildren SHOULD be used. permissions to access any of them. In this case, \HasNoChildren
In many cases, however, a server may not be able to efficiently SHOULD be used. In many cases, however, a server may not be
compute whether a user has access to all child mailboxes. As able to efficiently compute whether a user has access to all
such a client MUST be prepared to accept the \HasChildren child mailboxes. As such a client MUST be prepared to accept
attribute as a hint. That is, a mailbox MAY be flagged with the the \HasChildren attribute as a hint. That is, a mailbox MAY be
\HasChildren attribute, but no child mailboxes will appear in flagged with the \HasChildren attribute, but no child mailboxes
the LIST response. will appear in the LIST response.
\HasNoChildren - The presence of this attribute indicates that the \HasNoChildren
mailbox has NO child mailboxes that are accessible to the The presence of this attribute indicates that the mailbox has NO
currently authenticated user. child mailboxes that are accessible to the currently
authenticated user.
In some instances a server that supports the LISTEXT extension In some instances a server that supports the LISTEXT extension might
might not be able to determine whether a mailbox has children. For not be able to determine whether a mailbox has children. For example
example it may have difficulty determining whether there are child it may have difficulty determining whether there are child mailboxes
mailboxes when LISTing mailboxes while operating in a particular when LISTing mailboxes while operating in a particular namespace. In
namespace. these cases, a server MAY exclude both the \HasChildren and
In these cases, a server MAY exclude both the \HasChildren and
\HasNoChildren attributes in the LIST response. As such, a client \HasNoChildren attributes in the LIST response. As such, a client
can not make any assumptions about whether a mailbox has children can not make any assumptions about whether a mailbox has children
based upon the absence of a single attribute. In particular, some based upon the absence of a single attribute. In particular, some
servers may not be able to combine the SUBSCRIBED selection option servers may not be able to combine the SUBSCRIBED selection option
and CHILDREN return option. Such servers MUST honour the SUBSCRIBED and CHILDREN return option. Such servers MUST honour the SUBSCRIBED
selection option, and they will simply ignore the CHILDREN return option selection option, and they will simply ignore the CHILDREN return
if both are requested. It is an error for the server to return both a option if both are requested. It is an error for the server to
\HasChildren and a \HasNoChildren attribute in a LIST response. return both a \HasChildren and a \HasNoChildren 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
Example 1: 1: The first example shows the complete local hierarchy that will be
The first example shows the complete local hierarchy that will be
used for the other examples. used for the other examples.
C: A01 LIST "" "*" C: A01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Apple"
S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Fruit/Banana"
S: * LIST () "/" "Tofu" S: * LIST () "/" "Tofu"
S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable"
S: * LIST () "/" "Vegetable/Broccoli" S: * LIST () "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn" S: * LIST () "/" "Vegetable/Corn"
S: A01 OK done S: A01 OK done
Example 2: 2: In the next example, we'll see the subscribed mailboxes. This is
similar to, but not equivalent with, <LSUB "" "*">. Note that
In the next example, we'll see the subscribed mailboxes. This is the mailbox called "Fruit/Peach" is subscribed to, but does not
similar to, but not equivalent with, <LSUB "" "*">. Note that the mailbox actually exist (perhaps it was deleted while still subscribed).
called "Fruit/Peach" is subscribed to, but does not actually exist The "Fruit" mailbox is not subscribed to, but it has two
(perhaps it was deleted while still subscribed). The "Fruit" subscribed children. The "Vegetable" mailbox is subscribed and
mailbox is not subscribed to, but it has two subscribed children. has two children, one of them is subscribed as well.
The "Vegetable" mailbox is subscribed and has two children, one
of them is subscribed as well.
C: A02 LIST (SUBSCRIBED) "" "*" C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: A02 OK done S: A02 OK done
Example 3: 3: The next example shows the use of the CHILDREN option. The
client, without having to list the second level of hierarchy, now
The next example shows the use of the CHILDREN option. The client, knows which of the top-level mailboxes have submailboxes
without having to list the second level of hierarchy, now knows which (children) and which do not. Note that it's not necessary for
of the top-level mailboxes have submailboxes (children) and which do the server to return the \HasNoChildren attribute for the inbox,
not. Note that it's not necessary for the server to return the because the \NoInferiors attribute already implies that, and has
\HasNoChildren attribute for the inbox, because the \NoInferiors attribute a stronger meaning.
already implies that, and has a stronger meaning.
C: A03 LIST () "" "%" RETURN (CHILDREN) C: A03 LIST () "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST (\HasChildren) "/" "Vegetable"
S: A03 OK done S: A03 OK done
4: In this example we see more mailboxes, which reside on another
Example 4: server to which we may obtain referrals. This is similar to the
command <RLIST "" "%">. Note that in the case of the remote
In this example we see more mailboxes, which reside on another server mailboxes, the server might or might not be able to include
to which we may obtain referrals. This is similar to the command CHILDREN information; it includes it if it can, and omits it if
<RLIST "" "%">. Note that in the case of the remote mailboxes, the it can't.
server might or might not be able to include CHILDREN information;
it includes it if it can, and omits it if it can't.
C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread" S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat" S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done S: A04 OK done
Example 5: 5: The following example also requests the server to include
mailboxes, which reside on another server. The server returns
The following example also requests the server to include mailboxes, information about all mailboxes which are subscribed. This is
which reside on another server. The server returns information about similar to the command <RLSUB "" "%">. We also see the use of
all mailboxes which are subscribed. This is similar to the command two selection options.
<RLSUB "" "%">. We also see the use of two selection options.
C: A05 LIST (REMOTE SUBSCRIBED) "" "*" C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable" S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST (\Remote \Subscribed) "/" "Bread" S: * LIST (\Remote \Subscribed) "/" "Bread"
S: A05 OK done S: A05 OK done
Example 6: 6: The following example requests the server to include mailboxes,
which reside on another server. The server is requested to
The following example requests the server to include mailboxes, return subscription information for all returned mailboxes. This
which reside on another server. The server is requested to return is different from the example above.
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 Note that the output of this command is not a superset of the
in the previous example, as it doesn't include LIST response for the output in the previous example, as it doesn't include LIST
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
Example 7: 7: In the following example the client has specified multiple
mailbox patterns. Note that this example doesn't use the mailbox
In the following example the client has specified multiple mailbox hierarchy used in the previous examples.
patterns. Note that this example doesn't use the mailbox hierarchy
used in the previous examples.
C: BBB LIST "" ("INBOX" "Drafts" "Sent/%") C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
S: * LIST () "/" "INBOX" S: * LIST () "/" "INBOX"
S: * LIST (\NoInferiors) "/" "Drafts" S: * LIST (\NoInferiors) "/" "Drafts"
S: * LIST () "/" "Sent/March2004" S: * LIST () "/" "Sent/March2004"
S: * LIST (\Marked) "/" "Sent/December2003" S: * LIST (\Marked) "/" "Sent/December2003"
S: * LIST () "/" "Sent/August2004" S: * LIST () "/" "Sent/August2004"
S: BBB OK done S: BBB OK done
Example 8: 8: The following example demonstates the difference between
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: 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 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 will Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
return no mailboxes (as the mailboxes "Moo", "Foo" and "Inbox" are NOT will return no mailboxes (as the mailboxes "Moo", "Foo" and
subscribed). However, if the client issues: "Inbox" are NOT subscribed). However, if the client issues this:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED"))) S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
S: C04 OK done S: C04 OK done
i.e. the mailbox "Foo" is not subscribed, but it has a child that is. i.e. the mailbox "Foo" is not subscribed, but it has a child
that is.
A1). If the mailbox "Foo" would have been subscribed instead, the last A1) If the mailbox "Foo" had been subscribed instead, the last
command would return: command would return this:
S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO" ("SUBSCRIBED"))) C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO"
("SUBSCRIBED")))
S: C04 OK done
or even or even this:
S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO" ("SUBSCRIBED"))) 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 A2) If we assume instead that the mailbox "Foo" is not part of
original hierarchy and is not subscribed, the last command will the original hierarchy and is not subscribed, the last command
return will give this result:
S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO" ("SUBSCRIBED"))) 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 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, let's assume that only the mailboxes "Foo" and "Moo" are C) And finally, suppose that only the mailboxes "Foo" and "Moo"
subscribed. In this case the command: are subscribed. In that case we see this result:
C: LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN) C: LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
will return:
S: * LIST (\HasChildren \Subscribed) "/" "Foo" S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
Which means that the mailbox "Foo" has children, but none of them (which means that the mailbox "Foo" has children, but none of
is subscribed. them is subscribed).
Example 9:
The following example demonstrates that the CHILDINFO extended data item 9: The following example demonstrates that the CHILDINFO extended
is returned whether children mailboxes match the canonical LIST pattern data item is returned whether children mailboxes match the
or not. canonical LIST pattern or not.
Let's assume there is the following hierarchy: Let's assume there is the following hierarchy:
C: D01 LIST "" "*" C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2" S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1" S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2" S: * LIST () "/" "foo2/bar2"
S: * LIST () "/" "baz2" S: * LIST () "/" "baz2"
S: * LIST () "/" "baz2/bar2" S: * LIST () "/" "baz2/bar2"
skipping to change at line 738 skipping to change at page 20, line 6
The client issues the following command first: The client issues the following command first:
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED"))) S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "foo2/bar2" S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED"))) S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "baz2/bar2" S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22" S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222" S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" ("SUBSCRIBED"))) S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
("SUBSCRIBED")))
S: * LIST (\Subscribed) "/" "quux2/bar2" S: * LIST (\Subscribed) "/" "quux2/bar2"
S: D03 OK done S: D03 OK done
and the server may also include and the server may also include
S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO" ("SUBSCRIBED"))) S: * LIST (\NonExistent) "/" "quux2" (("CHILDINFO"
("SUBSCRIBED")))
The CHILDINFO extended data item is returned for mailboxes "foo2", "baz2" The CHILDINFO extended data item is returned for mailboxes
and "eps2", because all of them have subscribed children, "foo2", "baz2" and "eps2", because all of them have subscribed
even though for the mailbox "foo2" only one of the two subscribed children, even though for the mailbox "foo2" only one of the two
children match the pattern, for the mailbox "baz2" all the subscribed subscribed children match the pattern, for the mailbox "baz2" all
children match the pattern and for the mailbox "eps2" none of the the subscribed children match the pattern and for the mailbox
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" ("SUBSCRIBED"))) S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO"
("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 have the LIST responses for mailboxes "foo2", "baz2" and "eps2" still
the CHILDINFO extended data item, even though this information have the CHILDINFO extended data item, even though this
is redundant and the client can determine it by itself. information is redundant and the client can determine it by
itself.
Example 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 data item It also demonstrates that the presence of the CHILDINFO extended
doesn't necessarily imply \HasChildren. data item doesn't necessarily imply \HasChildren.
C: a1 LIST "" ("foo" "foo/*") C: a1 LIST "" ("foo" "foo/*")
S: * LIST () "/" foo S: * LIST () "/" foo
S: a1 OK done S: a1 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*" C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done S: a2 OK done
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN) C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN
S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO" ("SUBSCRIBED"))) (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO"
("SUBSCRIBED")))
S: a3 OK done S: a3 OK done
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF]. Terms not defined here are taken Form (BNF) as described in [ABNF]. Terms not defined here are taken
from [IMAP4]. "vendor-token" is defined in [ACAP]. from [IMAP4].
childinfo-extended-item = "CHILDINFO" SP "(" list-sel-base-opt-quoted "vendor-token" is defined in [ACAP]. [[anchor4: This is an issue in
*( SP list-sel-base-opt-quoted ) ")" moving forward, since ACAP will never move to Draft Standard. Should
we define vendor-token here, and also define the IANA registry here?
Should we put it into another document? Is there someplace else we
can get the same definition?]]
childinfo-extended-item = "CHILDINFO" 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.
child-mbox-flag = "\HasChildren" / "\HasNoChildren" child-mbox-flag = "\HasChildren" / "\HasNoChildren"
skipping to change at line 821 skipping to change at page 22, 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-base-opt list-select-opts = "(" [*(list-select-mod-opt SP)
list-select-base-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-sel-mod-opt / list-sel-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-sel-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-sel-base-opt-quoted = <"> list-sel-base-opt <"> list-select-base-opt-quoted = <"> list-select-base-opt <">
list-sel-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 return-option)] ")" list-return-opts = "RETURN" SP "(" [return-option *(SP
return-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 ")"
mbox-list-extended-item-data = mbox-list-extended-item-tag SP nstring-list mbox-list-extended-item-data = mbox-list-extended-item-tag SP
nstring-list
mbox-list-extended-item-tag = astring mbox-list-extended-item-tag = astring
; The content MUST conform to either "eitem-vendor-tag" or ; The content MUST conform to either "eitem-vendor-tag"
; "eitem-standard-tag" ABNF productions. ; or "eitem-standard-tag" ABNF productions.
; A tag registration template is described in section ; A tag registration template is described in this
; 8.5 of this document. document
; in Section 8.5.
mbox-list-oflag = child-mbox-flag / "\NonExistent" / mbox-list-oflag = child-mbox-flag / "\NonExistent" /
/ "\Subscribed" / "\Remote" / "\Subscribed" / "\Remote"
mbox-or-pat = list-mailbox / patterns mbox-or-pat = list-mailbox / patterns
nstring-list = nstring / nstring-list = nstring /
"(" [nstring-list *(SP nstring-list)] ")" "(" [nstring-list *(SP nstring-list)] ")"
;; a recursive list definition ; a recursive list definition
option-extension = option-vendor-tag / option-standard-tag option-extension = option-vendor-tag / option-standard-tag
option-vendor-tag = vendor-tag option-vendor-tag = vendor-tag
; a vendor specific option ; a vendor specific option
option-standard-tag= atom option-standard-tag= atom
; an option defined in a Standard Track or ; an option defined in a Standard Track or
; Experimental RFC ; Experimental RFC
patterns = "(" list-mailbox *(SP list-mailbox) ")" patterns = "(" list-mailbox *(SP list-mailbox) ")"
return-option = "SUBSCRIBED" / "CHILDREN" / return-option = "SUBSCRIBED" / "CHILDREN" /
option-extension option-extension
vendor-tag = vendor-token "-" atom vendor-tag = vendor-token "-" atom
skipping to change at line 888 skipping to change at page 25, line 10
return-option = "SUBSCRIBED" / "CHILDREN" / return-option = "SUBSCRIBED" / "CHILDREN" /
option-extension option-extension
vendor-tag = vendor-token "-" atom vendor-tag = vendor-token "-" atom
7. Security Considerations 7. Security Considerations
This document describes syntactic changes to the specification of the This document describes syntactic changes to the specification of the
IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
command has the same security considerations as those commands. They command has the same security considerations as those commands. They
are described in [IMAP4] and [MboxRefer]. are described in [IMAP4] and [MBRef].
The Child Mailbox Extension provides a client a more efficient means The Child Mailbox Extension provides a client a more efficient means
of determining whether a particular mailbox has children. If a of determining whether a particular mailbox has children. If a
mailbox has children, but the currently authenticated user does not mailbox has children, but the currently authenticated user does not
have access to any of them, the server SHOULD respond with a have access to any of them, the server SHOULD respond with a
\HasNoChildren attribute. In many cases, however, a server may not \HasNoChildren attribute. In many cases, however, a server may not
be able to efficiently compute whether a user has access to all child be able to efficiently compute whether a user has access to all child
mailboxes. If such a server responds with a \HasChildren attribute, mailboxes. If such a server responds with a \HasChildren attribute,
when in fact the currently authenticated user does not have access to when in fact the currently authenticated user does not have access to
any child mailboxes, potentially more information is conveyed about any child mailboxes, potentially more information is conveyed about
the mailbox than intended. In most situations this will not be a the mailbox than intended. In most situations this will not be a
security concern, because if information regarding whether a mailbox security concern, because if information regarding whether a mailbox
has children is considered sensitive, a user would not be granted has children is considered sensitive, a user would not be granted
access to that mailbox in the first place. access to that mailbox in the first place.
<<The CHILDINFO extended data item has the same security considerations The CHILDINFO extended data item has the same security considerations
as the \HasChildren attribute described above.>> as the \HasChildren attribute described above.
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 LISTEXT
options and LISTEXT extended response data. The templates and options and LISTEXT extended response data. The templates and the
the initial registrations are detailed below. 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 LISTEXT option is done by filling in the template
in section 8.3 and sending it via electronic mail to <iana@iana.org>. in Section 8.3 and sending it via electronic mail to iana@iana.org.
Registration of a LISTEXT extended data item is done by filling in the Registration of a LISTEXT extended data item is done by filling in
template in section 8.5 and sending it via electronic mail to <iana@iana.org>. the template in Section 8.5 and sending it via electronic mail to
IANA has the right to reject obviously bogus registrations, but will iana@iana.org. IANA has the right to reject obviously bogus
perform no review of claims made in the registration form. registrations, but will perform no review of claims made in the
registration form.
A LISTEXT option/extended data item name that starts with "V-" is reserved A LISTEXT option/extended data item name that starts with "V-" is
for vendor specific options/extended data items. All options, whether reserved for vendor specific options/extended data items. All
they are vendor specific or global, should be registered with IANA. options, whether they are vendor specific or global, should be
If a LISTEXT extended data item is returned as a result of requesting registered with IANA. If a LISTEXT extended data item is returned as
a particular LISTEXT option, the name of the option SHOULD be used a result of requesting a particular LISTEXT option, the name of the
as the name of the LISTEXT extended data item. option SHOULD be used as the name of the LISTEXT 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 insensitive. Standard LISTEXT option/extended data item names are case
If the vendor prefix is omitted from a vendor specific LISTEXT insensitive. If the vendor prefix is omitted from a vendor specific
option/extended data item name, the rest is case insensitive. The vendor LISTEXT option/extended data item name, the rest is case insensitive.
prefix itself is not case-sensitive, as it might contain non-ASCII The vendor prefix itself is not case-sensitive, as it might contain
characters. non-ASCII characters.
While the registration procedures do not require it, authors of LISTEXT While the registration procedures do not require it, authors of
options/extended data items are encouraged to seek community review and LISTEXT options/extended data items are encouraged to seek community
comment whenever that is feasible. Authors may seek community review by review and comment whenever that is feasible. Authors may seek
posting a specification of their proposed mechanism as an Internet- community review by posting a specification of their proposed
Draft. LISTEXT options/extended data items intended for widespread use mechanism as an Internet- Draft. LISTEXT options/extended data items
should be standardized through the normal IETF process, when appropriate. intended for widespread use should be standardized through the normal
IETF process, when appropriate.
Comments on registered LISTEXT options/extended response data should Comments on registered LISTEXT options/extended response data should
first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG first be sent to the "owner" of the mechanism and/or to the IMAPEXT
mailing list. WG mailing list. Submitters of comments may, after a reasonable
Submitters of comments may, after a reasonable attempt to contact the attempt to contact the owner, request IANA to attach their comment to
owner, request IANA to attach their comment to the registration itself. the registration itself. If IANA approves of this, the comment will
If IANA approves of this, the comment will be be made accessible in conjunction with the registration LISTEXT
made accessible in conjunction with the registration LISTEXT options/ options/ extended response data itself.
extended response data itself.
Once a LISTEXT registration has been published by IANA, the Once a LISTEXT registration has been published by IANA, the author
author may request a change to its definition. The change request may request a change to its definition. The change request follows
follows the same procedure as the registration request. the same procedure as the registration request.
The owner of a LISTEXT registration may pass responsibility for the The owner of a LISTEXT registration may pass responsibility for the
registered option/extended data item to another person or agency by registered option/extended data item to another person or agency by
informing IANA; this can be done without discussion or review. informing IANA; this can be done without discussion or review.
The IESG may reassign responsibility for a LISTEXT option/extended data item. The IESG may reassign responsibility for a LISTEXT option/extended
The most common case of this will be to enable changes to be made to data item. The most common case of this will be to enable changes to
mechanisms where the author of the registration has died, moved out be made to mechanisms where the author of the registration has died,
of contact or is otherwise unable to make changes that are important moved out of contact or is otherwise unable to make changes that are
to the community. important to the community.
LISTEXT registrations may not be deleted; mechanisms which are LISTEXT registrations may not be deleted; mechanisms which are no
no longer believed appropriate for use can be declared OBSOLETE by a longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended use" field; such LISTEXT options/extended data change to their "intended use" field; such LISTEXT options/extended
items will be clearly marked in the lists published by IANA. data items will be clearly marked in the lists published by IANA.
The IESG is considered to be the owner of all LISTEXT options/extended data items The IESG is considered to be the owner of all LISTEXT
which are on the IETF standards track. options/extended data items which are on the IETF standards track.
8.3. Registration template for LISTEXT options 8.3 Registration template for LISTEXT options
To: iana@iana.org To: iana@iana.org
Subject: Registration of LISTEXT option X Subject: Registration of LISTEXT option X
LISTEXT option name: LISTEXT option name:
LISTEXT option type: (One of SELECTION or RETURN) LISTEXT option type: (One of SELECTION or RETURN)
Implied return options(s), if the option type is SELECTION: (zero or more) Implied return options(s), if the option type is SELECTION: (zero or
more)
LISTEXT option description: LISTEXT 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 & 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 (Any other information that the author deems interesting may be added
added below this line.) below this line.)
8.4. Initial LISTEXT option registrations
It is requested that the LISTEXT option registry is being populated 8.4 Initial LISTEXT option registrations
with the following entries:
1) It is requested that the LISTEXT option registry be populated with
the following entries:
To: iana@iana.org 1. To: iana@iana.org
Subject: Registration of LISTEXT option SUBSCRIBED Subject: Registration of LISTEXT option SUBSCRIBED
LISTEXT option name: SUBSCRIBED LISTEXT option name: SUBSCRIBED
LISTEXT option type: SELECTION LISTEXT option type: SELECTION
Implied return options(s): SUBSCRIBED Implied return options(s): SUBSCRIBED
LISTEXT option description: Causes the LIST command to list LISTEXT option description: Causes the LIST command to list
subscribed mailboxes, rather than the actual mailboxes. subscribed mailboxes, rather than the actual mailboxes.
Published specification : this RFC, section 3. Published specification : XXXX, Section 3.
Security considerations: this RFC, section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person & 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 <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 LISTEXT option REMOTE
LISTEXT option name: REMOTE LISTEXT option name: REMOTE
LISTEXT option type: SELECTION LISTEXT option type: SELECTION
Implied return options(s): (none) Implied return options(s): (none)
LISTEXT option description: causes the LIST command to return LISTEXT option description: causes the LIST command to return
remote mailboxes as well as local ones, as described in remote mailboxes as well as local ones, as described in RFC 2193.
RFC 2193.
Published specification : this RFC, section 3. Published specification : XXXX, Section 3.
Security considerations: this RFC, section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person & 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 <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 LISTEXT option SUBSCRIBED
LISTEXT option name: SUBSCRIBED LISTEXT option name: SUBSCRIBED
LISTEXT option type: RETURN LISTEXT option type: RETURN
LISTEXT option description: Causes the LIST command to return LISTEXT option description: Causes the LIST command to return
subscription state. subscription state.
Published specification : this RFC, section 3. Published specification : XXXX, Section 3.
Security considerations: this RFC, section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person & 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 <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 LISTEXT option RECURSIVEMATCH
LISTEXT option name: RECURSIVEMATCH LISTEXT option name: RECURSIVEMATCH
LISTEXT option type: SELECTION LISTEXT option type: SELECTION
Implied return options(s): (none) Implied return options(s): (none)
LISTEXT option description: Requests that CHILDINFO LISTEXT option description: Requests that CHILDINFO extended data
extended data item is to be returned. item is to be returned.
Published specification : this RFC, sections 3.
Published specification : this RFC Published specification : XXXX, Section 3.
Security considerations: this RFC, section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person & 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 <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 LISTEXT option CHILDREN
LISTEXT option name: CHILDREN LISTEXT option name: CHILDREN
LISTEXT option type: RETURN LISTEXT option type: RETURN
LISTEXT option description: Requests mailbox child information. LISTEXT option description: Requests mailbox child information.
Published specification : this RFC, sections 3 and 4. Published specification : XXXX, Section 3 and Section 4.
Published specification : this RFC
Security considerations: this RFC, section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person & 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 <iesg@ietf.org> Owner/Change controller: iesg@ietf.org
8.5. Registration template for LISTEXT extended data item 8.5 Registration template for LISTEXT extended data item
To: iana@iana.org To: iana@iana.org
Subject: Registration of X LISTEXT extended data item Subject: Registration of X LISTEXT extended data item
LISTEXT extended data item tag: LISTEXT extended data item tag:
LISTEXT extended data item description: LISTEXT extended data item description:
Which LISTEXT option(s) (and their types) causes this extended Which LISTEXT option(s) (and their types) causes this extended data
data item to be returned (if any): 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 & 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 (Any other information that the author deems interesting may be added
added below this line.) below this line.)
8.6. Initial LISTEXT extended data item registrations
It is requested that the LISTEXT extended data item registry is 8.6 Initial LISTEXT extended data item registrations
being populated with the following entries:
1) It is requested that the LISTEXT extended data item registry be
populated with the following entries:
To: iana@iana.org 1. To: iana@iana.org
Subject: Registration of CHILDINFO LISTEXT extended data item Subject: Registration of CHILDINFO LISTEXT extended data item
LISTEXT extended data item tag: CHILDINFO LISTEXT extended data item tag: CHILDINFO
LISTEXT extended data item description: The CHILDINFO extended data LISTEXT extended data item description: The CHILDINFO extended
item describes the selection criteria that has caused it to be data item describes the selection criteria that has caused it to
returned and indicates that the mailbox has one or more child be returned and indicates that the mailbox has one or more child
mailbox that match the selection criteria. mailbox that match the selection criteria.
Which LISTEXT option(s) (and their types) causes this extended Which LISTEXT option(s) (and their types) causes this extended
data item to be returned (if any): RECURSIVEMATCH selection data item to be returned (if any): RECURSIVEMATCH selection
option option
Published specification : this RFC, section 3.3 Published specification : XXXX, Section 3.3.
Security considerations: this RFC, section 7. Security considerations: XXXX, Section 7.
Intended usage: COMMON Intended usage: COMMON
Person & 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 <iesg@ietf.org> Owner/Change controller: iesg@ietf.org
9. References
9.1. Normative References 9. Acknowledgements
[Keywords] Bradner, S., "Key words for use in RFCs to Indicate Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
Requirement Levels", RFC 2119, Harvard University, March 1997. devised the Child Mailbox Extension and proposed it in 1997; the
idea, as well as most of the text in Section 4, is theirs.
[ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax This document is the result of discussions on the IMAP4 and IMAPEXT
Specifications: ABNF", RFC 2234, November 1997. 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.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 10. Normative References
4rev1", RFC 3501, University of Washington, March 2003.
[MboxRefer] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Microsoft Corporation, September 1997. Specifications: ABNF", RFC 2234, November 1997.
[ChildMbox] Gahrns, M. & Cheng, R., "IMAP4 Child Mailbox Extension", [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration
RFC 3348, Microsoft Corporation, July 2002. Access Protocol", RFC 2244, November 1997.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application [CMbox] Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.
Configuration Access Protocol", RFC 2244, November 1997.
10. Acknowledgements [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
Mike Gahrns and Raymond Cheng of Microsoft Corporation originally [Kwds] Bradner, S., "Key words for use in RFCs to Indicate
devised the Child Mailbox Extension and proposed it in 1997; the Requirement Levels", RFC 2119, March 1997.
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 [MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
mailing lists and is meant to reflect consensus of those groups. 1997.
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. Author's Address 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
Phone: 1-914-784-7941 US
Email: leiba@watson.ibm.com
Phone: +1 914 784 7941
Email: leiba@watson.ibm.com
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex Hampton, Middlesex TW12 2BX
TW12 2BX, UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
Home page: http://www.melnikov.ca/ URI: http://www.melnikov.ca/
12. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which we become aware will be disclosed, in accordance with
RFC 3668.
13. Intellectual Property Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 1279 skipping to change at page 34, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
14. Full Copyright Statement Disclaimer of Validity
Copyright (C) The Internet Society (2005). 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Copyright Statement
Funding for the RFC Editor function is currently provided by Copyright (C) The Internet Society (2005). This document is subject
the Internet Society. to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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