< draft-leiba-imap-implement-guide-05.txt		draft-leiba-imap-implement-guide-06.txt >
	Network Working Group B. Leiba		Network Working Group B. Leiba
	Internet Draft IBM T.J. Watson Research Center		Internet Draft IBM T.J. Watson Research Center
	Document: draft-leiba-imap-implement-guide-05.txt April 1998		Document: draft-leiba-imap-implement-guide-06.txt April 1998
	Expires September 1998		Expires September 1998
	IMAP4 Implementation Recommendations		IMAP4 Implementation Recommendations
	Status of this Document		Status of this Document
	This document provides information for the Internet community. This		This document provides information for the Internet community. This
	document does not specify an Internet standard of any kind.		document does not specify an Internet standard of any kind.
	Distribution of this document is unlimited.		Distribution of this document is unlimited.
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 24 ¶
	itself, expecting a particular server behavior. However, a client		itself, expecting a particular server behavior. However, a client
	SHOULD permit a USER, by configuration, to use a reference name.		SHOULD permit a USER, by configuration, to use a reference name.
	There is in no way universal agreement about the use or non-use of		There is in no way universal agreement about the use or non-use of
	the reference name. The last words here are, "Be aware."		the reference name. The last words here are, "Be aware."
	3.4.12. Mailbox Hierarchy Delimiters		3.4.12. Mailbox Hierarchy Delimiters
	The server's selection of what to use as a mailbox hierarchy		The server's selection of what to use as a mailbox hierarchy
	delimiter is a difficult one, involving several issues: What		delimiter is a difficult one, involving several issues: What
	characters do users expect to see here? What characters can they		characters do users expect to see? What characters can they enter
	enter in cases where they want to or must type them in? What		for a hierarchy delimiter if it is desired (or required) that the
	characters can be used for delimiters, which characters will then not		user enter it? What character can be used for the hierarchy
	be allowed in the mailbox names themselves?		delimiter, nothing that the chosen character can not otherwise be
			used in the mailbox name?
	Because some interfaces show users the hierarchy delimiters or allow		Because some interfaces show users the hierarchy delimiters or allow
	users to enter qualified mailbox names containing them, server		users to enter qualified mailbox names containing them, server
	implementations SHOULD use delimiter characters that users generally		implementations SHOULD use delimiter characters that users generally
	expect to see as name separators. The most common characters used		expect to see as name separators. The most common characters used
	for this are "/" (as in Unix file names), "\" (as in OS/2, and		for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows
	Windows file names), and "." (as in news groups). There is little to		file names), and "." (as in news groups). There is little to choose
	choose among these apart from what users may be used to or what is		among these apart from what users may expect or what is dictated by
	dictated by the underlying file system, if any. One consideration		the underlying file system, if any. One consideration about using
	about using "\" is that it's also a special character in the IMAP		"\" is that it's also a special character in the IMAP protocol.
	protocol. While the use of other hierarchy delimiter characters is		While the use of other hierarchy delimiter characters is permissible,
	permissible, A DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS		A DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the
	SET unless the server is intended for special purposes only.		server is intended for special purposes only. Characters such as
	Characters such as "-", "_", ";", "&", "#", "@", and "!" may be		"-", "_", ";", "&", "#", "@", and "!" may be considered, but the
	considered, but the implementer should be aware of the surprise to		implementer should be aware of the surprise to the user as well as of
	the user as well as of the affect on URLs and other external		the effect on URLs and other external specifications (since some of
	specifications (since some of these characters have special meanings		these characters have special meanings there). Also, a server that
	there). Also, a server that uses "\" (and clients of such a server)		uses "\" (and clients of such a server) must remember to escape that
	must remember to escape that character in quoted strings or to send		character in quoted strings or to send literals instead. Literals
	literals instead:		are recommended over escaped characters in quoted strings in order to
			maintain compatibility with older IMAP versions that did not allow
			escaped characters in quoted strings (but check the grammar to see
			where literals are allowed):
	001 LIST "" "this\\%\\%\\%\\h*"		C: 001 LIST "" {13}
	* LIST () "\\" {27}		S: + send literal
	this\is\a\mailbox\hierarchy		C: this\%\%\%\h*
	001 OK LIST complete		S: * LIST () "\\" {27}
			S: this\is\a\mailbox\hierarchy
			S: 001 OK LIST complete
	In any case, a server SHOULD NOT use normal alpha-numeric characters		In any case, a server SHOULD NOT use normal alpha-numeric characters
	(such as "X" or "0") as delimiters; a user would be very surprised to		(such as "X" or "0") as delimiters; a user would be very surprised to
	find that "EXPENDITURES" actually represented a two-level hierarchy.		find that "EXPENDITURES" actually represented a two-level hierarchy.
	And a server SHOULD NOT use characters that are non-printable or		And a server SHOULD NOT use characters that are non-printable or
	difficult or impossible to enter on a standard US keyboard. Control		difficult or impossible to enter on a standard US keyboard. Control
	characters, box-drawing characters, and characters from non-US		characters, box-drawing characters, and characters from non-US
	alphabets fit into this category. Their use presents		alphabets fit into this category. Their use presents
	interoperability problems that are best avoided.		interoperability problems that are best avoided.
End of changes. 4 change blocks.
	24 lines changed or deleted		30 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/