< draft-ietf-imapext-annotate-12.txt		draft-ietf-imapext-annotate-13.txt >
	IMAP Extensions Working Group C. Daboo		IMAP Extensions Working Group C. Daboo
	Internet-Draft ISAMET, Inc.		Internet-Draft ISAMET, Inc.
	Expires: August 4, 2005 R. Gellens		Expires: September 29, 2005 R. Gellens
	QUALCOMM Incorporated		QUALCOMM Incorporated
	February 3, 2005		March 31, 2005
	IMAP ANNOTATE Extension		IMAP ANNOTATE Extension
	draft-ietf-imapext-annotate-12		draft-ietf-imapext-annotate-13
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any 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 is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 August 4, 2005.		This Internet-Draft will expire on September 29, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	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 "metadata" for messages		permits clients and servers to maintain "metadata" for messages, or
	stored in an IMAP mailbox.		individual message parts, stored in an IMAP mailbox.
	Change History (to be removed prior to publication as an RFC)		Change History (to be removed prior to publication as an RFC)
			Changes from -12 to -13:
			1. Sync with change from DC meeting wrt 'r' right for both read and
			write of .priv.
			2. Add text about 'n' right being a 'shared flag right' as defined
			in 2086upd.
			3. Allow NIL in /<section-part>/flags entries.
			4. Expand abstract to also indicate that annotations can apply on a
			per-body part basis as well as per message.
			5. Fix resp-text-code to use nil instead of "NIL".
			6. Use double-quotes consistently around ANNOTATESIZE etc.
			7. Fix typos.
			8. Remove redundant second para of Introduction.
			9. Added 'Conventions' section with RFC2119 reference..
			10. Describe S:, C: example behaviour in conventions section..
			11. Clarify that new rights must also be present if only old ACL is
			present.
			12. Entry/attributes MUST NOT contain consecutive or trailing '/' or
			'.'.
			13. Clarify default charset for content-type text/plain.
			14. Recommend use of utf-8 for all non-ascii text.
			15. Clarify terminology of ANNOTATESIZE response code.
			16. Require servers to return ANNOTATESIZE on SELECT.
			17. Change an example to use UID FETCH for variety.
			18. Clarify what to do about annotations exceeding allowed
			ANNOTATESIZE when doing copy.
			19. Use ABNFext document for extended SELECT etc.
			20. Remove RFC1891 reference.
			21. capability syntax extension.
			22. Comment on validation content-type attribute.
			23. Added recommended content-type in IANA registration.
			24. Added use of literal8 for values.
			25. Prevent use of 'shared' and 'priv' as separate hierarchy
			components.
			26. Restrict entry/attribute names to ascii and added display-name
			attribute.
			27. Remove references to CATENATE and use ABNFext for extended
			APPEND syntax.
	Changes from -11 to -12:		Changes from -11 to -12:
	1. Fixed raw XML in formal syntax.		1. Fixed raw XML in formal syntax.
	2. Fixed double \ in IANA section titles.		2. Fixed double \ in IANA section titles.
	3. Fixed APPEND formal syntax.		3. Fixed APPEND formal syntax.
	4. Added annotations to CATENATE extension.		4. Added annotations to CATENATE extension.
	5. Reworded text for unsolicited responses.		5. Reworded text for unsolicited responses.
	6. Fixed formal syntax for fetch responses to extend base spec item.		6. Fixed formal syntax for fetch responses to extend base spec item.
	Changes from -10 to -11:		Changes from -10 to -11:
	1. Flags are now read-only and exactly match their IMAP		1. Flags are now read-only and exactly match their IMAP
	counterparts.		counterparts.
	2. Added new ACL bits for annotations.		2. Added new ACL bits for annotations.
	3. Revise security considerations.		3. Revise security considerations.
	4. Fixed some references.		4. Fixed some references.
	Changes from -09 to -10:		Changes from -09 to -10:
	1. Added Content-Language value.		1. Added Content-Language value.
	2. Added IANA registrations for entries/attributes in this document.		2. Added IANA registrations for entries/attributes in this document.
	skipping to change at page 5, line 7 ¶		skipping to change at page 6, line 7 ¶
	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. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8		2. Conventions Used in This Document . . . . . . . . . . . . . 8
	2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.2 Namespace of entries and attributes . . . . . . . . . . . 8		3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 9		3.2 Namespace of entries and attributes . . . . . . . . . . . 9
	2.2.2 Attribute Names . . . . . . . . . . . . . . . . . . . 11		3.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 10
	2.3 Private versus Shared . . . . . . . . . . . . . . . . . . 12		3.2.2 Attribute Names . . . . . . . . . . . . . . . . . . . 12
	2.4 Access Control . . . . . . . . . . . . . . . . . . . . . . 13		3.3 Private versus Shared . . . . . . . . . . . . . . . . . . 13
	2.5 Access to Standard IMAP Flags and Keywords . . . . . . . . 15		3.4 Access Control . . . . . . . . . . . . . . . . . . . . . . 14
	3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 15		3.5 Access to Standard IMAP Flags and Keywords . . . . . . . . 16
	3.1 General Considerations . . . . . . . . . . . . . . . . . . 15		4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 16
	3.2 Optional parameters with the SELECT/EXAMINE commands . . . 15		4.1 General Considerations . . . . . . . . . . . . . . . . . . 16
	3.3 ANNOTATION Message Data Item in FETCH Command . . . . . . 17		4.2 ANNOTATE parameter with the SELECT/EXAMINE commands . . . 16
	3.4 ANNOTATION Message Data Item in FETCH Response . . . . . . 19		4.3 ANNOTATION Message Data Item in FETCH Command . . . . . . 17
	3.5 ANNOTATION Message Data Item in STORE . . . . . . . . . . 20		4.4 ANNOTATION Message Data Item in FETCH Response . . . . . . 19
	3.6 ANNOTATION interaction with COPY . . . . . . . . . . . . . 22		4.5 ANNOTATION Message Data Item in STORE . . . . . . . . . . 20
	3.7 ANNOTATION Message Data Item in APPEND . . . . . . . . . . 22		4.6 ANNOTATION interaction with COPY . . . . . . . . . . . . . 22
	3.8 ANNOTATION Parameter in CATENATE . . . . . . . . . . . . . 23		4.7 ANNOTATION Message Data Item in APPEND . . . . . . . . . . 22
	3.9 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 23		4.8 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 23
	3.10 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . 24		4.9 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 24
	3.11 New ACL Rights . . . . . . . . . . . . . . . . . . . . . 25		4.10 New ACL Rights . . . . . . . . . . . . . . . . . . . . . 24
	4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 25		5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 24
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
	5.1 Entry and Attribute Registration Template . . . . . . . . 27		6.1 Entry and Attribute Registration Template . . . . . . . . 27
	5.2 Entry Registrations . . . . . . . . . . . . . . . . . . . 27		6.2 Entry Registrations . . . . . . . . . . . . . . . . . . . 27
	5.2.1 /comment . . . . . . . . . . . . . . . . . . . . . . . 28		6.2.1 /comment . . . . . . . . . . . . . . . . . . . . . . . 28
	5.2.2 /flags/\answered . . . . . . . . . . . . . . . . . . . 28		6.2.2 /flags/\answered . . . . . . . . . . . . . . . . . . . 28
	5.2.3 /flags/\flagged . . . . . . . . . . . . . . . . . . . 29		6.2.3 /flags/\flagged . . . . . . . . . . . . . . . . . . . 29
	5.2.4 /flags/\deleted . . . . . . . . . . . . . . . . . . . 29		6.2.4 /flags/\deleted . . . . . . . . . . . . . . . . . . . 29
	5.2.5 /flags/\seen . . . . . . . . . . . . . . . . . . . . . 30		6.2.5 /flags/\seen . . . . . . . . . . . . . . . . . . . . . 30
	5.2.6 /flags/\draft . . . . . . . . . . . . . . . . . . . . 30		6.2.6 /flags/\draft . . . . . . . . . . . . . . . . . . . . 30
	5.2.7 /flags/\recent . . . . . . . . . . . . . . . . . . . . 31		6.2.7 /flags/\recent . . . . . . . . . . . . . . . . . . . . 31
	5.2.8 /flags/$mdnsent . . . . . . . . . . . . . . . . . . . 31		6.2.8 /flags/$mdnsent . . . . . . . . . . . . . . . . . . . 31
	5.2.9 /flags/$redirected . . . . . . . . . . . . . . . . . . 32		6.2.9 /flags/$redirected . . . . . . . . . . . . . . . . . . 32
	5.2.10 /flags/$forwarded . . . . . . . . . . . . . . . . . 32		6.2.10 /flags/$forwarded . . . . . . . . . . . . . . . . . 32
	5.2.11 /altsubject . . . . . . . . . . . . . . . . . . . . 33		6.2.11 /altsubject . . . . . . . . . . . . . . . . . . . . 33
	5.2.12 /<section-part>/comment . . . . . . . . . . . . . . 33		6.2.12 /<section-part>/comment . . . . . . . . . . . . . . 33
	5.2.13 /<section-part>/flags/seen . . . . . . . . . . . . . 34		6.2.13 /<section-part>/flags/seen . . . . . . . . . . . . . 34
	5.2.14 /<section-part>/flags/answered . . . . . . . . . . . 34		6.2.14 /<section-part>/flags/answered . . . . . . . . . . . 34
	5.2.15 /<section-part>/flags/flagged . . . . . . . . . . . 35		6.2.15 /<section-part>/flags/flagged . . . . . . . . . . . 35
	5.2.16 /<section-part>/flags/forwarded . . . . . . . . . . 35		6.2.16 /<section-part>/flags/forwarded . . . . . . . . . . 35
	5.3 Attribute Registrations . . . . . . . . . . . . . . . . . 35		6.3 Attribute Registrations . . . . . . . . . . . . . . . . . 35
	5.3.1 value . . . . . . . . . . . . . . . . . . . . . . . . 36		6.3.1 value . . . . . . . . . . . . . . . . . . . . . . . . 36
	5.3.2 size . . . . . . . . . . . . . . . . . . . . . . . . . 36		6.3.2 size . . . . . . . . . . . . . . . . . . . . . . . . . 36
	5.3.3 content-type . . . . . . . . . . . . . . . . . . . . . 37		6.3.3 content-type . . . . . . . . . . . . . . . . . . . . . 37
	5.3.4 content-language . . . . . . . . . . . . . . . . . . . 37		6.3.4 content-language . . . . . . . . . . . . . . . . . . . 37
			6.3.5 display-name . . . . . . . . . . . . . . . . . . . . . 38
	6. Security Considerations . . . . . . . . . . . . . . . . . . 37		7. Security Considerations . . . . . . . . . . . . . . . . . . 38
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	7.1 Normative References . . . . . . . . . . . . . . . . . . . . 38		8.1 Normative References . . . . . . . . . . . . . . . . . . . . 38
	7.2 Informative References . . . . . . . . . . . . . . . . . . . 38		8.2 Informative References . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
	A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39		A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40
	Intellectual Property and Copyright Statements . . . . . . . 40		Intellectual Property and Copyright Statements . . . . . . . 41
	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" as one of the supported
	capabilities in the CAPABILITY response.		capabilities in the CAPABILITY response.
	The ANNOTATE extension adds a new message data item to the FETCH and
	STORE commands, as well as adding SEARCH and SORT keys and an APPEND
	modifier. It also extends tyhe CATENATE extension with a new
	parameter.
	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 ANNOTATION parameter for use in CATENATE		f. adds a new requirement on the COPY command
	g. adds a new requirement on the COPY command		g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE
	h. adds a extension mechanism for adding parameters to the SELECT/		commands
	EXAMINE commands and defines the ANNOTATE parameter		h. adds two new response codes to indicate store failures of
	i. adds two new response codes to indicate store failures of
	annotations.		annotations.
	j. adds a new untagged response codes 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.
	k. adds two new ACL 'bits' for use with the ACL [ACLUPD] extension.		j. adds a new ACL "bit" for use with the ACL extensions [RFC2086]
			and [ACLUPD] .
	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.
	This extension also introduces a generalised mechanism for adding
	parameters to the SELECT or EXAMINE commands. It is anticipated that
	other extensions may want to utilise this, so it is not strictly
	dependent on the ANNOTATE extension being present.
	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 [CONDSTORE] extension.		SHOULD also support the Conditional STORE [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. Data Model		2. Conventions Used in This Document
	2.1 Overview		In examples, "C:" and "S:" indicate lines sent by the client and
			server respectively.
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			3. Data Model
			3.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 "metadata" for a message is stored as a single entry, made up of		of "metadata" for a message is stored as a single entry, made up of
	several attributes.		several attributes.
	For example, a comment added to a message has an entry name of "/		For example, a comment annotation added to a message has an entry
	comment". This entry is composed of several attributes such as		name of "/comment". This entry is composed of several attributes
	"value", "size", etc. which contain the properties and data of the		such as "value", "size", etc. which contain the properties and data
	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 2.4 for specifics).		Section 3.4 for specifics).
	2.2 Namespace of entries and attributes		3.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 in UTF-8, with each component of the name		has a hierarchical name, with each component of the name separated by
	separated by a slash ("/").		a slash ("/"). An entry name MUST NOT contain two consecutive "/"
			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 in UTF-8, with each component of the name separated		hierarchical name, with each component of the name separated by a
	by a period (".").		period ("."). An attribute name MUST NOT contain two consecutive "."
			characters and MUST NOT end with a "." character.
	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 be valid UTF-8 strings which do not contain		("%") characters and MUST NOT contain non-ASCII characters or the
	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
			names "priv" or "shared" as those have special meaning (see Section
			3.3.
	Entry and attribute names are case-sensitive.		Entry and attribute names are case-sensitive.
	Use of non-visible UTF-8 characters in entry and attribute names is		Use of control or punctuation characters in entry and attribute names
	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 for extensibility.		added as needed.
	2.2.1 Entry Names		3.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 Section		experimental RFC, or fall under the vendor namespace. See Section
	5.1 for the registration template.		6.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.
	/flags		/flags
	Defines the top-level of entries for flags associated with an		Defines the top-level of entries for flags associated with an
	entire message. The "value" attribute of each of the entries		entire message. The "value" attribute of each of the entries
	described below must be either "1", "0" or NIL. "1" corresponds		described below must be either "1", "0" or "NIL". "1" corresponds
	to the flag being set.		to the flag being set.
	Standard [RFC3501] flags always have a '\' prefix character.		Standard [RFC3501] flags always have a "\" prefix character.
	Other standard flags have a '$' prefix. The annotation names used		Other standard flags have a "$" prefix. The annotation names used
	for all flags uses the complete name for that flag, including the		for all flags uses the complete name for that flag, including the
	prefix character.		prefix character.
	Flag annotations are read-only. Clients MUST NOT attempt to		Flag annotations are read-only. Clients MUST NOT attempt to
	change them via the annotation entries, using instead the normal		change them via the annotation entries, instead the normal IMAP
	IMAP STORE FLAGS command.		STORE FLAGS command is used.
	The set of standard IMAP flags annotations are:		The set of standard IMAP flags annotations are:
	/flags/\answered		/flags/\answered
	/flags/\flagged		/flags/\flagged
	/flags/\deleted		/flags/\deleted
	/flags/\seen		/flags/\seen
	/flags/\draft		/flags/\draft
	/flags/\recent		/flags/\recent
	Note that entry names are sent as IMAP string elements which		Note that entry names are sent as IMAP string elements which
	requires that '\' characters be escaped if sent as a quoted string		requires that "\" characters be escaped if sent as a quoted string
	as opposed to a literal.		as opposed to a literal.
	Note that flag and keyword names in IMAP are case-insensitive,		Note that flag and keyword names in IMAP are case-insensitive,
	however the entry names for the corresponding annotations are		however the entry names for the corresponding annotations are
	case-sensitive. Thus the IMAP flag and keyword names MUST be		case-sensitive. Thus the IMAP flag and keyword names MUST be
	mapped to lowercase characters before being used as entry names		mapped to lowercase characters before being used as entry names
	for annotations.		for annotations.
	Additional standard flags are:		Additional standard flags are:
	/flags/$mdnsent		/flags/$mdnsent
	/flags/$redirected		/flags/$redirected
	/flags/$forwarded		/flags/$forwarded
	The '$mdnsent' flag is used to indicate message disposition		The "$mdnsent" flag is used to indicate message disposition
	notification processing state [RFC3503].		notification processing state [RFC3503].
	The '$redirected' flag indicates that a message has been handed		The "$redirected" flag indicates that a message has been handed
	off to someone else, by resending the message with minimal		off to someone else, by resending the message with minimal
	alterations, and in such a way that a reply by the new		alterations, and in such a way that a reply by the new
	recipient is addressed to the original author, not the user who		recipient is addressed to the original author, not the user who
	performed the redirection.		performed the redirection.
	The '$forwarded' flag indicates the message was resent to		The "$forwarded" flag indicates the message was resent to
	another user, embedded within or attached to a new message.		another user, embedded within or attached to a new message.
	/altsubject		/altsubject
	Contains text supplied by the message recipient, to be used by the		Contains text supplied by the message recipient, to be used by the
	client instead of the original message Subject.		client instead of the original message Subject.
	/vendor/<vendor-token>		/vendor/<vendor-token>
	Defines the top-level of entries associated with an entire message		Defines the top-level of entries associated with an entire message
	as created by a particular product of some vendor. These		as created by a particular product of some vendor. These
	sub-entries can be used by vendors to provide client-specific		sub-entries can be used by vendors to provide client-specific
	skipping to change at page 11, line 15 ¶		skipping to change at page 12, line 17 ¶
	specific body part of a message. All sub-entries are maintained		specific body part of a message. All sub-entries are maintained
	entirely by the client. There is no implicit change to any flag		entirely by the client. There is no implicit change to any flag
	by the server.		by the server.
	/<section-part>/flags/seen		/<section-part>/flags/seen
	/<section-part>/flags/answered		/<section-part>/flags/answered
	/<section-part>/flags/flagged		/<section-part>/flags/flagged
	/<section-part>/flags/forwarded		/<section-part>/flags/forwarded
	Defines flags for a specific body part of a message. The "value"		Defines flags for a specific body part of a message. The "value"
	attribute of these entries must be either "1" or "0".		attribute of each of the entries described above must be either
			"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 attributes. The vendor-token MUST be registered with		specific attributes. The vendor-token MUST be registered with
	IANA.		IANA.
	2.2.2 Attribute Names		3.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, or fall under the vendor namespace. See		approved experimental RFC, or fall under the vendor namespace. See
	Section 5.1 for the registration template.		Section 6.1 for the registration 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.
	value		value
	A UTF8 string representing the data value of the attribute. To		A string or binary data representing the value of the annotation.
	delete an annotation, the client can store NIL into the value.		To delete an annotation, the client can store "NIL" into the
			value. The content represented by the string is set via the
			content-type attribute. When the content-type attribute is not
			present, the value MUST be a "text/plain" content-type with a
			character set of "utf-8" [RFC3629]. Clients SHOULD use the utf-8
			character set for any text values that contain non ASCII data.
			Note that binary data (data which may contain the NULL octet) is
			allowed (e.g. for storing images etc), and this extension uses
			the "literal8" syntax element [ABNFEXT] to allow 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-type		content-type
	A MIME [RFC2046] content type and subtype that describes the		A MIME [RFC2046] content type and subtype that describes the
	nature of the content of the "value" attribute. If not present, a		nature of the content of the "value" attribute. If not present, a
	value of "text/plain; charset=utf8" is assumed.		value of "text/plain; charset=utf-8" is assumed.
	content-language		content-language
	Indicates the language used for the value. This follows the		Indicates the language used for the value. This follows the
	format described in [RFC3282]. Clients SHOULD set this value when		format described in [RFC3282]. Clients SHOULD set this value when
	storing an annotation that uses text that can be presented to the		storing an annotation that uses text that can be presented to the
	user. It is not required for enumerated or numeric values such as		user. It is not required for enumerated or numeric values such as
	flags etc.		flags etc. If a value is being set, clients MUST ensure that it
			accurately reflects the content stored in the value attribute.
			display-name
			A text string using the "utf-8" character set [RFC3629] that
			describes the nature of the corresponding annotation, in a
			language specified by the "content-language" attribute.
	vendor.<vendor-token>		vendor.<vendor-token>
	Defines an attribute associated with a particular product of some		Defines an attribute associated with a particular product of some
	vendor. This attribute can be used by vendors to provide client		vendor. This attribute can be used by vendors to provide client
	specific attributes. The vendor-token MUST be registered with		specific attributes. The vendor-token MUST be registered with
	IANA, using the [RFC2244] vendor subtree registry.		IANA, using the [RFC2244] vendor subtree registry.
	2.3 Private versus Shared		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
	[ACLUPD] which permits access by other users, or because it is a		[ACLUPD] which permits access by other users, or 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
	skipping to change at page 12, line 49 ¶		skipping to change at page 14, line 18 ¶
	individual users may wish to supplement with additional notes.		individual users may wish to supplement with additional notes.
	If shared and private annotations are to coexist, we need a clear way		If shared and private annotations are to coexist, we need a clear way
	to differentiate them. Also, it should be as easy as possible for a		to differentiate them. Also, it should be as easy as possible for a
	client to access both and not overlook either. There is also a		client to access both and not overlook either. There is also a
	danger in allowing a client to store an annotation without knowing if		danger in allowing a client to store an annotation without knowing if
	it is shared or private.		it is shared or private.
	This document proposes two standard suffixes for all attributes:		This document proposes two standard suffixes for all attributes:
	".shared" and ".priv". A search, fetch, or sort which specifies		".shared" and ".priv". A search, fetch, or sort which specifies
	neither uses both. Store operations MUST explicitly use .priv or		neither uses both. Store operations MUST explicitly use ".priv" or
	.shared suffixes.		".shared" suffixes.
	2.4 Access Control		3.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 calculated		".priv" or ".shared" annotation values. How those rights are
	depends on whether the ACL [ACLUPD] extension is present or not. If		calculated depends on whether the ACL [RFC2086] extension or its
	a client attempts to store or fetch an annotation to which they do		update [ACLUPD] is present or not. If a client attempts to store or
	not have the appropriate rights, the server MUST respond with a NO		fetch an annotation to which they do not have the appropriate rights,
	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 two new		When the ACL extension is present, the server MUST recognise the new
	ACL rights, 'm' and 'n', in addition to the ones defined by the ACL		ACL right "n", in addition to the ones defined by the ACL extension
	extension itself.		itself.
	The 'm' right controls both read and write access to .priv annotation		The "r" right controls both read and write access to ".priv"
	values. When it is on, access to .priv annotations is allowed, when		annotation values. When it is on, access to ".priv" annotations is
	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, when it		values. When it is on, ".shared" annotations can be changed, when it
	is off, .shared annotations cannot be changed. The 'n' right MUST		is off, ".shared" annotations cannot be changed. The "n" right MUST
	NOT be present if the 'r' is not present.		NOT be present if the "r" is not present. The "n" right constitutes
			a "shared flag right" as defined in [ACLUPD] Section 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 14, line 30 ¶		skipping to change at page 15, line 33 ¶
	| | read .shared | Any mailbox that can be SELECTED |		| | read .shared | Any mailbox that can be SELECTED |
	| | values | or EXAMINED. |		| | values | or EXAMINED. |
	| | | |		| | | |
	| +---------------+-----------------------------------+		| +---------------+-----------------------------------+
	| | | |		| | | |
	| | write .shared | Any mailbox that can be SELECTED |		| | write .shared | Any mailbox that can be SELECTED |
	| | values | or EXAMINED and is [READ-WRITE]. |		| | values | or EXAMINED and is [READ-WRITE]. |
	| | | |		| | | |
	+---------------+---------------+-----------------------------------+		+---------------+---------------+-----------------------------------+
	| | | |		| | | |
	| | read .priv | Any mailbox with the 'm' |		| | read .priv | Any mailbox with the "r" |
	| | values | ACL right. |		| | values | ACL right. |
	| | | |		| | | |
	| +---------------+-----------------------------------+		| +---------------+-----------------------------------+
	| | | |		| | | |
	| | write .priv | Any mailbox with the 'm' |		| | write .priv | Any mailbox with the "r" |
	| Server | values | ACL right. |		| Server | values | ACL right. |
	| with | | |		| with | | |
	| ACL Extension +---------------+-----------------------------------+		| ACL Extension +---------------+-----------------------------------+
	| | | |		| | | |
	| | 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. |
	| | | |		| | | |
	+---------------+---------------+-----------------------------------+		+---------------+---------------+-----------------------------------+
	2.5 Access to Standard IMAP Flags and Keywords		3.5 Access to Standard IMAP Flags and Keywords
	Flags cannot be changed through annotations due to ambiguity of how		Flags cannot be changed through annotations due to ambiguity of how
	private and shared values would map to the base IMAP flag and keyword		private and shared values would map to the base IMAP flag and keyword
	values. As a result the /flags annotation values are treated as		values. As a result the /flags annotation values are treated as
	read-only and MUST NOT be changed by a client. In turn this means		read-only and MUST NOT be changed by a client. In turn this means
	that the .priv and .shared values of a flag annotation are always the		that the ".priv" and ".shared" values of a flag annotation are always
	same and represent the value of the base IMAP flag or keyword.		the same and represent the value of the base IMAP flag or keyword.
	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.
	3. IMAP Protocol Changes		4. IMAP Protocol Changes
	3.1 General Considerations		4.1 General Considerations
	The server is allowed to impose limitations on the size of any one		The server is allowed to impose limitations on the size of any one
	annotation or the total number of annotations for a single message.		annotation or the total number of annotations for a single message.
	However, the server MUST accept a minimum annotation data size of at		However, the server MUST accept a minimum annotation data size of at
	least 1024 bytes, and a minimum annotation count per message of at		least 1024 bytes, and a minimum annotation count per message of at
	least 10.		least 10.
	The server SHOULD indicate the maximum size for an annotation value		The server MUST indicate the maximum size for an annotation value by
	by sending an untagged "ANNOTATESIZE" response during a SELECT or		sending an untagged ANNOTATESIZE response containing the maximum size
	EXAMINE command. Clients MUST NOT store annotation values of a size		value during a SELECT or EXAMINE command. Clients MUST NOT store
	greater than the amount indicated by the server in the "ANNOTATESIZE"		annotation values of a size greater than the amount indicated by the
	response.		server in the ANNOTATESIZE response.
	In some cases, servers may be able to offer annotations on some		In some cases, servers may be able to offer annotations on some
	mailboxes and not others, or may be able to provide only read-only		mailboxes and not others, or may be able to provide only read-only
	annotations on some mailboxes. For mailboxes that cannot have		annotations on some mailboxes. For mailboxes that cannot have
	annotations associated with them, the server MUST return an		annotations associated with them, the server MUST return an
	"ANNOTATESIZE" response with a value of "NIL" during the SELECT or		ANNOTATESIZE response with a value of "NIL" during the SELECT or
	EXAMINE command for that mailbox. Clients MUST NOT attempt to fetch		EXAMINE command for that mailbox. Clients MUST NOT attempt to fetch
	or store annotations on any messages in a mailbox for which the		or store annotations on any messages in a mailbox for which the
	"ANNOTATESIZE" response was "NIL". For mailboxes that can only have		ANNOTATESIZE response was "NIL". For mailboxes that can only have
	read-only annotations associated with them, the server MUST return an		read-only annotations associated with them, the server MUST return an
	"ANNOTATESIZE" response with a value of "0" (zero) during the SELECT		ANNOTATESIZE response with a value of "0" (zero) during the SELECT or
	or EXAMINE command for that mailbox. Clients MUST NOT attempt to		EXAMINE command for that mailbox. Clients MUST NOT attempt to store
	store annotations on any messages in a mailbox for which the		annotations on any messages in a mailbox for which the ANNOTATESIZE
	"ANNOTATESIZE" response was zero.		response was zero.
	3.2 Optional parameters with the SELECT/EXAMINE commands
	This extension adds the ability to include one or more parameters
	with the IMAP SELECT or EXAMINE commands, to turn on or off certain
	standard behaviour, or to add new optional behaviours required for a
	particular extension.
	There are two possible modes of operation:
	o A global state change where a single use of the optional parameter
	will effect the session state from that time on, irrespective of
	subsequent SELECT/EXAMINE commands.
	o A per-mailbox state change that will effect the session only for
	the duration of the new selected state. A subsequent SELECT/
	EXAMINE without the optional parameter will cancel its effect for
	the newly selected mailbox.
	It is anticipated that other extensions may want to use this
	facility, so a generalised approach is given here. This facility is
	not dependent on the presence of the ANNOTATE extension - other
	extensions can use it with a server that does not implement ANNOTATE.
	Optional parameters to the SELECT or EXAMINE commands are added as a
	parenthesised list of atoms or strings, and appear after the mailbox
	name in the standard SELECT or EXAMINE command. The order of
	individual parameters is arbitrary. Individual parameters may
	consist of one or more atoms or strings in a specific order. If a
	parameter consists of more than one atom or string, it MUST appear in
	its own parenthesised list. Any parameter not defined by extensions
	that the server supports MUST be rejected with a NO response.
	Example:
	C: a SELECT INBOX (ANNOTATE)
	S: ...
	S: a OK SELECT complete
	In the above example, a single parameter is used with the SELECT
	command.
	Example:
	C: a EXAMINE INBOX (ANNOTATE (RESPONSES "UID Responses") CONDSTORE)
	S: ...
	S: a OK EXAMINE complete
	In the above example, three parameters are used with the EXAMINE
	command. The second parameter consists of two items: an atom
	followed by a quoted string.
	Example:
	C: a SELECT INBOX (BLURDYBLOOP)
	S: a NO Unknown parameter in SELECT command
	In the above example, a parameter not supported by the server is		4.2 ANNOTATE parameter with the SELECT/EXAMINE commands
	incorrectly used.
	The ANNOTATE extension defines a single optional SELECT parameter		The ANNOTATE extension defines a single optional SELECT parameter
	"ANNOTATE", which is used to turn on unsolicited responses for		[ABNFEXT] "ANNOTATE", which is used to turn on unsolicited responses
	annotations as described in Section 3.4. This optional parameter		for annotations as described in Section 4.4. This optional parameter
	results in a per-mailbox state change, i.e. it must be used in each		results in a per-mailbox state change, i.e. it must be used in each
	SELECT/EXAMINE command in order to be effective, irrespective of		SELECT/EXAMINE command in order to be effective, irrespective of
	whether it was used in a previous SELECT/EXAMINE during the same		whether it was used in a previous SELECT/EXAMINE during the same
	session.		session.
	3.3 ANNOTATION Message Data Item in FETCH Command		4.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 5 ¶		skipping to change at page 18, line 5 ¶
	"*" and "%" wildcard characters can be used in either specifier to		"*" and "%" wildcard characters can be used in either specifier to
	match one or more characters at that position, with the exception		match one or more characters at that position, with the exception
	that "%" does not match the hierarchy delimiter for the specifier it		that "%" does not match the hierarchy delimiter for the specifier it
	appears in (that is, "/" for an entry specifier or "." for an		appears in (that is, "/" for an entry specifier or "." for an
	attribute specifier). Thus an entry specifier of "/%" matches		attribute specifier). Thus an entry specifier of "/%" matches
	entries such as "/comment" and "/altsubject", but not "/flags/		entries such as "/comment" and "/altsubject", but not "/flags/
	$redirected".		$redirected".
	Example:		Example:
	C: a FETCH 1 (ANNOTATION ("/*" ("value.priv" "size.priv")))		C: a UID FETCH 1123 (UID ANNOTATION
	S: * 1 FETCH (ANNOTATION		("/*" ("value.priv" "size.priv")))
			S: * 12 FETCH (UID 1123 ANNOTATION
	("/comment" ("value.priv" "My comment"		("/comment" ("value.priv" "My comment"
	"size.priv" "10")		"size.priv" "10")
	"/altsubject" ("value.priv" "Rhinoceroses!"		"/altsubject" ("value.priv" "Rhinoceroses!"
	"size.priv" "13")		"size.priv" "13")
	"/vendor/foobar/label.priv"		"/vendor/foobar/label.priv"
	("value.priv" "label43"		("value.priv" "label43"
	"size.priv" "7")		"size.priv" "7")
	"/vendor/foobar/personality"		"/vendor/foobar/personality"
	("value.priv" "Tallulah Bankhead"		("value.priv" "Tallulah Bankhead"
	"size.priv" "17")))		"size.priv" "17")))
	S: a OK Fetch complete		S: a OK Fetch complete
	In the above example, the contents of the private "value" and		In the above example, the contents of the private "value" and
	"size" attributes for any entries in the "" hierarchy are		"size" attributes for any entries in the "/" hierarchy are
	requested by the client and returned by the server.		requested by the client and returned by the server.
	Example:		Example:
	C: a FETCH 1 (ANNOTATION ("/%" "value.shared"))		C: a FETCH 1 (ANNOTATION ("/%" "value.shared"))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	("/comment" ("value.shared" "Patch Mangler")		("/comment" ("value.shared" "Patch Mangler")
	"/altsubject" ("value.shared" "Patches? We don't		"/altsubject" ("value.shared" "Patches? We don't
	need no steenkin patches!")))		need no steenkin patches!")))
	S: a OK Fetch complete		S: a OK Fetch complete
	In the above example, the contents of the shared "value"		In the above example, the contents of the shared "value"
	attributes for entries at the top level only of the "" hierarchy		attributes for entries at the top level only of the "/" hierarchy
	are requested by the client and returned by the server.		are requested by the client and returned by the server.
	Entry and attribute specifiers can be lists of atomic specifiers, so		Entry and attribute specifiers can be lists of atomic specifiers, so
	that multiple items of each type may be returned in a single FETCH		that multiple items of each type may be returned in a single FETCH
	command.		command.
	Example:		Example:
	C: a FETCH 1 (ANNOTATION		C: a FETCH 1 (ANNOTATION
	(("/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.
	3.4 ANNOTATION Message Data Item in FETCH Response		4.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:
	C: a FETCH 1 (ANNOTATION ("/comment" "value"))		C: a FETCH 1 (ANNOTATION ("/comment" "value"))
	S: * 1 FETCH (ANNOTATION ("/comment"		S: * 1 FETCH (ANNOTATION ("/comment"
	("value.priv" "My comment"		("value.priv" "My comment"
	"value.shared" NIL)))		"value.shared" NIL)))
	S: a OK Fetch complete		S: a OK Fetch complete
	In the above example, a single entry with a single attribute-value		In the above example, a single entry with a single attribute-value
	pair is returned by the server. Since the client did not specify		pair is returned by the server. Since the client did not specify
	a ".shared" or ".priv" suffix, both are returned. Only the		a ".shared" or ".priv" suffix, both are returned. Only the
	private attribute has a value (the shared value is NIL).		private attribute has a value (the shared value is "NIL").
	Example:		Example:
	C: a FETCH 1 (ANNOTATION		C: a FETCH 1 (ANNOTATION
	(("/comment" "/altsubject") "value"))		(("/comment" "/altsubject") "value"))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	("/comment" ("value.priv" "My comment"		("/comment" ("value.priv" "My comment"
	"value.shared" NIL)		"value.shared" NIL)
	"/altsubject" ("value.priv" "My subject"		"/altsubject" ("value.priv" "My subject"
	"value.shared" NIL)))		"value.shared" NIL)))
	S: a OK Fetch complete		S: a OK Fetch complete
	In the above example, two entries each with a single		In the above example, two entries each with a single
	attribute-value pair are returned by the server. Since the client		attribute-value pair are returned by the server. Since the client
	did not specify a ".shared" or ".priv" suffix, both are returned.		did not specify a ".shared" or ".priv" suffix, both are returned.
	Only the private attributes have values; the shared attributes are		Only the private attributes have values; the shared attributes are
	NIL.		"NIL".
	Example:		Example:
	C: a FETCH 1 (ANNOTATION		C: a FETCH 1 (ANNOTATION
	("/comment" ("value" "size")))		("/comment" ("value" "size")))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	("/comment"		("/comment"
	("value.priv" "My comment"		("value.priv" "My comment"
	"value.shared" NIL		"value.shared" NIL
	"size.priv" "10"		"size.priv" "10"
	"size.shared" "0")))		"size.shared" "0")))
	S: a OK Fetch complete		S: a OK Fetch complete
	In the above example, a single entry with two attribute-value		In the above example, a single entry with two attribute-value
	pairs is returned by the server. Since the client did not specify		pairs is returned by the server. Since the client did not specify
	a ".shared" or ".priv" suffix, both are returned. Only the		a ".shared" or ".priv" suffix, both are returned. Only the
	private attributes have values; the shared attributes are NIL.		private attributes have values; the shared attributes are "NIL".
	Servers SHOULD send ANNOTATION message data items in unsolicited		Servers SHOULD send ANNOTATION message data items in unsolicited
	FETCH responses if an annotation entry is changed by a third-party,		FETCH responses if an annotation entry is changed by a third-party,
	and the ANNOTATE select parameter was used. This allows servers to		and the ANNOTATE select parameter was used. This allows servers to
	keep clients updated with changes to annotations by other clients.		keep clients updated with changes to annotations by other clients.
	Unsolicited ANNOTATION responses MUST NOT include ANNOTATION data		Unsolicited ANNOTATION responses MUST NOT include ANNOTATION data
	values - only the entry name of the ANNOTATION that has changed.		values - only the entry name of the ANNOTATION that has changed.
	This restriction avoids sending ANNOTATION data values (which may be		This restriction avoids sending ANNOTATION data values (which may be
	large) to a client unless the client explicitly asks for the value.		large) to a client unless the client explicitly asks for the value.
	skipping to change at page 20, line 42 ¶		skipping to change at page 20, line 42 ¶
	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.
	3.5 ANNOTATION Message Data Item in STORE		4.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
	assumes that the client updates its own cache if the command		assumes that the client updates its own cache if the command
	succeeds.		succeeds.
	If the server is unable to store an annotation because the size of		If the server is unable to store an annotation because the size of
	its value is too large, the server MUST return a tagged NO response		its value is too large, the server MUST return a tagged NO response
	with a "[ANNOTATE TOOBIG]" response code.		with a "[ANNOTATE TOOBIG]" response code.
	skipping to change at page 21, line 34 ¶		skipping to change at page 21, line 34 ¶
	to "My new comment" is created if not already present, or replaced		to "My new comment" is created if not already present, or replaced
	if it exists.		if it exists.
	Example:		Example:
	C: a STORE 1 ANNOTATION ("/comment"		C: a STORE 1 ANNOTATION ("/comment"
	("value.shared" NIL))		("value.shared" NIL))
	S: a OK Store complete		S: a OK Store complete
	In the above example, the shared "value" attribute of the entry "/		In the above example, the shared "value" attribute of the entry "/
	comment" is removed by storing NIL into the attribute.		comment" is removed by storing "NIL" into the attribute.
	Multiple entries can be set in a single STORE command by listing		Multiple entries can be set in a single STORE command by listing
	entry-attribute-value pairs in the list.		entry-attribute-value pairs in the list.
	Example:		Example:
	C: a STORE 1 ANNOTATION ("/comment"		C: a STORE 1 ANNOTATION ("/comment"
	("value.priv" "Get tix Tuesday")		("value.priv" "Get tix Tuesday")
	"/altsubject"		"/altsubject"
	("value.priv" "Wots On"))		("value.priv" "Wots On"))
	skipping to change at page 22, line 19 ¶		skipping to change at page 22, line 19 ¶
	C: a STORE 1 ANNOTATION ("/comment"		C: a STORE 1 ANNOTATION ("/comment"
	("value.priv" "My new comment"		("value.priv" "My new comment"
	"vendor.foobar.priv" "foo's bar"))		"vendor.foobar.priv" "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 attributes "value" and "vendor.foobar" are		present) and the private attributes "value" and "vendor.foobar" are
	created if not already present, or replaced if they exist.		created if not already present, or replaced if they exist.
	3.6 ANNOTATION interaction with COPY		4.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 zero or "NIL" value for its ANNOTATESIZE		mailbox that returns a zero or "NIL" value for its ANNOTATESIZE
	response code). Servers MUST NOT copy '.priv' annotation data for		response code), or if the destination mailbox cannot support the size
	users other than the current user.		of a annotation because it exceeds the ANNOTATESIZE value. Servers
			MUST NOT copy ".priv" annotation data for users other than the
			current user.
	3.7 ANNOTATION Message Data Item in APPEND		4.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. The new data		appended via the addition of a new append data item [ABNFEXT]. The
	item can also be used with the multi-append [RFC3502] extension that		new data item can also be used with the multi-append [RFC3502]
	allows multiple messages to be appended via a single APPEND command.		extension that allows multiple messages to be appended via a single
			APPEND command.
	Example:		Example:
	C: a APPEND drafts ANNOTATION ("/comment"		C: a APPEND drafts ANNOTATION ("/comment"
	("value.priv" "Don't send until we hear from Sally")) {310}		("value.priv" "Don't send until we hear from Sally")) {310}
	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.
	3.8 ANNOTATION Parameter in CATENATE		4.8 ANNOTATION Criterion in SEARCH
	ANNOTATION <parenthesised entry-attribute-value list>
	Sets the specified list of entries and attributes in the resulting
	message.
	The CATENATE [CATENATE] extension defines a new command similar to
	the APPEND command. When the CATENATE extension is present on a
	server that also supports the ANNOTATE extension, the CATENATE
	command MUST allow annotations to be added to the message being
	'catenated' via the addition of a new parameter item in the command.
	Example:
	C: a CATENATE drafts ANNOTATION ("/comment"
	("value.priv" "Don't send until we hear from Sally"))
	TEXT {310}
	S: + Ready for literal data
	C: MIME-Version: 1.0
	...
	C:
	S: a OK CATENATE completed
	In the above example, a comment with a private value is added to a
	new message 'catenated' to the mailbox. The ellipsis represents
	the bulk of the message.
	3.9 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 24, line 28 ¶		skipping to change at page 24, line 5 ¶
	Example:		Example:
	C: a SEARCH ANNOTATION "*" "*" "IMAP4"		C: a SEARCH ANNOTATION "*" "*" "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 any attribute (public or private)		containing the string "IMAP4" in any attribute (public or private)
	of any entry are returned in the search results.		of any entry are returned in the search results.
	3.10 ANNOTATION Key in SORT		4.9 ANNOTATION Key in SORT
	ANNOTATION <entry-name> <attribute-name>		ANNOTATION <entry-name> <attribute-name>
	The ANNOTATION criterion for the SORT command [SORT] instructs the		The ANNOTATION criterion for the SORT command [SORT] instructs the
	server to return the message numbers or UIDs of a mailbox, sorted		server to return the message numbers or UIDs of a mailbox, sorted
	using the values of the specified annotations. The ANNOTATION		using the values of the specified annotations. The ANNOTATION
	criterion is available if the server returns both "ANNOTATE" and		criterion is available if the server returns both ANNOTATE and SORT
	"SORT" as supported capabilities in the CAPABILITY command response.		as supported capabilities in the 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. (The charset argument		attributes in the <entry-name> entries. (The charset argument
	determines sort order, as specified in the SORT extension		determines sort order, as specified in the SORT extension
	description.)		description.)
	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 and attribute -- wildcards are not allowed.		entry and attribute -- wildcards are not allowed.
	3.11 New ACL Rights		4.10 New ACL Rights
	As discussed in Section 2.4 this extension adds new 'm' and 'n'		As discussed in Section 3.4 this extension adds a new "n" right to
	rights to the list of rights provided by the ACL [ACLUPD] extension.		the list of rights provided by the ACL extensions [RFC2086] and
			[ACLUPD].
	4. Formal Syntax		5. 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 [ABNFEXT] superceding those in
	[RFC3501].		[RFC3501].
	Except as noted otherwise, all alphabetic characters are		Except as noted otherwise, all alphabetic characters are
	case-insensitive. The use of upper or lower case characters to		case-insensitive. The use of upper or lower case characters to
	define token strings is for editorial clarity only. Implementations		define token strings is for editorial clarity only. Implementations
	MUST accept these strings in a case-insensitive fashion.		MUST accept these strings in a case-insensitive fashion.
	annotate-param = "ANNOTATE"		append-ext =/ att-annotate
	; defines the select parameter used with		; modifies [RFC3501] extension behaviour
	; ANNOTATE extension
	append = "APPEND" SP mailbox [SP flag-list] [SP date-time]
	[SP att-annotate] SP literal
	; modifies original IMAP APPEND command
	append-message = [SP flag-list] [SP date-time]
	[SP att-annotate] SP literal
	; modifies [MULTIAPPEND] extension behaviour
	att-annotate = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")"		att-annotate = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")"
	att-match = string		att-match = string
	; dot-separated attribute name		; dot-separated attribute name
	; MAY contain "*" or "%" for use as wildcards		; MAY contain "*" or "%" for use as wildcards
	att-value = attrib SP value		att-value = attrib SP value
	attrib = string		attrib = string
	; dot-separated attribute name		; dot-separated attribute name
	; MUST NOT contain "*" or "%"		; MUST NOT contain "*" or "%"
	attribs = att-match /		attribs = att-match /
	"(" att-match *(SP att-match) ")"		"(" att-match *(SP att-match) ")"
			capability =/ "ANNOTATE"
			; defines the capability for this extension
	entries = entry-match /		entries = entry-match /
	"(" entry-match *(SP entry-match) ")"		"(" entry-match *(SP entry-match) ")"
	entry = string		entry = string
	; 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) ")"
	entry-match = string		entry-match = string
	; slash-separated path to entry		; slash-separated path to entry
	; MAY contain "*" or "%" for use as wildcards		; MAY contain "*" or "%" for use as wildcards
	examine =/ *(SP "(" select-param *(SP select-param) ")"
	; modifies the original IMAP examine command to
	; accept optional parameters
	fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")"		fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")"
	; modifies original IMAP fetch-att		; modifies original IMAP fetch-att
	msg-att-dynamic =/ "ANNOTATION" SP		msg-att-dynamic =/ "ANNOTATION" SP
	( "(" entry-att *(SP entry-att) ")" /		( "(" entry-att *(SP entry-att) ")" /
	"(" entry *(SP entry) ")" )		"(" entry *(SP entry) ")" )
	; extends FETCH response with annotation data		; extends FETCH response with annotation data
	parameter =/ att-annotate
	; modifies original IMAP CATENATE formal syntax
	; to include annotations
	resp-text-code =/ "ANNOTATE" SP "TOOBIG" /		resp-text-code =/ "ANNOTATE" SP "TOOBIG" /
	"ANNOTATE" SP "TOOMANY" /		"ANNOTATE" SP "TOOMANY" /
	"ANNOTATESIZE" SP (number / "NIL")		"ANNOTATESIZE" SP (number / nil)
	; new response codes		; new response codes
	search-key =/ "ANNOTATION" SP entry-match SP att-match		search-key =/ "ANNOTATION" SP entry-match SP att-match
	SP value		SP value
	; modifies original IMAP search-key		; modifies original IMAP search-key
	select =/ *(SP "(" select-param *(SP select-param) ")"		select-param =/ "ANNOTATE"
	; modifies the original IMAP select command to		; defines the select parameter used with
	; accept optional parameters		; ANNOTATE extension
	select-param = astring / "(" astring SP astring *(SP astring) ")"
	; parameters to SELECT may contain one or
	; more atoms or strings - multiple items
	; are always parenthesised
	sort-key =/ "ANNOTATION" SP entry SP attrib		sort-key =/ "ANNOTATION" SP entry SP attrib
	; 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		value = nstring / literal8
	5. IANA Considerations		6. IANA Considerations
	Both entry names and attribute names MUST be specified in a standards		Both entry names and attribute names MUST be specified in a standards
	track or IESG approved experimental RFC, or fall under the vendor		track or IESG approved experimental RFC, or fall under the vendor
	namespace. Vendor names MUST be registered.		namespace. Vendor names MUST be registered. Each entry registration
			MUST include a recommended content-type that is used to indicate the
			expected nature of the annotation value.
	5.1 Entry and Attribute Registration Template		6.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: ______________________________
	Description: _______________________		Description: _______________________
	____________________________________		____________________________________
	____________________________________		____________________________________
			Recommended Content-Type:___________
			____________________________________
	Contact person: ____________________		Contact person: ____________________
	email: ____________________		email: ____________________
	5.2 Entry Registrations		6.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.
	5.2.1 /comment		6.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.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.2 /flags/\answered		6.2.2 /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: /flags/\answered		Name: /flags/\answered
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.3 /flags/\flagged		6.2.3 /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: /flags/\flagged		Name: /flags/\flagged
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.4 /flags/\deleted		6.2.4 /flags/\deleted
	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/\deleted		Name: /flags/\deleted
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.5 /flags/\seen		6.2.5 /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: /flags/\seen		Name: /flags/\seen
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.6 /flags/\draft		6.2.6 /flags/\draft
	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/\draft		Name: /flags/\draft
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.7 /flags/\recent		6.2.7 /flags/\recent
	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/\recent		Name: /flags/\recent
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.8 /flags/$mdnsent		6.2.8 /flags/$mdnsent
	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/$mdnsent		Name: /flags/$mdnsent
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.9 /flags/$redirected		6.2.9 /flags/$redirected
	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/$redirected		Name: /flags/$redirected
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.10 /flags/$forwarded		6.2.10 /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: /flags/$forwarded		Name: /flags/$forwarded
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.11 /altsubject		6.2.11 /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.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.12 /<section-part>/comment		6.2.12 /<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.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.13 /<section-part>/flags/seen		6.2.13 /<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.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.14 /<section-part>/flags/answered		6.2.14 /<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.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.15 /<section-part>/flags/flagged		6.2.15 /<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.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.2.16 /<section-part>/flags/forwarded		6.2.16 /<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.
			Recommended Content-Type: text/plain
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.3 Attribute Registrations		6.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.
	5.3.1 value		6.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: daboo@isamet.com		email: daboo@isamet.com
	5.3.2 size		6.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: daboo@isamet.com		email: daboo@isamet.com
	5.3.3 content-type		6.3.3 content-type
	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: content-type		Name: content-type
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	5.3.4 content-language		6.3.4 content-language
	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: content-language		Name: content-language
	Description: Defined in IMAP ANNOTATE extension document.		Description: Defined in IMAP ANNOTATE extension document.
	Contact person: Cyrus Daboo		Contact person: Cyrus Daboo
	email: daboo@isamet.com		email: daboo@isamet.com
	6. Security Considerations		6.3.5 display-name
			To: iana@iana.org
			Subject: IMAP Annotate Registration
			Please register the following IMAP Annotate item:
			[] Entry [X] Attribute
			Name: display-name
			Description: Defined in IMAP ANNOTATE extension document.
			Contact person: Cyrus Daboo
			email: daboo@isamet.com
			7. 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].
	7. References		8. References
	7.1 Normative References		8.1 Normative References
			[ABNFEXT] Melnikov, A., "Collected extensions to IMAP4 ABNF",
			draft-melnikov-imap-ext-abnf-01.txt, March 2005.
	[ACLUPD] Melnikov, A., "IMAP4 ACL extension",		[ACLUPD] Melnikov, A., "IMAP4 ACL extension",
	draft-ietf-imapext-2086upd-02.txt, December 2004.		draft-ietf-imapext-2086upd-02.txt, December 2004.
	[CATENATE]
	Resnick, P., "Internet Message Access Protocol (IMAP)
	CATENATE Extension", draft-ietf-lemonade-catenate-03.txt,
	December 2004.
	[RFC1891] Moore, K., "SMTP Service Extension for Delivery Status
	Notifications", RFC 1891, January 1996.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
			[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. and P. Overell, "Augmented BNF for Syntax		[RFC2234] Crocker, D. 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		[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May
	skipping to change at page 38, line 46 ¶		skipping to change at page 39, line 22 ¶
	[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.
	[RFC3503] Melnikov, A., "Message Disposition Notification (MDN)		[RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
	profile for Internet Message Access Protocol (IMAP)", RFC		profile for Internet Message Access Protocol (IMAP)", RFC
	3503, March 2003.		3503, March 2003.
			[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
			10646", STD 63, RFC 3629, November 2003.
	[SORT] Crispin, M. and K. Murchison, "Internet Message Access		[SORT] Crispin, M. and K. Murchison, "Internet Message Access
	Protocol - Sort and Thread Extension",		Protocol - Sort and Thread Extension",
	draft-ietf-imapext-sort-17.txt, May 2004.		draft-ietf-imapext-sort-17.txt, May 2004.
	7.2 Informative References		8.2 Informative References
	[CONDSTORE]		[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-05.txt,		STORE operation", draft-ietf-imapext-condstore-05.txt,
	November 2003.		November 2003.
	Authors' Addresses		Authors' Addresses
	Cyrus Daboo		Cyrus Daboo
	ISAMET, Inc.		ISAMET, Inc.
	skipping to change at page 39, line 18 ¶		skipping to change at page 40, line 4 ¶
	Authors' Addresses		Authors' Addresses
	Cyrus Daboo		Cyrus Daboo
	ISAMET, Inc.		ISAMET, Inc.
	5001 Baum Blvd.		5001 Baum Blvd.
	Suite 650		Suite 650
	Pittsburgh, PA 15213		Pittsburgh, PA 15213
	US		US
	EMail: daboo@isamet.com		EMail: daboo@isamet.com
	Randall Gellens		Randall Gellens
	QUALCOMM Incorporated		QUALCOMM Incorporated
	5775 Morehouse Dr.		5775 Morehouse Dr.
	San Diego, CA 92121-2779		San Diego, CA 92121-2779
	US		US
	EMail: randy@qualcomm.com		EMail: randy@qualcomm.com
	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.		dinner in Pittsburgh. The participants of the IMAPext working group
			made significant contributions to this work.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes. 151 change blocks.
	346 lines changed or deleted		364 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/