< draft-ietf-imapext-annotate-01.txt		draft-ietf-imapext-annotate-02.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-01.txt February 2001		Document: draft-ietf-imapext-annotate-02.txt November 2001
	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. Internet-Drafts are		all provisions of Section 10 of RFC2026. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	skipping to change at page 19, line ? ¶		skipping to change at page 19, line ? ¶
	5 Introduction and Overview . . . . . . . . . . . . . . . . . . 4		5 Introduction and Overview . . . . . . . . . . . . . . . . . . 4
	6 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 4		6 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
	6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4		6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
	6.2 Namespace of Entries and Attributes . . . . . . . . . . 5		6.2 Namespace of Entries and Attributes . . . . . . . . . . 5
	6.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 5		6.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 5
	6.2.2 Attribute Names . . . . . . . . . . . . . . . . . . 7		6.2.2 Attribute Names . . . . . . . . . . . . . . . . . . 7
	7 Private versus Shared . . . . . . . . . . . . . . . . . . . . 8		7 Private versus Shared . . . . . . . . . . . . . . . . . . . . 8
	8 IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 9		8 IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 9
	8.1 ANNOTATION Message Data Item in FETCH Command . . . . . . 9		8.1 ANNOTATION Message Data Item in FETCH Command . . . . . . 9
	8.2 ANNOTATION Message Data Item in FETCH Response . . . . . 10		8.2 ANNOTATION Message Data Item in FETCH Response . . . . . 10
	8.3 ANNOTATION Message Data Item in STORE . . . . . . . . . . 12		8.3 ANNOTATION Message Data Item in STORE . . . . . . . . . . 11
	8.4 ANNOTATION Message Data Item in APPEND . . . . . . . . . 13		8.4 ANNOTATION Message Data Item in APPEND . . . . . . . . . 13
	8.5 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . 13		8.5 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . 13
	8.6 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . 14		8.6 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . 14
	8.7 ACL Rights . . . . . . . . . . . . . . . . . . . . . . . 15		8.7 ACL Rights . . . . . . . . . . . . . . . . . . . . . . . 15
	9 Interaction with MODTIME . . . . . . . . . . . . . . . . . . 15		9 Interaction with MODTIME . . . . . . . . . . . . . . . . . . 15
	10 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15		10 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
	11 IANA Considerations . . . . . . . . . . . . . . . . . . . . 17		11 IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
	11.1 Entry and Attribute Registration Template . . . . . . . . 17		11.1 Entry and Attribute Registration Template . . . . . . . . 16
	12 Security Considerations . . . . . . . . . . . . . . . . . . 17		12 Security Considerations . . . . . . . . . . . . . . . . . . 17
	13 References . . . . . . . . . . . . . . . . . . . . . . . . . 17		13 References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18		14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
	15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18		15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
	16 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18		16 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
	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
	skipping to change at page 19, line ? ¶		skipping to change at page 19, line ? ¶
	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 Document Meta-Data		4 Document Meta-Data
	4.1 Open Issues		4.1 Open Issues
	At points in this document open issues are discussed, marked by the		At points in this document open issues are discussed, marked by the
	text "<<<OPEN-ISSUE>>>". These are items which have not been		text "<<<OPEN-ISSUE>>>". These are items which have not been
	finalized. Discussion and comment is requested. Please use the		finalized. Discussion and comment is requested. Please use the
	IETF IMAP Extensions mailing list, as described in section		IETF IMAP Extensions mailing list, as described in section 2.
	2.
	4.2 Change History		4.2 Change History
	Changes from -01 to -02:		Changes from -01 to -02:
			1. Now require .pric or .shared on store operations.
			Changes from -00 to -01:
	1. MODTIME moved to its own draft, which this draft now		1. MODTIME moved to its own draft, which this draft now
	depends on. Thus, Conditional Annotation STORE and		depends on. Thus, Conditional Annotation STORE and
	related items deleted from this draft.		related items deleted from this draft.
	2. Private versus Shared Annotations: both are possible		2. Private versus Shared Annotations: both are possible
	(separately addressable using ".priv" and ".shared"		(separately addressable using ".priv" and ".shared"
	suffixes). There is a per-mailbox setting for the		suffixes). There is a per-mailbox setting for the
	default. It is an open issue how this is viewed or		default. It is an open issue how this is viewed or
	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 -00 to -01:		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.
	skipping to change at page 19, line ? ¶		skipping to change at page 19, line ? ¶
	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		If shared and private annotations are to coexist, we need a clear
	way to differentiate them. Also, it should be as easy as possible		way to differentiate them. Also, it should be as easy as possible
	for a client to access both and not overlook either. There is also		for a client to access both and not overlook either. There is also
	a danger in allowing a client to store an annotation without knowing		a danger in allowing a client to store an annotation without knowing
	if it is shared or private.		if 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. A store without using either stores into the		neither uses both. Store operations MUST explicitly use .priv or
	default.		.shared suffixes.
	<<<OPEN-ISSUE>>>
	This is dangerous since it allows a client to store an entry without
	knowing if other users are able to view it.
	How a client learns or changes the default is an open issue. One
	suggestion is to use an additional ACL bit to indicate the current
	default state.
	It may be better to remove the default, and force clients to always
	explicitly store into one or the other.
	8 IMAP Protocol Changes		8 IMAP Protocol Changes
	8.1 ANNOTATION Message Data Item in FETCH Command		8.1 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>
	skipping to change at page 19, line ? ¶		skipping to change at page 19, line ? ¶
	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 for the		In the above example, the content of the "value" attribute
	"/message/comment" entry is requested by the client and returned by		for the "/message/comment" entry is requested by the client
	the server. Since neither ".shared" nor ".priv" was specified, both		and returned by the server. Since neither ".shared" nor
	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:
	skipping to change at page 19, line ? ¶		skipping to change at page 19, line ? ¶
	"modtime.priv" "20000704000001"))		"modtime.priv" "20000704000001"))
	("/message/subject" ("value.priv" "Rhinoceroses!"		("/message/subject" ("value.priv" "Rhinoceroses!"
	"modtime.priv" "19991231235959"))		"modtime.priv" "19991231235959"))
	("/message/vendor/eudora/label.priv"		("/message/vendor/eudora/label.priv"
	("value.priv" "label43"		("value.priv" "label43"
	"modtime.priv" "20000705101502"))		"modtime.priv" "20000705101502"))
	("/message/vendor/eudora/personality"		("/message/vendor/eudora/personality"
	("value.priv" "Tallulah Bankhead"		("value.priv" "Tallulah Bankhead"
	"modtime.priv" "20000705101558"))))		"modtime.priv" "20000705101558"))))
	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
	"modtime" attributes for any entries in the "/message" hierarchy are		"modtime" attributes for any entries in the "/message" hierarchy are
	requested by the client and returned by the server.		requested 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'
	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" attributes		In the above example, the contents of the shared "value"
	for entries at the top level only of the "/message" hierarchy are		attributes for entries at the top level only of the
	requested by the client and returned by the server.		"/message" hierarchy 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.
	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"))
	skipping to change at page 19, line ? ¶		skipping to change at page 19, line ? ¶
	annotations by other clients.		annotations by other clients.
	Servers MUST NOT include ANNOTATION data in unsolicited responses		Servers MUST NOT include ANNOTATION data in unsolicited responses
	until the client has used ANNOTATION data in a FETCH command. This		until the client has used ANNOTATION data in a FETCH command. This
	restriction avoids sending ANNOTATION data to a client until the		restriction avoids sending ANNOTATION data to a client until the
	client has shown it is capable of handling it.		client has shown it is capable of handling it.
	<<<OPEN-ISSUE>>>		<<<OPEN-ISSUE>>>
	Is this prohibition really necessary?		Is this prohibition really necessary?
	* OK [ANNOTATIONS FLAGS MODTIME <modtime> <set>]		* OK [ANNOTATIONS FLAGS MODTIME <modtime> <set>]
	8.3 ANNOTATION Message Data Item in STORE		8.3 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" behavior. This means the server does not		implicit ".SILENT" behavior. 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.
	skipping to change at page 19, line ? ¶		skipping to change at page 19, line ? ¶
	[ACL-EXT] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,		[ACL-EXT] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
	January 1997.		January 1997.
	[IMAP4] Crispin, "Internet Message Access Protocol - Version 4rev1",		[IMAP4] Crispin, "Internet Message Access Protocol - Version 4rev1",
	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.
	[MODTIME-EXT] Melnikov, "IMAP Conditional Store", work in progress.		[MODTIME-EXT] Melnikov, "IMAP Conditional Store", work in progress.
	<http://www.ietf.org/internet-drafts/draft-melnikov-imap-condstore-xx.txt>		<http://www.ietf.org/internet-drafts/draft-melnikov-imap-condstore-03.txt>
	[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-xx.txt>		<http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-07.txt>
	14 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.
	15 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.
	Phone: +1 858 651 5115
	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.
	Phone: +1 412 605 0499
	Email: daboo@cyrusoft.com		Email: daboo@cyrusoft.com
	16 Full Copyright Statement		16 Full Copyright Statement
	Copyright (C) The Internet Society 2001. All Rights Reserved.		Copyright (C) The Internet Society 2001. 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. 17 change blocks.
	35 lines changed or deleted		23 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/