< draft-ietf-imapext-annotate-14.txt		draft-ietf-imapext-annotate-15.txt >
	IMAP Extensions Working Group C. Daboo		IMAP Extensions Working Group C. Daboo
	Internet-Draft		Internet-Draft
	Expires: May 25, 2006 R. Gellens		Expires: September 29, 2006 R. Gellens
	QUALCOMM Incorporated		QUALCOMM Incorporated
	November 21, 2005		March 28, 2006
	IMAP ANNOTATE Extension		IMAP ANNOTATE Extension
	draft-ietf-imapext-annotate-14		draft-ietf-imapext-annotate-15
	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 35 ¶		skipping to change at page 1, line 35 ¶
	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 May 25, 2006.		This Internet-Draft will expire on September 29, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The ANNOTATE extension to the Internet Message Access Protocol		The ANNOTATE extension to the Internet Message Access Protocol
	permits clients and servers to maintain "meta data" for messages, or		permits clients and servers to maintain "meta data" for messages, or
	individual message parts, stored in a mailbox on the server.		individual message parts, stored in a mailbox on the server. For
			example, this can be used to attach comments and other useful
			information to a message. It is also possible to attach annotations
			to specific parts of a message, so that, for example, they could be
			marked as seen or important, or a comment added.
	Change History (to be removed prior to publication as an RFC)		Change History (to be removed prior to publication as an RFC)
	Changes from -13 to -14:		Changes from -14 to -15:
			1. Updated to rfc 4314 reference.
			2. Removed Content-Language value and reference.
			3. Added statement about experimental status.
			4. Changed to experimental capability name.
			5. Removed ability to sort on size attribute.
			6. Expanded abstract.
			Changes from -13 to -14:
	1. Changed 'string' formal syntax to 'list-mailbox' and 'astring'		1. Changed 'string' formal syntax to 'list-mailbox' and 'astring'
	for entry/attribute names.		for entry/attribute names.
	2. Updated examples to match new astring syntax.		2. Updated examples to match new astring syntax.
	3. Now requires explicit use of .priv or .shared in SORT.		3. Now requires explicit use of .priv or .shared in SORT.
	4. Removed requirement that 'n' right only be present if 'r' right		4. Removed requirement that 'n' right only be present if 'r' right
	is also present.		is also present.
	5. Changed ANNOTATESIZE response to ANNOTATIONS response.		5. Changed ANNOTATESIZE response to ANNOTATIONS response.
	6. Allow servers to indicate that they do not support private		6. Allow servers to indicate that they do not support private
	annotations.		annotations.
	7. Added example for extended SELECT including ANNOTATIONS response		7. Added example for extended SELECT including ANNOTATIONS response
	skipping to change at page 5, line 40 ¶		skipping to change at page 6, line 4 ¶
	until the client uses it first. (Open issue as to if needed).		until the client uses it first. (Open issue as to if needed).
	6. Examples now only use valid entries and attributes.		6. Examples now only use valid entries and attributes.
	7. Updated Security Considerations.		7. Updated Security Considerations.
	8. Content-Type now defaults to text/plain.		8. Content-Type now defaults to text/plain.
	9. Open Issue: Shared vs. private annotations.		9. Open Issue: Shared vs. private annotations.
	10. Open issue: Annotation Modtime untagged response or VALIDTIME		10. Open issue: Annotation Modtime untagged response or VALIDTIME
	FETCH data.		FETCH data.
	11. Open issue: Conditional annotation STORE.		11. Open issue: Conditional annotation STORE.
	12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in		12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in
	CAPABILITY command response.		CAPABILITY command response.
	13. Prohibition on annotations in lieu of base spec functionality.		13. Prohibition on annotations in lieu of base spec functionality.
	14. Specified required ACL rights.		14. Specified required ACL rights.
	15. ANNOTATION message data item in APPEND.		15. ANNOTATION message data item in APPEND.
	16. ANNOTATION-MODTIME message data item in STATUS.		16. ANNOTATION-MODTIME message data item in STATUS.
	17. Replaced ATOM_CHAR with utf8-char.		17. Replaced ATOM_CHAR with utf8-char.
	18. Updated other ABNF entries.		18. Updated other ABNF entries.
	Table of Contents		Table of Contents
	1. Introduction and Overview . . . . . . . . . . . . . . . . . . 7		1. Introduction and Overview . . . . . . . . . . . . . . . . . . 8
	2. Conventions Used in This Document . . . . . . . . . . . . . . 7		2. Working Group Note on Status . . . . . . . . . . . . . . . . . 8
	3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Conventions Used in This Document . . . . . . . . . . . . . . 9
	3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2. Namespace of entries and attributes . . . . . . . . . . . 8		4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 9		4.2. Namespace of entries and attributes . . . . . . . . . . . 9
	3.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 10		4.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 10
	3.3. Private versus Shared . . . . . . . . . . . . . . . . . . 11		4.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 12
	3.4. Access Control . . . . . . . . . . . . . . . . . . . . . . 12		4.3. Private versus Shared . . . . . . . . . . . . . . . . . . 12
	3.5. Access to Standard IMAP Flags and Keywords . . . . . . . . 15		4.4. Access Control . . . . . . . . . . . . . . . . . . . . . . 13
	4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 15		4.5. Access to Standard IMAP Flags and Keywords . . . . . . . . 16
	4.1. General Considerations . . . . . . . . . . . . . . . . . . 15		5. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 16
	4.2. ANNOTATE parameter with the SELECT/EXAMINE commands . . . 16		5.1. General Considerations . . . . . . . . . . . . . . . . . . 16
	4.3. ANNOTATION Message Data Item in FETCH Command . . . . . . 16		5.2. ANNOTATE parameter with the SELECT/EXAMINE commands . . . 17
	4.4. ANNOTATION Message Data Item in FETCH Response . . . . . . 18		5.3. ANNOTATION Message Data Item in FETCH Command . . . . . . 17
	4.5. ANNOTATION Message Data Item in STORE . . . . . . . . . . 20		5.4. ANNOTATION Message Data Item in FETCH Response . . . . . . 19
	4.6. ANNOTATION interaction with COPY . . . . . . . . . . . . . 21		5.5. ANNOTATION Message Data Item in STORE . . . . . . . . . . 21
	4.7. ANNOTATION Message Data Item in APPEND . . . . . . . . . . 22		5.6. ANNOTATION interaction with COPY . . . . . . . . . . . . . 22
	4.8. ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 22		5.7. ANNOTATION Message Data Item in APPEND . . . . . . . . . . 23
	4.9. ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 23		5.8. ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 23
	4.10. New ACL Rights . . . . . . . . . . . . . . . . . . . . . . 24		5.9. ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 24
	5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 24		5.10. New ACL Rights . . . . . . . . . . . . . . . . . . . . . . 25
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.1. Entry and Attribute Registration Template . . . . . . . . 26		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	6.2. Entry Registrations . . . . . . . . . . . . . . . . . . . 27		7.1. Entry and Attribute Registration Template . . . . . . . . 27
	6.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 27		7.2. Entry Registrations . . . . . . . . . . . . . . . . . . . 28
	6.2.2. /flags . . . . . . . . . . . . . . . . . . . . . . . . 27		7.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 28
	6.2.3. /altsubject . . . . . . . . . . . . . . . . . . . . . 28		7.2.2. /flags . . . . . . . . . . . . . . . . . . . . . . . . 28
	6.2.4. /<section-part>/comment . . . . . . . . . . . . . . . 28		7.2.3. /altsubject . . . . . . . . . . . . . . . . . . . . . 29
	6.2.5. /<section-part>/flags/seen . . . . . . . . . . . . . . 29		7.2.4. /<section-part>/comment . . . . . . . . . . . . . . . 29
	6.2.6. /<section-part>/flags/answered . . . . . . . . . . . . 29		7.2.5. /<section-part>/flags/seen . . . . . . . . . . . . . . 30
	6.2.7. /<section-part>/flags/flagged . . . . . . . . . . . . 30		7.2.6. /<section-part>/flags/answered . . . . . . . . . . . . 30
	6.2.8. /<section-part>/flags/forwarded . . . . . . . . . . . 30		7.2.7. /<section-part>/flags/flagged . . . . . . . . . . . . 31
	6.3. Attribute Registrations . . . . . . . . . . . . . . . . . 30		7.2.8. /<section-part>/flags/forwarded . . . . . . . . . . . 31
	6.3.1. value . . . . . . . . . . . . . . . . . . . . . . . . 31		7.3. Attribute Registrations . . . . . . . . . . . . . . . . . 31
	6.3.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 31		7.3.1. value . . . . . . . . . . . . . . . . . . . . . . . . 32
	6.3.3. content-language . . . . . . . . . . . . . . . . . . . 32		7.3.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 32
	7. Internationalization Considerations . . . . . . . . . . . . . 32		8. Internationalization Considerations . . . . . . . . . . . . . 32
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 32		9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 32		10.1. Normative References . . . . . . . . . . . . . . . . . . . 33
	9.2. Informative References . . . . . . . . . . . . . . . . . . 33		10.2. Informative References . . . . . . . . . . . . . . . . . . 33
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 33		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
	Intellectual Property and Copyright Statements . . . . . . . . . . 35		Intellectual Property and Copyright Statements . . . . . . . . . . 36
	1. Introduction and Overview		1. Introduction and Overview
	The ANNOTATE extension is present in any IMAP [RFC3501]		The ANNOTATE extension is present in any IMAP [RFC3501]
	implementation which returns "ANNOTATE" as one of the supported		implementation which returns "ANNOTATE-EXPERIMENT-1" as one of the
	capabilities in the CAPABILITY response.		supported capabilities in the CAPABILITY response.
	This extension makes the following changes to the IMAP protocol:		This extension makes the following changes to the IMAP protocol:
	a. adds a new ANNOTATION message data item for use in FETCH		a. adds a new ANNOTATION message data item for use in FETCH
	b. adds a new ANNOTATION message data item for use in STORE		b. adds a new ANNOTATION message data item for use in STORE
	c. adds a new ANNOTATION search criterion for use in SEARCH		c. adds a new ANNOTATION search criterion for use in SEARCH
	d. adds a new ANNOTATION sort key for use in SORT extension		d. adds a new ANNOTATION sort key for use in SORT extension
	e. adds a new ANNOTATION data item for use in APPEND		e. adds a new ANNOTATION data item for use in APPEND
	f. adds a new requirement on the COPY command		f. adds a new requirement on the COPY command
	g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE		g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE
	commands		commands
	h. adds two new response codes to indicate store failures of		h. adds two new response codes to indicate store failures of
	annotations.		annotations.
	i. adds a new untagged response code for the SELECT or EXAMINE		i. adds a new untagged response code for the SELECT or EXAMINE
	commands to indicate the maximum size.		commands to indicate the maximum size.
	j. adds a new ACL "bit" for use with the ACL extensions [RFC2086]		j. adds a new ACL "bit" for use with the ACL extensions [RFC2086]
	and [I-D.ietf-imapext-2086upd] .		and [RFC4314] .
	The data model used for the storage of annotations is based on that		The data model used for the storage of annotations is based on that
	of the Application Configuration Access Protocol [RFC2244]. Note		of the Application Configuration Access Protocol [RFC2244]. Note
	that there is no inheritance in annotations.		that there is no inheritance in annotations.
	If a server supports annotations, then it MUST store all annotation		If a server supports annotations, then it MUST store all annotation
	data permanently, i.e. there is no concept of "session only"		data permanently, i.e. there is no concept of "session only"
	annotations that would correspond to the behaviour of "session" flags		annotations that would correspond to the behaviour of "session" flags
	as defined in the IMAP base specification.		as defined in the IMAP base specification.
	In order to provide optimum support for a disconnected client (one		In order to provide optimum support for a disconnected client (one
	that needs to synchronise annotations for use when offline), servers		that needs to synchronise annotations for use when offline), servers
	SHOULD also support the Conditional STORE [I-D.ietf-imapext-		SHOULD also support the Conditional STORE [I-D.ietf-imapext-
	condstore] extension.		condstore] extension.
	The rest of this document describes the data model and protocol		The rest of this document describes the data model and protocol
	changes more rigorously.		changes more rigorously.
	2. Conventions Used in This Document		2. Working Group Note on Status
			The IMAP Extensions Working Group, which produced this specification,
			has felt it important to first gain implementation experience with
			this specification before submitting it as a 'proposed standard' for
			more general deployment, and therefore suggests that it be published
			as Experimental. As such the Working Group strongly encourages
			implementers to implement this specification as-is and provide their
			valuable feedback on any problems or issues found when doing that or
			when attempting to interoperate with other products.
			Implementers should be aware that this specification may change in an
			incompatible manner when going to 'proposed standard' status.
			However, any incompatible changes will result in a new capability
			name being used to prevent problems with any deployments of the
			experimental extension.
			3. 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.
	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 this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Data Model		4. Data Model
	3.1. Overview		4.1. Overview
	The data model used in ANNOTATE is that of a uniquely named entry		The data model used in ANNOTATE is that of a uniquely named entry
	which contains a set of standard attributes. A single coherent unit		which contains a set of standard attributes. A single coherent unit
	of "meta data" for a message is stored as a single entry, made up of		of "meta data" for a message is stored as a single entry, made up of
	several attributes.		several attributes.
	For example, a comment annotation added to a message has an entry		For example, a comment annotation added to a message has an entry
	name of "/comment". This entry is composed of several attributes		name of "/comment". This entry is composed of several attributes
	such as "value", "size", etc. which contain the properties and data		such as "value", "size", etc. which contain the properties and data
	of the entry.		of the entry.
	The protocol changes to IMAP described below allow a client to access		The protocol changes to IMAP described below allow a client to access
	or change the values of any attributes in any entries in a message		or change the values of any attributes in any entries in a message
	annotation, assuming it has sufficient access rights to do so (see		annotation, assuming it has sufficient access rights to do so (see
	Section 3.4 for specifics).		Section 4.4 for specifics).
	3.2. Namespace of entries and attributes		4.2. Namespace of entries and attributes
	Each message annotation is made up of a set of entries. Each entry		Each message annotation is made up of a set of entries. Each entry
	has a hierarchical name, with each component of the name separated by		has a hierarchical name, with each component of the name separated by
	a slash ("/"). An entry name MUST NOT contain two consecutive "/"		a slash ("/"). An entry name MUST NOT contain two consecutive "/"
	characters and MUST NOT end with a "/" character.		characters and MUST NOT end with a "/" character.
	Each entry is made up of a set of attributes. Each attribute has a		Each entry is made up of a set of attributes. Each attribute has a
	hierarchical name, with each component of the name separated by a		hierarchical name, with each component of the name separated by a
	period ("."). An attribute name MUST NOT contain two consecutive "."		period ("."). An attribute name MUST NOT contain two consecutive "."
	characters and MUST NOT end with a "." character.		characters and MUST NOT end with a "." character.
	skipping to change at page 8, line 47 ¶		skipping to change at page 10, line 18 ¶
	The value of an attribute is "NIL" (has no value), or is a string of		The value of an attribute is "NIL" (has no value), or is a string of
	zero or more octets.		zero or more octets.
	Entry and attribute names MUST NOT contain asterisk ("*") or percent		Entry and attribute names MUST NOT contain asterisk ("*") or percent
	("%") characters and MUST NOT contain non-ASCII characters or the		("%") characters and MUST NOT contain non-ASCII characters or the
	NULL octet. Invalid entry or attribute names result in a BAD		NULL octet. Invalid entry or attribute names result in a BAD
	response in any IMAP commands where they are used.		response in any IMAP commands where they are used.
	Attribute names MUST NOT contain any hierarchical components with the		Attribute names MUST NOT contain any hierarchical components with the
	names "priv" or "shared" as those have special meaning (see		names "priv" or "shared" as those have special meaning (see
	Section 3.3.		Section 4.3).
	Entry and attribute names are case-sensitive.		Entry and attribute names are case-sensitive.
	Use of control or punctuation characters in entry and attribute names		Use of control or punctuation characters in entry and attribute names
	is strongly discouraged.		is strongly discouraged.
	This specification defines an initial set of entry and attribute		This specification defines an initial set of entry and attribute
	names available for use in message annotations. In addition, an		names available for use in message annotations. In addition, an
	extension mechanism is described to allow additional names to be		extension mechanism is described to allow additional names to be
	added as needed.		added as needed.
	3.2.1. Entry Names		4.2.1. Entry Names
	Entry names MUST be specified in a standards track or IESG approved		Entry names MUST be specified in a standards track or IESG approved
	experimental RFC, or fall under the vendor namespace. See		experimental RFC, or fall under the vendor namespace. See
	Section 6.1 for the registration template.		Section 7.1 for the registration template.
	/		/
	Defines the top-level of entries associated with an entire		Defines the top-level of entries associated with an entire
	message. This entry itself does not contain any attributes. All		message. This entry itself does not contain any attributes. All
	entries that start with a numeric character ("0" - "9") refer to		entries that start with a numeric character ("0" - "9") refer to
	an annotation on a specific body part. All other entries are for		an annotation on a specific body part. All other entries are for
	annotations on the entire message.		annotations on the entire message.
	/comment		/comment
	Defines a comment or note associated with an entire message.		Defines a comment or note associated with an entire message.
	skipping to change at page 10, line 31 ¶		skipping to change at page 12, line 5 ¶
	attribute of each of the entries described above must be either		attribute of each of the entries described above must be either
	"1", "0" or "NIL". "1" corresponds to the flag being set.		"1", "0" or "NIL". "1" corresponds to the flag being set.
	/<section-part>/vendor/<vendor-token>		/<section-part>/vendor/<vendor-token>
	Defines the top-level of entries associated with a specific body		Defines the top-level of entries associated with a specific body
	part of a message as created by a particular product of some		part of a message as created by a particular product of some
	vendor. This entry can be used by vendors to provide client		vendor. This entry can be used by vendors to provide client
	specific annotations. The vendor-token MUST be registered with		specific annotations. The vendor-token MUST be registered with
	IANA.		IANA.
	3.2.2. Attribute Names		4.2.2. Attribute Names
	Attribute names MUST be specified in a standards track or IESG		Attribute names MUST be specified in a standards track or IESG
	approved experimental RFC. See Section 6.1 for the registration		approved experimental RFC. See Section 7.1 for the registration
	template.		template.
	All attribute names implicitly have a ".priv" and a ".shared" suffix		All attribute names implicitly have a ".priv" and a ".shared" suffix
	which maps to private and shared versions of the entry. Searching or		which maps to private and shared versions of the entry. Searching or
	fetching without using either suffix includes both. The client MUST		fetching without using either suffix includes both. The client MUST
	specify either a ".priv" or ".shared" suffix when storing an		specify either a ".priv" or ".shared" suffix when storing an
	annotation.		annotation or sorting on annotations.
	value		value
	A string or binary data representing the value of the annotation.		A string or binary data representing the value of the annotation.
	To delete an annotation, the client can store "NIL" into the		To delete an annotation, the client can store "NIL" into the
	value. The content represented by the string is determined by the		value. The content represented by the string is determined by the
	Content-type used to register the entry (see Section 6.1 for entry		content-type used to register the entry (see Section 7.1 for entry
	registration templates). Where applicable, the registered		registration templates). Where applicable, the registered
	content-type MUST include a charset parameter. Text values SHOULD		content-type MUST include a charset parameter. Text values SHOULD
	use the utf-8 [RFC3629] character set.		use the utf-8 [RFC3629] character set.
	Note that binary data (data which may contain the NULL octet) is		Note that binary data (data which may contain the NULL octet) is
	allowed (e.g. for storing images etc), and this extension uses the		allowed (e.g. for storing images etc), and this extension uses the
	"literal8" syntax element [I-D.melnikov-imap-ext-abnf] to allow		"literal8" syntax element [I-D.melnikov-imap-ext-abnf] to allow
	such data to be written to or read from the server.		such data to be written to or read from the server.
	size		size
	The size of the value, in octets. Set automatically by the		The size of the value, in octets. Set automatically by the
	server, read-only to clients.		server, read-only to clients.
	content-language		4.3. Private versus Shared
	Indicates the language used for the value. This follows the
	format described in [RFC3282]. Clients SHOULD set this value when
	storing an annotation that uses text that can be presented to the
	user. It is not required for enumerated or numeric values such as
	flags etc. If a value is being set, clients MUST ensure that it
	accurately reflects the content stored in the value attribute.
	Servers MUST ensure that the "content-language" attribute value is
	kept in synchronization with the "value" attribute. To ensure
	that, the server MUST remove any "content-language" attribute
	value when the client STOREs a "value" attribute without also
	including a "content-language" attribute in the same STORE
	command.
	3.3. Private versus Shared
	Some IMAP mailboxes are private, accessible only to the owning user.		Some IMAP mailboxes are private, accessible only to the owning user.
	Other mailboxes are not, either because the owner has set an ACL		Other mailboxes are not, either because the owner has set an ACL
	[I-D.ietf-imapext-2086upd] which permits access by other users, or		[RFC4314] which permits access by other users, or because it is a
	because it is a shared mailbox.		shared mailbox.
	This raises the issue of shared versus private annotations.		This raises the issue of shared versus private annotations.
	If all annotations are private, it is impossible to set annotations		If all annotations are private, it is impossible to set annotations
	in a shared or otherwise non-private mailbox that are visible to		in a shared or otherwise non-private mailbox that are visible to
	other users. This eliminates what could be a useful aspect of		other users. This eliminates what could be a useful aspect of
	annotations in a shared environment. An example of such use is a		annotations in a shared environment. An example of such use is a
	shared IMAP folder containing bug reports. Engineers may want to use		shared IMAP folder containing bug reports. Engineers may want to use
	annotations to add information to existing messages, indicate		annotations to add information to existing messages, indicate
	assignments, status, etc. This use requires shared annotations.		assignments, status, etc. This use requires shared annotations.
	skipping to change at page 12, line 26 ¶		skipping to change at page 13, line 32 ¶
	If the ANNOTATE extension is present, support for shared annotations		If the ANNOTATE extension is present, support for shared annotations
	in servers is REQUIRED, whilst support for private annotations in		in servers is REQUIRED, whilst support for private annotations in
	servers is OPTIONAL. This recognises the fact that support for		servers is OPTIONAL. This recognises the fact that support for
	private annotations may introduce significantly more complexity to a		private annotations may introduce significantly more complexity to a
	server in terms of tracking ownership of the annotations, how quota		server in terms of tracking ownership of the annotations, how quota
	is determined for users based on their own annotations etc. Clients		is determined for users based on their own annotations etc. Clients
	that support the ANNOTATE extension MUST handle both shared and		that support the ANNOTATE extension MUST handle both shared and
	private annotations.		private annotations.
	3.4. Access Control		4.4. Access Control
	A user needs to have appropriate rights in order to read or write		A user needs to have appropriate rights in order to read or write
	".priv" or ".shared" annotation values. How those rights are		".priv" or ".shared" annotation values. How those rights are
	calculated depends on whether the ACL [RFC2086] extension or its		calculated depends on whether the ACL [RFC2086] extension or its
	update [I-D.ietf-imapext-2086upd] is present or not. If a client		update [RFC4314] is present or not. If a client attempts to store or
	attempts to store or fetch an annotation to which they do not have		fetch an annotation to which they do not have the appropriate rights,
	the appropriate rights, the server MUST respond with a NO response.		the server MUST respond with a NO response.
	When the ACL extension is not present, access to annotation values is		When the ACL extension is not present, access to annotation values is
	governed by the nature of the selected state. In particular whether		governed by the nature of the selected state. In particular whether
	the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE		the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE
	mode.		mode.
	When the ACL extension is present, the server MUST recognise the new		When the ACL extension is present, the server MUST recognise the new
	ACL right "n", in addition to the ones defined by the ACL extension		ACL right "n", in addition to the ones defined by the ACL extension
	itself.		itself.
	skipping to change at page 13, line 9 ¶		skipping to change at page 14, line 14 ¶
	allowed, when it is off, access to ".priv" annotations is disallowed.		allowed, when it is off, access to ".priv" annotations is disallowed.
	The "r" right controls only the read access for ".shared" annotation		The "r" right controls only the read access for ".shared" annotation
	values. When it is on, ".shared" annotations can be read, when it is		values. When it is on, ".shared" annotations can be read, when it is
	off, ".shared" annotations cannot be read.		off, ".shared" annotations cannot be read.
	The "n" right controls only the write access for ".shared" annotation		The "n" right controls only the write access for ".shared" annotation
	values. When it is on, ".shared" annotations can be changed or		values. When it is on, ".shared" annotations can be changed or
	created through either a STORE or APPEND command, when it is off,		created through either a STORE or APPEND command, when it is off,
	".shared" annotations cannot be changed or created. The "n" right		".shared" annotations cannot be changed or created. The "n" right
	constitutes a "shared flag right" as defined in [I-D.ietf-imapext-		constitutes a "shared flag right" as defined in [RFC4314] Section
	2086upd] Section 6.2.		6.2.
	A summary of all the access control restrictions is tabulated below		A summary of all the access control restrictions is tabulated below
	+---------------+---------------+-----------------------------------+		+---------------+---------------+-----------------------------------+
	| Server Type | Action on | Type of mailbox |		| Server Type | Action on | Type of mailbox |
	| | annotation | |		| | annotation | |
	+===============+===============+===================================+		+===============+===============+===================================+
	| | | |		| | | |
	| | read .priv | Any mailbox that can be SELECTED |		| | read .priv | Any mailbox that can be SELECTED |
	| | values | or EXAMINED. |		| | values | or EXAMINED. |
	| | | |		| | | |
	skipping to change at page 15, line 5 ¶		skipping to change at page 16, line 5 ¶
	| | read .shared | Any mailbox with the "r" |		| | read .shared | Any mailbox with the "r" |
	| | values | ACL right. |		| | values | ACL right. |
	| | | |		| | | |
	| +---------------+-----------------------------------+		| +---------------+-----------------------------------+
	| | | |		| | | |
	| | write .shared | Any mailbox with the "n" |		| | write .shared | Any mailbox with the "n" |
	| | values | ACL right. |		| | values | ACL right. |
	| | | |		| | | |
	+---------------+---------------+-----------------------------------+		+---------------+---------------+-----------------------------------+
	3.5. Access to Standard IMAP Flags and Keywords		4.5. Access to Standard IMAP Flags and Keywords
	Due to ambiguity of how private and shared values would map to the		Due to ambiguity of how private and shared values would map to the
	base IMAP flag and keyword values, the ANNOTATE extension does not		base IMAP flag and keyword values, the ANNOTATE extension does not
	expose IMAP flags or keywords as entries. However, the /flags		expose IMAP flags or keywords as entries. However, the /flags
	annotation entry is reserved for future use and MUST NOT be used by		annotation entry is reserved for future use and MUST NOT be used by
	clients or servers supporting this extension.		clients or servers supporting this extension.
	Clients that need to implement shared and private "flags" can create		Clients that need to implement shared and private "flags" can create
	their own annotation entries for those, completely bypassing the base		their own annotation entries for those, completely bypassing the base
	IMAP flag/keyword behaviour.		IMAP flag/keyword behaviour.
	4. IMAP Protocol Changes		5. IMAP Protocol Changes
	4.1. General Considerations		5.1. General Considerations
	Servers may be able to offer only a limited level of support for		Servers may be able to offer only a limited level of support for
	annotations in mailboxes, and it is useful for clients to be able to		annotations in mailboxes, and it is useful for clients to be able to
	know what level of support is available. Servers MUST return an		know what level of support is available. Servers MUST return an
	ANNOTATIONS response during the SELECT or EXAMINE command for a		ANNOTATIONS response during the SELECT or EXAMINE command for a
	mailbox to indicate the level of support. Possible response codes		mailbox to indicate the level of support. Possible response codes
	used with the ANNOTATIONS response are:		used with the ANNOTATIONS response are:
	"NONE" - this indicates that the mailbox being selected does not		"NONE" - this indicates that the mailbox being selected does not
	support annotations at all. Clients MUST NOT attempt to use		support annotations at all. Clients MUST NOT attempt to use
	skipping to change at page 16, line 10 ¶		skipping to change at page 17, line 10 ¶
	server MUST indicate the maximum size for an annotation value by		server MUST indicate the maximum size for an annotation value by
	providing the maximum size value in the response code. Clients		providing the maximum size value in the response code. Clients
	MUST NOT store annotation values of a size greater than the amount		MUST NOT store annotation values of a size greater than the amount
	indicated by the server. Servers MUST accept a minimum annotation		indicated by the server. Servers MUST accept a minimum annotation
	data size of at least 1024 bytes if annotations can be written.		data size of at least 1024 bytes if annotations can be written.
	In addition the server MAY limit the total number of annotations for		In addition the server MAY limit the total number of annotations for
	a single message. However, the server MUST provide a minimum		a single message. However, the server MUST provide a minimum
	annotation count per message of at least 10.		annotation count per message of at least 10.
	4.2. ANNOTATE parameter with the SELECT/EXAMINE commands		5.2. ANNOTATE parameter with the SELECT/EXAMINE commands
	The ANNOTATE extension defines a single optional SELECT parameter		The ANNOTATE extension defines a single optional SELECT parameter
	[I-D.melnikov-imap-ext-abnf] "ANNOTATE", which is used to turn on		[I-D.melnikov-imap-ext-abnf] "ANNOTATE", which is used to turn on
	unsolicited responses for annotations as described in Section 4.4.		unsolicited responses for annotations as described in Section 5.4.
	This optional parameter results in a per-mailbox state change, i.e.		This optional parameter results in a per-mailbox state change, i.e.
	it must be used in each SELECT/EXAMINE command in order to be		it must be used in each SELECT/EXAMINE command in order to be
	effective, irrespective of whether it was used in a previous SELECT/		effective, irrespective of whether it was used in a previous SELECT/
	EXAMINE during the same session.		EXAMINE during the same session.
	Example:		Example:
	C: a SELECT INBOX ANNOTATE		C: a SELECT INBOX (ANNOTATE)
	S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)		S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
	S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft		S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
	\Deleted \Seen \*)]		\Deleted \Seen \*)]
	S: * 10268 EXISTS		S: * 10268 EXISTS
	S: * 1 RECENT		S: * 1 RECENT
	S: * OK [UNSEEN 10268]		S: * OK [UNSEEN 10268]
	S: * OK [UIDVALIDITY 890061587]		S: * OK [UIDVALIDITY 890061587]
	S: * OK [UIDNEXT 34643]		S: * OK [UIDNEXT 34643]
	S: * OK [ANNOTATIONS 20480 NOPRIVATE]		S: * OK [ANNOTATIONS 20480 NOPRIVATE]
	S: a OK [READ-WRITE] Completed		S: a OK [READ-WRITE] Completed
	In the above example, a SELECT command with the ANNOTATE parameter		In the above example, a SELECT command with the ANNOTATE parameter
	is issued. The response from the server includes the required		is issued. The response from the server includes the required
	ANNOTATIONS response that indicates that the server supports		ANNOTATIONS response that indicates that the server supports
	annotations up to a maximum size of 20480 bytes and does not		annotations up to a maximum size of 20480 bytes and does not
	support private annotations (only shared).		support private annotations (only shared).
	4.3. ANNOTATION Message Data Item in FETCH Command		5.3. ANNOTATION Message Data Item in FETCH Command
	This extension adds an ANNOTATION message data item to the FETCH		This extension adds an ANNOTATION message data item to the FETCH
	command. This allows clients to retrieve annotations for a range of		command. This allows clients to retrieve annotations for a range of
	messages in the currently selected mailbox.		messages in the currently selected mailbox.
	ANNOTATION <entry-specifier> <attribute-specifier>		ANNOTATION <entry-specifier> <attribute-specifier>
	The ANNOTATION message data item, when used by the client in the		The ANNOTATION message data item, when used by the client in the
	FETCH command, takes an entry specifier and an attribute		FETCH command, takes an entry specifier and an attribute
	specifier.		specifier.
	skipping to change at page 18, line 26 ¶		skipping to change at page 19, line 26 ¶
	((/comment /altsubject) value.priv))		((/comment /altsubject) value.priv))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	(/comment (value.priv "What a chowder-head")		(/comment (value.priv "What a chowder-head")
	/altsubject (value.priv "How to crush beer cans")))		/altsubject (value.priv "How to crush beer cans")))
	S: a OK Fetch complete		S: a OK Fetch complete
	In the above example, the contents of the private "value"		In the above example, the contents of the private "value"
	attributes for the two entries "/comment" and "/altsubject" are		attributes for the two entries "/comment" and "/altsubject" are
	requested by the client and returned by the server.		requested by the client and returned by the server.
	4.4. ANNOTATION Message Data Item in FETCH Response		5.4. ANNOTATION Message Data Item in FETCH Response
	The ANNOTATION message data item in the FETCH response displays		The ANNOTATION message data item in the FETCH response displays
	information about annotations in a message.		information about annotations in a message.
	ANNOTATION parenthesised list		ANNOTATION parenthesised list
	The response consists of a list of entries, each of which has a		The response consists of a list of entries, each of which has a
	list of attribute-value pairs.		list of attribute-value pairs.
	Example:		Example:
	skipping to change at page 20, line 10 ¶		skipping to change at page 21, line 10 ¶
	C: a STORE 1 +FLAGS (\Seen)		C: a STORE 1 +FLAGS (\Seen)
	S: * 1 FETCH (FLAGS (\Seen))		S: * 1 FETCH (FLAGS (\Seen))
	ANNOTATION (/comment))		ANNOTATION (/comment))
	S: a OK STORE complete		S: a OK STORE complete
	In the above example, an unsolicited ANNOTATION response is		In the above example, an unsolicited ANNOTATION response is
	returned during a STORE command. The unsolicited response		returned during a STORE command. The unsolicited response
	contains only the entry name of the annotation that changed, and		contains only the entry name of the annotation that changed, and
	not its value.		not its value.
	4.5. ANNOTATION Message Data Item in STORE		5.5. ANNOTATION Message Data Item in STORE
	ANNOTATION <parenthesised entry-attribute-value list>		ANNOTATION <parenthesised entry-attribute-value list>
	Sets the specified list of entries by adding or replacing the		Sets the specified list of entries by adding or replacing the
	specified attributes with the values provided. Clients can use		specified attributes with the values provided. Clients can use
	"NIL" for values of attributes it wants to remove from entries.		"NIL" for values of attributes it wants to remove from entries.
	The ANNOTATION message data item used with the STORE command has an		The ANNOTATION message data item used with the STORE command has an
	implicit ".SILENT" behaviour. This means the server does not		implicit ".SILENT" behaviour. This means the server does not
	generate an untagged FETCH in response to the STORE command and		generate an untagged FETCH in response to the STORE command and
	skipping to change at page 21, line 35 ¶		skipping to change at page 22, line 35 ¶
	C: a STORE 1 ANNOTATION (/comment		C: a STORE 1 ANNOTATION (/comment
	(value.priv "My new comment"		(value.priv "My new comment"
	value.shared "foo's bar"))		value.shared "foo's bar"))
	S: a OK Store complete		S: a OK Store complete
	In the above example, the entry "/comment" is created (if not already		In the above example, the entry "/comment" is created (if not already
	present) and the private and shared "value" attributes are created if		present) and the private and shared "value" attributes are created if
	not already present, or replaced if they exist.		not already present, or replaced if they exist.
	4.6. ANNOTATION interaction with COPY		5.6. ANNOTATION interaction with COPY
	The COPY command can be used to move messages from one mailbox to		The COPY command can be used to move messages from one mailbox to
	another on the same server. Servers that support the ANNOTATION		another on the same server. Servers that support the ANNOTATION
	extension MUST, for each message being copied, copy all ".priv"		extension MUST, for each message being copied, copy all ".priv"
	annotation data for the current user only, and all ".shared"		annotation data for the current user only, and all ".shared"
	annotation data along with the message to the new mailbox. The only		annotation data along with the message to the new mailbox. The only
	exceptions to this are if the destination mailbox permissions are		exceptions to this are if the destination mailbox permissions are
	such that either the ".priv" or ".shared" annotations are not		such that either the ".priv" or ".shared" annotations are not
	allowed, or if the destination mailbox is of a type that does not		allowed, or if the destination mailbox is of a type that does not
	support annotations or does not support storing of annotations (a		support annotations or does not support storing of annotations (a
	mailbox that returns a "NONE" or "READ-ONLY" response code in its		mailbox that returns a "NONE" or "READ-ONLY" response code in its
	ANNOTATIONS response), or if the destination mailbox cannot support		ANNOTATIONS response), or if the destination mailbox cannot support
	the size of a annotation because it exceeds the ANNOTATIONS value.		the size of a annotation because it exceeds the ANNOTATIONS value.
	Servers MUST NOT copy ".priv" annotation data for users other than		Servers MUST NOT copy ".priv" annotation data for users other than
	the current user.		the current user.
	4.7. ANNOTATION Message Data Item in APPEND		5.7. ANNOTATION Message Data Item in APPEND
	ANNOTATION <parenthesised entry-attribute-value list>		ANNOTATION <parenthesised entry-attribute-value list>
	Sets the specified list of entries and attributes in the resulting		Sets the specified list of entries and attributes in the resulting
	message.		message.
	The APPEND command can include annotations for the message being		The APPEND command can include annotations for the message being
	appended via the addition of a new append data item [I-D.melnikov-		appended via the addition of a new append data item [I-D.melnikov-
	imap-ext-abnf]. The new data item can also be used with the multi-		imap-ext-abnf]. The new data item can also be used with the multi-
	append [RFC3502] extension that allows multiple messages to be		append [RFC3502] extension that allows multiple messages to be
	skipping to change at page 22, line 32 ¶		skipping to change at page 23, line 32 ¶
	S: + Ready for literal data		S: + Ready for literal data
	C: MIME-Version: 1.0		C: MIME-Version: 1.0
	...		...
	C:		C:
	S: a OK APPEND completed		S: a OK APPEND completed
	In the above example, a comment with a private value is added to a		In the above example, a comment with a private value is added to a
	new message appended to the mailbox. The ellipsis represents the		new message appended to the mailbox. The ellipsis represents the
	bulk of the message.		bulk of the message.
	4.8. ANNOTATION Criterion in SEARCH		5.8. ANNOTATION Criterion in SEARCH
	ANNOTATION <entry-name> <attribute-name> <value>		ANNOTATION <entry-name> <attribute-name> <value>
	The ANNOTATION criterion for the SEARCH command allows a client to		The ANNOTATION criterion for the SEARCH command allows a client to
	search for a specified string in the value of an annotation entry of		search for a specified string in the value of an annotation entry of
	a message.		a message.
	Messages that have annotations with entries matching <entry-name> and		Messages that have annotations with entries matching <entry-name> and
	attributes matching <attribute-name> and the specified string <value>		attributes matching <attribute-name> and the specified string <value>
	in their values are returned in the SEARCH results. The "*"		in their values are returned in the SEARCH results. The "*"
	skipping to change at page 23, line 24 ¶		skipping to change at page 24, line 24 ¶
	Example:		Example:
	C: a SEARCH ANNOTATION * value.priv "IMAP4"		C: a SEARCH ANNOTATION * value.priv "IMAP4"
	S: * SEARCH 1 2 3 5 8 13 21 34		S: * SEARCH 1 2 3 5 8 13 21 34
	S: a OK Search complete		S: a OK Search complete
	In the above example, the message numbers of any messages		In the above example, the message numbers of any messages
	containing the string "IMAP4" in the private "value" attribute of		containing the string "IMAP4" in the private "value" attribute of
	any entry are returned in the search results.		any entry are returned in the search results.
	4.9. ANNOTATION Key in SORT		5.9. ANNOTATION Key in SORT
	ANNOTATION <entry-name> <attribute-name>		ANNOTATION <entry-name> <attribute-name>
	The ANNOTATION criterion for the SORT command [I-D.ietf-imapext-sort]		The ANNOTATION criterion for the SORT command [I-D.ietf-imapext-sort]
	instructs the server to return the message numbers or UIDs of a		instructs the server to return the message numbers or UIDs of a
	mailbox, sorted using the values of the specified annotations. The		mailbox, sorted using the values of the specified annotations. The
	ANNOTATION criterion is available if the server returns both ANNOTATE		ANNOTATION criterion is available if the server returns both
	and SORT as supported capabilities in the CAPABILITY command		ANNOTATE-EXPERIMENT-1 and SORT as supported capabilities in the
	response.		CAPABILITY command response.
	Messages are sorted using the values of the <attribute-name>		Messages are sorted using the values of the <attribute-name>
	attributes in the <entry-name> entries.		attributes in the <entry-name> entries.
	Clients MUST provide either the ".priv" or ".shared" suffix to the		Clients MUST provide either the ".priv" or ".shared" suffix to the
	attribute name to ensure that the server knows which specific value		attribute name to ensure that the server knows which specific value
	to sort on.		to sort on.
	Only the "value.priv", "value.shared", "size.priv" and "size.shared"		Only the "value.priv" and "value.shared" attributes can be used for
	attributes can be used for sorting. Clients MUST NOT specify an		sorting. Clients MUST NOT specify an attribute other than either
	attribute other than either "value.priv", "value.shared", "size.priv"		"value.priv" or "value.shared". Servers MUST return a BAD response
	or "size.shared". Servers MUST return a BAD response if the client		if the client tries to search any other attribute.
	tries to search any other attribute.
	When either "value.priv" or "value.shared" is being sorted, the		When either "value.priv" or "value.shared" is being sorted, the
	server MUST use the character set value specified in the SORT command		server MUST use the character set value specified in the SORT command
	to determine the appropriate sort order.		to determine the appropriate sort order.
	When either "size.priv" or "size.shared" is being sorted, the server
	sorts using the numeric values of those attributes, as it would when
	the "SIZE" sort key is used.
	Example:		Example:
	C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL		C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL
	S: * SORT 2 3 4 5 1 11 10 6 7 9 8		S: * SORT 2 3 4 5 1 11 10 6 7 9 8
	S: a OK Sort complete		S: a OK Sort complete
	In the above example, the message numbers of all messages are		In the above example, the message numbers of all messages are
	returned, sorted according to the shared "value" attribute of the		returned, sorted according to the shared "value" attribute of the
	"/altsubject" entry.		"/altsubject" entry.
	Note that the ANNOTATION sort key must include a fully specified		Note that the ANNOTATION sort key must include a fully specified
	entry - wild cards are not allowed.		entry - wild cards are not allowed.
	4.10. New ACL Rights		5.10. New ACL Rights
	As discussed in Section 3.4 this extension adds a new "n" right to		As discussed in Section 4.4 this extension adds a new "n" right to
	the list of rights provided by the ACL extensions [RFC2086] and		the list of rights provided by the ACL extensions [RFC2086] and
	[I-D.ietf-imapext-2086upd].		[RFC4314].
	5. Formal Syntax		6. Formal Syntax
	The following syntax specification uses the Augmented Backus-Naur		The following syntax specification uses the Augmented Backus-Naur
	Form (ABNF) notation as specified in [RFC2234].		Form (ABNF) notation as specified in [RFC2234].
	Non-terminals referenced but not defined below are as defined by		Non-terminals referenced but not defined below are as defined by
	[RFC3501] with the new definitions in [I-D.melnikov-imap-ext-abnf]		[RFC3501] with the new definitions in [I-D.melnikov-imap-ext-abnf]
	superseding those in [RFC3501].		superseding those in [RFC3501].
	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
	skipping to change at page 25, line 8 ¶		skipping to change at page 25, line 51 ¶
	append-ext =/ att-annotate		append-ext =/ att-annotate
	; modifies [RFC3501] extension behaviour		; modifies [RFC3501] extension behaviour
	att-annotate = "ANNOTATION" SP		att-annotate = "ANNOTATION" SP
	"(" entry-att *(SP entry-att) ")"		"(" entry-att *(SP entry-att) ")"
	att-search = "value" / "value.priv" / "value.shared"		att-search = "value" / "value.priv" / "value.shared"
	; the only attributes that can be searched		; the only attributes that can be searched
	att-sort = "value.priv" / "value.shared" /		att-sort = "value.priv" / "value.shared"
	"size.priv" / "size.shared"
	; the only attributes that can be sorted		; the only attributes that can be sorted
	att-value = attrib SP value		att-value = attrib SP value
	attrib = astring		attrib = astring
	; dot-separated attribute name		; dot-separated attribute name
	; MUST NOT contain "*" or "%"		; MUST NOT contain "*" or "%"
	attribs = attrib / "(" attrib *(SP attrib) ")"		attribs = attrib / "(" attrib *(SP attrib) ")"
	; one or more attribute specifiers		; one or more attribute specifiers
	capability =/ "ANNOTATE"		capability =/ "ANNOTATE-EXPERIMENT-1"
	; defines the capability for this extension		; defines the capability for this extension
	entries = entry-match /		entries = entry-match /
	"(" entry-match *(SP entry-match) ")"		"(" entry-match *(SP entry-match) ")"
	entry = astring		entry = astring
	; slash-separated path to entry		; slash-separated path to entry
	; MUST NOT contain "*" or "%"		; MUST NOT contain "*" or "%"
	entry-att = entry SP "(" att-value *(SP att-value) ")"		entry-att = entry SP "(" att-value *(SP att-value) ")"
	skipping to change at page 26, line 17 ¶		skipping to change at page 27, line 13 ¶
	; ANNOTATE extension		; ANNOTATE extension
	sort-key =/ "ANNOTATION" SP entry SP att-sort		sort-key =/ "ANNOTATION" SP entry SP att-sort
	; modifies original sort-key		; modifies original sort-key
	store-att-flags =/ att-annotate		store-att-flags =/ att-annotate
	; modifies original IMAP STORE command		; modifies original IMAP STORE command
	value = nstring / literal8		value = nstring / literal8
	6. IANA Considerations		7. IANA Considerations
	Entry names MUST be specified in a standards track or IESG approved		Entry names MUST be specified in a standards track or IESG approved
	experimental RFC, or fall under the vendor namespace. Vendor names		experimental RFC, or fall under the vendor namespace. Vendor names
	MUST be registered.		MUST be registered.
	Attribute names MUST be specified in a standards track or IESG		Attribute names MUST be specified in a standards track or IESG
	approved experimental RFC.		approved experimental RFC.
	Each entry registration MUST include a content-type that is used to		Each entry registration MUST include a content-type that is used to
	indicate the nature of the annotation value. Where applicable a		indicate the nature of the annotation value. Where applicable a
	charset parameter MUST be included with the content-type.		charset parameter MUST be included with the content-type.
	6.1. Entry and Attribute Registration Template		7.1. Entry and Attribute Registration Template
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[] Entry [] Attribute		[] Entry [] Attribute
	Name: ______________________________		Name: ______________________________
	skipping to change at page 27, line 4 ¶		skipping to change at page 27, line 46 ¶
	Description: _______________________		Description: _______________________
	____________________________________		____________________________________
	____________________________________		____________________________________
	Content-Type:_______________________		Content-Type:_______________________
	Contact person: ____________________		Contact person: ____________________
	email: ____________________		email: ____________________
	6.2. Entry Registrations		7.2. Entry Registrations
	The following templates specify the IANA registrations of annotation		The following templates specify the IANA registrations of annotation
	entries specified in this document.		entries specified in this document.
	6.2.1. /comment		7.2.1. /comment
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[X] Entry [] Attribute		[X] Entry [] Attribute
	Name: /comment		Name: /comment
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Content-Type: text/plain; charset=utf-8		Content-Type: text/plain; charset=utf-8
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.2.2. /flags		7.2.2. /flags
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[X] Entry [] Attribute		[X] Entry [] Attribute
	Name: /flags		Name: /flags
	Description: Reserved entry hierarchy.		Description: Reserved entry hierarchy.
	Content-Type: -		Content-Type: -
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.2.3. /altsubject		7.2.3. /altsubject
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[X] Entry [] Attribute		[X] Entry [] Attribute
	Name: /altsubject		Name: /altsubject
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Content-Type: text/plain; charset=utf-8		Content-Type: text/plain; charset=utf-8
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.2.4. /<section-part>/comment		7.2.4. /<section-part>/comment
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[X] Entry [] Attribute		[X] Entry [] Attribute
	Name: /<section-part>/comment		Name: /<section-part>/comment
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Content-Type: text/plain; charset=utf-8		Content-Type: text/plain; charset=utf-8
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.2.5. /<section-part>/flags/seen		7.2.5. /<section-part>/flags/seen
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[X] Entry [] Attribute		[X] Entry [] Attribute
	Name: /<section-part>/flags/seen		Name: /<section-part>/flags/seen
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Content-Type: text/plain; charset=utf-8		Content-Type: text/plain; charset=utf-8
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.2.6. /<section-part>/flags/answered		7.2.6. /<section-part>/flags/answered
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[X] Entry [] Attribute		[X] Entry [] Attribute
	Name: /<section-part>/flags/answered		Name: /<section-part>/flags/answered
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Content-Type: text/plain; charset=utf-8		Content-Type: text/plain; charset=utf-8
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.2.7. /<section-part>/flags/flagged		7.2.7. /<section-part>/flags/flagged
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[X] Entry [] Attribute		[X] Entry [] Attribute
	Name: /<section-part>/flags/flagged		Name: /<section-part>/flags/flagged
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Content-Type: text/plain; charset=utf-8		Content-Type: text/plain; charset=utf-8
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.2.8. /<section-part>/flags/forwarded		7.2.8. /<section-part>/flags/forwarded
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[X] Entry [] Attribute		[X] Entry [] Attribute
	Name: /<section-part>/flags/forwarded		Name: /<section-part>/flags/forwarded
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Content-Type: text/plain; charset=utf-8		Content-Type: text/plain; charset=utf-8
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.3. Attribute Registrations		7.3. Attribute Registrations
	The following templates specify the IANA registrations of annotation		The following templates specify the IANA registrations of annotation
	attributes specified in this document.		attributes specified in this document.
	6.3.1. value		7.3.1. value
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[] Entry [X] Attribute		[] Entry [X] Attribute
	Name: value		Name: value
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.3.2. size		7.3.2. size
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP Annotate Registration		Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:		Please register the following IMAP Annotate item:
	[] Entry [X] Attribute		[] Entry [X] Attribute
	Name: size		Name: size
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: cyrus@daboo.name		email: cyrus@daboo.name
	6.3.3. content-language		8. Internationalization Considerations
	To: iana@iana.org
	Subject: IMAP Annotate Registration
	Please register the following IMAP Annotate item:
	[] Entry [X] Attribute
	Name: content-language
	Description: Defined in IMAP ANNOTATE extension document.
	Contact person: Cyrus Daboo
	email: cyrus@daboo.name
	7. Internationalization Considerations
	Annotations may contain values that include text strings, and both		Annotations may contain values that include text strings, and both
	searching and sorting are possible with annotations. Servers MUST		searching and sorting are possible with annotations. Servers MUST
	follow standard IMAP text normalization, character set conversion and		follow standard IMAP text normalization, character set conversion and
	collation rules when such operations are acarried out, as they would		collation rules when such operations are acarried out, as they would
	for other textual fields being searched or sorted on.		for other textual fields being searched or sorted on.
	8. Security Considerations		9. Security Considerations
	Annotations whose values are intended to remain private MUST be		Annotations whose values are intended to remain private MUST be
	stored in ".priv" values, and not ".shared" values which may be		stored in ".priv" values, and not ".shared" values which may be
	accessible to other users.		accessible to other users.
	Excluding the above issues the ANNOTATE extension does not raise any		Excluding the above issues the ANNOTATE extension does not raise any
	security considerations that are not present in the base IMAP		security considerations that are not present in the base IMAP
	protocol, and these issues are discussed in [RFC3501].		protocol, and these issues are discussed in [RFC3501].
	9. References		10. References
	9.1. Normative References
	[I-D.ietf-imapext-2086upd]		10.1. Normative References
	Melnikov, A., "IMAP4 ACL extension",
	draft-ietf-imapext-2086upd-08 (work in progress),
	June 2005.
	[I-D.ietf-imapext-sort]		[I-D.ietf-imapext-sort]
	Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS		Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS
	PROTOCOL - SORT AND THREAD EXTENSION",		PROTOCOL - SORT AND THREAD EXTENSION",
	draft-ietf-imapext-sort-17 (work in progress), May 2004.		draft-ietf-imapext-sort-17 (work in progress), May 2004.
	[I-D.melnikov-imap-ext-abnf]		[I-D.melnikov-imap-ext-abnf]
	Daboo, C. and A. Melnikov, "Collected extensions to IMAP4		Daboo, C. and A. Melnikov, "Collected extensions to IMAP4
	ABNF", draft-melnikov-imap-ext-abnf-05 (work in progress),		ABNF", draft-melnikov-imap-ext-abnf-08 (work in progress),
	October 2005.		January 2006.
	[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.		[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.		Specifications: ABNF", RFC 2234, November 1997.
	[RFC2244] Newman, C. and J. Myers, "ACAP -- Application		[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
	Configuration Access Protocol", RFC 2244, November 1997.		Configuration Access Protocol", RFC 2244, November 1997.
	[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
	May 2002.
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, March 2003.		4rev1", RFC 3501, March 2003.
	[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -		[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
	MULTIAPPEND Extension", RFC 3502, March 2003.		MULTIAPPEND Extension", RFC 3502, March 2003.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	9.2. Informative References		[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
			RFC 4314, December 2005.
			10.2. Informative References
	[I-D.ietf-imapext-condstore]		[I-D.ietf-imapext-condstore]
	Melnikov, A. and S. Hole, "IMAP Extension for Conditional		Melnikov, A. and S. Hole, "IMAP Extension for Conditional
	STORE operation", draft-ietf-imapext-condstore-06 (work in		STORE operation", draft-ietf-imapext-condstore-09 (work in
	progress), October 2005.		progress), February 2006.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	Many thanks to Chris Newman for his detailed comments on the first		Many thanks to Chris Newman for his detailed comments on the first
	draft of this document, and to the participants at the ACAP working		draft of this document, and to the participants at the ACAP working
	dinner in Pittsburgh. The participants of the IMAPext working group		dinner in Pittsburgh. The participants of the IMAPext working group
	made significant contributions to this work.		made significant contributions to this work.
	Authors' Addresses		Authors' Addresses
	skipping to change at page 35, line 41 ¶		skipping to change at page 36, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 76 change blocks.
	172 lines changed or deleted		159 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/