view Side-By-Side changes
Network Working Group M. Gahrns, Microsoft
J. Myers
J. De Winter, Wildbear Consulting
C. Newman, Innosoft
Internet Draft
Document: draft-gahrns-imap-namespace-00.txt April draft-gahrns-imap-namespace-01.txt June 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 November 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 namespace. As a
result, two common namespace models have evolved:
The "Personal Mailbox" model, in which the default namespace that is
presented consists of only the user's personal mailboxes. To access
shared mailboxes, the user must use an escape mechanism to reach
another namespace.
The "Complete Hierarchy" model, in which the default namespace that
is presented includes the user's personal mailboxes along with any
other mailboxes they have access to.
These two models, create difficulties for certain client operations.
This document defines a #personal namespace for identifying a user's
personal mailbox scope and a CANONICAL NAMESPACE 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
discover the prefixes of namespaces used by a server
specific for 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
mailboxes, other user's mailboxes, and shared mailboxes. This
allows a client to
present a view to avoid much of the manual user configuration that
is completely restricted to the
user's personal folders without displaying any shared mailboxes.
Gahrns, Myers now necessary when mixing and De Winter matching IMAP4 clients and servers.
Gahrns and Newman 1
IMAP4 Namespace April June 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
Personal Namespace: A mailbox can be known by different names. For example, for namespace that the server considers within the
personal scope of the
user authenticated as joe, user on a particular connection.
Typically, only the authenticated user has access to mailboxes in
their Personal Namespace. The specially defined IMAP4 mailbox INBOX could also be known as
/var/spool/mail/joe. A mailbox can also exist
resides in more than one a user's personal namespace.
Other Users' Namespace: A namespace that consists of mailboxes from
the Personal Namespaces of other users. To access mailboxes in the
Other Users' Namespace, the currently authenticated user MUST be
explicitly granted access rights. For example, the mailbox #news.comp.mail.imap could also it is common for a
manager to grant to their secretary access rights to their mailbox.
Shared Namespace: A namespace that consists of mailboxes that are
intended to be known as "#shared/internet newsgroups/comp/mail/imap". shared amongst users and do not exist within a user's
Personal Namespace.
The canonical name 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
Clients often attempt to create mailboxes for such purposes as
maintaining a record of sent messages (e.g. "Sent Mail") or
temporarily saving messages being composed (e.g. "Drafts"). For
these clients to inter-operate correctly with the variety of IMAP4
servers available, the user must enter the prefix of the Personal
Namespace used by the server. Using the NAMESPACE command, a mailbox client
is able to automatically discover this prefix without manual user
configuration.
In addition, users are often required to manually enter the server's preferred name prefixes
of various namespaces in order to view the mailbox within mailboxes located there.
For example, they might be required to enter the server's default hierarchy.
The canonical name prefix of #shared
to view the shared mailboxes namespace. The NAMESPACE command allows
a mailbox MAY be different for different
logged client to automatically discover the namespaces that are available
on users. a server. This allows a client to present the available
namespaces to the user in which ever manner it deems appropriate.
For example, for a client could choose to initially display only
personal mailboxes, or it may choose to display the complete list of
mailboxes available, and initially position the user logged on as "joe", at the
canonical name root of
their INBOX mailbox may be "INBOX". The canonical
name Personal Namespace.
A server MAY choose to make available to the NAMESPACE command only
a subset of the complete set of namespaces the server supports.
Gahrns and Newman 2
IMAP4 Namespace June 1997
4. Requirements
IMAP4 servers that support this same mailbox could be "users.joe.INBOX" for any other
user not logged on extension MUST list the keyword
NAMESPACE in their CAPABILITY response.
5. NAMESPACE Command
Arguments: none
Response: an untagged NAMESPACE response that contains the prefix
to the server's default Personal Namespace, the Other
Users' Namespace, and the Shared Namespace that the
server wishes to expose. The Personal Namespace and
Other User's Namespace prefix are each to a single
namespace, and as "joe".
4. Requirements
IMAP4 servers that support this extension such, MUST list end with the keyword
CANONICAL hierarchy
character used 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 The Shared Namespace
prefix MAY be to any one of multiple namespaces. If the
mailbox names SHOULD result in a subscription Shared
Namespace prefix is to multiple namespaces, the canonical name
of
hierarchy character is not included in the mailbox.
5. #personal prefix.
Result: OK - Command completed
NO - Error: Can't complete command
BAD - argument invalid
If a particular namespace
#personal is not available, the namespace prefix to that the
namespace is NIL.
Example:
< A server considers within that supports only the personal scope of the authenticated namespace. No leading
prefix is used on personal mailboxes. >
C: A001 NAMESPACE
S: * NAMESPACE "" NIL NIL
S: A001 OK NAMESPACE command completed
Example:
< A user logged on anonymously to a particular connection.
Servers defining this namespace server. No personal
mailboxes are associated with the anonymous user. No prefix is
required to access shared mailboxes. >
C: A001 NAMESPACE
S: * NAMESPACE NIL NIL ""
S: A001 OK NAMESPACE command completed
The Personal Namespace prefix returned MUST use "/" as be to a single Personal
Namespace and MUST end with the hierachy
Gahrns, Myers hierarchy character used in that
Gahrns and De Winter 2 Newman 3
IMAP4 Namespace April June 1997
separator within the #personal namespace. Servers MAY use use
different hierarchy separators outside the #personal
namespace.
IMAP4 defines INBOX as This allows 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 client to other users.
By defining a #personal namespace, servers allow clients use the ability Personal Namespace
prefix to automatically create personal scope mailboxes or limit a list response to
personal scope mailboxes, without regard to mailboxes.
Example:
< A server that supports only the underlying default
mailbox hierarchy Personal Namespace, with a server has choosen.
Example:
leading prefix of INBOX to personal mailboxes. >
C: A001 CREATE "#personal/sent mail" NAMESPACE
S: * NAMESPACE "INBOX." NIL NIL
S: A001 OK CREATE NAMESPACE command completed
C: A002 LIST "" "#personal/%"
S: * LIST () "/" "#personal/INBOX"
S: * LIST () "/" "#personal/sent mail" CREATE "INBOX.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 CREATE command
BAD - argument invalid completed
The CANONICAL command calculates the canonical name of the mailbox
and generates an untagged LIST response as if Other Users' Namespace prefix MUST be to a LIST command were
issued with an empty reference argument single Other Users'
Namespace and MUST end with the canonical name hierarchy character used in that
namespace. The next level of hierarchy following the mailbox Other Users'
Namespace prefix SHOULD consist of <username>, where <username> is a
user name as per the pattern.
Gahrns, Myers and De Winter 3 IMAP4 Namespace April 1997
Example:
Consider LOGIN or AUTHENTICATE command.
A client can construct a server with LIST command by appending a default hierarchy as follows:
The user's personal scope starts at "%" to the
Other Users' Namespace prefix to discover the INBOX mailbox. Personal mailboxes Namespaces of
other users that are created as inferiors available to INBOX, with "."
as the hierarchy delimiter.
Shared currently authenticate user.
In response to such a LIST command, a server SHOULD NOT return user
names that have not granted access to their personal mailboxes are created at to
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: * user in question.
A server MAY return a LIST () "." "foo"
S: A003 OK Completed
Example:
Consider response containing only the names of
users that have explicitly granted access to the user in question.
Alternatively, a server with MAY return NO to such a default hierarchy LIST command,
requiring that starts right at a user name be included with the Other Users'
Namespace prefix before listing any other user's #personal namespace. In this example, #personal does
not translate mailboxes.
Example:
< A server that supports providing a list of other user's
mailboxes that are accessible to a selectable mailbox. the currently logged on user. >
C: A001 CANONICAL #personal NAMESPACE
S: * LIST (\Noselect) "/" NAMESPACE "" "Other Users/" NIL
S: A001 OK Completed NAMESPACE command completed
C: A002 CANONICAL "#personal/foo" LIST "" "Other Users/%"
S: * LIST (\Noinferiors) () "/" "foo"
S: A002 OK
C: A003 CANONICAL "#personal/inbox" "Other Users/Mike"
S: * LIST () "/" "inbox" "Other Users/Karen"
S: A003 A002 OK LIST command completed
Gahrns and Newman 4
IMAP4 Namespace June 1997
Example:
Consider
< A server that does not support providing a mailbox list of other user's
mailboxes that is known by two different names.
CANONICAL returns are accessible to the currently logged on user.
The mailboxes are listable if the client includes the same canonical name for each. of the
other user with the Other Users' Namespace prefix. >
C: A001 CANONICAL #news.alt.comp.mail.imap NAMESPACE
S: * LIST () "/" "public/internet news/alt/comp/mail/imap" NAMESPACE "" "#Users/" NIL
S: A001 OK CANONICAL NAMESPACE command completed
Gahrns, Myers and De Winter 4
IMAP4
< In this example, the currently logged on user has access to the
Personal Namespace April 1997 of user Mike, but the server chose to suppress
this information in the LIST response. However, by appending the
user name Mike (received through user input) to the Other Users'
Namespace prefix, the client is able to get a listing of the
personal mailboxes of user Mike. >
C: A002 CANONICAL "public folders/internet news/alt/comp/imap" LIST "" "#Users/%"
S: A002 NO The requested item could not be found.
C: A003 LIST "" "#Users/Mike/%"
S: * LIST () "/" "public folders/internet news/alt/comp/imap" "#Users/Mike/INBOX"
S: A002 * LIST () "/" "#Users/Mike/Foo"
S: A003 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 command completed.
The shared mailboxes prefix MAY be to multiple Shared Namespaces. A
client can complete the display of construct a "tree" control that shows LIST command by appending a "%" to the initial set of mailboxes Shared
Namespace prefix to discover available Shared Namespaces.
Example:
< A server that contains a client has access to. single Shared Namespace. >
C: A001 CANONICAL #personal NAMESPACE
S: * list () "/" "All/Users/Joe" NAMESPACE "" NIL "Public Folders/"
S: A001 OK CANONICAL NAMESPACE command completed
To complete the tree view, the client issues a
C: A002 LIST "" "Public Folders/%"
S: * LIST () "/" "Public Folders/Foo"
S: * LIST () "/" "Public Folders/Bar"
S: A002 OK LIST % command on
each hierarchy above the personal scope so completed.
Example:
< A server that contains multiple Shared Namespaces. Note that it can gather the
information needed to complete the display of
the "tree" control. hierarchy delimiter used within each namespace can be
different. >
C: A002 LIST "" "All/Users/%"
S: * LIST () "" "All/Users/Joe" A001 NAMESPACE
S: * LIST () "" "All/Users/Fred" NAMESPACE "~/mail/" NIL "#"
S: A002 A001 OK LIST NAMESPACE command completed
Gahrns and Newman 5
IMAP4 Namespace June 1997
C: A003 A002 LIST "" "All/%" "#%"
S: * LIST (\Noselect) "" "Users" () "." "#News"
S: * LIST (\Noselect) "" "Shared" () "/" "#Shared"
S: A003 A002 OK LIST command completed.
The client now
Historical convention has gathered enough information so that it could
display been to start all namespaces with 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 "#"
character. Namespaces that has include the "#" character are not yet been expanded by IMAP
URL [IMAP-URL] friendly requiring the
user.
7. "#" character to be
represented as %23 when within URLs. As such, server implementers
MAY instead consider using namespace prefixes that do not contain
the "#" character.
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF].
Canonical
Namespace_Command = "NAMESPACE"
Namespace_Response = "CANONICAL" "*" SPACE mailbox "NAMESPACE" SPACE Prefix SPACE Prefix
SPACE Prefix
; The first prefix is a prefix to the Personal Namespace
; The second prefix is a prefix to the Other Users' Namespace
; The third prefix is a prefix to the Shared Namespace
mailbox = <mailbox>
; <mailbox as defined in [RFC-2060]
Gahrns, Myers and De Winter 5
IMAP4 Namespace April 1997
8.
Prefix = NIL | mailbox
7. Security Considerations
This extension does
In response to a LIST command containing an argument of the Other
Users' Namespace prefix, a server SHOULD NOT list users that have
not impose any granted access to their personal mailboxes to the currently
authenticated user. Providing such a list, could compromise
security considerations over and
above those discussed in [RFC-2060].
9. by potentially disclosing confidential information of who
is located on the server, or providing a starting point of a list of
user accounts to attack.
8. 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
Gahrns and Newman 6
IMAP4 Namespace June 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.
[IMAP-URL], Newman, C., "IMAP URL Scheme", draft-newman-url-imap-
09.txt (work in progress), Innosoft, May 1997
9. Acknowledgments
Randy Gellens,
Many people have participated in the discussion of IMAP namespaces
on the IMAP mailing list. In particular, the authors would like to
thank Mark Crispin for many of the concepts relating to the Personal
Namespace and accessing the Personal Namespace of other users, Steve Hole, Andrew McCown, Larry Osterman,
Hole for summarizing the two namespace models, John Myers and Sam
Weiler contributed Jack
De Winter for their work in a preceding effort trying to define a
standardized personal namespace, and Larry Osterman for his review
and collaboration on this document.
11. Author's Addresses
Mike Gahrns
Microsoft
One Microsoft Way
Redmond, WA, 98072 98072, USA
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
Chris Newman
Innosoft International, Inc.
1050 East Garvey Ave. South
West Covina, CA, 91790, USA
Email: jack@wildbear.on.ca
Gahrns, Myers chris.newman@innosoft.com
Gahrns and De Winter 6 Newman 7
----