The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
RFC 3348
Document | Type |
RFC - Informational
(July 2002; Errata)
Obsoleted by RFC 5258
Was draft-gahrns-imap-child-mailbox (individual in app area)
|
|
---|---|---|---|
Authors | Raymond Cheng , Mike Gahrns | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3348 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ned Freed | ||
IESG note | Responsible: Finished | ||
Send notices to | (None) |
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 computeShow full document text