mirror of
https://github.com/uw-imap/imap.git
synced 2024-11-16 18:38:21 +01:00
340 lines
12 KiB
Plaintext
340 lines
12 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group M. Gahrns
|
||
Request for Comments: 3348 R. Cheng
|
||
Category: Informational Microsoft
|
||
July 2002
|
||
|
||
|
||
The Internet Message Action Protocol (IMAP4)
|
||
Child Mailbox Extension
|
||
|
||
Status of this Memo
|
||
|
||
This memo provides information for the Internet community. It does
|
||
not specify an Internet standard of any kind. Distribution of this
|
||
memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
The Internet Message Action Protocol (IMAP4) CHILDREN extension
|
||
provides a mechanism for a client to efficiently determine if a
|
||
particular mailbox has children, without issuing a LIST "" * or a
|
||
LIST "" % for each mailbox.
|
||
|
||
1. Conventions used in this document
|
||
|
||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||
server respectively. If such lines are wrapped without a new "C:" or
|
||
"S:" label, then the wrapping is for editorial clarity and is not
|
||
part of the command.
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC-2119].
|
||
|
||
2. Introduction and Overview
|
||
|
||
Many IMAP4 [RFC-2060] clients present to the user a hierarchical view
|
||
of the mailboxes that a user has access to. Rather than initially
|
||
presenting to the user the entire mailbox hierarchy, it is often
|
||
preferable to show to the user a collapsed outline list of the
|
||
mailbox hierarchy (particularly if there is a large number of
|
||
mailboxes). The user can then expand the collapsed outline hierarchy
|
||
as needed. It is common to include within the collapsed hierarchy a
|
||
|
||
|
||
|
||
|
||
|
||
Gahrns, et al. Informational [Page 1]
|
||
|
||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||
|
||
|
||
visual clue (such as a "+") to indicate that there are child
|
||
mailboxes under a particular mailbox. When the visual clue is
|
||
clicked the hierarchy list is expanded to show the child mailboxes.
|
||
|
||
Several IMAP vendors implemented this proposal, and it is proposed to
|
||
document this behavior and functionality as an Informational RFC.
|
||
|
||
There is interest in addressing the general extensibility of the IMAP
|
||
LIST command through an IMAP LIST Extension draft. Similar
|
||
functionality to the \HasChildren and \HasNoChildren flags could be
|
||
incorporated into this new LIST Extension. It is proposed that the
|
||
more general LIST Extension draft proceed on the standards track with
|
||
this proposal being relegated to informational status only.
|
||
|
||
If the functionality of the \HasChildren and \HasNoChildren flags
|
||
were incorporated into a more general LIST extension, this would have
|
||
the advantage that a client could then have the opportunity to
|
||
request whether or not the server should return this information.
|
||
This would be an advantage over the current draft for servers where
|
||
this information is expensive to compute, since the server would only
|
||
need to compute the information when it knew that the client
|
||
requesting the information was able to consume it.
|
||
|
||
3. Requirements
|
||
|
||
IMAP4 servers that support this extension MUST list the keyword
|
||
CHILDREN in their CAPABILITY response.
|
||
|
||
The CHILDREN extension defines two new attributes that MAY be
|
||
returned within a LIST response.
|
||
|
||
\HasChildren - The presence of this attribute indicates that the
|
||
mailbox has child mailboxes.
|
||
|
||
Servers SHOULD NOT return \HasChildren if child mailboxes exist, but
|
||
none will be displayed to the current user in a LIST response (as
|
||
should be the case where child mailboxes exist, but a client does not
|
||
have permissions to access them.) In this case, \HasNoChildren
|
||
SHOULD be used.
|
||
|
||
In many cases, however, a server may not be able to efficiently
|
||
compute whether a user has access to all child mailboxes, or multiple
|
||
users may be accessing the same account and simultaneously changing
|
||
the mailbox hierarchy. As such a client MUST be prepared to accept
|
||
the \HasChildren attribute as a hint. That is, a mailbox MAY be
|
||
flagged with the \HasChildren attribute, but no child mailboxes will
|
||
appear in a subsequent LIST response.
|
||
|
||
|
||
|
||
|
||
Gahrns, et al. Informational [Page 2]
|
||
|
||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||
|
||
|
||
Example 3.1:
|
||
============
|
||
|
||
/*** Consider a server that has the following mailbox hierarchy:
|
||
|
||
INBOX
|
||
ITEM_1
|
||
ITEM_1A
|
||
ITEM_2
|
||
TOP_SECRET
|
||
|
||
Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes. ITEM_1A is a
|
||
child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of ITEM_2
|
||
that the currently logged on user does NOT have access to.
|
||
|
||
Note that in this case, the server is not able to efficiently compute
|
||
access rights to child mailboxes and responds with a \HasChildren
|
||
attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not
|
||
appear in the list response. ***/
|
||
|
||
C: A001 LIST "" *
|
||
S: * LIST (\HasNoChildren) "/" INBOX
|
||
S: * LIST (\HasChildren) "/" ITEM_1
|
||
S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A
|
||
S: * LIST (\HasChildren) "/" ITEM_2
|
||
S: A001 OK LIST Completed
|
||
|
||
\HasNoChildren - The presence of this attribute indicates that the
|
||
mailbox has NO child mailboxes that are accessible to the currently
|
||
authenticated user. If a mailbox has the \Noinferiors attribute, the
|
||
\HasNoChildren attribute is redundant and SHOULD be omitted in the
|
||
LIST response.
|
||
|
||
In some instances a server that supports the CHILDREN extension MAY
|
||
NOT be able to determine whether a mailbox has children. For example
|
||
it may have difficulty determining whether there are child mailboxes
|
||
when LISTing mailboxes while operating in a particular namespace.
|
||
|
||
In these cases, a server MAY exclude both the \HasChildren and
|
||
\HasNoChildren attributes in the LIST response. As such, a client
|
||
can not make any assumptions about whether a mailbox has children
|
||
based upon the absence of a single attribute.
|
||
|
||
It is an error for the server to return both a \HasChildren and a
|
||
\HasNoChildren attribute in a LIST response.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gahrns, et al. Informational [Page 3]
|
||
|
||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||
|
||
|
||
It is an error for the server to return both a \HasChildren and a
|
||
\NoInferiors attribute in a LIST response.
|
||
|
||
Note: the \HasNoChildren attribute should not be confused with the
|
||
IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that
|
||
no child mailboxes exist now and none can be created in the future.
|
||
|
||
The \HasChildren and \HasNoChildren attributes might not be returned
|
||
in response to a LSUB response. Many servers maintain a simple
|
||
mailbox subscription list that is not updated when the underlying
|
||
mailbox structure is changed. A client MUST NOT assume that
|
||
hierarchy information will be maintained in the subscription list.
|
||
|
||
RLIST is a command defined in [RFC-2193] that includes in a LIST
|
||
response mailboxes that are accessible only via referral. That is, a
|
||
client must explicitly issue an RLIST command to see a list of these
|
||
mailboxes. Thus in the case where a mailbox has child mailboxes that
|
||
are available only via referral, the mailboxes would appear as
|
||
\HasNoChildren in response to the LIST command, and \HasChildren in
|
||
response to the RLIST command.
|
||
|
||
5. Formal Syntax
|
||
|
||
The following syntax specification uses the augmented Backus-Naur
|
||
Form (BNF) as described in [ABNF].
|
||
|
||
Two new mailbox attributes are defined as flag_extensions to the
|
||
IMAP4 mailbox_list response:
|
||
|
||
HasChildren = "\HasChildren"
|
||
|
||
HasNoChildren = "\HasNoChildren"
|
||
|
||
6. Security Considerations
|
||
|
||
This extension provides a client a more efficient means of
|
||
determining whether a particular mailbox has children. If a mailbox
|
||
has children, but the currently authenticated user does not have
|
||
access to any of them, the server SHOULD respond with a
|
||
\HasNoChildren attribute. In many cases, however, a server may not
|
||
be able to efficiently compute whether a user has access to all child
|
||
mailboxes. If such a server responds with a \HasChildren attribute,
|
||
when in fact the currently authenticated user does not have access to
|
||
any child mailboxes, potentially more information is conveyed about
|
||
the mailbox than intended. A server designed with such levels of
|
||
security in mind SHOULD NOT attach the \HasChildren attribute to a
|
||
mailbox unless the server is certain that the user has access to at
|
||
least one of the child mailboxes.
|
||
|
||
|
||
|
||
Gahrns, et al. Informational [Page 4]
|
||
|
||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||
|
||
|
||
7. References
|
||
|
||
[RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
|
||
4rev1", RFC 2060, December 1996.
|
||
|
||
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC-2234] Crocker, D. and P. Overell, Editors, "Augmented BNF for
|
||
Syntax Specifications: ABNF", RFC 2234, November 1997.
|
||
|
||
[RFC-2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
|
||
1997.
|
||
|
||
8. Acknowledgments
|
||
|
||
The authors would like to thank the participants of several IMC Mail
|
||
Connect events for their input when this idea was originally
|
||
presented and refined.
|
||
|
||
9. Author's Address
|
||
|
||
Mike Gahrns
|
||
Microsoft
|
||
One Microsoft Way
|
||
Redmond, WA, 98052
|
||
Phone: (425) 936-9833
|
||
EMail: mikega@microsoft.com
|
||
|
||
Raymond Cheng
|
||
Microsoft
|
||
One Microsoft Way
|
||
Redmond, WA, 98052
|
||
Phone: (425) 703-4913
|
||
EMail: raych@microsoft.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gahrns, et al. Informational [Page 5]
|
||
|
||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||
|
||
|
||
10. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
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
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
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
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gahrns, et al. Informational [Page 6]
|
||
|