Network Working Group                              M. Gahrns, Microsoft
                                                   J. Myers
                                      J. De Winter, Wildbear Consulting
Internet Draft
Document: draft-gahrns-imap-namespace-00.txt                April 1997


                          IMAP4 Namespace


Status of this Memo

   This document is an Internet Draft.  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 may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.

   A revised version of this draft document will be submitted to the
   RFC editor as a Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested.  This
   document will expire before October 1997. Distribution of this draft
   is unlimited.


1. Abstract

   IMAP4[RFC-2060] does not define a default mailbox namespace and
   hierarchy.  As such, server behavior regarding namespaces can
   differ, creating difficulties for certain client operations.

   This document defines a #personal namespace for identifying a user's
   personal mailbox scope and a CANONICAL command that allows the
   discovery of the preferred name of a mailbox within the server's
   default mailbox hierarchy.

   By using the #personal namespace, a client is able to automatically
   create or access a mailbox without first configuring a server
   specific personal mailbox prefix.  For example, many clients often
   create at initial start up time a "Sent Mail" or "Draft" mailbox.

   In addition, the #personal mailbox namespace allows a client to
   present a view to the user that is completely restricted to the
   user's personal folders without displaying any shared mailboxes.

Gahrns, Myers and De Winter                                          1

                           IMAP4 Namespace                 April 1997


   By using the CANONICAL command, a client is able to determine where
   a mailbox exists in the server's entire default mailbox hierarchy.
   Used in conjunction with #personal namespace, a graphical client is
   able to display a server's entire default hierarchy, starting the
   user at their personal space.


2. Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   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].


3. Introduction and Overview

   A mailbox can be known by different names.  For example, for the
   user authenticated as joe, the mailbox INBOX could also be known as
   /var/spool/mail/joe.  A mailbox can also exist in more than one
   namespace.  For example, the mailbox #news.comp.mail.imap could also
   be known as "#shared/internet newsgroups/comp/mail/imap".

   The canonical name of a mailbox is the server's preferred name of
   the mailbox within the server's default hierarchy.

   The canonical name of a mailbox MAY be different for different
   logged on users.  For example, for the user logged on as "joe", the
   canonical name of their INBOX mailbox may be "INBOX".  The canonical
   name of this same mailbox could be "users.joe.INBOX" for any other
   user not logged on as "joe".


4. Requirements

   IMAP4 servers that support this extension MUST list the keyword
   CANONICAL in their CAPABILITY response.  A server that implements
   the CANONICAL command MUST also define a #personal namespace.

   If a mailbox has multiple names, a subscription to any one of the
   mailbox names SHOULD result in a subscription to the canonical name
   of the mailbox.


5. #personal namespace


   #personal is the namespace that the server considers within the
   personal scope of the authenticated user on a particular connection.
   Servers defining this namespace MUST use "/" as the hierachy


Gahrns, Myers and De Winter                                          2

                           IMAP4 Namespace                 April 1997


   separator within the #personal namespace.  Servers MAY use use
   different hierarchy separators outside the #personal namespace.

   IMAP4 defines INBOX as a special mailbox reserved to mean 'the
   primary mailbox for this user on this server'.  If this mailbox
   exists on the server, it MAY also appear in the #personal namespace
   as #personal/INBOX.

   Typically, no other users will have access to the mailboxes within
   the #personal namespace unless the user has explicitly granted
   access rights to other users.

   By defining a #personal namespace, servers allow clients the ability
   to create personal scope mailboxes or limit a list response to
   personal scope mailboxes, without regard to the underlying default
   mailbox hierarchy a server has choosen.

   Example:

       C: A001 CREATE "#personal/sent mail"
       S: A001 OK CREATE completed

       C: A002 LIST "" "#personal/%"
       S: * LIST () "/" "#personal/INBOX"
       S: * LIST () "/" "#personal/sent mail"
       S: A002 OK LIST completed


6. CANONICAL Command

   Argument:  namespace or mailbox name

   Responses: LIST response for the canonical mailbox name

   Result:    OK - Command completed
              NO - Error: Can't complete command
              BAD - argument invalid

   The CANONICAL command calculates the canonical name of the mailbox
   and generates an untagged LIST response as if a LIST command were
   issued with an empty reference argument and the canonical name of
   the mailbox as the pattern.












