--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / uw-imap / commitdiff