< draft-ietf-imapext-2086upd-07.txt		draft-ietf-imapext-2086upd-08.txt >
	Individual A. Melnikov		Individual A. Melnikov
	Internet-Draft Isode Ltd.		Internet-Draft Isode Ltd.
	Obsoletes: 2086 (if approved) June 12, 2005		Obsoletes: 2086 (if approved) June 27, 2005
	Expires: December 14, 2005		Expires: December 29, 2005
	IMAP4 ACL extension		IMAP4 ACL extension
	draft-ietf-imapext-2086upd-07		draft-ietf-imapext-2086upd-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 14, 2005.		This Internet-Draft will expire on December 29, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	The ACL (Access Control List) extension (RFC 2086) of the Internet		The ACL (Access Control List) extension (RFC 2086) of the Internet
	Message Access Protocol (IMAP) permits mailbox access control lists		Message Access Protocol (IMAP) permits mailbox access control lists
	to be retrieved and manipulated through the IMAP protocol.		to be retrieved and manipulated through the IMAP protocol.
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	3.7 LISTRIGHTS response . . . . . . . . . . . . . . . . . . . 12		3.7 LISTRIGHTS response . . . . . . . . . . . . . . . . . . . 12
	3.8 MYRIGHTS response . . . . . . . . . . . . . . . . . . . . 13		3.8 MYRIGHTS response . . . . . . . . . . . . . . . . . . . . 13
	4. Rights required to perform different IMAP4rev1 commands . . . 13		4. Rights required to perform different IMAP4rev1 commands . . . 13
	5. Other considerations . . . . . . . . . . . . . . . . . . . . . 17		5. Other considerations . . . . . . . . . . . . . . . . . . . . . 17
	5.1 Additional requirements and Implementation notes . . . . . 17		5.1 Additional requirements and Implementation notes . . . . . 17
	5.1.1 Servers . . . . . . . . . . . . . . . . . . . . . . . 17		5.1.1 Servers . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1.2 Clients . . . . . . . . . . . . . . . . . . . . . . . 19		5.1.2 Clients . . . . . . . . . . . . . . . . . . . . . . . 19
	5.2 Mapping of ACL rights to READ-WRITE and READ-ONLY		5.2 Mapping of ACL rights to READ-WRITE and READ-ONLY
	response codes . . . . . . . . . . . . . . . . . . . . . . 19		response codes . . . . . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 21		6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21		7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	9. Internationalization Considerations . . . . . . . . . . . . . 23		9. Internationalization Considerations . . . . . . . . . . . . . 24
	A. Changes since RFC 2086 . . . . . . . . . . . . . . . . . . . . 23		A. Changes since RFC 2086 . . . . . . . . . . . . . . . . . . . . 24
	B. Compatibility with RFC 2086 . . . . . . . . . . . . . . . . . 24		B. Compatibility with RFC 2086 . . . . . . . . . . . . . . . . . 25
	C. Known deficiencies . . . . . . . . . . . . . . . . . . . . . . 24		C. Known deficiencies . . . . . . . . . . . . . . . . . . . . . . 25
	D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25		D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	10.1 Normative References . . . . . . . . . . . . . . . . . . . 25		10.1 Normative References . . . . . . . . . . . . . . . . . . . 26
	10.2 Informative References . . . . . . . . . . . . . . . . . . 26		10.2 Informative References . . . . . . . . . . . . . . . . . . 27
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . 27		Intellectual Property and Copyright Statements . . . . . . . . 28
	1. Introduction and Overview		1. Introduction and Overview
	The ACL (Access Control List) extension of the Internet Message		The ACL (Access Control List) extension of the Internet Message
	Access Protocol [IMAP4] permits mailbox access control lists to be		Access Protocol [IMAP4] permits mailbox access control lists to be
	retrieved and manipulated through the IMAP protocol.		retrieved and manipulated through the IMAP protocol.
	This document is a revision of RFC 2086 [RFC2086]. It tries to		This document is a revision of RFC 2086 [RFC2086]. It tries to
	clarify different ambiguities in RFC 2086, in particular use of UTF-8		clarify different ambiguities in RFC 2086, in particular use of UTF-8
	[UTF-8] in identifiers, which rights are required for different IMAP4		[UTF-8] in access identifiers, which rights are required for
	commands; how READ-WRITE/READ-ONLY response codes are related to ACL.		different IMAP4 commands; how READ-WRITE/READ-ONLY response codes are
			related to ACL.
	2. Access Control		2. Access Control
	The ACL extension is present in any IMAP4 implementation which		The ACL extension is present in any IMAP4 implementation which
	returns "ACL" as one of the supported capabilities to the CAPABILITY		returns "ACL" as one of the supported capabilities to the CAPABILITY
	command.		command.
	A server implementation conformant to this document MUST also return		A server implementation conformant to this document MUST also return
	rights (see below) not defined in Section 2.2 in the "RIGHTS="		rights (see below) not defined in Section 2.2 in the "RIGHTS="
	capability.		capability.
	An access control list is a set of <identifier,rights> pairs. An ACL		An access control list is a set of <access identifier,rights> pairs.
	applies to a mailbox name.		An ACL applies to a mailbox name.
	Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is		Access identifier (or just "identifier") is a UTF-8 [UTF-8] string.
	reserved to refer to the universal identity (all authentications,		The identifier "anyone" is reserved to refer to the universal
	including anonymous). All user name strings accepted by the LOGIN or		identity (all authentications, including anonymous). All user name
	AUTHENTICATE commands to authenticate to the IMAP server are reserved		strings accepted by the LOGIN or AUTHENTICATE commands to
	as identifiers for the corresponding users. Identifiers starting		authenticate to the IMAP server are reserved as identifiers for the
	with a dash ("-") are reserved for "negative rights", described		corresponding users. Identifiers starting with a dash ("-") are
	below. All other identifier strings are interpreted in an		reserved for "negative rights", described below. All other
	implementation-defined manner.		identifier strings are interpreted in an implementation-defined
			manner.
	Rights is a string listing a (possibly empty) set of alphanumeric		Rights is a string listing a (possibly empty) set of alphanumeric
	characters, each character listing a set of operations which is being		characters, each character listing a set of operations which is being
	controlled. Lowercase letters are reserved for "standard" rights,		controlled. Lowercase letters are reserved for "standard" rights,
	listed in Section 2.1. (Note that for compatibility with deployed		listed in Section 2.1. (Note that for compatibility with deployed
	clients and servers uppercase rights are not allowed). The set of		clients and servers uppercase rights are not allowed). The set of
	standard rights can only be extended by a standards-track document.		standard rights can only be extended by a standards-track document.
	Digits are reserved for implementation or site defined rights.		Digits are reserved for implementation or site defined rights.
	An implementation MAY tie rights together or MAY force rights to		An implementation MAY tie rights together or MAY force rights to
	skipping to change at page 9, line 24 ¶		skipping to change at page 9, line 24 ¶
	digits ("0" .. "9").		digits ("0" .. "9").
	3. Access control management commands and responses		3. Access control management commands and responses
	Servers, when processing a command that has an identifier as a		Servers, when processing a command that has an identifier as a
	parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands),		parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands),
	SHOULD first prepare the received identifier using "SASLprep" profile		SHOULD first prepare the received identifier using "SASLprep" profile
	[SASLprep] of the "stringprep" algorithm [Stringprep]. If the		[SASLprep] of the "stringprep" algorithm [Stringprep]. If the
	preparation of the identifier fails or results in an empty string,		preparation of the identifier fails or results in an empty string,
	the server MUST refuse to perform the command with a BAD response.		the server MUST refuse to perform the command with a BAD response.
			Note that Section 6 recommends additional identifier's verification
			steps.
	3.1 SETACL command		3.1 SETACL command
	Arguments: mailbox name		Arguments: mailbox name
	identifier		identifier
	access right modification		access right modification
	Data: no specific data for this command		Data: no specific data for this command
	Result: OK - setacl completed		Result: OK - setacl completed
	skipping to change at page 21, line 34 ¶		skipping to change at page 21, line 34 ¶
	For example, when a user agent executes a GETACL command on a mailbox		For example, when a user agent executes a GETACL command on a mailbox
	that the user has no permission to LIST, the server would respond to		that the user has no permission to LIST, the server would respond to
	that request with the same error that would be used if the mailbox		that request with the same error that would be used if the mailbox
	did not exist, thus revealing no existence information, much less the		did not exist, thus revealing no existence information, much less the
	mailbox's ACL.		mailbox's ACL.
	IMAP clients implementing ACL that are able to modify ACLs SHOULD		IMAP clients implementing ACL that are able to modify ACLs SHOULD
	warn a user that wants to give full access (or even just the "a"		warn a user that wants to give full access (or even just the "a"
	right) to the special identifier "anyone".		right) to the special identifier "anyone".
			This document relies on [SASLprep] to describe steps required to
			perform identifier canonicalization (preparation). The preparation
			algorithm in SASLPrep was specifically designed such that its output
			is canonical, and it is well-formed. However, due to an anomaly
			[PR29] in the specification of Unicode normalization, canonical
			equivalence is not guaranteed for a select few character sequences.
			Identifiers prepared with SASLPrep can be stored and returned by an
			ACL server. The anomaly affects ACL manipulation and evaluation of
			identifiers containing the selected character sequences. These
			sequences, however, do not appear in well-formed text. In order to
			address this problem ACL server MAY reject identifiers containing
			sequences described in [PR29] by sending the tagged BAD response.
			This is in addition to the requirement to reject identifiers that
			fail SASLPrep preparation as described in Section 3.
			Other security considerations described in [IMAP4] are relevant to
			this document. In particular, ACL information is sent in the clear
			over the network unless confidentiality protection is negotiated.
			This can be accomplished either by the use of STARTTLS, negotiated
			privacy protection in the AUTHENTICATE command, or some other
			protection mechanism.
	7. Formal Syntax		7. Formal Syntax
	Formal syntax is defined using ABNF [ABNF], extending the ABNF rules		Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
	in section 9 of [IMAP4]. Elements not defined here can be found in		in section 9 of [IMAP4]. Elements not defined here can be found in
	the [ABNF] and [IMAP4].		the [ABNF] and [IMAP4].
	Except as noted otherwise, all alphabetic characters are case-		Except as noted otherwise, all alphabetic characters are case-
	insensitive. The use of upper or lower case characters to define		insensitive. The use of upper or lower case characters to define
	token strings is for editorial clarity only. Implementations MUST		token strings is for editorial clarity only. Implementations MUST
	accept these strings in a case-insensitive fashion.		accept these strings in a case-insensitive fashion.
	skipping to change at page 26, line 10 ¶		skipping to change at page 27, line 10 ¶
	December 2002.		December 2002.
	[SASLprep]		[SASLprep]
	Zeilenga, K., "SASLprep: Stringprep Profile for User Names		Zeilenga, K., "SASLprep: Stringprep Profile for User Names
	and Passwords", RFC 4013, February 2005.		and Passwords", RFC 4013, February 2005.
	10.2 Informative References		10.2 Informative References
	[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.		[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
			[PR29] "Public Review Issue #29: Normalization Issue",
			February 2004, <http://www.unicode.org/review/pr-29.html>.
	Author's Address		Author's Address
	Alexey Melnikov		Alexey Melnikov
	Isode Ltd.		Isode Ltd.
	5 Castle Business Village		5 Castle Business Village
	36 Station Road		36 Station Road
	Hampton, Middlesex TW12 2BX		Hampton, Middlesex TW12 2BX
	GB		GB
	Email: alexey.melnikov@isode.com		Email: alexey.melnikov@isode.com
End of changes. 10 change blocks.
	28 lines changed or deleted		58 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/