Gahrns, Myers and De Winter                                          3

                           IMAP4 Namespace                 April 1997


   Example:

      Consider a server with a default hierarchy as follows:

      The user's personal scope starts at the INBOX mailbox.
      Personal mailboxes are created as inferiors to INBOX, with "."
      as the hierarchy delimiter.
      Shared mailboxes are created at the same level as INBOX.

      INBOX
      INBOX.<Any Personal mailboxes>
      <Any Shared mailboxes>


      C: A001 CANONICAL #personal
      S: * LIST () "." "INBOX"
      S: A001 OK Completed

      C: A002 CANONICAL #personal/foo
      S: * LIST () "." "INBOX.foo"
      S: A002 OK Completed

      C: A003 CANONICAL foo
      S: * LIST () "." "foo"
      S: A003 OK Completed

   Example:

      Consider a server with a default hierarchy that starts right at
      the user's #personal namespace. In this example, #personal does
      not translate to a selectable mailbox.

      C: A001 CANONICAL #personal
      S: * LIST (\Noselect) "/" ""
      S: A001 OK Completed

      C: A002 CANONICAL "#personal/foo"
      S: * LIST (\Noinferiors) "/" "foo"
      S: A002 OK

      C: A003 CANONICAL "#personal/inbox"
      S: * LIST () "/" "inbox"
      S: A003 OK


   Example:

      Consider a mailbox that is known by two different names.
      CANONICAL returns the same canonical name for each.

      C: A001 CANONICAL #news.alt.comp.mail.imap
      S: * LIST () "/" "public/internet news/alt/comp/mail/imap"
      S: A001 OK CANONICAL completed


Gahrns, Myers and De Winter                                          4

                           IMAP4 Namespace                 April 1997


      C: A002 CANONICAL "public folders/internet news/alt/comp/imap"
      S: * LIST () "/" "public folders/internet news/alt/comp/imap"
      S: A002 OK CANONICAL completed

   Example:

      Using the CANONICAL command, a graphical client can discover
      where in the exposed default hierarchy it should present the
      user's personal mailboxes. Using the LIST command, the graphical
      client can complete the display of a "tree" control that shows
      the initial set of mailboxes a client has access to.

      C: A001 CANONICAL #personal
      S: * list () "/" "All/Users/Joe"
      S: A001 OK CANONICAL completed

      To complete the tree view, the client issues a LIST % command on
      each hierarchy above the personal scope so that it can gather the
      information needed to complete the display of the "tree" control.

      C: A002 LIST "" "All/Users/%"
      S: * LIST () "" "All/Users/Joe"
      S: * LIST () "" "All/Users/Fred"
      S: A002 OK LIST completed

      C: A003 LIST "" "All/%"
      S: * LIST (\Noselect) "" "Users"
      S: * LIST (\Noselect) "" "Shared"
      S: A003 OK LIST completed.

      The client now has gathered enough information so that it could
      display to the user a "tree" control such as:

      All
         Users
            +Joe
            +Fred
         +Shared

      Where lower level of hierarchy is denoted by indentation, and "+"
      indicates a hierarchy level that has not yet been expanded by the
      user.


7. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].

   Canonical = "CANONICAL" SPACE mailbox

   mailbox = <mailbox>
             ; <mailbox as defined in [RFC-2060]

Gahrns, Myers and De Winter                                          5

                           IMAP4 Namespace                 April 1997




8. Security Considerations

   This extension does not impose any security considerations over and
   above those discussed in [RFC-2060].


9. References

   [RFC-2060], Crispin, M., "Internet Message Access Protocol – Version
   4rev1", RFC 2060, University of Washington, December 1996.

   [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997

   [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
   Syntax Specifications: ABNF", draft-drums-abnf-02.txt (work in
   progress), Internet Mail Consortium, April 1997


10.  Acknowledgments

   Randy Gellens, Steve Hole, Andrew McCown, Larry Osterman, and Sam
   Weiler contributed to this document.


11. Author's Addresses

   Mike Gahrns
   Microsoft
   One Microsoft Way
   Redmond, WA, 98072
   Phone: (206) 936-9833
   Email: mikega@microsoft.com

   John G. Myers
   220 Palo Alto Ave., Apt 102
   Palo Alto, CA 94301
   Email: jgm@cmu.edu

   Jack De Winter
   Wildbear Consulting, Inc
   96 Rankin Street
   Waterloo, Ontario, Canada
   N2V 2B6
   Email: jack@wildbear.on.ca







Gahrns, Myers and De Winter                                          6