< draft-melnikov-imap-condstore-08.txt		draft-melnikov-imap-condstore-09.txt >
	Internet Draft: IMAP Extension for Conditional STORE A. Melnikov		Internet Draft: IMAP Extension for Conditional STORE A. Melnikov
	Document: draft-melnikov-imap-condstore-08.txt S. Hole		Document: draft-melnikov-imap-condstore-09.txt S. Hole
	Expires: December 2002 ACI WorldWide/MessagingDirect		Expires: June 2003 ACI WorldWide/MessagingDirect
	June 2002		December 2002
	IMAP Extension for Conditional STORE operation		IMAP Extension for Conditional STORE operation
	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 line 37 ¶		skipping to change at line 37 ¶
	Copyright (C) The Internet Society 2001-2002. All Rights Reserved.		Copyright (C) The Internet Society 2001-2002. All Rights Reserved.
	0.1. Open issues		0.1. Open issues
	1). Should conditional STORE be atomic accross message set (i.e. either		1). Should conditional STORE be atomic accross message set (i.e. either
	all messages in message set weren't changed since and conditional		all messages in message set weren't changed since and conditional
	STORE succeeds or operation fails for all messages)?		STORE succeeds or operation fails for all messages)?
	This can be difficult to implement for some servers.		This can be difficult to implement for some servers.
	2). MODSEQ as the result of STORE/UID STORE or changes to a flag in another
	session: what type of modseq should be returned: private, shared, both?
	Or default (i.e. the type of a particular flag)?
	0.2. Change History		0.2. Change History
			Changes from -08 to -09:
			1. Added an extended example about reporting regular (non-conditional) flag
			changes to other sessions.
			2. Simplified FETCH MODSEQ syntax by removing per-metadata requests and
			responses.
	Changes from -07 to -08:		Changes from -07 to -08:
	1. Added note saying the change to UIDVALIDITY also invalidates HIGHESTMODSEQ.		1. Added note saying the change to UIDVALIDITY also invalidates HIGHESTMODSEQ.
	2. Fixed several bugs in ABNF for STATUS and STORE commands.		2. Fixed several bugs in ABNF for STATUS and STORE commands.
	Changes from -06 to -07:		Changes from -06 to -07:
	1. Added clarification that when a server does reordering, the second		1. Added clarification that when a server does command reordering, the second
	completed operation gets the higher mod sequence.		completed operation gets the higher mod sequence.
	2. Renamed annotation type specifier "both" to "all" as per suggestion		2. Renamed annotation type specifier "both" to "all" as per suggestion
	from Minneapolis meeting.		from Minneapolis meeting.
	3. Removed PERFLAGMODSEQ capability, as it doesn't buy anything: a client		3. Removed PERFLAGMODSEQ capability, as it doesn't buy anything: a client
	has to work with both types of servers (i.e. servers that support per		has to work with both types of servers (i.e. servers that support per
	message per flag modseqs and servers that support only per message		message per flag modseqs and servers that support only per message
	modseqs) anyway.		modseqs) anyway.
	4. Per flag modsequences are optional for a server to return. Updated syntax.		4. Per flag modsequences are optional for a server to return. Updated syntax.
	5. Allow MODSEQ response code only as a result of SEARCH/SORT as suggested		5. Allow MODSEQ response code only as a result of SEARCH/SORT as suggested
	by John Myers. MODSEQ response code is not allowed after FETCH or STORE.		by John Myers. MODSEQ response code is not allowed after FETCH or STORE.
	skipping to change at line 112 ¶		skipping to change at line 114 ¶
	1. Refreshed the list of Open Issues.		1. Refreshed the list of Open Issues.
	2. Changed "attr-name" to "entry-name", because modtime applies to		2. Changed "attr-name" to "entry-name", because modtime applies to
	entry, not attribute.		entry, not attribute.
	3. Added MODTIME untagged response.		3. Added MODTIME untagged response.
	4. Cleaned up ABNF.		4. Cleaned up ABNF.
	5. Added "Acknowledgments" section.		5. Added "Acknowledgments" section.
	6. Fixed some spelling mistakes.		6. Fixed some spelling mistakes.
	Table of Contents		Table of Contents
	<<To be completed later>>		1 Abstract .................................................. X
			2 Conventions Used in This Document ......................... X
			3 Introduction and Overview ................................. X
			4 IMAP Protocol Changes ..................................... X
			4.1 New OK untagged responses for SELECT and EXAMINE ......... X
			4.1.1 HIGHESTMODSEQ response code ............................ X
			4.2 STORE and UID STORE Commands ............................. X
			4.3 MODSEQ message data item in FETCH Command ................ X
			4.4 MODSEQ search criterion in SEARCH ........................ X
			4.5 MODSEQ Sort Criterion .................................... X
			4.6 MODSEQ Response code for successful SEARCH and SORT ...... X
			4.7 HIGHESTMODSEQ status data items .......................... X
			5 Formal Syntax ............................................. X
			6 Security Considerations ................................... X
			7 References ................................................ X
			7.1 Normative References ..................................... X
			7.2 Informative References ................................... X
			8 Acknowledgments ........................................... X
			9 Author's Addresses ........................................ X
			10 Full Copyright Statement ................................. X
	1. Abstract		1. Abstract
	Often, multiple IMAP clients need to coordinate changes to a common		Often, multiple IMAP clients need to coordinate changes to a common
	IMAP mailbox. Examples include different clients for the same user,		IMAP mailbox. Examples include different clients for the same user,
	and multiple users accessing shared mailboxes. These clients		and multiple users accessing shared mailboxes. These clients
	need a mechanism to synchronize state changes for messages within the		need a mechanism to synchronize state changes for messages within the
	mailbox. They must be able to guarantee that only one client can change		mailbox. They must be able to guarantee that only one client can change
	message state (e.g., message flags or annotations) at any time. An		message state (e.g., message flags or annotations) at any time. An
	example of such an application is use of an IMAP mailbox as a message		example of such an application is use of an IMAP mailbox as a message
	skipping to change at line 142 ¶		skipping to change at line 163 ¶
	"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].
	In examples, lines beginning with "S:" are sent by the IMAP server, and		In examples, lines beginning with "S:" are sent by the IMAP server, and
	lines beginning with "C:" are sent by the client. Line breaks may appear		lines beginning with "C:" are sent by the client. Line breaks may appear
	in example commands solely for editorial clarity; when present in		in example commands solely for editorial clarity; when present in
	the actual message they are represented by "CRLF".		the actual message they are represented by "CRLF".
	Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].		Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
	The term metadata or metadata item is used throughout this		The term "metadata" or "metadata item" is used throughout this document.
	document. It refers to any system or user defined keyword or an annotation		It refers to any system or user defined keyword or an annotation
	[ANNOTATION].		[ANNOTATE].
			Some IMAP mailboxes are private, accessible only to the owning user.
			Other mailboxes are not, either because the owner has set an ACL
			[ACL] which permits access by other users, or because it is a
			shared mailbox. Let's call a metadata item "shared" for the mailbox
			if any changes to the metadata items are persistent and visible to all
			other users accessing the mailbox. Otherwise the metadata item is called
			"private". Note, that private metadata items are still visible to all
			sessions accessing the mailbox as the same user. Also note, that different
			mailboxes may have different metadata items as shared.
	3. Introduction and Overview		3. Introduction and Overview
	The Conditional STORE extension is present in any IMAP4 implementation		The Conditional STORE extension is present in any IMAP4 implementation
	which returns "CONDSTORE" as one of the supported capabilities in the		which returns "CONDSTORE" as one of the supported capabilities in the
	CAPABILITY command response.		CAPABILITY command response.
	Every IMAP message has an associated unsigned 64-bit value called a		Every IMAP message has an associated positive unsigned 64-bit value called a
	modification sequence (mod-sequence). This is an opaque value updated by		modification sequence (mod-sequence). This is an opaque value updated by
	the server whenever a metadata item is modified. The value is intended to		the server whenever a metadata item is modified. The value is intended to
	be used only for comparisons within a server. However, the server MUST		be used only for comparisons within a server. However, the server MUST
	guarantee that each STORE command performed on the same mailbox, including		guarantee that each STORE command performed on the same mailbox, including
	simultaneous stores to different metadata items from different connections,		simultaneous stores to different metadata items from different connections,
	will get a different mod-sequence value. Also, for any two successfull		will get a different mod-sequence value. Also, for any two successfull
	conditional STORE operations performed in the same session on the same mailbox,		STORE operations performed in the same session on the same mailbox,
	the mod-sequence of the second completed operation MUST be greater than		the mod-sequence of the second completed operation MUST be greater than
	the mod-sequence of the first completed. Note that the latter rule disallows		the mod-sequence of the first completed. Note that the latter rule disallows
	the use of the system clock as a mod-sequence, because if system time changes		the use of the system clock as a mod-sequence, because if system time changes
	(e.g., a NTP client adjusting the time), the next generated value might be less		(e.g., a NTP [NTP] client adjusting the time), the next generated value might
	than the previous one.		be less than the previous one.
	Mod-sequences allow a client that supports the CONDSTORE extension to		Mod-sequences allow a client that supports the CONDSTORE extension to
	determine if a message metadata has changed since some known		determine if a message metadata has changed since some known
	moment. Whenever the state of a flag changes (i.e., the flag is added and		moment. Whenever the state of a flag changes (i.e., the flag is added and
	before it wasn't set, or the flag is removed and before it was set) the		before it wasn't set, or the flag is removed and before it was set) the
	value of the modification sequence for the message MUST be updated.		value of the modification sequence for the message MUST be updated.
	Adding the flag when it is already present or removing when it is not		Adding the flag when it is already present or removing when it is not
	present SHOULD NOT change the mod-sequence.		present SHOULD NOT change the mod-sequence.
	When a message is appended to a mailbox (via the IMAP APPEND command,		When a message is appended to a mailbox (via the IMAP APPEND command,
	skipping to change at line 201 ¶		skipping to change at line 232 ¶
	b) adds the MODIFIED response code which should be used with		b) adds the MODIFIED response code which should be used with
	a NO response to the STORE command		a NO response to the STORE command
	c) adds a new MODSEQ message data item for use with the FETCH command		c) adds a new MODSEQ message data item for use with the FETCH command
	d) adds a new MODSEQ search criterion		d) adds a new MODSEQ search criterion
	e) adds a new MODSEQ response code		e) adds a new MODSEQ response code
	f) adds a new OK untagged response for the SELECT and EXAMINE commands		f) adds a new OK untagged responses for the SELECT and EXAMINE commands
	g) adds the HIGHESTMODSEQ status data item to the STATUS command		g) adds the HIGHESTMODSEQ status data item to the STATUS command
	h) adds a new MODSEQ sort criterion		h) adds a new MODSEQ sort criterion
	The rest of this document describes the protocol changes more rigorously.		The rest of this document describes the protocol changes more rigorously.
	4. IMAP Protocol Changes		4. IMAP Protocol Changes
	4.1. OK untagged response for SELECT and EXAMINE		4.1. New OK untagged responses for SELECT and EXAMINE
	This document adds a new OK untagged response for the SELECT and EXAMINE		4.1.1. HIGHESTMODSEQ response code
	commands. A server supporting the CONDSTORE extension MUST send
	the following OK untagged response with any successful SELECT or		This document adds a new response code that is returned in the OK
	EXAMINE command:		untagged response for the SELECT and EXAMINE commands. A server
			supporting the CONDSTORE extension MUST send the OK untagged
			response including HIGHESTMODSEQ response code with every successful
			SELECT or EXAMINE command:
	OK [HIGHESTMODSEQ <mod-sequence-value>]		OK [HIGHESTMODSEQ <mod-sequence-value>]
	Where <mod-sequence-value> is the highest mod-sequence value of all		Where <mod-sequence-value> is the highest mod-sequence value of all
	messages in the mailbox. When the server changes UIDVALIDITY for a		messages in the mailbox. When the server changes UIDVALIDITY for a
	mailbox, it doesn't have to keep the same HIGHESTMODSEQ for the		mailbox, it doesn't have to keep the same HIGHESTMODSEQ for the
	mailbox.		mailbox.
	A disconnected client can use the value of HIGHESTMODSEQ to check if		A disconnected client can use the value of HIGHESTMODSEQ to check if
	it has to refetch flags and/or annotations from the server. If the		it has to refetch flags and/or annotations from the server. If the
	UIDVALIDITY value has changed for the selected mailbox, the client		UIDVALIDITY value has changed for the selected mailbox, the client
	MUST delete the cached value of HIGHESTMODSEQ. If UIDVALIDITY for		MUST delete the cached value of HIGHESTMODSEQ. If UIDVALIDITY for
	the mailbox is the same and if the HIGHESTMODSEQ value stored in		the mailbox is the same and if the HIGHESTMODSEQ value stored in
	the client's cache is less than the value returned by the server,		the client's cache is less than the value returned by the server,
	then some metadata items on the server have changed since the last		then some metadata items on the server have changed since the last
	synchronization, and the client needs to update its cache. The client		synchronization, and the client needs to update its cache. The client
	MAY use SEARCH MODSEQ as described in section 4.4 to find out exactly		MAY use SEARCH MODSEQ as described in section 4.4 to find out exactly
	which metadata items have changed.		which metadata items have changed.
	Example: C: A142 SELECT INBOX		Example: C: A142 SELECT INBOX
	S: * 172 EXISTS		S: * 172 EXISTS
	S: * 1 RECENT		S: * 1 RECENT
	S: * OK [UNSEEN 12] Message 12 is first unseen		S: * OK [UNSEEN 12] Message 12 is first unseen
	S: * OK [UIDVALIDITY 3857529045] UIDs valid		S: * OK [UIDVALIDITY 3857529045] UIDs valid
			S: * OK [UIDNEXT 4392] Predicted next UID
	S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)		S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
	S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited		S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
	S: * OK [HIGHESTMODSEQ 20010715194045007]		S: * OK [HIGHESTMODSEQ 20010715194045007]
	S: A142 OK [READ-WRITE] SELECT completed		S: A142 OK [READ-WRITE] SELECT completed
	4.2. STORE and UID STORE Commands		4.2. STORE and UID STORE Commands
	Arguments: message set		Arguments: message set
	OPTIONAL store modifiers		OPTIONAL store modifiers
	message data item name		message data item name
	value for message data item		value for message data item
	Responses: untagged responses: FETCH		Responses: untagged responses: FETCH
	Result: OK - store completed		Result: OK - store completed
	NO - store error: can't store that data		NO - store error: can't store that data
	skipping to change at line 328 ¶		skipping to change at line 363 ¶
	if the operation completed successfully for the first occurrence.		if the operation completed successfully for the first occurrence.
	For example, if the client specifies:		For example, if the client specifies:
	a100 STORE 7,3:9 (UNCHANGEDSINCE 200012121230045)		a100 STORE 7,3:9 (UNCHANGEDSINCE 200012121230045)
	+FLAGS.SILENT (\Deleted)		+FLAGS.SILENT (\Deleted)
	the server must not fail the operation for message 7 as part of		the server must not fail the operation for message 7 as part of
	processing "3:9" if it succeeded when message 7 was processed		processing "3:9" if it succeeded when message 7 was processed
	the first time.		the first time.
	4.3 MODSEQ message data item in FETCH Command		4.3. MODSEQ message data item in FETCH Command
	This extension adds a MODSEQ message data item to the FETCH command.		This extension adds a MODSEQ message data item to the FETCH command.
	The MODSEQ message data item allows clients to retrieve mod-sequence		The MODSEQ message data item allows clients to retrieve mod-sequence
	values for a range of messages in the currently selected mailbox.		values for a range of messages in the currently selected mailbox.
	Once the client specifies the MODSEQ message data item in a FETCH request,		Once the client specified the MODSEQ message data item in a FETCH request,
	the server MUST include the MODSEQ fetch response data items in all		the server MUST include the MODSEQ fetch response data items in all
	subsequent unsolicited FETCH responses.		subsequent unsolicited FETCH responses.
	Syntax: MODSEQ [<entry-names>]		Syntax: MODSEQ [<entry-names>]
	The MODSEQ message data item, when used by the client in the FETCH		The MODSEQ message data item causes the server to return MODSEQ fetch
	command, takes a list of metadata items. For a flag <flagname> the		response data items.
	corresponding entry-name has a form "/message/flags/<flagname>".
	System flags has no leading "\" and all user defined flags are prefixed
	with "-". Each metadata item is followed by one of "private", "shared"
	or "all", that describes what variant of the metadata item should
	be used. An empty list requests the server to return only the
	per-message mod-sequence.
	The MODSEQ message data item causes the server to return MODSEQ
	fetch response data items.
	Syntax: MODSEQ ( <permsg-modsequence>		Syntax: MODSEQ ( <permsg-modsequence> )
	[<entry-name> <entry-type-resp> <mod-sequence-value> ...] )
	MODSEQ response data items contain per-message mod-sequences and an optional,		MODSEQ response data items contain per-message mod-sequences.
	possibly empty list of requested metadata items and their corresponding
	types (i.e. private or shared) and mod-sequences. Server is not required
	to return the list if it doesn't store per metadata per message modsequences.
	The MODSEQ response data item is returned if the client issued FETCH with		The MODSEQ response data item is returned if the client issued FETCH with
	MODSEQ message data item. It also allows the server to notify the client		MODSEQ message data item. It also allows the server to notify the client
	about mod-sequence changes caused by conditional STOREs (section 4.2) and/or		about mod-sequence changes caused by conditional STOREs (section 4.2) and/or
	changes caused by external sources.		changes caused by external sources.
	Example:		Example:
	C: a FETCH 1 (MODSEQ ("/message/comment" all "/message/flags/-$MDNSent" shared))		C: a FETCH 1:3 (MODSEQ)
	S: * 1 FETCH (MODSEQ (20000624140000 "/message/comment" private 20000624140000		S: * 1 FETCH (MODSEQ (20000624140003))
	"/message/comment" shared 20000624140000		S: * 2 FETCH (MODSEQ (20000624140007))
	"/message/flags/-$MDNSent" shared 20000624140000))		S: * 3 FETCH (MODSEQ (20000624140005))
	S: a OK Fetch complete		S: a OK Fetch complete
	In this example the client requests detailed information about modsequences		In this example the client requests per message modsequences for a
	for an annotation and a user defined keyword on a particular message. The server		set of messages.
	is able to return the requested information.
	Example:		When a flag for a message is modified in a different session, the server
			sends an unsolicited FETCH response containing the modsequence for the
			message.
	C: a FETCH 1 (MODSEQ ("/message/comment" all "/message/flags/-$MDNSent" shared))		Example:
	S: * 1 FETCH (MODSEQ (20000624140000))
	S: a OK Fetch complete
	In this example the client requests detailed information about modsequences		(Session 1, authenticated as a user "alex"). The user adds a shared
	for an annotation and a user defined keyword on a particular message, but the server		flag \Deleted:
	only stores per message modsequences internally, so it only returns per message
	modsequence.
	Example:		C: A142 SELECT INBOX
			...
			S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
			S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited
			...
	C: a FETCH 1:3 (MODSEQ)		C: A160 STORE 7 +FLAGS.SILENT (\Deleted)
	S: * 1 FETCH (MODSEQ (20000624140003))		S: * 7 FETCH (MODSEQ (200012121231000))
	S: * 2 FETCH (MODSEQ (20000624140007))		S: A160 OK Store completed
	S: * 3 FETCH (MODSEQ (20000624140005))
	S: a OK Fetch complete
	In this example the client requests per message modsequences for a message set.		(Session 2, also authenticated as the user "alex"). Any changes to flags
			are always reported to all sessions authenticated as the same user as in
			the session 1.
	4.4 MODSEQ search criterion in SEARCH		C: C180 NOOP
			S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (200012121231000))
			S: C180 OK Noop completed
			(Session 3, authenticated as a user "andrew"). As \Deleted is a shared
			flag, changes in the session 1 are also reported in the session 3:
			C: D210 NOOP
			S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (200012121231000))
			S: D210 OK Noop completed
			The user modifies a private flag \Seen in the session 1 ...
			C: A240 STORE 7 +FLAGS.SILENT (\Seen)
			S: * 7 FETCH (MODSEQ (200012121231777))
			S: A240 OK Store completed
			... which is only reported in the session 2 ...
			C: C270 NOOP
			S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ (200012121231777))
			S: C270 OK Noop completed
			... but not in the session 3.
			C: D300 NOOP
			S: D300 OK Noop completed
			And finally the user removes flags \Answered (shared) and \Seen (private)
			in the session 1.
			C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen)
			S: * 7 FETCH (MODSEQ (200012121245160))
			S: A330 OK Store completed
			Both changes are reported in the session 2 ...
			C: C360 NOOP
			S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (200012121245160))
			S: C360 OK Noop completed
			... and only changes to shared flags are reported in session 3.
			C: D390 NOOP
			S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (200012121245160))
			S: D390 OK Noop completed
			4.4. MODSEQ search criterion in SEARCH
	The MODSEQ criterion for the SEARCH command allows a client to search		The MODSEQ criterion for the SEARCH command allows a client to search
	for the metadata items that were modified since a specified moment.		for the metadata items that were modified since a specified moment.
	Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-value>		Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-value>
	Messages that have modification values which are equal to or		Messages that have modification values which are equal to or
	greater than <mod-sequence-value>. This allows a client, for example,		greater than <mod-sequence-value>. This allows a client, for example,
	to find out which messages contain metadata items that have changed		to find out which messages contain metadata items that have changed
	since the last time it updated its disconnected cache.		since the last time it updated its disconnected cache.
	The client can also specify <entry-name> and entry type before		The client can also specify <entry-name> and entry type (one of
	<mod-sequence-value>. If the server doesn't store internally		"shared", "private" or "all") before <mod-sequence-value>.
	separate mod-sequences for different flags and annotations,		If the server doesn't store internally separate mod-sequences
	it MUST ignore <entry-name> and <entry-type-req>. Otherwise		for different flags and annotations, it MUST ignore
	the server should use them to narrow down the search.		<entry-name> and <entry-type-req>. Otherwise the server should
			use them to narrow down the search.
	If client specifies a MODSEQ criterion in a SEARCH command and		If client specifies a MODSEQ criterion in a SEARCH command and
	the server returns a non-empty SEARCH result, the server MUST also		the server returns a non-empty SEARCH result, the server MUST also
	return a MODSEQ response code in the tagged OK response. The MODSEQ		return a MODSEQ response code in the tagged OK response. The MODSEQ
	response code covers all messages returned in the untagged SEARCH results.		response code covers all messages returned in the untagged SEARCH results.
	See also section 4.6.		See also section 4.6.
	Example:		Example:
	C: a SEARCH MODSEQ "/message/flags/draft" all 20010320162338		C: a SEARCH MODSEQ "/message/flags/draft" all 20010320162338
	ANNOTATION "/message/comment" "value" "IMAP4"		ANNOTATION "/message/comment" "value" "IMAP4"
	S: * SEARCH 2 5 6 7 11 12 18 19 20 23		S: * SEARCH 2 5 6 7 11 12 18 19 20 23
	S: a OK [MODSEQ 2,5:7,11:12,18:20,23 20010917162500] Search complete		S: a OK [MODSEQ 2,5:7,11:12,18:20,23 20010917162500] Search complete
	In the above example, the message numbers of any messages		In the above example, the message numbers of any messages
	containing the string "IMAP4" in the "value" attribute of the		containing the string "IMAP4" in the "value" attribute of the
	"/message/comment" entry and having a mod-sequence equal to or		"/message/comment" entry and having a mod-sequence equal to or
	greater than 20010320162338 for the "\Draft" flag are returned in		greater than 20010320162338 for the "\Draft" flag are returned in
	the search results.		the search results.
	Example:		Example:
	C: a SEARCH OR NOT MODSEQ 20010320162338 LARGER 50000		C: a SEARCH OR NOT MODSEQ 20010320162338 LARGER 50000
	S: * SEARCH		S: * SEARCH
	S: a OK Search complete, nothing found		S: a OK Search complete, nothing found
	4.5 MODSEQ Sort Criterion		4.5. MODSEQ Sort Criterion
	If a server implementing CONDSTORE also implements the SORT		If a server implementing CONDSTORE also implements the SORT
	extension as defined by [SORT], it MUST also support sorting on		extension as defined by [SORT], it MUST also support sorting on
	per-message mod-sequence.		per-message mod-sequence.
	Syntax: MODSEQ		Syntax: MODSEQ
	If client specifies a MODSEQ search (as per section 4.4) or sort		If client specifies a MODSEQ search (as per section 4.4) or sort
	criterion in the SORT command and the server returns a non-empty		criterion in the SORT command and the server returns a non-empty
	SORT result, the server MUST also return a MODSEQ response		SORT result, the server MUST also return a MODSEQ response
	skipping to change at line 468 ¶		skipping to change at line 539 ¶
	C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 MODSEQ 21		C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 MODSEQ 21
	S: * SORT 6 3 4 5 2		S: * SORT 6 3 4 5 2
	S: A283 OK [MODSEQ 2:6 125] SORT completed		S: A283 OK [MODSEQ 2:6 125] SORT completed
	Example:		Example:
	C: A284 SORT (MODSEQ) KOI8-R OR NOT MODSEQ 20010320162338		C: A284 SORT (MODSEQ) KOI8-R OR NOT MODSEQ 20010320162338
	SUBJECT "Privet"		SUBJECT "Privet"
	S: * SORT		S: * SORT
	S: A284 OK Sort complete, nothing found		S: A284 OK Sort complete, nothing found
	4.6 MODSEQ Response code for successful SEARCH and SORT		4.6. MODSEQ Response code for successful SEARCH and SORT
	Data: message set		Data: message set
	mod-sequence value		mod-sequence value
	The MODSEQ response code is sent in the following two cases:		The MODSEQ response code is sent in the following two cases:
	1) If a client specifies a MODSEQ criterion in a SEARCH command		1) If a client specifies a MODSEQ criterion in a SEARCH command
	and the server returns a non-empty SEARCH result, the server MUST		and the server returns a non-empty SEARCH result, the server MUST
	also return a MODSEQ response code in the tagged OK response.		also return a MODSEQ response code in the tagged OK response.
	The MODSEQ response code MUST be for all messages which were returned		The MODSEQ response code MUST be for all messages which were returned
	skipping to change at line 494 ¶		skipping to change at line 565 ¶
	2) If client specifies a MODSEQ search or sort criterion in a		2) If client specifies a MODSEQ search or sort criterion in a
	SORT command and the server returns a non-empty SORT result,		SORT command and the server returns a non-empty SORT result,
	the server MUST also return a MODSEQ response code in the tagged		the server MUST also return a MODSEQ response code in the tagged
	OK response for all messages returned in the untagged SORT response.		OK response for all messages returned in the untagged SORT response.
	The MODSEQ response code contains the message set to which		The MODSEQ response code contains the message set to which
	the mod-sequence applies if it is sent in response to a SORT command,		the mod-sequence applies if it is sent in response to a SORT command,
	or the UID set if it is caused by UID SORT.		or the UID set if it is caused by UID SORT.
	4.7 HIGHESTMODSEQ status data items		4.7. HIGHESTMODSEQ status data items
	This document defines a new status data item:		This document defines a new status data item:
	HIGHESTMODSEQ		HIGHESTMODSEQ
	The highest mod-sequence value all messages		The highest mod-sequence value all messages
	in the mailbox. This is the same value that is returned by the server		in the mailbox. This is the same value that is returned by the server
	in the HIGHESTMODSEQ response code in OK untagged response		in the HIGHESTMODSEQ response code in OK untagged response
	(see section 4.1).		(see section 4.1.1).
	Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)		Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
	S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292		S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
	HIGHESTMODSEQ 200201011231777)		HIGHESTMODSEQ 200201011231777)
	S: A042 OK STATUS completed		S: A042 OK STATUS completed
	5. 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 [ABNF].		Form (ABNF) notation as specified in [ABNF].
	skipping to change at line 547 ¶		skipping to change at line 618 ¶
	store-modifiers = [ SP "(" store-modifier *(SP store-modifier) ")" ]		store-modifiers = [ SP "(" store-modifier *(SP store-modifier) ")" ]
	store-modifier = "UNCHANGEDSINCE" SP mod-sequence-value		store-modifier = "UNCHANGEDSINCE" SP mod-sequence-value
	;; Only single "UNCHANGEDSINCE" may be specified		;; Only single "UNCHANGEDSINCE" may be specified
	;; in a STORE operation		;; in a STORE operation
	fetch-att =/ fetch-mod-sequence		fetch-att =/ fetch-mod-sequence
	;; modifies original IMAP4 fetch-att		;; modifies original IMAP4 fetch-att
	fetch-mod-sequence = "MODSEQ" [SP entry-names]		fetch-mod-sequence = "MODSEQ"
	fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence [permetadata-details] ")"		fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")"
	search-key =/ search-modsequence		search-key =/ search-modsequence
	;; modifies original IMAP4 search-key		;; modifies original IMAP4 search-key
	search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-value		search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-value
	search-modseq-ext = SP entry-name SP entry-type-req		search-modseq-ext = SP entry-name SP entry-type-req
	resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value /		resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value /
	"MODIFIED" SP set /		"MODIFIED" SP set /
	"MODSEQ" SP set SP mod-sequence-value		"MODSEQ" SP set SP mod-sequence-value
	;; set of message numbers for STORE/FETCH or		;; set of message numbers for STORE/FETCH or
	;; set of UIDs for UID STORE/UID FECTH		;; set of UIDs for UID STORE/UID FECTH
	entry-names = "(" 1*(entry-name SP entry-type) ")"
	;; the list can't be empty
	entry-name = '"' "/message/flags/" attr-flag '"'		entry-name = '"' "/message/flags/" attr-flag '"'
	;; each system or user defined flag <flag>		;; each system or user defined flag <flag>
	;; is mapped to "/message/flags/<flag>",		;; is mapped to "/message/flags/<flag>",
	;; where <flag> has no leading "\" for system		;; where <flag> has no leading "\" for system
	;; flags and has a leading "-" for all user		;; flags and has a leading "-" for all user
	;; defined flags.		;; defined flags.
	entry-type-resp = "private" | "shared"		entry-type-resp = "private" | "shared"
	;; metadata item type		;; metadata item type
	entry-type-req = entry-type-resp | "all"		entry-type-req = entry-type-resp | "all"
	;; perform FETCH/SEARCH operation on private		;; perform SEARCH operation on private
	;; annotation(s), shared annotation(s) or both		;; metadata item, shared metadata item or both
	permsg-modsequence = mod-sequence-value		permsg-modsequence = mod-sequence-value
	;; per message mod-sequence		;; per message mod-sequence
	permetadata-details = *(entry-name SP entry-type-resp SP mod-sequence-value)
	;; per metadata details should returned only if
	;; requested by the client and supported by the server
	mod-sequence-value = 1*DIGIT		mod-sequence-value = 1*DIGIT
	;; Unsigned 64-bit integer (mod-sequence)		;; Unsigned 64-bit integer (mod-sequence)
	;; (0 <= n < 18,446,744,073,709,551,615)		;; (0 <= n < 18,446,744,073,709,551,615)
	;;Borrowed from IMAP4rev1 and modified accordingly:		;;Borrowed from IMAP4rev1 and modified accordingly:
	attr-flag = "Answered" / "Flagged" / "Deleted" /		attr-flag = "Answered" / "Flagged" / "Deleted" /
	"Seen" / "Draft" / "-" attr-flag-keyword /		"Seen" / "Draft" / "-" attr-flag-keyword /
	attr-flag-extension		attr-flag-extension
	;; Does not include "\Recent"		;; Does not include "\Recent"
	skipping to change at line 615 ¶		skipping to change at line 679 ¶
	;; revisions of this specification.		;; revisions of this specification.
	attr-flag-keyword = atom		attr-flag-keyword = atom
	;;Extension to SORT		;;Extension to SORT
	sort-key =/ "MODSEQ"		sort-key =/ "MODSEQ"
	6. Security Considerations		6. Security Considerations
	There are no known security issues with this extension.		There are no known security issues with this extension, not already
			found in [IMAP4].
	7. References		7. References
			7.1. Normative References
			[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119, Harvard University, March 1997.
	[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.
	[IMAP4] Crispin, M., "Internet Message Access Protocol - Version		[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
	4rev1", RFC 2060, University of Washington, December 1996.		4rev1", RFC 2060, University of Washington, December 1996.
	[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate		[ANNOTATE] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension",
	Requirement Levels", RFC 2119, Harvard University, March 1997.
	[ACAP] Newman, Myers, "ACAP -- Application Configuration Access
	Protocol", RFC 2244, Innosoft, Netscape, November 1997.
	<ftp://ftp.isi.edu/in-notes/rfc2244.txt>
	[ANNOTATION] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension",
	work in progress.		work in progress.
	<http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-xx.txt>		<http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-xx.txt>
	[SORT] Crispin, M., "Internet Message Access Protocol -- SORT		[SORT] Crispin, M., "Internet Message Access Protocol -- SORT
	Extension", work in progress.		Extension", work in progress.
	<http://www.ietf.org/internet-drafts/draft-crispin-imapext-sort-xx.txt>		<http://www.ietf.org/internet-drafts/draft-crispin-imapext-sort-xx.txt>
			7.2. Informative References
			[ACAP] Newman, Myers, "ACAP -- Application Configuration Access
			Protocol", RFC 2244, Innosoft, Netscape, November 1997.
			<ftp://ftp.isi.edu/in-notes/rfc2244.txt>
			[ACL] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
			January 1997.
			<ftp://ftp.isi.edu/in-notes/rfc2086.txt>
			[NTP] Mills, D, "Network Time Protocol (Version 3) Specification,
			Implementation and Analysis", RFC 1305, March 1992.
			<ftp://ftp.isi.edu/in-notes/rfc1305.txt>
	8. Acknowledgments		8. Acknowledgments
	Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens		Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens
	and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol"		and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol"
	by Chris Newman and John Myers.		by Chris Newman and John Myers.
	Many thanks to Randall Gellens for his comments on how CONDSTORE should		Many thanks to Randall Gellens for his comments on how CONDSTORE should
	interact with ANNOTATE extension and for thorough review of the document.		interact with ANNOTATE extension and for thorough review of the document.
	Authors also acknowledge the feedback provided by Cyrus Daboo, Larry		Authors also acknowledge the feedback provided by Cyrus Daboo, Larry
	Greenfield and Arnt Gulbrandsen.		Greenfield, Chris Newman and Arnt Gulbrandsen.
	9. Author's Addresses		9. Author's Addresses
	Alexey Melnikov		Alexey Melnikov
	mailto: Alexey.Melnikov@messagingdirect.com		mailto: Alexey.Melnikov@messagingdirect.com
	ACI WorldWide/MessagingDirect		ACI WorldWide/MessagingDirect
	22 The Quadrant, Richmond, Surrey		59 Clarendon Road, Watford, Hertfordshire,
	TW9 1BP, United Kingdom		WD17 1FQ, United Kingdom
	Steve Hole		Steve Hole
	mailto: Steve.Hole@messagingdirect.com		mailto: Steve.Hole@messagingdirect.com
	ACI WorldWide/MessagingDirect		ACI WorldWide/MessagingDirect
	#900, 10117 Jasper Avenue,		#900, 10117 Jasper Avenue,
	Edmonton, Alberta, T5J 1W8, CANADA		Edmonton, Alberta, T5J 1W8, CANADA
	10. Full Copyright Statement		10. Full Copyright Statement
	skipping to change at line 696 ¶		skipping to change at line 773 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 48 change blocks.
	102 lines changed or deleted		179 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/