draft-ietf-imapext-list-extensions-06.txt   draft-ietf-imapext-list-extensions-07.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
Document: draft-ietf-imapext-list-extensions-06.txt May 2004 A. Melnikov (Ed.)
Expires November 2004 Isode Limited
Expires January 2004 July 2004
IMAP4 LIST Command Extensions IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-07.txt
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. Internet-Drafts are working patent or other IPR claims of which I am aware have been disclosed, or
documents of the Internet Engineering Task Force (IETF), its areas, will be disclosed, and any of which I become aware will be disclosed,
and its working groups. Note that other groups may also distribute in accordance with RFC 3668.
working documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
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.
skipping to change at line 57 skipping to change at line 63
exponential increase in specialized list commands. exponential increase in specialized list commands.
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 [Keywords].
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.
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: if the first word after the command
name begins with a parenthesis, the new syntax is being used; if it name begins with a parenthesis, the new syntax is being used; if it
does not, it's in the original syntax. does not, it's in the original syntax.
skipping to change at line 86 skipping to change at line 98
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 "LISTEXT". The LISTEXT extension makes the capability string "LISTEXT". The 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. adds LIST command options: SUBSCRIBED, REMOTE and CHILDREN b. adds LIST command options: SUBSCRIBED, REMOTE and CHILDREN
c. adds new mailbox flags "\NonExistent", "\PlaceHolder", c. adds new mailbox flags "\NonExistent", "\PlaceHolder",
"\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
The LIST command syntax is extended by adding a parenthesized list of The LIST command syntax is extended by adding a parenthesized list of
command options between the command name and the reference name (see command options between the command name and the reference name (see
the formal syntax in section 6 for specific details). Command the formal syntax in section 6 for specific details). Command
options will be defined in this document and in approved extension options will be defined in this document and in approved extension
documents; each option will be enabled by a capability string (one documents; each option will be enabled by a capability string (one
capability may enable multiple options), and a client MUST NOT send capability may enable multiple options), and a client MUST NOT send
an option for which the server has not advertised support. A server 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.
skipping to change at line 123 skipping to change at line 169
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 syntatic 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 "\PlaceHolder" flag indicates that the designated mailbox does not
meet the selection criteria of the given LIST command, but that it
has one or more child mailbox that might (unspecified whether any,
all, or none match the canonical LIST pattern).
The LSUB command indicates this condition by using the "\NoSelect"
flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since
"\NoSelect" retains its original meaning here. Further, the
"\PlaceHolder" flag is more general, in that it can be used with any
extended set of selection criteria.
The "\HasSubmailboxes" flag indicates that the designated mailbox meets
the selection criteria of the given LIST command and also has one or more child
mailbox that might (unspecified whether any, all, or none match the canonical
LIST pattern).
Absence of both \PlaceHolder and \HasSubmailboxes means that the mailbox
meets the selection criterion, but doesn't have any children that also
meet the selection criterion and don't match the canonical LIST pattern.
However, absence of both \PlaceHolder and \HasSubmailboxes doesn't tell
whether there are any children that meet the selection criterion and match
the canonical LIST pattern.
<<We probably need an example to illustrate this>>
The SUBMAILBOXES option described below REQUIRES that the "\Placeholder"
and the "\HasSubmailboxes" flags be accurately computed.
The "\Placeholder"/""\HasSubmailboxes" flag implies "\HasChildren".
The "\NonExistent" flag indicates that a mailbox does not actually exist.
Note that this flag is not meaningful by itself, as mailboxes that match
the canonical LIST pattern but don't exist must not be returned unless one
of the two conditions listed below is also satisfied:
a) the mailbox also satisfy the selection criteria
b) the mailbox has at least one child mailbox that satisfies the selection
criteria, but doesn't match the canonical LIST pattern.
In practice this means that the "\NonExistent" flag is usually returned
with one or more of \PlaceHolder/\HasSubmailboxes, \Subscribed, \Remote
(see there description below).
The "\NonExistent" flag implies "\NoSelect".
The "\NonExistent" flag MUST be supported and MUST be accurately computed.
The following table summarizes when \NonExistent, \PlaceHolder or
\HasSubmailboxes flags are to be returned:
+------+------------+---------------------+--------------------------------+
|exists| meets the | has a child that | returned |
| | selection | meets the selection | LISTEXT flags |
| | criteria | criteria | |
+------+------------+---------------------+--------------------------------+
| no | no | no | no LIST response returned |
| yes | no | no | no LIST response returned |
| no | yes | no | (\NonExistent) |
| yes | yes | no | () |
| no | no | yes | (\NonExistent \PlaceHolder) |
| yes | no | yes | (\PlaceHolder) |
| no | yes | yes | (\NonExistent \HasSubmailboxes)|
| yes | yes | yes | (\HasSubmailboxes) |
+------+------------+---------------------+--------------------------------+
The options defined in this specification are The 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 mailboxes, 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 selection criteria and are subscribed to. This that match the selection criteria 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 flags as returned by this
skipping to change at line 146 skipping to change at line 259
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 option described here, the flags are accurate the SUBSCRIBED option described here, the flags are accurate
and complete, and have no special meanings. 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, "\NonExistent", that This option defines a new mailbox flag, "\Subscribed" that
indicates that a mailbox is subscribed to, but does not indicates that a mailbox is subscribed to. The "\Subscribed"
actually exist. The "\NonExistent" flag MUST be supported and flag MUST be supported and MUST be accurately computed
MUST be accurately computed. when the SUBSCRIBED option is specified.
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 option, the RLSUB command. This option is with the SUBSCRIBED option, the RLSUB command. This option is
only available on servers that also support RFC 2193. only available on servers that also support RFC 2193.
This option defines a new mailbox flag, "\Remote", that
indicates that a mailbox is a remote mailbox. The "\Remote"
flag MUST be accurately computed when the REMOTE 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 option.
SUBMAILBOXES - when this option is specified, the "\Placeholder"
and the "\HasSubmailboxes" flags MUST be accurate.
Note, that even it SUBMAILBOXES 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.
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.
Support for this is optional, but this option MUST be accepted This option MUST be accepted by all servers, however it MAY
by all servers (though it MAY be ignored). be ignored.
The LISTEXT capability also defines a new mailbox flag,
"\PlaceHolder", that indicates that the designated mailbox does not
meet the selection criteria of the given LIST command, but that it
has one or more child mailboxes that do <<EDITORIAL NOTE: "might"?>>.
The LSUB command indicates this condition by using the "\NoSelect"
flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since
"\NoSelect" retains its original meaning here. Further, the
"\PlaceHolder" flag is more general, in that it can be used with any
extended set of selection criteria.
4. The CHILDREN Option 4. The CHILDREN Option
The CHILDREN option implements the Child Mailbox Extension, The CHILDREN 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
option is simply an indication that the client wants this 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.
skipping to change at line 202 skipping to change at line 324
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 Child Mailbox Extension 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 option is provided to indicate that the client command, the CHILDREN option is provided to indicate that the client
particularly wants this information. If the CHILDREN option is particularly wants this information. If the CHILDREN option is
present, the server SHOULD return these attributes even if their 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 mailbox \HasChildren - The presence of this attribute indicates that the
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
mailboxes, and the user does not have permissions to access any mailboxes, and the user does not have permissions to access any
of them. In this case, \HasNoChildren SHOULD be used. of them. In this case, \HasNoChildren SHOULD be used.
In many cases, however, a server may not be able to efficiently In many cases, however, a server may not be able to efficiently
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.
skipping to change at line 250 skipping to change at line 372
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: 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). And 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
of them is subscribed as well.
C: A02 LIST (SUBSCRIBED) "" "*" C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\PlaceHolder) "/" "Fruit" S: * LIST (\PlaceHolder) "/" "Fruit"
S: * LIST () "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed \HasSubmailboxes) "/" "Vegetable"
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 flag for the inbox, because the \NoInferiors flag
already implies that, and has a stronger meaning. already implies that, and has a stronger meaning.
C: A03 LIST (CHILDREN) "" "%" C: A03 LIST (CHILDREN) "" "%"
skipping to change at line 291 skipping to change at line 418
<RLIST "" "%">. We also see the mixing of two options. Note that in <RLIST "" "%">. We also see the mixing of two options. Note that in
the case of the remote mailboxes, the server might or might not be the case of the remote mailboxes, the server might or might not be
able to include CHILDREN information; it includes it if it can, and able to include CHILDREN information; it includes it if it can, and
omits it if it can't. omits it if it can't.
C: A04 LIST (REMOTE CHILDREN) "" "%" C: A04 LIST (REMOTE 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 () "/" "Bread" S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren) "/" "Meat" S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done S: A04 OK done
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF]. Terms not defined here are taken Form (BNF) as described in [ABNF]. Terms not defined here are taken
from [IMAP4]. from [IMAP4]. "vendor-token" is defined in [ACAP].
child-mbox-flag = "\HasChildren" / "\HasNoChildren" child-mbox-flag = "\HasChildren" / "\HasNoChildren"
; flags for Child Mailbox Extension, at most one ; flags for Child Mailbox Extension, at most one
; possible per LIST response ; possible per LIST response
list = "LIST" [SP list-options] SP mailbox SP list-mailbox list = "LIST" [SP list-options] SP mailbox SP list-mailbox
list-options = "(" [option *(SP option)] ")" list-options = "(" [option *(SP option)] ")"
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 = vendor-tag / standard-tag mbox-list-extended-item-tag = astring
; The content MUST conform to either "eitem-vendor-tag" or
; "eitem-standard-tag" ABNF productions.
; A tag registration template is described in section ; A tag registration template is described in section
; 8.5 of this document. ; 8.5 of this document.
vendor-tag = "V-" atom eitem-vendor-tag = vendor-tag
; a vendor specific tag for extended list data ; a vendor specific tag for extended list data
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 / "\NonExistent" / "\PlaceHolder" /
"\HasSubmailboxes" / "\Subscribed" / "\Remote"
option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / "SUBMAILBOXES" /
option-extension option-extension
; An option registration template is described in section ; An option registration template is described in section
; 8.3 of this document. ; 8.3 of this document.
option-extension = option-vendor / option-public option-extension = option-vendor-tag / option-standard-tag
option-vendor = "V-" atom option-vendor-tag = vendor-tag
; a vendor specific option ; a vendor specific option
option-public = 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
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 [MboxRefer].
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
skipping to change at line 395 skipping to change at line 527
template in section 8.5 and sending it via electronic mail to <iana@iana.org>. template in section 8.5 and sending it via electronic mail to <iana@iana.org>.
IANA has the right to reject obviously bogus registrations, but will IANA has the right to reject obviously bogus registrations, but will
perform no review of claims made in the registration form. 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 reserved
for vendor specific options/extended data items. All options, whether for vendor specific options/extended data items. All options, whether
they are vendor specific or global, should be registered with IANA. they are vendor specific or global, should be registered with IANA.
If a LISTEXT extended data item is returned as a result of requesting If a LISTEXT extended data item is returned as a result of requesting
a particular LISTEXT option, the name of the option SHOULD be used a particular LISTEXT option, the name of the option SHOULD be used
as the name of the LISTEXT extended data item. as the name of the LISTEXT extended data item.
LISTEXT option/extended data item names are case insensitive.
Each vendor specific options/extended data item MUST start with their
vendor-token ("vendor prefix"). The vendor-token MUST be registered
with IANA, using the [ACAP] vendor subtree registry.
Standard LISTEXT option/extended data item names are case insensitive.
If the vendor prefix is omitted from a vendor specific LISTEXT
option/extended data item name, the rest is case insensitive. The vendor
prefix itself is not case-sensitive, as it might contain non-ASCII
characters.
While the registration procedures do not require it, authors of LISTEXT While the registration procedures do not require it, authors of LISTEXT
options/extended data items are encouraged to seek community review and options/extended data items are encouraged to seek community review and
comment whenever that is feasible. Authors may seek community review by comment whenever that is feasible. Authors may seek community review by
posting a specification of their proposed mechanism as an Internet- posting a specification of their proposed mechanism as an Internet-
Draft. LISTEXT options/extended data items intended for widespread use Draft. LISTEXT options/extended data items intended for widespread use
should be standardized through the normal IETF process, when appropriate. 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 WG
skipping to change at line 509 skipping to change at line 650
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>
3) 3)
To: iana@iana.org To: iana@iana.org
Subject: Registration of LISTEXT option SUBMAILBOXES
LISTEXT option name: SUBMAILBOXES
LISTEXT option description: Requests that \Placeholder/
\HasSubmailboxes flags are to be accurately computed.
Published specification : this RFC, sections 3.
Published specification : this RFC
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>
4)
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 description: Requests mailbox child information. LISTEXT option description: Requests mailbox child information.
Published specification : this RFC, sections 3 and 4. Published specification : this RFC, sections 3 and 4.
Published specification : this RFC Published specification : this RFC
skipping to change at line 558 skipping to change at line 722
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 below this line.) added below this line.)
9. References 9. References
9.1. Normative References 9.1. Normative References
[Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate [Keywords] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels"; RFC 2119; Harvard University; March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
[ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, March 2003. 4rev1", RFC 3501, University of Washington, March 2003.
[MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193; [MboxRefer] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
Microsoft Corporation; September 1997. Microsoft Corporation, September 1997.
[ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension"; [ChildMbox] Gahrns, M. & Cheng, R., "IMAP4 Child Mailbox Extension",
RFC 3348; Microsoft Corporation; July 2002. RFC 3348, Microsoft Corporation, July 2002.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
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 mailing list
and is meant to reflect consensus of this group. In particular, and is meant to reflect consensus of this group. In particular,
Mark Crispin, Cyrus Daboo, Timo Sirainen, Ken Murchison, Alexey Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen,
Melnikov, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry
Greenfield, Phlip Guenther and Pete Maclean were active participants Greenfield 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
12. Full Copyright Statement Alexey Melnikov (Editor)
Isode Limited
Copyright (C) The Internet Society 2004. All Rights Reserved. 5 Castle Business Village
36 Station Road
This document and translations of it may be copied and furnished to Hampton, Middlesex
others, and derivative works that comment on or otherwise explain it TW12 2BX, UK
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an Email: Alexey.Melnikov@isode.com
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING URI: http://www.melnikov.ca/
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 12. IPR Disclosure Acknowledgement
Funding for the RFC Editor function is currently provided by By submitting this Internet-Draft, we certify that any applicable
the Internet Society. 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 13. Intellectual Property
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
skipping to change at line 651 skipping to change at line 802
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
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/