< draft-ietf-imapext-annotate-04.txt		draft-ietf-imapext-annotate-05.txt >
	IMAP Extensions Working Group R. Gellens		IMAP Extensions Working Group R. Gellens
	Internet Draft: IMAP ANNOTATE Extension C. Daboo		Internet Draft: IMAP ANNOTATE Extension C. Daboo
	Document: draft-ietf-imapext-annotate-04.txt March 2002		Document: draft-ietf-imapext-annotate-05.txt November 2002
	IMAP ANNOTATE Extension		IMAP ANNOTATE Extension
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 2, line 9 ¶		skipping to change at page 2, line 9 ¶
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society 2002. All Rights Reserved.		Copyright (C) The Internet Society 2002. All Rights Reserved.
	Table of Contents		Table of Contents
	1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2		1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 2		2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3 Conventions Used in This Document . . . . . . . . . . . . . . 2		3 Conventions Used in This Document . . . . . . . . . . . . . . 2
	4 Change History . . . . . . . . . . . . . . . . . . . . . . . 3		4 Open Issues: . . . . . . . . . . . . . . . . . . . . . . . . 3
	5 Introduction and Overview . . . . . . . . . . . . . . . . . . 4		5 Change History . . . . . . . . . . . . . . . . . . . . . . . 3
	6 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5		6 Introduction and Overview . . . . . . . . . . . . . . . . . 4
	6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 5		7 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.2 Namespace of Entries and Attributes . . . . . . . . . . 5		7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 6		7.2 Namespace of Entries and Attributes . . . . . . . . . . . 5
	6.2.2 Attribute Names . . . . . . . . . . . . . . . . . . 8		7.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . 6
	7 Private versus Shared and Access Control . . . . . . . . . . 8		7.2.2 Attribute Names . . . . . . . . . . . . . . . . . . . 8
	8 IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 9		8 Private versus Shared and Access Control . . . . . . . . . . 9
	8.1 Optional parameters with the SELECT/EXAMINE commands . . 9		9 IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 10
	8.2 ANNOTATION Message Data Item in FETCH Command . . . . . 10		9.1 Optional parameters with the SELECT/EXAMINE commands . . 10
	8.3 ANNOTATION Message Data Item in FETCH Response . . . . . 12		9.2 ANNOTATION Message Data Item in FETCH Command . . . . . . 10
	8.4 ANNOTATION Message Data Item in STORE . . . . . . . . . 13		9.3 ANNOTATION Message Data Item in FETCH Response . . . . . 12
	8.5 ANNOTATION interaction with COPY . . . . . . . . . . . . 14		9.4 ANNOTATION Message Data Item in STORE . . . . . . . . . . 13
	8.6 ANNOTATION Message Data Item in APPEND . . . . . . . . . 14		9.5 ANNOTATION interaction with COPY . . . . . . . . . . . . 14
	8.7 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . 15		9.6 ANNOTATION Message Data Item in APPEND . . . . . . . . . 15
	8.8 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . 15		9.7 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . 15
	9 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16		9.8 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . 16
	10 IANA Considerations . . . . . . . . . . . . . . . . . . . . 18		10 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1 Entry and Attribute Registration Template . . . . . . . . 18		11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	11 Security Considerations . . . . . . . . . . . . . . . . . . 18		11.1 Entry and Attribute Registration Template . . . . . . . 18
	12 References . . . . . . . . . . . . . . . . . . . . . . . . . 18		12 Security Considerations . . . . . . . . . . . . . . . . . . . 18
	13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19		13 References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19		14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	15 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19		15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
			16 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
	1 Abstract		1 Abstract
	The ANNOTATE extension to the Internet Message Access Protocol		The ANNOTATE extension to the Internet Message Access Protocol
	[IMAP4] permits clients and servers to maintain "metadata" for		[IMAP4] permits clients and servers to maintain "metadata" for
	messages stored in an IMAP4 mailbox.		messages stored in an IMAP4 mailbox.
	2 Discussion		2 Discussion
	Public comments can be sent to the IETF IMAP Extensions mailing		Public comments can be sent to the IETF IMAP Extensions mailing
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [KEYWORDS].		document are to be interpreted as described in RFC 2119 [KEYWORDS].
	Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].		Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
	In examples, "C:" and "S:" indicate lines sent by the client and		In examples, "C:" and "S:" indicate lines sent by the client and
	server respectively. Line breaks not preceded by a "C:" or "S:" are		server respectively. Line breaks not preceded by a "C:" or "S:" are
	for editorial clarity only.		for editorial clarity only.
	4 Change History		4 Open Issues:
			*How to deal with flag vs keyword namespace issues. Should standard
			IMAP flags go under /message/flags and keywords under
			/message/keywords, or should they all go under /message/flags and
			follow the exact naming scheme in IMAP (i.e. with '\' prefix in
			front of standard flags, and '$' for appropriate keywords)?
			5 Change History
			Changes from -03 to -04:
			1. Fixed examples to match formal syntax for FETCH responses where
			parenthesis do not appear around entry-att items.
	Changes from -03 to -04:		Changes from -03 to -04:
	1. Fixed attrib/attrib-match grammar to use "." instead of "/".		1. Fixed attrib/attrib-match grammar to use "." instead of "/".
	2. Add text for server to reject unknown <part-specifier>.		2. Add text for server to reject unknown <part-specifier>.
	3. Do not allow empty part-specifier.		3. Do not allow empty part-specifier.
	4. Store NIL to value to delete.		4. Store NIL to value to delete.
	5. Comment on COPY interaction with ANNOTATE.		5. Comment on COPY interaction with ANNOTATE.
	6. Added comment that IMAP flags are mapped one-to-one with their		6. Added comment that IMAP flags are mapped one-to-one with their
	corresponding FLAGS items.		corresponding FLAGS items.
	7. Added comment that the recent flag annotation is read-only.		7. Added comment that the recent flag annotation is read-only.
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 17 ¶
	changed by the client.		changed by the client.
	3. In ACLs, the "w" right is needed to updated shared state;		3. In ACLs, the "w" right is needed to updated shared state;
	the "s" right is needed to update private state.		the "s" right is needed to update private state.
	4. Various clarifications and text modifications.		4. Various clarifications and text modifications.
	5. Added 'forwarded' flag for message parts.		5. Added 'forwarded' flag for message parts.
	Changes from pre-imapext to -00:		Changes from pre-imapext to -00:
	1. Clarified text describing attributions, entries, and		1. Clarified text describing attributions, entries, and
	attributes.		attributes.
	2. Changed 'modifiedsince' to 'modtime'; referenced ACAP spec.		2. Changed 'modifiedsince' to 'modtime'; referenced ACAP spec.
	3. Deleted 'queued' flag.		3. Deleted 'queued' flag.
	4. Expanded and explained smtp-envelope entry.		4. Expanded and explained smtp-envelope entry.
	5. Restricted including ANNOTATION data in unsolicited responses		5. Restricted including ANNOTATION data in unsolicited responses
	until the client uses it first. (Open issue as to if needed).		until the client uses it first. (Open issue as to if needed).
	6. Examples now only use valid entries and attributes.		6. Examples now only use valid entries and attributes.
	7. Updated Security Considerations.		7. Updated Security Considerations.
	8. Content-Type now defaults to text/plain.		8. Content-Type now defaults to text/plain.
	9. Open Issue: Shared vs. private annotations.		9. Open Issue: Shared vs. private annotations.
	10. Open issue: Annotation Modtime untagged response or VALIDTIME		10. Open issue: Annotation Modtime untagged response or VALIDTIME
	FETCH data.		FETCH data.
	11. Open issue: Conditional annotation STORE.		11. Open issue: Conditional annotation STORE.
	12. ANNOTATION criterion available if both "ANNOTATE" and "SORT"		12. ANNOTATION criterion available if both "ANNOTATE" and "SORT"
	in CAPABILITY command response.		in 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.
	5 Introduction and Overview		6 Introduction and Overview
	The ANNOTATE extension is present in any IMAP4 implementation which		The ANNOTATE extension is present in any IMAP4 implementation which
	returns "ANNOTATE" as one of the supported capabilities in the		returns "ANNOTATE" as one of the supported capabilities in the
	CAPABILITY response.		CAPABILITY response.
	The ANNOTATE extension adds a new message data item to the FETCH and		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		STORE commands, as well as adding SEARCH and SORT keys and an APPEND
	modifier.		modifier.
	This extension makes the following changes to the IMAP4 protocol:		This extension makes the following changes to the IMAP4 protocol:
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 32 ¶
	and PERMANENTFLAGS responses to a SELECT or EXAMINE command.		and PERMANENTFLAGS responses to a SELECT or EXAMINE command.
	This extension also introduces a generalised mechanism for adding		This extension also introduces a generalised mechanism for adding
	parameters to the SELECT or EXAMINE commands. It is anticipated		parameters to the SELECT or EXAMINE commands. It is anticipated
	that other extensions may want to utilise this, so it is not		that other extensions may want to utilise this, so it is not
	strictly dependent on the ANNOTATE extension being present.		strictly dependent on the ANNOTATE extension being present.
	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.
	6 Data Model		7 Data Model
	6.1 Overview		7.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 added to a message has an entry name of
	"/message/comment". This entry is composed of several attributes		"/message/comment". This entry is composed of several attributes
	such as "value", "size", etc. which contain the properties and data		such as "value", "size", etc. which contain the properties and data
	of the entry.		of the entry.
	The protocol changes to IMAP described below allow a client to		The protocol changes to IMAP described below allow a client to
	access or change the values of any attributes in any entries in a		access or change the values of any attributes in any entries in a
	message annotation, assuming it has sufficient access rights to do		message annotation, assuming it has sufficient access rights to do
	so (see Section 7 for specifics).		so (see Section 8 for specifics).
	6.2 Namespace of Entries and Attributes
			7.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 in UTF-8, with each component of the name
	separated by a slash ("/").		separated by a slash ("/").
	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		hierarchical name in UTF-8, with each component of the name
	separated by a period (".").		separated by a period (".").
	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.
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 28 ¶
	a BAD response in any IMAP commands where they are used.		a BAD response in any IMAP commands where they are used.
	Use of non-visible UTF-8 characters in entry and attribute names is		Use of non-visible UTF-8 characters in entry and attribute names is
	strongly discouraged.		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 for extensibility.
	6.2.1 Entry Names		7.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
	10.1 for the registration template.		11.1 for the registration template.
	/message		/message
	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.		message. This entry itself does not contain any attributes.
	/message/comment		/message/comment
	Defines a comment or note associated with an entire message.		Defines a comment or note associated with an entire message.
	/message/flags		/message/flags
	Defines the top-level of entries for flags associated with an		Defines the top-level of entries for flags associated with an
	skipping to change at page 8, line 17 ¶		skipping to change at page 8, line 30 ¶
	"value" attribute of these entries must be either "1", "0" or		"value" attribute of these entries must be either "1", "0" or
	NIL.		NIL.
	/body/<part-specifier>/vendor/<vendor-token>		/body/<part-specifier>/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.
	6.2.2 Attribute Names		7.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 10.1 for the registration template.		Section 11.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		which maps to private and shared versions of the entry. Searching
	or fetching without using either suffix includes both. The client		or fetching without using either suffix includes both. The client
	MUST specify either a ".priv" or ".shared" suffix when storing an		MUST 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 UTF8 string representing the data value of the attribute. To
	delete an annotation, the client can store NIL into the value.		delete an annotation, the client can store NIL into the value.
	skipping to change at page 8, line 48 ¶		skipping to change at page 9, line 11 ¶
	A MIME [MIME] content type and subtype that describes the nature		A MIME [MIME] content type and subtype that describes the nature
	of the content of the "value" attribute. If not present, a		of the content of the "value" attribute. If not present, a
	value of "text/plain; charset=utf8" is assumed.		value of "text/plain; charset=utf8" is assumed.
	vendor.<vendor-token>		vendor.<vendor-token>
	Defines an attribute associated with a particular product of		Defines an attribute associated with a particular product of
	some vendor. This attribute can be used by vendors to provide		some vendor. This attribute can be used by vendors to provide
	client specific attributes. The vendor-token MUST be registered		client specific attributes. The vendor-token MUST be registered
	with IANA.		with IANA.
	7 Private versus Shared and Access Control		8 Private versus Shared and Access Control
	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
	[ACL-EXT] which permits access by other users, or because it is a		[ACL-EXT] 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 9, line 44 ¶		skipping to change at page 10, line 5 ¶
	.shared suffixes.		.shared suffixes.
	A user can only store and fetch private annotations on messages in		A user can only store and fetch private annotations on messages in
	any mailbox which they can SELECT or EXAMINE, including ones which		any mailbox which they can SELECT or EXAMINE, including ones which
	only open READ-ONLY. A user can only store and fetch shared		only open READ-ONLY. A user can only store and fetch shared
	annotations on messages in any mailbox that they can SELECT and		annotations on messages in any mailbox that they can SELECT and
	which opens READ-WRITE. If a client attempts to store or fetch a		which opens READ-WRITE. If a client attempts to store or fetch a
	shared annotation on a READ-ONLY mailbox, the server MUST respond		shared annotation on a READ-ONLY mailbox, the server MUST respond
	with a NO response.		with a NO response.
	8 IMAP Protocol Changes		9 IMAP Protocol Changes
	8.1 Optional parameters with the SELECT/EXAMINE commands		9.1 Optional parameters with the SELECT/EXAMINE commands
	This extension adds the ability to include one or more parameters		This extension adds the ability to include one or more parameters
	with the IMAP SELECT or EXAMINE commands, to turn on or off certain		with the IMAP SELECT or EXAMINE commands, to turn on or off certain
	standard behaviour, or to add new optional behaviours required for a		standard behaviour, or to add new optional behaviours required for a
	particular extension. It is anticipated that other extensions may		particular extension. It is anticipated that other extensions may
	want to use this facility, so a generalised approach is given here.		want to use this facility, so a generalised approach is given here.
	This facility is not dependent on the presence of the ANNOTATE		This facility is not dependent on the presence of the ANNOTATE
	extension - other extensions can use it with a server that does not		extension - other extensions can use it with a server that does not
	implement ANNOTATE.		implement ANNOTATE.
	skipping to change at page 10, line 39 ¶		skipping to change at page 10, line 52 ¶
	items: an atom followed by a quoted string.		items: an atom followed by a quoted string.
	C: a SELECT INBOX (BLURDYBLOOP)		C: a SELECT INBOX (BLURDYBLOOP)
	S: a NO Unknown parameter in SELECT command		S: a NO Unknown parameter in SELECT command
	In the above example, a parameter not supported by the		In the above example, a parameter not supported by the
	server is incorrectly used.		server is 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		"ANNOTATE", which is used to turn on unsolicited responses for
	annotations as described in Section 8.3.		annotations as described in Section 9.3.
	8.2 ANNOTATION Message Data Item in FETCH Command
			9.2 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.
	Example:		Example:
	C: a FETCH 1 (ANNOTATION ("/message/comment" "value"))		C: a FETCH 1 (ANNOTATION ("/message/comment" "value"))
	S: * 1 FETCH (ANNOTATION ("/message/comment"		S: * 1 FETCH (ANNOTATION ("/message/comment"
	("value.priv" "My comment"		("value.priv" "My comment"
	"value.shared" "Group note")))		"value.shared" "Group note")))
	S: a OK Fetch complete		S: a OK Fetch complete
	In the above example, the content of the "value" attribute		In the above example, the content of the "value" attribute
	for the "/message/comment" entry is requested by the client		for the "/message/comment" entry is requested by the client
	and returned by the server. Since neither ".shared" nor		and returned by the server. Since neither ".shared" nor
	".priv" was specified, both are returned.		".priv" was specified, both are returned.
	"*" 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 "/message/%"		attribute specifier). Thus an entry specifier of "/message/%"
	matches entries such as "/message/comment" and "/message/subject",		matches entries such as "/message/comment" and "/message/subject",
	but not "/message/flags/redirected".		but not "/message/flags/redirected".
	Examples:		Examples:
	C: a FETCH 1 (ANNOTATION ("/message/*" ("value.priv"		C: a FETCH 1 (ANNOTATION ("/message/*" ("value.priv"
	"size.priv")))		"size.priv")))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	(("/message/comment" ("value.priv" "My comment"		("/message/comment" ("value.priv" "My comment"
	"size.priv" "10"))		"size.priv" "10")
	("/message/subject" ("value.priv" "Rhinoceroses!"		"/message/subject" ("value.priv" "Rhinoceroses!"
	"size.priv" "13"))		"size.priv" "13")
	("/message/vendor/foobar/label.priv"		"/message/vendor/foobar/label.priv"
	("value.priv" "label43"		("value.priv" "label43"
	"size.priv" "7"))		"size.priv" "7")
	("/message/vendor/foobar/personality"		"/message/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 "size"		In the above example, the contents of the private "value" and "size"
	attributes for any entries in the "/message" hierarchy are requested		attributes for any entries in the "/message" hierarchy are requested
	by the client and returned by the server.		by the client and returned by the server.
	C: a FETCH 1 (ANNOTATION ("/message/%" "value.shared"))		C: a FETCH 1 (ANNOTATION ("/message/%" "value.shared"))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	(("/message/comment" ("value.shared" "Patch Mangler"))		("/message/comment" ("value.shared" "Patch Mangler")
	("/message/subject" ("value.shared" "Patches? We don'		"/message/subject" ("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		attributes for entries at the top level only of the
	"/message" hierarchy are requested by the client and		"/message" hierarchy are requested by the client and
	returned by the server.		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.
	Examples:		Examples:
	C: a FETCH 1 (ANNOTATION		C: a FETCH 1 (ANNOTATION
	(("/message/comment" "/message/subject") "value.priv"))		(("/message/comment" "/message/subject") "value.priv"))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	(("/message/comment" ("value.priv" "What a chowder-head"))		("/message/comment" ("value.priv" "What a chowder-head")
	("/message/subject" ("value.priv" "How to crush beer		"/message/subject" ("value.priv" "How to crush beer cans")))
	cans"))))
	S: a OK Fetch complete		S: a OK Fetch complete
	In the above example, the contents of the private "value" attributes		In the above example, the contents of the private "value" attributes
	for the two entries "/message/comment" and "/message/subject" are		for the two entries "/message/comment" and "/message/subject" are
	requested by the client and returned by the server.		requested by the client and returned by the server.
	8.3 ANNOTATION Message Data Item in FETCH Response		9.3 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.
	Examples:		Examples:
	skipping to change at page 12, line 43 ¶		skipping to change at page 12, line 54 ¶
	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 a		pair is returned by the server. Since the client did not specify a
	".shared" or ".priv" suffix, both are returned. Only the private		".shared" or ".priv" suffix, both are returned. Only the private
	attribute has a value (the shared value is NIL).		attribute has a value (the shared value is NIL).
	C: a FETCH 1 (ANNOTATION		C: a FETCH 1 (ANNOTATION
	(("/message/comment" "/message/subject") "value"))		(("/message/comment" "/message/subject") "value"))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	(("/message/comment" ("value.priv" "My comment"		("/message/comment" ("value.priv" "My comment"
	"value.shared" NIL))		"value.shared" NIL)
	("/message/subject" ("value.priv" "My subject"		"/message/subject" ("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 attribute-value		In the above example, two entries each with a single attribute-value
	pair are returned by the server. Since the client did not specify a		pair are returned by the server. Since the client did not specify a
	".shared" or ".priv" suffix, both are returned. Only the private		".shared" or ".priv" suffix, both are returned. Only the private
	attributes have values; the shared attributes are NIL.		attributes have values; the shared attributes are NIL.
	C: a FETCH 1 (ANNOTATION		C: a FETCH 1 (ANNOTATION
	("/message/comment" ("value" "size")))		("/message/comment" ("value" "size")))
	S: * 1 FETCH (ANNOTATION		S: * 1 FETCH (ANNOTATION
	(("/message/comment"		("/message/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 pairs		In the above example, a single entry with two attribute-value pairs
	is returned by the server. Since the client did not specify a		is returned by the server. Since the client did not specify a
	".shared" or ".priv" suffix, both are returned. Only the private		".shared" or ".priv" suffix, both are returned. Only the private
	attributes have values; the shared attributes are NIL.		attributes have values; the shared attributes are NIL.
	Servers MUST NOT include ANNOTATION data in unsolicited responses		Servers MUST NOT include ANNOTATION data in unsolicited responses
	unless the client used the ANNOTATE select parameter when it issued		unless the client used the ANNOTATE select parameter when it issued
	the last SELECT or EXAMINE command. This restriction avoids sending		the last SELECT or EXAMINE command. This restriction avoids sending
	ANNOTATION data to a client unless the client explicitly asks for		ANNOTATION data to a client unless the client explicitly asks for
	it.		it.
	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.
	8.4 ANNOTATION Message Data Item in STORE		9.4 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
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 15 ¶
	S: a OK Store complete		S: a OK Store complete
	In the above example, the entry "/message/comment" is created (if		In the above example, the entry "/message/comment" is created (if
	not already present) and the private attribute "value" with data set		not already present) and the private attribute "value" with data set
	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.
	C: a STORE 1 ANNOTATION ("/message/comment"		C: a STORE 1 ANNOTATION ("/message/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
	"/message/comment" is removed by storing NIL into the attribute.		"/message/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 ("/message/comment" ("value.priv"		C: a STORE 1 ANNOTATION ("/message/comment"
	"Get tix Tuesday")		("value.priv" "Get tix Tuesday")
	"/message/subject" ("value.priv"		"/message/subject"
	"Wots On"))		("value.priv" "Wots On"))
	S: a OK Store complete		S: a OK Store complete
	In the above example, the entries "/message/comment" and		In the above example, the entries "/message/comment" and
	"/message/subject" are created (if not already present) and the		"/message/subject" are created (if not already present) and the
	private attribute "value" is created for each entry if not already		private attribute "value" is created for each entry if not already
	present, or replaced if they exist.		present, or replaced if they exist.
	Multiple attributes can be set in a single STORE command by listing		Multiple attributes can be set in a single STORE command by listing
	multiple attribute-value pairs in the entry list.		multiple attribute-value pairs in the entry list.
	skipping to change at page 14, line 36 ¶		skipping to change at page 14, line 48 ¶
	C: a STORE 1 ANNOTATION ("/message/comment"		C: a STORE 1 ANNOTATION ("/message/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 "/message/comment" is created (if		In the above example, the entry "/message/comment" is created (if
	not already present) and the private attributes "value" and		not already present) and the private attributes "value" and
	"vendor.foobar" are created if not already present, or replaced if		"vendor.foobar" are created if not already present, or replaced if
	they exist.		they exist.
	8.5 ANNOTATION interaction with COPY		9.5 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 copy all the annotation data associated with any		extension MUST copy all the annotation data associated with any
	messages being copied via the COPY command. The only exception to		messages being copied via the COPY command. The only exception to
	this is if the destination mailbox permissions are such that either		this is if the destination mailbox permissions are such that either
	the '.priv' or '.shared' annotations are not allowed.		the '.priv' or '.shared' annotations are not allowed.
	8.6 ANNOTATION Message Data Item in APPEND		9.6 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		Sets the specified list of entries and attributes in the
	resulting message.		resulting message.
	Example:		Example:
	C: a APPEND drafts ANNOTATION ("/message/comment"		C: a APPEND drafts ANNOTATION ("/message/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.
	8.7 ANNOTATION Criterion in SEARCH		9.7 ANNOTATION Criterion in SEARCH
	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.
	ANNOTATION <entry-name> <attribute-name> <value>		ANNOTATION <entry-name> <attribute-name> <value>
	Messages that have annotations with entries matching <entry-name>		Messages that have annotations with entries matching <entry-name>
	and attributes matching <attribute-name> and the specified string		and attributes matching <attribute-name> and the specified string
	<value> in their values are returned in the SEARCH results. The "*"		<value> in their values are returned in the SEARCH results. The "*"
	character can be used in the entry or attribute name fields to match		character can be used in the entry or attribute name fields to match
	skipping to change at page 15, line 45 ¶		skipping to change at page 16, line 6 ¶
	"/message/comment" entry are returned in the search results.		"/message/comment" entry are returned in the search results.
	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 containing		In the above example, the message numbers of any messages containing
	the string "IMAP4" in any attribute (public or private) of any entry		the string "IMAP4" in any attribute (public or private) of any entry
	are returned in the search results.		are returned in the search results.
	8.8 ANNOTATION Key in SORT		9.8 ANNOTATION Key in SORT
	The ANNOTATION criterion for the SORT command [SORT-EXT] instructs		The ANNOTATION criterion for the SORT command [SORT-EXT] instructs
	the server to return the message numbers or UIDs of a mailbox,		the server to return the message numbers or UIDs of a mailbox,
	sorted using the values of the specified annotations. The		sorted using the values of the specified annotations. The
	ANNOTATION criterion is available if the server returns both		ANNOTATION criterion is available if the server returns both
	"ANNOTATE" and "SORT" as supported capabilities in the CAPABILITY		"ANNOTATE" and "SORT" as supported capabilities in the CAPABILITY
	command response.		command response.
	ANNOTATION <entry-name> <attribute-name>		ANNOTATION <entry-name> <attribute-name>
	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.)
	Examples:		Examples:
	C: a SORT (ANNOTATION "/message/subject" "value.shared") UTF-8		C: a SORT (ANNOTATION "/message/subject" "value.shared") UTF-8
	ALL		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
	"/message/subject" entry.		"/message/subject" 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.
	9 Formal Syntax		10 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 [ABNF].		Form (ABNF) notation as specified in [ABNF].
	Non-terminals referenced but not defined below are as defined by		Non-terminals referenced but not defined below are as defined by
	[IMAP4].		[IMAP4].
	Except as noted otherwise, all alphabetic characters are case-		Except as noted otherwise, all alphabetic characters are case-
	insensitive. The use of upper or lower case characters to define		insensitive. The use of upper or lower case characters to define
	token strings is for editorial clarity only. Implementations MUST		token strings is for editorial clarity only. Implementations MUST
	skipping to change at page 17, line 4 ¶		skipping to change at page 17, line 15 ¶
	; modifies original IMAP4 fetch-att		; modifies original IMAP4 fetch-att
	fetch-annotate = "ANNOTATION" SP "(" entries SP attribs ")"		fetch-annotate = "ANNOTATION" SP "(" entries SP attribs ")"
	fetch-ann-resp = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")"		fetch-ann-resp = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")"
	store-att-flags =/ att-annotate		store-att-flags =/ att-annotate
	; modifies original IMAP4 STORE command		; modifies original IMAP4 STORE command
	search-key =/ search-annotate		search-key =/ search-annotate
	; modifies original IMAP4 search-key		; modifies original IMAP4 search-key
	search-annotate = "ANNOTATION" SP entry-match SP attrib-match		search-annotate = "ANNOTATION" SP entry-match SP attrib-match
	SP value		SP value
	sort-key =/ sort-annotate		sort-key =/ sort-annotate
	; modifies original		; modifies original
	; draft-crispin-imapext-sort-xx.txt sort-key		; draft-crispin-imapext-sort-xx.txt sort-key
	sort-annotate = "ANNOTATION" SP entry SP attrib		sort-annotate = "ANNOTATION" SP entry SP attrib
	entries = entry-match /		entries = entry-match /
	"(" entry-match *(SP entry-match) ")"		"(" entry-match *(SP entry-match) ")"
	attribs = attrib-match /		attribs = attrib-match /
	"(" attrib-match *(SP attrib-match) ")"		"(" attrib-match *(SP attrib-match) ")"
	entry-att = entry SP "(" att-value *(SP att-value) ")		entry-att = entry SP "(" att-value *(SP att-value) ")"
	att-value = attrib SP value		att-value = attrib SP value
	utf8-char = %x01-FF		utf8-char = %x01-FF
	; any character, excluding NUL		; any character, excluding NUL
	atom-slash = any utf8-char except "/"		atom-slash = any utf8-char except "/"
	atom-dot = any utf8-char except "."		atom-dot = any utf8-char except "."
	entry = DQUOTE 1*atom-slash *("/" 1*atom-slash) DQUOTE		entry = DQUOTE 1*atom-slash *("/" 1*atom-slash) DQUOTE
	entry-match = DQUOTE 1*entry-match-atom		entry-match = DQUOTE 1*entry-match-atom
	*("/" 1*entry-match-atom) DQUOTE		*("/" 1*entry-match-atom) DQUOTE
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 15 ¶
	; accept optional parameters		; accept optional parameters
	select-param = astring / "(" astring SP astring *(SP astring) ")"		select-param = astring / "(" astring SP astring *(SP astring) ")"
	; parameters to SELECT may contain one or		; parameters to SELECT may contain one or
	; more atoms or strings - multiple items		; more atoms or strings - multiple items
	; are always parenthesised		; are always parenthesised
	annotate-param = "ANNOTATE"		annotate-param = "ANNOTATE"
	; defines the select parameter used with		; defines the select parameter used with
	; ANNOTATE extension		; ANNOTATE extension
	10 IANA Considerations
			11 IANA Considerations
	Both entry names and attribute names MUST be specified in a		Both entry names and attribute names MUST be specified in a
	standards track or IESG approved experimental RFC, or fall under the		standards track or IESG approved experimental RFC, or fall under the
	vendor namespace. Vendor names MUST be registered.		vendor namespace. Vendor names MUST be registered.
	10.1 Entry and Attribute Registration Template		11.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
	[] Vendor [] Open: RFC _______		[] Vendor [] Open: RFC _______
	Name: ______________________________		Name: ______________________________
	skipping to change at page 18, line 32 ¶		skipping to change at page 18, line 44 ¶
	Description: _______________________		Description: _______________________
	____________________________________		____________________________________
	____________________________________		____________________________________
	Contact person: ____________________		Contact person: ____________________
	email: ____________________		email: ____________________
	11 Security Considerations		12 Security Considerations
	Care must be taken to ensure that annotations whose values are		Care must be taken to ensure that annotations whose values are
	intended to remain private are not stored in mailboxes which are		intended to remain private are not stored in mailboxes which are
	accessible to other users. This includes mailboxes owned by the		accessible to other users. This includes mailboxes owned by the
	user by whose ACLs permit access by others as well as any shared		user by whose ACLs permit access by others as well as any shared
	mailboxes.		mailboxes.
	12 References		13 References
	[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:		[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
	ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,		ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
	November 1997.		November 1997.
	[ACAP] Newman, Myers, "ACAP -- Application Configuration Access		[ACAP] Newman, Myers, "ACAP -- Application Configuration Access
	Protocol", RFC 2244, Innosoft, Netscape, November 1997.		Protocol", RFC 2244, Innosoft, Netscape, November 1997.
	[ACL-EXT] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,		[ACL-EXT] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
	January 1997.		January 1997.
	skipping to change at page 19, line 13 ¶		skipping to change at page 19, line 26 ¶
	RFC 2060, University of Washington, December 1996.		RFC 2060, University of Washington, December 1996.
	[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, Harvard University, March 1997.		Requirement Levels", RFC 2119, Harvard University, March 1997.
	[SMTP-DSN] Moore, "SMTP Service Extension for Delivery Status		[SMTP-DSN] Moore, "SMTP Service Extension for Delivery Status
	Notifications", RFC 1891, University of Tennessee, January 1996.		Notifications", RFC 1891, University of Tennessee, January 1996.
	[SORT-EXT] Crispin, "Internet Message Access Protocol -- SORT		[SORT-EXT] Crispin, "Internet Message Access Protocol -- SORT
	Extension", work in progress.		Extension", work in progress.
	<http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-07.txt>		<http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-10.txt>
	13 Acknowledgments		14 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.
	14 Authors' Addresses		15 Authors' Addresses
	Randall Gellens		Randall Gellens
	QUALCOMM Incorporated		QUALCOMM Incorporated
	5775 Morehouse Dr.		5775 Morehouse Dr.
	San Diego, CA 92121-2779		San Diego, CA 92121-2779
	U.S.A.		U.S.A.
	Email: randy@qualcomm.com		Email: randy@qualcomm.com
	Cyrus Daboo		Cyrus Daboo
	Cyrusoft International, Inc.		Cyrusoft International, Inc.
	Suite 780, 5001 Baum Blvd.		Suite 780, 5001 Baum Blvd.
	Pittsburgh, PA 15213		Pittsburgh, PA 15213
	U.S.A.		U.S.A.
	Email: daboo@cyrusoft.com		Email: daboo@cyrusoft.com
	15 Full Copyright Statement		16 Full Copyright Statement
	Copyright (C) The Internet Society 2002. All Rights Reserved.		Copyright (C) The Internet Society 2002. All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this		are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
End of changes. 46 change blocks.
	90 lines changed or deleted		100 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/