< draft-gahrns-imap-namespace-00.txt		draft-gahrns-imap-namespace-01.txt >
	Network Working Group M. Gahrns, Microsoft		Network Working Group M. Gahrns, Microsoft
	J. Myers		C. Newman, Innosoft
	J. De Winter, Wildbear Consulting
	Internet Draft		Internet Draft
	Document: draft-gahrns-imap-namespace-00.txt April 1997		Document: draft-gahrns-imap-namespace-01.txt June 1997
	IMAP4 Namespace		IMAP4 Namespace
	Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,		documents of the Internet Engineering Task Force (IETF), its Areas,
	and its Working Groups. Note that other groups may also distribute		and its Working Groups. Note that other groups may also distribute
	working documents as Internet Drafts.		working documents as Internet Drafts.
	skipping to change at line 31 ¶		skipping to change at line 30 ¶
	"working draft" or "work in progress".		"working draft" or "work in progress".
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	1id-abstracts.txt listing contained in the Internet-Drafts Shadow		1id-abstracts.txt listing contained in the Internet-Drafts Shadow
	Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or		Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
	munnari.oz.au.		munnari.oz.au.
	A revised version of this draft document will be submitted to the		A revised version of this draft document will be submitted to the
	RFC editor as a Proposed Standard for the Internet Community.		RFC editor as a Proposed Standard for the Internet Community.
	Discussion and suggestions for improvement are requested. This		Discussion and suggestions for improvement are requested. This
	document will expire before October 1997. Distribution of this draft		document will expire before November 1997. Distribution of this
	is unlimited.		draft is unlimited.
	1. Abstract		1. Abstract
	IMAP4[RFC-2060] does not define a default mailbox namespace and		IMAP4[RFC-2060] does not define a default server namespace. As a
	hierarchy. As such, server behavior regarding namespaces can		result, two common namespace models have evolved:
	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		The "Personal Mailbox" model, in which the default namespace that is
	create or access a mailbox without first configuring a server		presented consists of only the user's personal mailboxes. To access
	specific personal mailbox prefix. For example, many clients often		shared mailboxes, the user must use an escape mechanism to reach
	create at initial start up time a "Sent Mail" or "Draft" mailbox.		another namespace.
	In addition, the #personal mailbox namespace allows a client to		The "Complete Hierarchy" model, in which the default namespace that
	present a view to the user that is completely restricted to the		is presented includes the user's personal mailboxes along with any
	user's personal folders without displaying any shared mailboxes.		other mailboxes they have access to.
	Gahrns, Myers and De Winter 1		These two models, create difficulties for certain client operations.
	By using the CANONICAL command, a client is able to determine where		This document defines a NAMESPACE command that allows a client to
	a mailbox exists in the server's entire default mailbox hierarchy.		discover the prefixes of namespaces used by a server for personal
	Used in conjunction with #personal namespace, a graphical client is		mailboxes, other user's mailboxes, and shared mailboxes. This
	able to display a server's entire default hierarchy, starting the		allows a client to avoid much of the manual user configuration that
	user at their personal space.		is now necessary when mixing and matching IMAP4 clients and servers.
			Gahrns and Newman 1
	2. Conventions used in this document		2. Conventions used in this document
	In examples, "C:" and "S:" indicate lines sent by the client and		In examples, "C:" and "S:" indicate lines sent by the client and
	server respectively.		server respectively.
			Personal Namespace: A namespace that the server considers within the
			personal scope of the authenticated user on a particular connection.
			Typically, only the authenticated user has access to mailboxes in
			their Personal Namespace. The specially defined IMAP4 mailbox INBOX
			resides in 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, 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 shared amongst users and do not exist within a user's
			Personal Namespace.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in [RFC-2119].		this document are to be interpreted as described in [RFC-2119].
	3. Introduction and Overview		3. Introduction and Overview
	A mailbox can be known by different names. For example, for the		Clients often attempt to create mailboxes for such purposes as
	user authenticated as joe, the mailbox INBOX could also be known as		maintaining a record of sent messages (e.g. "Sent Mail") or
	/var/spool/mail/joe. A mailbox can also exist in more than one		temporarily saving messages being composed (e.g. "Drafts"). For
	namespace. For example, the mailbox #news.comp.mail.imap could also		these clients to inter-operate correctly with the variety of IMAP4
	be known as "#shared/internet newsgroups/comp/mail/imap".		servers available, the user must enter the prefix of the Personal
			Namespace used by the server. Using the NAMESPACE command, a client
			is able to automatically discover this prefix without manual user
			configuration.
	The canonical name of a mailbox is the server's preferred name of		In addition, users are often required to manually enter the prefixes
	the mailbox within the server's default hierarchy.		of various namespaces in order to view the mailboxes located there.
			For example, they might be required to enter the prefix of #shared
			to view the shared mailboxes namespace. The NAMESPACE command allows
			a client to automatically discover the namespaces that are available
			on a server. This allows a client to present the available
			namespaces to the user in which ever manner it deems appropriate.
			For example, 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 at the root of
			their Personal Namespace.
	The canonical name of a mailbox MAY be different for different		A server MAY choose to make available to the NAMESPACE command only
	logged on users. For example, for the user logged on as "joe", the		a subset of the complete set of namespaces the server supports.
	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".
			Gahrns and Newman 2
	4. Requirements		4. Requirements
	IMAP4 servers that support this extension MUST list the keyword		IMAP4 servers that support this extension MUST list the keyword
	CANONICAL in their CAPABILITY response. A server that implements		NAMESPACE in their CAPABILITY response.
	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		5. NAMESPACE Command
	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		Arguments: none
	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		Response: an untagged NAMESPACE response that contains the prefix
	primary mailbox for this user on this server'. If this mailbox		to the server's default Personal Namespace, the Other
	exists on the server, it MAY also appear in the #personal namespace		Users' Namespace, and the Shared Namespace that the
	as #personal/INBOX.		server wishes to expose. The Personal Namespace and
			Other User's Namespace prefix are each to a single
			namespace, and as such, MUST end with the hierarchy
			character used in that namespace. The Shared Namespace
			prefix MAY be to multiple namespaces. If the Shared
			Namespace prefix is to multiple namespaces, the
			hierarchy character is not included in the prefix.
	Typically, no other users will have access to the mailboxes within		Result: OK - Command completed
	the #personal namespace unless the user has explicitly granted		NO - Error: Can't complete command
	access rights to other users.		BAD - argument invalid
	By defining a #personal namespace, servers allow clients the ability		If a particular namespace is not available, the prefix to that
	to create personal scope mailboxes or limit a list response to		namespace is NIL.
	personal scope mailboxes, without regard to the underlying default
	mailbox hierarchy a server has choosen.
	Example:		Example:
	C: A001 CREATE "#personal/sent mail"		< A server that supports only the personal namespace. No leading
	S: A001 OK CREATE completed		prefix is used on personal mailboxes. >
	C: A002 LIST "" "#personal/%"		C: A001 NAMESPACE
	S: * LIST () "/" "#personal/INBOX"		S: * NAMESPACE "" NIL NIL
	S: * LIST () "/" "#personal/sent mail"		S: A001 OK NAMESPACE command completed
	S: A002 OK LIST completed
	6. CANONICAL Command		Example:
	Argument: namespace or mailbox name		< A user logged on anonymously to a server. No personal
			mailboxes are associated with the anonymous user. No prefix is
			required to access shared mailboxes. >
	Responses: LIST response for the canonical mailbox name		C: A001 NAMESPACE
			S: * NAMESPACE NIL NIL ""
			S: A001 OK NAMESPACE command completed
	Result: OK - Command completed		The Personal Namespace prefix returned MUST be to a single Personal
	NO - Error: Can't complete command		Namespace and MUST end with the hierarchy character used in that
	BAD - argument invalid
	The CANONICAL command calculates the canonical name of the mailbox		Gahrns and Newman 3
	and generates an untagged LIST response as if a LIST command were		namespace. This allows a client to use the Personal Namespace
	issued with an empty reference argument and the canonical name of		prefix to automatically create personal mailboxes.
	the mailbox as the pattern.
	Gahrns, Myers and De Winter 3
	Example:		Example:
	Consider a server with a default hierarchy as follows:		< A server that supports only the Personal Namespace, with a
			leading prefix of INBOX to personal mailboxes. >
	The user's personal scope starts at the INBOX mailbox.		C: A001 NAMESPACE
	Personal mailboxes are created as inferiors to INBOX, with "."		S: * NAMESPACE "INBOX." NIL NIL
	as the hierarchy delimiter.		S: A001 OK NAMESPACE command completed
	Shared mailboxes are created at the same level as INBOX.
	INBOX		C: A002 CREATE "INBOX.Sent Mail"
	INBOX.<Any Personal mailboxes>		S: A002 OK CREATE command completed
	<Any Shared mailboxes>
	C: A001 CANONICAL #personal		The Other Users' Namespace prefix MUST be to a single Other Users'
	S: * LIST () "." "INBOX"		Namespace and MUST end with the hierarchy character used in that
	S: A001 OK Completed		namespace. The next level of hierarchy following the Other Users'
			Namespace prefix SHOULD consist of <username>, where <username> is a
			user name as per the IMAP4 LOGIN or AUTHENTICATE command.
	C: A002 CANONICAL #personal/foo		A client can construct a LIST command by appending a "%" to the
	S: * LIST () "." "INBOX.foo"		Other Users' Namespace prefix to discover the Personal Namespaces of
	S: A002 OK Completed		other users that are available to the currently authenticate user.
	C: A003 CANONICAL foo		In response to such a LIST command, a server SHOULD NOT return user
	S: * LIST () "." "foo"		names that have not granted access to their personal mailboxes to
	S: A003 OK Completed		the user in question.
	Example:		A server MAY return a LIST response containing only the names of
			users that have explicitly granted access to the user in question.
			Alternatively, a server MAY return NO to such a LIST command,
			requiring that a user name be included with the Other Users'
			Namespace prefix before listing any other user's mailboxes.
	Consider a server with a default hierarchy that starts right at		Example:
	the user's #personal namespace. In this example, #personal does
	not translate to a selectable mailbox.
	C: A001 CANONICAL #personal		< A server that supports providing a list of other user's
	S: * LIST (\Noselect) "/" ""		mailboxes that are accessible to the currently logged on user. >
	S: A001 OK Completed
	C: A002 CANONICAL "#personal/foo"		C: A001 NAMESPACE
	S: * LIST (\Noinferiors) "/" "foo"		S: * NAMESPACE "" "Other Users/" NIL
	S: A002 OK		S: A001 OK NAMESPACE command completed
	C: A003 CANONICAL "#personal/inbox"		C: A002 LIST "" "Other Users/%"
	S: * LIST () "/" "inbox"		S: * LIST () "/" "Other Users/Mike"
	S: A003 OK		S: * LIST () "/" "Other Users/Karen"
			S: A002 OK LIST command completed
			Gahrns and Newman 4
	Example:		Example:
	Consider a mailbox that is known by two different names.		< A server that does not support providing a list of other user's
	CANONICAL returns the same canonical name for each.		mailboxes that are accessible to the currently logged on user.
			The mailboxes are listable if the client includes the name of the
			other user with the Other Users' Namespace prefix. >
	C: A001 CANONICAL #news.alt.comp.mail.imap		C: A001 NAMESPACE
	S: * LIST () "/" "public/internet news/alt/comp/mail/imap"		S: * NAMESPACE "" "#Users/" NIL
	S: A001 OK CANONICAL completed		S: A001 OK NAMESPACE command completed
	Gahrns, Myers and De Winter 4		< In this example, the currently logged on user has access to the
	C: A002 CANONICAL "public folders/internet news/alt/comp/imap"		Personal Namespace of user Mike, but the server chose to suppress
	S: * LIST () "/" "public folders/internet news/alt/comp/imap"		this information in the LIST response. However, by appending the
	S: A002 OK CANONICAL completed		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 LIST "" "#Users/%"
			S: A002 NO The requested item could not be found.
			C: A003 LIST "" "#Users/Mike/%"
			S: * LIST () "/" "#Users/Mike/INBOX"
			S: * LIST () "/" "#Users/Mike/Foo"
			S: A003 OK LIST command completed.
			The shared mailboxes prefix MAY be to multiple Shared Namespaces. A
			client can construct a LIST command by appending a "%" to the Shared
			Namespace prefix to discover available Shared Namespaces.
	Example:		Example:
	Using the CANONICAL command, a graphical client can discover		< A server that contains a single Shared Namespace. >
	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		C: A001 NAMESPACE
	S: * list () "/" "All/Users/Joe"		S: * NAMESPACE "" NIL "Public Folders/"
	S: A001 OK CANONICAL completed		S: A001 OK NAMESPACE command completed
	To complete the tree view, the client issues a LIST % command on		C: A002 LIST "" "Public Folders/%"
	each hierarchy above the personal scope so that it can gather the		S: * LIST () "/" "Public Folders/Foo"
	information needed to complete the display of the "tree" control.		S: * LIST () "/" "Public Folders/Bar"
			S: A002 OK LIST command completed.
	C: A002 LIST "" "All/Users/%"		Example:
	S: * LIST () "" "All/Users/Joe"
	S: * LIST () "" "All/Users/Fred"
	S: A002 OK LIST completed
	C: A003 LIST "" "All/%"		< A server that contains multiple Shared Namespaces. Note that
	S: * LIST (\Noselect) "" "Users"		the hierarchy delimiter used within each namespace can be
	S: * LIST (\Noselect) "" "Shared"		different. >
	S: A003 OK LIST completed.
	The client now has gathered enough information so that it could		C: A001 NAMESPACE
	display to the user a "tree" control such as:		S: * NAMESPACE "~/mail/" NIL "#"
			S: A001 OK NAMESPACE command completed
	All		Gahrns and Newman 5
	Users		C: A002 LIST "" "#%"
	+Joe		S: * LIST () "." "#News"
	+Fred		S: * LIST () "/" "#Shared"
	+Shared		S: A002 OK LIST command completed.
	Where lower level of hierarchy is denoted by indentation, and "+"		Historical convention has been to start all namespaces with the "#"
	indicates a hierarchy level that has not yet been expanded by the		character. Namespaces that include the "#" character are not IMAP
	user.		URL [IMAP-URL] friendly requiring the "#" 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.
	7. Formal Syntax		6. Formal Syntax
	The following syntax specification uses the augmented Backus-Naur		The following syntax specification uses the augmented Backus-Naur
	Form (BNF) as described in [ABNF].		Form (BNF) as described in [ABNF].
	Canonical = "CANONICAL" SPACE mailbox		Namespace_Command = "NAMESPACE"
			Namespace_Response = "*" SPACE "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 = <mailbox>
	; <mailbox as defined in [RFC-2060]		; <mailbox as defined in [RFC-2060]
	Gahrns, Myers and De Winter 5		Prefix = NIL | mailbox
	8. Security Considerations
	This extension does not impose any security considerations over and		7. Security Considerations
	above those discussed in [RFC-2060].
	9. References		In response to a LIST command containing an argument of the Other
			Users' Namespace prefix, a server SHOULD NOT list users that have
			not granted access to their personal mailboxes to the currently
			authenticated user. Providing such a list, could compromise
			security 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		[RFC-2060], Crispin, M., "Internet Message Access Protocol – Version
	4rev1", RFC 2060, University of Washington, December 1996.		4rev1", RFC 2060, University of Washington, December 1996.
	[RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate		[RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, Harvard University, March 1997		Requirement Levels", RFC 2119, Harvard University, March 1997
			Gahrns and Newman 6
	[ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for		[ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
	Syntax Specifications: ABNF", draft-drums-abnf-02.txt (work in		Syntax Specifications: ABNF", draft-drums-abnf-02.txt (work in
	progress), Internet Mail Consortium, April 1997		progress), Internet Mail Consortium, April 1997
	10. Acknowledgments		[IMAP-URL], Newman, C., "IMAP URL Scheme", draft-newman-url-imap-
			09.txt (work in progress), Innosoft, May 1997
	Randy Gellens, Steve Hole, Andrew McCown, Larry Osterman, and Sam		9. Acknowledgments
	Weiler contributed to this document.
			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 for summarizing the two namespace models, John Myers and 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		11. Author's Addresses
	Mike Gahrns		Mike Gahrns
	Microsoft		Microsoft
	One Microsoft Way		One Microsoft Way
	Redmond, WA, 98072		Redmond, WA, 98072, USA
	Phone: (206) 936-9833		Phone: (206) 936-9833
	Email: mikega@microsoft.com		Email: mikega@microsoft.com
	John G. Myers		Chris Newman
	220 Palo Alto Ave., Apt 102		Innosoft International, Inc.
	Palo Alto, CA 94301		1050 East Garvey Ave. South
	Email: jgm@cmu.edu		West Covina, CA, 91790, USA
			Email: chris.newman@innosoft.com
	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		Gahrns and Newman 7
End of changes. 62 change blocks.
	171 lines changed or deleted		218 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/