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