The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
RFC 3348

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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