draft-ietf-imapext-condstore-04.txt   draft-ietf-imapext-condstore-05.txt 
Internet Draft: IMAP Extension for Conditional STORE A. Melnikov Internet Draft: IMAP Extension for Conditional STORE A. Melnikov
Document: draft-ietf-imapext-condstore-04.txt Isode Ltd. Document: draft-ietf-imapext-condstore-05.txt Isode Ltd.
Expires: April 2004 S. Hole Expires: May 2004 S. Hole
ACI WorldWide/MessagingDirect ACI WorldWide/MessagingDirect
October 2003 November 2003
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 36 skipping to change at line 36
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2001-2003. All Rights Reserved. Copyright (C) The Internet Society 2001-2003. All Rights Reserved.
Please see the Full Copyright section near the end of this document Please see the Full Copyright section near the end of this document
for more information. for more information.
Abstract Abstract
Often, multiple IMAP clients need to coordinate changes to a common Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
IMAP mailbox. Examples include different clients for the same user, a common IMAP mailbox. Examples include different clients working on behalf
and multiple users accessing shared mailboxes. These clients of the same user, 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
queue with multiple dequeueing clients. queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between message state information that can detect and resolve conflicts between
multiple writing mail clients. multiple writing mail clients.
This document defines an extension to IMAP (RFC 3501).
Table of Contents Table of Contents
1 Conventions Used in This Document ......................... X 1 Conventions Used in This Document ......................... X
2 Introduction and Overview ................................. X 2 Introduction and Overview ................................. X
3 IMAP Protocol Changes ..................................... X 3 IMAP Protocol Changes ..................................... X
3.1 New OK untagged responses for SELECT and EXAMINE ......... X 3.1 New OK untagged responses for SELECT and EXAMINE ......... X
3.1.1 HIGHESTMODSEQ response code ............................ X 3.1.1 HIGHESTMODSEQ response code ............................ X
3.1.2 NOMODSEQ response code ................................. X 3.1.2 NOMODSEQ response code ................................. X
3.2 STORE and UID STORE Commands ............................. X 3.2 STORE and UID STORE Commands ............................. X
3.3 FETCH and UID FETCH Commands ............................. X 3.3 FETCH and UID FETCH Commands ............................. X
3.3.1 FETCH modifiers ........................................ X 3.3.1 FETCH modifiers ........................................ X
3.3.2 MODSEQ message data item in FETCH Command .............. X 3.3.2 MODSEQ message data item in FETCH Command .............. X
3.4 MODSEQ search criterion in SEARCH ........................ X 3.4 MODSEQ search criterion in SEARCH ........................ X
3.5 MODSEQ Sort Criterion .................................... X 3.5 MODSEQ Sort Criterion .................................... X
3.6 Modified SEARCH and SORT untagged responses .............. X 3.6 Modified SEARCH and SORT untagged responses .............. X
3.7 HIGHESTMODSEQ status data items .......................... X 3.7 HIGHESTMODSEQ status data items .......................... X
3.8 CONDSTORE parameter to SELECT and EXAMINE ................ X 3.8 CONDSTORE parameter to SELECT and EXAMINE ................ X
4 Formal Syntax ............................................. X 4 Formal Syntax ............................................. X
5 Security Considerations ................................... X 5 Server implementation considerations ...................... X
6 References ................................................ X 6 Security Considerations ................................... X
6.1 Normative References ..................................... X 7 References ................................................ X
6.2 Informative References ................................... X 7.1 Normative References ..................................... X
7 IANA Considerations ....................................... X 7.2 Informative References ................................... X
8 Acknowledgments ........................................... X 8 IANA Considerations ....................................... X
9 Author's Addresses ........................................ X 9 Acknowledgments ........................................... X
10 Intellectual Property Rights .............................. X 10 Author's Addresses ........................................ X
11 Full Copyright Statement .................................. X 11 Intellectual Property Rights .............................. X
12 Full Copyright Statement .................................. X
1. Conventions Used in This Document 1. Conventions Used in This Document
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].
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
skipping to change at line 387 skipping to change at line 390
Use of UNCHANGEDSINCE with a modification sequence of 0 Use of UNCHANGEDSINCE with a modification sequence of 0
always fails if the metadata item exists. A system flag always fails if the metadata item exists. A system flag
MUST always be considered existent, whether it was set or not. MUST always be considered existent, whether it was set or not.
Example: Example:
C: a102 STORE 12 (UNCHANGEDSINCE 0) C: a102 STORE 12 (UNCHANGEDSINCE 0)
+FLAGS.SILENT ($MDNSent) +FLAGS.SILENT ($MDNSent)
S: a102 OK [MODIFIED 12] Conditional STORE failed S: a102 OK [MODIFIED 12] Conditional STORE failed
The client has tested the presence of the $MDNSent user defined
keyword.
Note: A client trying to make an atomic change to the state of a particular Note: A client trying to make an atomic change to the state of a particular
metadata item (or a set of metadata items) should be prepared metadata item (or a set of metadata items) should be prepared
to deal with the case when the server returns MODIFIED response code to deal with the case when the server returns MODIFIED response code
if the state of the metadata item being watched hasn't changed (but if the state of the metadata item being watched hasn't changed (but
the state of some other metadata item has). This is necessary, because the state of some other metadata item has). This is necessary, because
some servers don't store separate mod-sequences for different metadata some servers don't store separate mod-sequences for different metadata
items. However, a server implementation SHOULD avoid generating items. However, a server implementation SHOULD avoid generating
spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
even when the server stores a single mod-sequence per message. even when the server stores a single mod-sequence per message. Section
5 describes how this can be achieved.
Upon the receipt of MODIFIED response code the client SHOULD try to Unless the server has included an unsolicited FETCH to update client's
figure out if the required metadata items have indeed changed. If they knowledge about message(s) that has failed UNCHANGEDSINCE test, upon the
haven't the client SHOULD retry the command. receipt of MODIFIED response code the client SHOULD try to
figure out if the required metadata items have indeed changed by issuing
FETCH or NOOP command. It is RECOMMENDED that the server avoids the
need for the client to do that by sending an unsolicited FETCH response
(see two following examples).
If the required metadata items haven't changed the client SHOULD retry
the command with the new modsequence. The client SHOULD allow for a
configurable but reasonable number of retries (at least 2).
Example: Example:
In the example below the server returns MODIFIED response code
without sending information describing why the STORE UNCHANGEDSINCE
operation has failed.
C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000) C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (200303181230852)) S: * 100 FETCH (MODSEQ (200303181230852))
S: * 102 FETCH (MODSEQ (200303181230852)) S: * 102 FETCH (MODSEQ (200303181230852))
... ...
S: * 150 FETCH (MODSEQ (200303181230852)) S: * 150 FETCH (MODSEQ (200303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed S: a106 OK [MODIFIED 101] Conditional STORE failed
the flag $Processed was set on the message 101 ... the flag $Processed was set on the message 101 ...
C: a107 NOOP C: a107 NOOP
S: * 101 FETCH (MODSEQ (200303011130956) FLAGS ($Processed)) S: * 101 FETCH (MODSEQ (200303011130956) FLAGS ($Processed))
S: a107 OK S: a107 OK
Or the flag hasn't changed ... Or the flag hasn't changed, but another has (note, that this
server behaviour is discouraged. Server implementors should also see
section 5) ...
C: b107 NOOP C: b107 NOOP
S: * 101 FETCH (MODSEQ (200303011130956) FLAGS (\Deleted \Answered)) S: * 101 FETCH (MODSEQ (200303011130956) FLAGS (\Deleted \Answered))
S: b107 OK S: b107 OK
... and the client retries the operation for the message 100 ... and the client retries the operation for the message 101
with the updated UNCHANGEDSINCE value with the updated UNCHANGEDSINCE value
C: b108 STORE 100 (UNCHANGEDSINCE 200303011130956) C: b108 STORE 101 (UNCHANGEDSINCE 200303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (200303181230852))
S: b108 OK Conditional Store completed
Example:
Same as above, but the server avoids the need for the client to
poll for changes.
the flag $Processed was set on the message 101 by another client ...
C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (200303181230852)) S: * 100 FETCH (MODSEQ (200303181230852))
S: * 101 FETCH (MODSEQ (200303011130956) FLAGS ($Processed))
S: * 102 FETCH (MODSEQ (200303181230852))
...
S: * 150 FETCH (MODSEQ (200303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
Or the flag hasn't changed, but another has (note, that this
server behaviour is discouraged. Server implementors should also see
section 5) ...
C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (200303181230852))
S: * 101 FETCH (MODSEQ (200303011130956) FLAGS (\Deleted \Answered))
S: * 102 FETCH (MODSEQ (200303181230852))
...
S: * 150 FETCH (MODSEQ (200303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
... and the client retries the operation for the message 101
with the updated UNCHANGEDSINCE value
C: b108 STORE 101 (UNCHANGEDSINCE 200303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (200303181230852))
S: b108 OK Conditional Store completed S: b108 OK Conditional Store completed
Or the flag hasn't changed, but another has (nice server behaviour.
Server implementors should also see section 5) ...
C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (200303181230852))
S: * 101 FETCH (MODSEQ (200303011130956) FLAGS ($Processed \Deleted \Answered))
S: * 102 FETCH (MODSEQ (200303181230852))
...
S: * 150 FETCH (MODSEQ (200303181230852))
S: a106 OK Conditional STORE completed
Example: Example:
The following example is based on the example from the section 4.2.3 of The following example is based on the example from the section 4.2.3 of
[RFC-2180] and demonstrates that the MODIFIED response code may be also [RFC-2180] and demonstrates that the MODIFIED response code may be also
returned in the tagged NO response. returned in the tagged NO response.
Client tries to conditionally STORE flags on a mixture of expunged Client tries to conditionally STORE flags on a mixture of expunged
and non-expunged messages, one message fails the UNCHANGEDSINCE test. and non-expunged messages, one message fails the UNCHANGEDSINCE test.
C: B001 STORE 1:7 (UNCHANGEDSINCE 20000320172338) +FLAGS (\SEEN) C: B001 STORE 1:7 (UNCHANGEDSINCE 20000320172338) +FLAGS (\SEEN)
skipping to change at line 905 skipping to change at line 975
attr-flag-extension = "\\" atom attr-flag-extension = "\\" atom
;; Future expansion. Client implementations ;; Future expansion. Client implementations
;; MUST accept flag-extension flags. Server ;; MUST accept flag-extension flags. Server
;; implementations MUST NOT generate ;; implementations MUST NOT generate
;; flag-extension flags except as defined by ;; flag-extension flags except as defined by
;; future standard or standards-track ;; future standard or standards-track
;; revisions of [IMAP4]. ;; revisions of [IMAP4].
attr-flag-keyword = atom attr-flag-keyword = atom
5. Security Considerations 5. Server implementation considerations
This section describes how a server implementation that
doesn't store separate per-metadata modsequences for different metadata
items can avoid sending MODIFIED response to any of the following
conditional STORE operations:
+FLAGS
-FLAGS
+FLAGS.SILENT
-FLAGS.SILENT
Note, that the optimization described in this section can't be performed
in case of a conditional STORE FLAGS operation.
Let's use the following example. The client has issued
C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000)
+FLAGS.SILENT ($Processed)
When the server receives the command and parses it successfully it
iterates through the message set and tries to execute the conditional
STORE command for each message.
Each server internally works as a client, i.e. it has to cache the
current state of all IMAP flags as it is known to the client.
In order to report flag changes to the client the server compares the
cached values with the values in its database for IMAP flags.
Imagine that another client has changed the state of a flag \Deleted on
message 101 and the change updated the modsequence for the message.
The server knows that the modsequence for the mailbox has changed, however
it also knows that
a) The client is not interested in \Deleted flag, as it hasn't included
it in +FLAGS.SILENT operation.
b) The state of the flag $Processed hasn't changed (server can determine
this by comparing cached flag state with the state of the flag in the
database),
so the server doesn't have to report MODIFIED to the client. Instead the
server may set $Processed flag, update the modsequence for the message 101
once again and send an untagged FETCH response with new modsequence and
flags:
S: * 101 FETCH (MODSEQ (200303011130956) FLAGS ($Processed \Deleted \Answered))
6. Security Considerations
It is believed that the Conditional STORE extension doesn't raise It is believed that the Conditional STORE extension doesn't raise
any new security concerns that are not already discussed in [IMAP4]. any new security concerns that are not already discussed in [IMAP4].
However, the availability of this extension may make it possible However, the availability of this extension may make it possible
for IMAP4 to be used in critical applications it could not be used for IMAP4 to be used in critical applications it could not be used
for previously, making correct IMAP server implementation and for previously, making correct IMAP server implementation and
operation in even more important. operation even more important.
6. References 7. References
6.1. Normative References 7.1. Normative References
[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.
[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 3501, University of Washington, March 2003. 4rev1", RFC 3501, University of Washington, March 2003.
[ANNOTATE] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension", [ANNOTATE] 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., Murchison, K., "Internet Message Access Protocol -- [SORT] Crispin, M., Murchison, K., "Internet Message Access Protocol --
SORT AND THREAD EXTENSIONS", work in progress. SORT AND THREAD EXTENSIONS", 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-xx.txt>
6.2. Informative References 7.2. Informative References
[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.
<ftp://ftp.isi.edu/in-notes/rfc2244.txt> <ftp://ftp.isi.edu/in-notes/rfc2244.txt>
[ACL] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, [ACL] Myers, "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
January 1997. January 1997.
<ftp://ftp.isi.edu/in-notes/rfc2086.txt> <ftp://ftp.isi.edu/in-notes/rfc2086.txt>
[NTP] Mills, D, "Network Time Protocol (Version 3) Specification, [NTP] Mills, D, "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992. Implementation and Analysis", RFC 1305, March 1992.
<ftp://ftp.isi.edu/in-notes/rfc1305.txt> <ftp://ftp.isi.edu/in-notes/rfc1305.txt>
[RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
RFC 2180, July 1997. RFC 2180, July 1997.
<ftp://ftp.isi.edu/in-notes/rfc2180.txt> <ftp://ftp.isi.edu/in-notes/rfc2180.txt>
7. IANA Considerations 8. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located IESG approved experimental RFC. The registry is currently located
at: at:
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities. This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities.
IANA should add them to the registry accordingly. IANA should add them to the registry accordingly.
8. Acknowledgments 9. 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.
The authors also acknowledge the feedback provided by Cyrus Daboo, Larry The authors also acknowledge the feedback provided by Cyrus Daboo, Larry
Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Timo Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Timo
Sirainen, Mark Crispin and Ned Freed. Sirainen, Mark Crispin and Ned Freed.
9. Author's Addresses 10. Author's Addresses
Alexey Melnikov Alexey Melnikov
mailto: Alexey.Melnikov@isode.com mailto: Alexey.Melnikov@isode.com
Isode Limited Isode Limited
5 Castle Business Village, 36 Station Road, 5 Castle Business Village, 36 Station Road,
Hampton, Middlesex, TW12 2BX, United Kingdom Hampton, Middlesex, TW12 2BX, 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. Intellectual Property Rights 11. Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at line 1016 skipping to change at line 1131
obtain a general license or permission for the use of such proprietary obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained rights by implementors or users of this specification can be obtained
from the IETF Secretariat. from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
11. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society 2001-2003. All Rights Reserved. Copyright (C) The Internet Society 2001-2003. 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
skipping to change at line 1054 skipping to change at line 1169
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Appendix A. Open Issues and Change History Appendix A. Open Issues and Change History
Note that this appendix will be removed before publication. Note that this appendix will be removed before publication.
0.1. Change History 0.1. Change History
Changes from draft-ietf-imapext-condstore-04
1. Fixed typo in an example, added more examples.
2. Clarified client behavior regarding retrying the request
when the server returns MODIFIED (IESG comment)
3. Added new section describing how a CONDSTORE server implementation
should avoid sending MODIFIED when the client has requested
a conditional store on a flag A and a flag B was modified
by another client. (IESG comment)
Changes from draft-ietf-imapext-condstore-03 Changes from draft-ietf-imapext-condstore-03
1. ABNF corrections from Ned Freed. 1. ABNF corrections from Ned Freed.
2. Minor spelling/wording corrections from Ned Freed. 2. Minor spelling/wording corrections from Ned Freed.
Changes from draft-ietf-imapext-condstore-02 Changes from draft-ietf-imapext-condstore-02
1. Added FETCH modifiers. 1. Added FETCH modifiers.
2. Added example for using ANNOTATE with UNCHANGEDSINCE STORE 2. Added example for using ANNOTATE with UNCHANGEDSINCE STORE
modifier. modifier.
3. Added a new requirement to send HIGHESTMODSEQ response code 3. Added a new requirement to send HIGHESTMODSEQ response code
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/