draft-ietf-imapext-list-extensions-08.txt   draft-ietf-imapext-list-extensions-09.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 A. Melnikov
Isode Limited Isode Limited
Expires February 2004 August 2004 Expires March 2005 September 2004
IMAP4 LIST Command Extensions IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-08.txt draft-ietf-imapext-list-extensions-09.txt
Status of this Document Status of this Document
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, or patent or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be disclosed, will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668. 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
skipping to change at line 69 skipping to change at line 69
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 [Keywords].
The term "canonical LIST pattern" refers to The term "canonical LIST pattern" refers to
the canonical pattern constructed internally by the server from the canonical pattern constructed internally by the server from
the reference and mailbox name arguments (Section 6.3.8 of [IMAP4]). the reference and mailbox name arguments (Section 6.3.8 of [IMAP4]).
The [IMAP4] LIST command returns only mailboxes that match the The [IMAP4] LIST command returns only mailboxes that match the
canonical LIST pattern. canonical LIST pattern.
Other terms are introduced where they are referenced for the first time.
<<Other editorial comments/questions are enclosed like this.>> <<Other editorial comments/questions are enclosed like this.>>
2. Introduction and overview 2. Introduction and overview
The extensions to the LIST command will be accomplished by amending The extensions to the LIST command will be accomplished by amending
the syntax to allow options to be specified. The list of options the syntax to allow options to be specified. The list of options
will replace the several commands that are currently used to mix and will replace the several commands that are currently used to mix and
match the information requested. The new syntax is backward- match the information requested. The new syntax is backward-
compatible, with no ambiguity: <<if the first word after the command compatible, with no ambiguity: the new syntax is being used if one of
name begins with a parenthesis, the new syntax is being used; if it the following conditions is true:
does not, it's in the original syntax>>. 1). if the first word after the command name begins with a parenthesis;
2). if the second word after the command name begins with a parenthesis;
3). if the LIST command has more than 2 parameters;
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 [MboxRefer]. We are also defining the mechanism to
request extended mailbox information, such as is described in the request extended mailbox information, such as is described in the
"Child Mailbox Extension" [ChildMbox]. The base "Child Mailbox Extension" [ChildMbox]. The base
LSUB command is not deprecated by this extension; rather, this LSUB command is not deprecated by this extension; rather, this
extension adds a way to obtain subscription information with more extension adds a way to obtain subscription information with more
options, with those server implementations that support it. Clients options, with those server implementations that support it. Clients
that simply need a list of subscribed mailboxes, as provided by the that simply need a list of subscribed mailboxes, as provided by the
LSUB command, SHOULD continue to use that command. LSUB command, SHOULD 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-W08-LISTEXT" <<the capability name will change capability string "X-DRAFT-W09-LISTEXT" <<Note to the RFC Editor:
upon publication as an RFC>>. The LISTEXT extension makes the the capability name will change upon publication as an RFC>>.
The X-DRAFT-W09-LISTEXT extension makes the
following changes to the IMAP4 protocol, which are described in following changes to the IMAP4 protocol, which are described in
more details in sections 3 and 4 of this document: 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. extend LIST to allow for multiple mailbox patterns.
c. adds LIST command match options: SUBSCRIBED and REMOTE c. adds LIST command selection options: SUBSCRIBED, REMOTE and MATCHPARENT.
d. adds LIST command return options: SUBSCRIBED, REMOTE, CHILDREN d. adds LIST command return options: SUBSCRIBED and CHILDREN.
and SUBMAILBOXES. e. adds new mailbox attributes: "\NonExistent", "\PlaceHolder",
e. adds new mailbox flags "\NonExistent", "\PlaceHolder",
"\Subscribed", "\Remote", "\HasSubmailboxes", "\Subscribed", "\Remote", "\HasSubmailboxes",
"\HasChildren" and "\HasNoChildren". "\HasChildren" and "\HasNoChildren".
2.1. General principals for returning LIST responses
This section outlines several principals that can be used by
implementors of this document to decide if a LIST response should be
returned, as well as how many responses and what kind of information
they may contain.
1) Exactly one LIST response should be returned for each mailbox
name which matches the canonical LIST pattern.
Server implementors must not assume that clients will be able to
assemble mailbox flags and other information returned in multiple
LIST responses.
<<The following will be removed if the \PlaceHolder flag is also removed:
2) There are only two reasons for including a matching mailbox name
in the responses to the LIST command:
a) the mailbox name also satisfies the selection criteria;
b) the mailbox name has at least one child mailbox that satisfies
the selection criteria, but doesn't match the canonical LIST
pattern. For more information on this case see the \PlaceHolder
flag description in Section 3.
>>
3) Flags returned in the same LIST response must be treated additively.
For example the following response
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed.
3. LIST Command Options 3. LIST Command Options
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 multiple
mailbox patterns to be specified, if they are enclosed in parantheses. mailbox patterns to be specified, if they are enclosed in parantheses.
A mailbox match a list of mailbox patterns, if it matches at least one A mailbox match a list of mailbox patterns, if it matches at least one
mailbox pattern. mailbox pattern.
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 adding a
parenthesized list of command options between the command name and the reference parenthesized list of command options between the command name and the reference
name (LIST match options) and an optional list of options at the end that name (LIST selection options) and an optional list of options at the end that
control what kind of information should be returned (LIST return options). control what kind of information should be returned (LIST return options).
See the formal syntax in section 6 for specific details. A LIST match option See the formal syntax in section 6 for specific details. A LIST selection option
tells the server which mailboxes should be selected by the LIST operation. tells the server which mailbox names should be selected by the LIST operation.
The server should return information about all mailboxes that match any of the The server should return information about all mailbox names that match any of the
"canonical LIST pattern" (as described above) and satisfy additional selection "canonical LIST pattern" (as described above) and satisfy additional selection
criteria (if any) specified by the LIST match options. Let's call any such criteria (if any) specified by the LIST selection options. Let's call any such
mailbox a "matched mailbox". Note, that if multiple match options are specified, mailbox name a "matched mailbox name".
the server MUST return information about intersection of mailboxes that satisfy When multiple selection options are specified, the server must return
any single match option. information about mailbox names that satisfy every selection option, unless
a description of a particular specified option prescribes special rules.
An example of an option prescribing special rules is the MATCHPARENT selection
option described later in this section.
We will use the term "selection criteria" when refering collectively to 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 matched
mailbox. Note, that some return options may cause the server to report mailbox name. Note, that return options MUST NOT cause the server to report
information about additional mailboxes (e.g. SUBMAILBOXES). If the client information about additional mailbox names. If the client has not specified any
has omitted return options, only flag information should be returned by the return option, only information about attributes should be returned by the server.
server. (Of course the server is allowed to include any other information at will)
Both match and return command options will be defined in this document and Both selection and return command options will be defined in this document and
in approved extension documents; each option will be enabled by a capability in approved extension documents; each option will be enabled by a capability
string (one capability may enable multiple options), and a client MUST NOT string (one capability may enable multiple options), and a client MUST NOT
send an option for which the server has not advertised support. A server send an option for which the server has not advertised support. A server
MUST respond to options it does not recognize with a NO response. MUST respond to options it does not recognize with a NO response.
This extension is identified by the capability string "X-DRAFT-W08-LISTEXT" This extension is identified by the capability string "X-DRAFT-W09-LISTEXT"
<<Note to the RFC editor: please update upon publication as above>>, <<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 support for an extended LIST command,
but use extended LIST responses (see below), don't need to advertise the
"X-DRAFT-W09-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 tagged
data (also referred to as "extended data item"). The first element of data (also referred to as "extended data item"). The first element of
an extended field is a tag, which identifies type of the data. Tags an extended field is a tag, which identifies type of the data. Tags
MUST be registered with IANA, as described in section 8.5 of this MUST be registered with IANA, as described in section 8.5 of this
document. An example of such extended set might be 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 syntatic details. See the formal grammar, below, for the full syntactic details.
The server MAY return data in the extended fields that was not solicited The server MAY return data in the extended fields that was not solicited
by the client. The client MUST ignore all extended fields it doesn't by the client. The client MUST ignore all extended fields it doesn't
recognize. recognize.
The LISTEXT capability defines several new mailbox flags. The X-DRAFT-W09-LISTEXT <<Note to the RFC Editor: fix upon publication>>
capability also defines several new mailbox attributes.
The "\PlaceHolder" flag indicates that the designated mailbox does not The "\PlaceHolder" attribute indicates that the designated mailbox does not
meet the selection criteria of the given LIST command, but that it meet the selection criteria of the given LIST command, but that it
has one or more child mailbox that might (unspecified whether any, has one or more child mailbox that might (unspecified whether any,
all, or none match the canonical LIST pattern). all, or none match the canonical LIST pattern).
The LSUB command indicates this condition by using the "\NoSelect" The LSUB command indicates this condition by using the "\NoSelect"
flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
"\NoSelect" retains its original meaning here. Further, the "\NoSelect" retains its original meaning here. Further, the
"\PlaceHolder" flag is more general, in that it can be used with any "\PlaceHolder" attribute is more general, in that it can be used with any
extended set of selection criteria. extended set of selection criteria.
The "\HasSubmailboxes" flag indicates that the designated mailbox meets The "\HasSubmailboxes" attribute indicates that the designated mailbox meets
the selection criteria of the given LIST command and also has one or more child the selection criteria of the given LIST command and also has one or more
mailbox that might (unspecified whether any, all, or none match the canonical child mailbox that might (unspecified whether any, all, or none match the
LIST pattern). canonical LIST pattern).
Absence of both \PlaceHolder and \HasSubmailboxes means that the mailbox The MATCHPARENT selection option described below REQUIRES that the
meets the selection criterion, but doesn't have any children that also "\Placeholder" and the "\HasSubmailboxes" attributes be accurately computed.
meet the selection criterion and don't match the canonical LIST pattern.
When the MATCHPARENT selection option was specified by the client,
the absence of both \PlaceHolder and \HasSubmailboxes means that the
mailbox meets the selection criteria, but doesn't have any children that
also meets the selection criteria and doesn't match the canonical LIST pattern.
However, absence of both \PlaceHolder and \HasSubmailboxes doesn't tell However, absence of both \PlaceHolder and \HasSubmailboxes doesn't tell
whether there are any children that meet the selection criterion and match whether there are any children that meet the selection criteria and match
the canonical LIST pattern. the canonical LIST pattern.
<<We probably need an example to illustrate this>> The "\PlaceHolder" and the "\HasSubmailboxes" attributes are mutually
exclusive.
The SUBMAILBOXES return option described below REQUIRES that the "\Placeholder" The presence of a "\Placeholder"/""\HasSubmailboxes" attribute implies
and the "\HasSubmailboxes" flags be accurately computed. "\HasChildren".
The "\Placeholder"/""\HasSubmailboxes" flag implies "\HasChildren". The example 8 in section 5 demonstrates the difference between
"\Placeholder"/""\HasSubmailboxes" and "\HasChildren" attributes.
The "\NonExistent" flag indicates that a mailbox does not actually exist. The "\NonExistent" attribute indicates that a mailbox does not actually exist.
Note that this flag is not meaningful by itself, as mailboxes that match Note that this attribute is not meaningful by itself, as mailboxes that match
the canonical LIST pattern but don't exist must not be returned unless one the canonical LIST pattern but don't exist must not be returned unless one
of the two conditions listed below is also satisfied: of the two conditions listed below is also satisfied:
a) the mailbox also satisfy the selection criteria a) the mailbox also satisfy the selection criteria
b) the mailbox has at least one child mailbox that satisfies the selection b) the mailbox has at least one child mailbox that satisfies the selection
criteria, but doesn't match the canonical LIST pattern. criteria, but doesn't match the canonical LIST pattern.
In practice this means that the "\NonExistent" flag is usually returned In practice this means that the "\NonExistent" attribute is usually returned
with one or more of \PlaceHolder/\HasSubmailboxes, \Subscribed, \Remote with one or more of "\PlaceHolder"/"\HasSubmailboxes", "\Subscribed",
(see there description below). "\Remote" (see their description below).
The "\NonExistent" flag implies "\NoSelect". The "\NonExistent" attribute implies "\NoSelect".
The "\NonExistent" flag MUST be supported and MUST be accurately computed. The "\NonExistent" attribute MUST be supported and MUST be accurately computed.
The following table summarizes when \NonExistent, \PlaceHolder or The following table summarizes when "\NonExistent", "\PlaceHolder" or
\HasSubmailboxes flags are to be returned: "\HasSubmailboxes" attributes are to be returned:
+------+------------+---------------------+--------------------------------+ +------+------------+---------------------+--------------------------------+
|exists| meets the | has a child that | returned | |exists| meets the | has a child that | returned |
| | selection | meets the selection | LISTEXT flags | | | selection | meets the selection | LISTEXT attributes |
| | criteria | criteria | | | | criteria | criteria | |
+------+------------+---------------------+--------------------------------+ +------+------------+---------------------+--------------------------------+
| no | no | no | no LIST response returned | | no | no | no | no LIST response returned |
| yes | no | no | no LIST response returned | | yes | no | no | no LIST response returned |
| no | yes | no | (\NonExistent) | | no | yes | no | (\NonExistent) |
| yes | yes | no | () | | yes | yes | no | () |
| no | no | yes | (\NonExistent \PlaceHolder) | | no | no | yes | (\NonExistent \PlaceHolder) |
| yes | no | yes | (\PlaceHolder) | | yes | no | yes | (\PlaceHolder) |
| no | yes | yes | (\NonExistent \HasSubmailboxes)| | no | yes | yes | (\NonExistent \HasSubmailboxes)|
| yes | yes | yes | (\HasSubmailboxes) | | yes | yes | yes | (\HasSubmailboxes) |
+------+------------+---------------------+--------------------------------+ +------+------------+---------------------+--------------------------------+
The match 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
mailboxes, rather than the actual mailboxes. This will often names, rather than the actual mailboxes. This will often
be a subset of the actual mailboxes. It's also possible for be a subset of the actual mailboxes. It's also possible for
this list to contain the names of mailboxes that don't exist. this list to contain the names of mailboxes that don't exist.
In any case, the list MUST include exactly those mailbox names In any case, the list MUST include exactly those mailbox names
that match the canonical list pattern and are subscribed to. This that match the canonical list pattern and are subscribed to. This
option is intended to supplement the LSUB command. option is intended to supplement the LSUB command.
Of particular note are the mailbox flags as returned by this Of particular note are the mailbox attributes as returned by this
option, compared with what is returned by LSUB. With the option, compared with what is returned by LSUB. With the
latter, the flags returned may not reflect the actual flag latter, the attributes returned may not reflect the actual attribute
status on the mailbox, and the \NoSelect flag has a special status on the mailbox name, and the \NoSelect attribute has a special
meaning (it indicates that this mailbox is not, itself, meaning (it indicates that this mailbox is not, itself,
subscribed, but that it has child mailboxes that are). With subscribed, but that it has child mailboxes that are). With
the SUBSCRIBED match option described here, the flags are accurate the SUBSCRIBED selection option described here, the attributes are
and complete, and have no special meanings. accurate and complete, and have no special meanings.
"LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing,
and some servers must do significant extra work to respond to and some servers must do significant extra work to respond to
"LIST (SUBSCRIBED)". Because of this, clients SHOULD continue "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue
to use "LSUB" unless they specifically want the additional to use "LSUB" unless they specifically want the additional
information offered by "LIST (SUBSCRIBED)". information offered by "LIST (SUBSCRIBED)".
This option defines a new mailbox flag, "\Subscribed" that This option defines a new mailbox attribute, "\Subscribed" that
indicates that a mailbox is subscribed to. The "\Subscribed" indicates that a mailbox name is subscribed to. The "\Subscribed"
flag MUST be supported and MUST be accurately computed attribute MUST be supported and MUST be accurately computed
when the SUBSCRIBED match option is specified. when the SUBSCRIBED selection option is specified.
<<Note, that the SUBSCRIBED match 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 local ones, as described in [MboxRefer]. This option well as local ones, as described in [MboxRefer]. This option
is intended to replace the RLIST command and, in conjunction is intended to replace the RLIST command and, in conjunction
with the SUBSCRIBED match option, the RLSUB command. with the SUBSCRIBED selection option, the RLSUB command.
This option defines a new mailbox flag, "\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"
flag MUST be accurately computed when the REMOTE option is attribute MUST be accurately computed when the REMOTE option is
specified. specified.
<<Note, that the REMOTE match option implies the REMOTE Note, that a server implementation that doesn't support
return option (see below).>> any remote mailboxes is compliant with this specification
as long as it accepts and ignores the REMOTE selection option.
MATCHPARENT - when this option is specified, the "\Placeholder"
and the "\HasSubmailboxes" attributes MUST be accurate (see their
description above). This might force the server to return
information about parent mailboxes that don't match other
selection options, but have some submailboxes that do.
Note 1: In order for a parent mailbox to be returned, it still
has to match the canonical LIST pattern.
Note 2: When calculating "\Placeholder"/"\HasSubmailboxes"
attributes, it doesn't matter if the submailbox matches
the canonical LIST pattern or not. See also example 9 in
section 5.
The MATCHPARENT option MUST NOT occur as the only selection option,
as it only makes sense when other selection options are also used.
The server MUST return BAD tagged response in such case.
Note, that even if MATCHPARENT option is specified, the client
still MUST be able to handle a case when a "\PlaceHolder"/
"\HasSubmailboxes" is returned and there are no submailboxes
that meet the selection criteria of the given LIST command,
as they can be deleted/renamed after the LIST response was sent,
but before the 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 all matching <<mailboxes?>>. The "\Subscribed" state for all matching mailbox names. The "\Subscribed"
flag MUST be supported and MUST be accurately computed attribute MUST be supported and MUST be accurately computed
when the SUBSCRIBED return option is specified. when the SUBSCRIBED return option is specified.
REMOTE - causes the LIST command to show if the matching <<mailbox>>
is local or remote. The "\Remote" flag MUST be accurately computed
when the REMOTE return option is specified.
Note, that a server implementation that doesn't support
any remote mailboxes is compliant with this specification
as long as it accepts and ignores the REMOTE return option.
CHILDREN - Requests mailbox child information as originally CHILDREN - Requests mailbox child information as originally
proposed in [ChildMbox]. See section 4, below, for details. proposed in [ChildMbox]. See section 4, below, for details.
This option MUST be accepted by all servers, however it MAY This option MUST be accepted by all servers, however it MAY
be ignored. be ignored.
SUBMAILBOXES - when this option is specified, the "\Placeholder" 3.1. General principals for returning LIST responses
and the "\HasSubmailboxes" flags MUST be accurate. This might
force the server to return information for additional mailboxes.
Note, that even it SUBMAILBOXES option is specified, the client This section outlines several principals that can be used by server
still must be able to handle a case when a "\PlaceHolder"/ implementations of this document to decide if a LIST response should be
"\HasSubmailboxes" is returned and there are no submailboxes returned, as well as how many responses and what kind of information
that meet the selection criteria of the given LIST command, they may contain.
as they can be deleted/renamed after the LIST response was sent,
but before the client had a chance to access them. 1) Exactly one LIST response should be returned for each mailbox
name which matches the canonical LIST pattern.
Server implementors must not assume that clients will be able to
assemble mailbox attributes and other information returned in multiple
LIST responses.
2) There are only two reasons for including a matching mailbox name
in the responses to the LIST command (Note, that the server is allowed
to return unsolicited responses at any time. Such responses are not
governed by this rule):
a) the mailbox name also satisfies the selection criteria;
b) the mailbox name has at least one child mailbox that satisfies
the selection criteria, but doesn't match the canonical LIST
pattern. For more information on this case see the \PlaceHolder
attribute description in Section 3.
3) Attributes returned in the same LIST response must be treated additively.
For example the following response
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed.
3.2. Additional requirements on LISTEXT clients
All clients that support this extension MUST treat an attribute with
a stronger meaning, as implying any attribute that can be inferred from it.
For example, the client must treat presence of the \NoInferiors attribute
as if the \HasNoChildren attribute was also sent by the server.
The following table summarizes inference rules described in section 3.
+--------------------+-------------------+
| returned attribute | implied attribute |
+--------------------+-------------------+
| \NoInferiors | \HasNoChildren |
| \Placeholder | \HasChildren |
| \HasSubmailboxes | \HasChildren |
| \NonExistent | \NoSelect |
+--------------------+-------------------+
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 [ChildMbox]. 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, or MAY ignore the option entirely. specified, or MAY ignore the option entirely.
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.
The Child Mailbox Extension 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 Child Mailbox Extension defines two new attributes that MAY be The 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 client command, the CHILDREN return option is provided to indicate that the client
particularly wants this information. If the CHILDREN return option particularly wants this information. If the CHILDREN return option
is present, the server SHOULD return these attributes even if their is present, the server SHOULD return these attributes even if their
computation is expensive. computation is expensive.
\HasChildren - The presence of this attribute indicates that the \HasChildren - The presence of this attribute indicates that the
mailbox has child mailboxes. mailbox has child mailboxes.
A server SHOULD NOT set this attribute if there are child A server SHOULD NOT set this attribute if there are child
skipping to change at line 386 skipping to change at line 434
compute whether a user has access to all child mailboxes. As compute whether a user has access to all child mailboxes. As
such a client MUST be prepared to accept the \HasChildren such a client MUST be prepared to accept the \HasChildren
attribute as a hint. That is, a mailbox MAY be flagged with the attribute as a hint. That is, a mailbox MAY be flagged with the
\HasChildren attribute, but no child mailboxes will appear in \HasChildren attribute, but no child mailboxes will appear in
the LIST response. the LIST response.
\HasNoChildren - The presence of this attribute indicates that the \HasNoChildren - The presence of this attribute indicates that the
mailbox has NO child mailboxes that are accessible to the mailbox has NO child mailboxes that are accessible to the
currently authenticated user. currently authenticated user.
In some instances a server that supports the Child Mailbox Extension In some instances a server that supports the LISTEXT extension
might not be able to determine whether a mailbox has children. For might not be able to determine whether a mailbox has children. For
example it may have difficulty determining whether there are child example it may have difficulty determining whether there are child
mailboxes when LISTing mailboxes while operating in a particular mailboxes when LISTing mailboxes while operating in a particular
namespace. namespace.
In 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 match 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
match option, and they will simply ignore the CHILDREN return option selection option, and they will simply ignore the CHILDREN return option
if both are requested. It is an error for the server to return both a if both are requested. It is an error for the server to return both a
\HasChildren and a \HasNoChildren attribute in a LIST response. \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
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.
Example 1:
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
In the next example, we'll see the subscribed mailboxes. This is In the next example, we'll see the subscribed mailboxes. This is
similar, but not equivalent, to <LSUB "" "*">. Note that the mailbox similar, but not equivalent, to <LSUB "" "*">. Note that the mailbox
called "Fruit/Peach" is subscribed to, but does not actually exist called "Fruit/Peach" is subscribed to, but does not actually exist
(perhaps it was deleted while still subscribed). The "Fruit" (perhaps it was deleted while still subscribed). The "Fruit"
mailbox is not subscribed to, but it has two subscribed children. mailbox is not subscribed to, but it has two subscribed children.
The "Vegetable" mailbox is subscribed and has two children, one The "Vegetable" mailbox is subscribed and has two children, one
of them is subscribed as well. of them is subscribed as well.
Example 2:
C: A02 LIST (SUBSCRIBED) "" "*" C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\PlaceHolder) "/" "Fruit" S: * LIST (\PlaceHolder) "/" "Fruit"
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 \HasSubmailboxes) "/" "Vegetable" S: * LIST (\Subscribed \HasSubmailboxes) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: A02 OK done S: A02 OK done
The next example shows the use of the CHILDREN option. The client, The next example shows the use of the CHILDREN option. The client,
without having to list the second level of hierarchy, now knows which without having to list the second level of hierarchy, now knows which
of the top-level mailboxes have sub-mailboxes (children) and which do of the top-level mailboxes have sub-mailboxes (children) and which do
not. Note that it's not necessary for the server to return the not. Note that it's not necessary for the server to return the
\HasNoChildren flag for the inbox, because the \NoInferiors flag \HasNoChildren attribute for the inbox, because the \NoInferiors attribute
already implies that, and has a stronger meaning. already implies that, and has a stronger meaning.
Example 3:
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
In this example we see more mailboxes, which reside on another server In this example we see more mailboxes, which reside on another server
to which we may obtain referrals. This is similar to the command to which we may obtain referrals. This is similar to the command
<RLIST "" "%">. Note that in the case of the remote mailboxes, the <RLIST "" "%">. Note that in the case of the remote mailboxes, the
server might or might not be able to include CHILDREN information; server might or might not be able to include CHILDREN information;
it includes it if it can, and omits it if it can't. it includes it if it can, and omits it if it can't.
Example 4:
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
The following example also requests the server to include mailboxes, The following example also requests the server to include mailboxes,
which reside on another server. The server returns information about which reside on another server. The server returns information about
all mailboxes which are subscribed. This is similar to the command all mailboxes which are subscribed. This is similar to the command
<RLSUB "" "%">. We also see the mixing of two match options. <RLSUB "" "%">. We also see the mixing of two selection options.
Example 5:
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
The following example requests the server to include mailboxes, The following example requests the server to include mailboxes,
which reside on another server. The server is requested to return which reside on another server. The server is requested to return
subscription information for all returned mailboxes. This is different subscription information for all returned mailboxes. This is different
from the example above. <<Can we say that the output is a superset from the example above.
of the output in the previous example? What about nonexistent
"Fruit/Peach"?>> Note, that the output of this command is not a superset of the output
in the previous example, as it doesn't include LIST response for the
non-existent "Fruit/Peach".
Example 6:
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 (\Subscribed \NonExistent) "/" "Fruit/Peach">>
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
In the following example the client has specified multiple mailbox In the following example the client has specified multiple mailbox
patterns. patterns. Note, that this example doesn't use the mailbox hierarchy
used in the previous examples.
Example 7:
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
The following example demonstates the difference between \HasChildren
and \PlaceHolder/\SubMailboxes.
Example 8:
Let's assume there is the following hierarchy:
C: C01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Foo"
S: * LIST () "/" "Foo/Bar"
S: * LIST () "/" "Foo/Baz"
S: * LIST () "/" "Moo"
S: C01 OK done
If the client asks RETURN (CHILDREN) it will get:
C: CA3 LIST "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Foo"
S: * LIST (\HasNoChildren) "/" "Moo"
S: CA3 OK done
A). Let's also assume that the mailbox "Foo/Baz" is the only subscribed
mailbox. Then
C: C02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "Foo/Baz"
S: C02 OK done
Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server will
return no mailboxes (as the mailboxes "Moo", "Foo" and "Inbox" are NOT
subscribed). However, if the client issues:
C: C04 LIST (SUBSCRIBED MATCHPARENT) "" "%"
S: * LIST (\PlaceHolder) "/" "Foo"
S: C04 OK done
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
command would return:
S: * LIST (\HasSubmailboxes \Subscribed) "/" "Foo"
or even
S: * LIST (\HasSubmailboxes \HasChildren \Subscribed) "/" "Foo"
(Both \HasSubmailboxes and \PlaceHolder imply \HasChildren, so the latter
doesn't have to be returned)
A2). If we assume instead that the mailbox "Foo" is not part of the
original hierarchy and is not subscribed, the last command will
return
S: * LIST (\PlaceHolder \NonExistent) "/" "Foo"
B). Now, let's assume that no mailbox is subscribed. In this case
the command <LIST (SUBSCRIBED MATCHPARENT) "" "%"> will return
no responses, as there are no subscribed children (although there
"Foo" has children).
C). And finally, let's assume that the mailboxes "Foo" and "Moo" are
subscribed. In this case the command:
LIST (SUBSCRIBED MATCHPARENT) "" "%" RETURN (CHILDREN)
will return:
S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
Which means that the mailbox "Foo" has children, but none of them
is subscribed.
The following example demonstrates the calculation of \PlaceHolder
(or \SubMailboxes) attributes is not affected by the fact that children
mailboxes match the canonical LIST pattern.
Example 9:
Let's assume there is the following hierarchy:
C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2"
S: * LIST () "/" "baz2"
S: * LIST () "/" "baz2/bar2"
S: * LIST () "/" "baz2/bar22"
S: * LIST () "/" "baz2/bar222"
S: * LIST () "/" "eps2"
S: * LIST () "/" "eps2/mamba"
S: * LIST () "/" "quux2/bar2"
S: D01 OK done
And that the following mailboxes are subscribed:
C: D02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2"
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "quux2/bar2"
S: D02 OK done
The client issues the following command first:
C: D03 LIST (MATCHPARENT SUBSCRIBED) "" "*2"
S: * LIST (\PlaceHolder) "/" "foo2"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\PlaceHolder) "/" "baz2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\HasSubmailboxes) "/" "eps2"
S: * LIST (\Subscribed) "/" "quux2/bar2"
S: D03 OK done
and the server may also include
S: * LIST (\PlaceHolder \NonExistent) "/" "quux2"
The \PlaceHolder attribute is returned for mailboxes "foo2" and
"baz2" (and the \HasSubmailboxes is returned for the mailbox "eps2"),
because all of them have subscribed children,
even though for the mailbox "foo2" only one of the two subscribed
children match the pattern, for the mailbox "baz2" all the subscribed
children match the pattern and for the mailbox "eps2" none of the
subscribed children match the pattern.
Note, that if the client issues
C: D03 LIST (MATCHPARENT SUBSCRIBED) "" "*"
S: * LIST (\PlaceHolder) "/" "foo2"
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\PlaceHolder) "/" "baz2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\HasSubmailboxes) "/" "eps2"
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "quux2/bar2"
S: D03 OK done
the mailboxes "foo2", "baz2" and "eps2" still have the same
\PlaceHolder/\HasSubmailboxes attribute, even though this information
is redundant and the client can determine it by itself.
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]. "vendor-token" is defined in [ACAP].
child-mbox-flag = "\HasChildren" / "\HasNoChildren" child-mbox-flag = "\HasChildren" / "\HasNoChildren"
; flags for Child Mailbox Extension, at most one ; attributes for CHILDREN return option, at most one
; possible per LIST response ; possible per LIST response
list = "LIST" [SP list-match-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-match-opts = "(" [match-option *(SP match-option)] ")" list-select-opts = "(" [list-select-option *(SP list-select-option)] ")"
; list match options, e.g. REMOTE ; list selection options, e.g. REMOTE
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
mparent-mbox-flag = "\PlaceHolder" / "\HasSubmailboxes"
; attributes for MATCHPARENT selection option,
; at most one possible per LIST response
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
skipping to change at line 564 skipping to change at line 787
; a vendor specific tag for extended list data ; a vendor specific tag for extended list data
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.
nstring-list = nstring / nstring-list = nstring /
"(" [nstring-list *(SP nstring-list)] ")" "(" [nstring-list *(SP nstring-list)] ")"
;; a recursive list definition ;; a recursive list definition
mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\PlaceHolder" / mbox-list-oflag = child-mbox-flag / mparent-mbox-flag / "\NonExistent" /
"\HasSubmailboxes" / "\Subscribed" / "\Remote" / "\Subscribed" / "\Remote"
match-option = "SUBSCRIBED" / "REMOTE" / option-extension list-select-option = "SUBSCRIBED" / "REMOTE" / "MATCHPARENT" /
; An option registration template is described in section option-extension
; 8.3 of this document. ; An option registration template is described in
; section 8.3 of this document.
return-option = "SUBSCRIBED" / "REMOTE" / "CHILDREN" / "SUBMAILBOXES" / return-option = "SUBSCRIBED" / "CHILDREN" /
option-extension option-extension
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
skipping to change at line 685 skipping to change at line 909
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 options/extended data items
which are on the IETF standards track. 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 MATCH or RETURN) LISTEXT option type: (One of SELECTION or RETURN)
<<Implied return options(s) if the option type is MATCH?>> 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)
skipping to change at line 717 skipping to change at line 941
It is requested that the LISTEXT option registry is being populated It is requested that the LISTEXT option registry is being populated
with the following entries: with the following entries:
1) 1)
To: iana@iana.org 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: MATCH LISTEXT option type: SELECTION
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 : this RFC, section 3.
Security considerations: this RFC, section 7. Security considerations: this RFC, section 7.
Intended usage: COMMON Intended usage: COMMON
skipping to change at line 740 skipping to change at line 966
Owner/Change controller: IESG <iesg@ietf.org> Owner/Change controller: IESG <iesg@ietf.org>
2) 2)
To: iana@iana.org 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: MATCH LISTEXT option type: SELECTION
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 : this RFC, section 3.
Security considerations: this RFC, section 7. Security considerations: this RFC, section 7.
Intended usage: COMMON Intended usage: COMMON
skipping to change at line 783 skipping to change at line 1011
Intended usage: COMMON Intended usage: COMMON
Person & email address to contact for further information: Person & 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 <iesg@ietf.org>
4) 4)
To: iana@iana.org To: iana@iana.org
Subject: Registration of LISTEXT option REMOTE Subject: Registration of LISTEXT option MATCHPARENT
LISTEXT option name: REMOTE
LISTEXT option type: MATCH
LISTEXT option description: causes the LIST command to return
if the mailbox is local or remote, as described in
RFC 2193.
Published specification : this RFC, section 3.
Security considerations: this RFC, section 7.
Intended usage: COMMON
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: IESG <iesg@ietf.org>
5)
To: iana@iana.org LISTEXT option name: MATCHPARENT
Subject: Registration of LISTEXT option SUBMAILBOXES
LISTEXT option name: SUBMAILBOXES LISTEXT option type: SELECTION
LISTEXT option type: RETURN Implied return options(s): (none)
LISTEXT option description: Requests that \Placeholder/ LISTEXT option description: Requests that \Placeholder/
\HasSubmailboxes flags are to be accurately computed. \HasSubmailboxes attributes are to be accurately computed.
Published specification : this RFC, sections 3. Published specification : this RFC, sections 3.
Published specification : this RFC Published specification : this RFC
Security considerations: this RFC, section 7. Security considerations: this RFC, section 7.
Intended usage: COMMON Intended usage: COMMON
Person & email address to contact for further information: Person & 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 <iesg@ietf.org>
6) 5)
To: iana@iana.org 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.
skipping to change at line 907 skipping to change at line 1113
[ACAP] Newman, C. and J. Myers, "ACAP -- Application [ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
10. Acknowledgements 10. Acknowledgements
Mike Gahrns and Raymond Cheng of Microsoft Corporation originally Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
devised the Child Mailbox Extension and proposed it in 1997; the devised the Child Mailbox Extension and proposed it in 1997; the
idea, as well as most of the text in section 4, is theirs. idea, as well as most of the text in section 4, is theirs.
This document is the result of discussions on the IMAP4 mailing list This document is the result of discussions on the IMAP4 and IMAPEXT
and is meant to reflect consensus of this group. In particular, mailing lists and is meant to reflect consensus of those groups.
Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen, In particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen,
Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry
Greenfield and Pete Maclean were active participants Greenfield, Dave Cridland and Pete Maclean were active participants
in this discussion or made suggestions to this document. in this discussion or made suggestions to this document.
11. Author's Address 11. Author's Address
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 Phone: 1-914-784-7941
Email: leiba@watson.ibm.com Email: leiba@watson.ibm.com
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex Hampton, Middlesex
TW12 2BX, UK TW12 2BX, UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/ Home page: http://www.melnikov.ca/
12. IPR Disclosure Acknowledgement 12. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 and any of which we become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
13. Intellectual Property 13. Intellectual Property
 End of changes. 

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