< draft-ietf-qresync-rfc4551bis-00.txt   draft-ietf-qresync-rfc4551bis-01.txt >
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd. Internet-Draft Isode Ltd.
Obsoletes: 4551 (if approved) May 30, 2013 Obsoletes: 4551 (if approved) June 06, 2013
Updates: 3501 (if approved) Updates: 3501, 2683 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 01, 2013 Expires: December 08, 2013
IMAP Extension for Conditional STORE Operation or Quick Flag Changes IMAP Extension for Conditional STORE Operation or Quick Flag Changes
Resynchronization Resynchronization
draft-ietf-qresync-rfc4551bis-00.txt draft-ietf-qresync-rfc4551bis-01.txt
Abstract Abstract
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on a common IMAP mailbox. Examples include different clients working on
behalf of the same user, and multiple users accessing shared behalf of the same user, and multiple users accessing shared
mailboxes. These clients need a mechanism to synchronize state mailboxes. These clients need a mechanism to synchronize state
changes for messages within the mailbox. They must be able to changes for messages within the mailbox. They must be able to
guarantee that only one client can change message state (e.g., guarantee that only one client can change message state (e.g.,
message flags) at any time. An example of such an application is use message flags) at any time. An example of such an application is use
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 01, 2013. This Internet-Draft will expire on December 08, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5
3.1. New OK Untagged Responses for SELECT and EXAMINE . . . . 5 3.1. New OK Untagged Responses for SELECT and EXAMINE . . . . 5
3.1.1. HIGHESTMODSEQ Response Code . . . . . . . . . . . . . 6 3.1.1. HIGHESTMODSEQ Response Code . . . . . . . . . . . . . 6
3.1.2. NOMODSEQ Response Code . . . . . . . . . . . . . . . 7 3.1.2. NOMODSEQ Response Code . . . . . . . . . . . . . . . 7
3.2. STORE and UID STORE Commands . . . . . . . . . . . . . . 7 3.2. STORE and UID STORE Commands . . . . . . . . . . . . . . 7
3.3. FETCH and UID FETCH Commands . . . . . . . . . . . . . . 13 3.3. FETCH and UID FETCH Commands . . . . . . . . . . . . . . 13
3.3.1. CHANGEDSINCE FETCH Modifier . . . . . . . . . . . . . 13 3.3.1. CHANGEDSINCE FETCH Modifier . . . . . . . . . . . . . 13
3.3.2. MODSEQ Message Data Item in FETCH Command . . . . . . 13 3.3.2. MODSEQ Message Data Item in FETCH Command . . . . . . 13
3.3.3. MODSEQ Search Criterion in SEARCH . . . . . . . . . . 16 3.4. MODSEQ Search Criterion in SEARCH . . . . . . . . . . . . 16
3.3.4. Modified SEARCH Untagged Response . . . . . . . . . . 17 3.5. Modified SEARCH Untagged Response . . . . . . . . . . . . 17
3.3.5. HIGHESTMODSEQ Status Data Items . . . . . . . . . . . 17 3.6. HIGHESTMODSEQ Status Data Items . . . . . . . . . . . . . 17
3.3.6. CONDSTORE Parameter to SELECT and EXAMINE . . . . . . 17 3.7. CONDSTORE Parameter to SELECT and EXAMINE . . . . . . . . 17
3.3.7. Additional Quality-of-Implementation Issues . . . . . 18 3.8. Additional Quality-of-Implementation Issues . . . . . . . 18
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Server Implementation Considerations . . . . . . . . . . . . 21 5. Server Implementation Considerations . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Long Command Lines . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction and Overview 1. Introduction and Overview
The Conditional STORE extension is present in any IMAP4 The Conditional STORE extension is present in any IMAP4
implementation that returns "CONDSTORE" as one of the supported implementation that returns "CONDSTORE" as one of the supported
capabilities in the CAPABILITY command response. capabilities in the CAPABILITY command response.
An IMAP server that supports this extension MUST associate a positive An IMAP server that supports this extension MUST associate a positive
unsigned 64-bit value called a modification sequence (mod-sequence) unsigned 64-bit value called a modification sequence (mod-sequence)
with every IMAP message. This is an opaque value updated by the with every IMAP message. This is an opaque value updated by the
skipping to change at page 10, line 29 skipping to change at page 10, line 29
... ...
S: * 150 FETCH (MODSEQ (303181230852)) S: * 150 FETCH (MODSEQ (303181230852))
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 (303011130956) FLAGS ($Processed)) S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: a107 OK S: a107 OK
Example 9
Or the flag hasn't changed, but another has (note that this server Or the flag hasn't changed, but another has (note that this server
behaviour is discouraged. Server implementers should also see behaviour is discouraged. Server implementers should also see
Section 5)... Section 5)...
C: b107 NOOP C: b107 NOOP
S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered)) S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
S: b107 OK S: b107 OK
...and the client retries the operation for the message 101 with ...and the client retries the operation for the message 101 with
the updated UNCHANGEDSINCE value the updated UNCHANGEDSINCE value
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956) C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852)) S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed S: b108 OK Conditional Store completed
Example 9
Same as above, but the server avoids the need for the client to poll Same as above, but the server avoids the need for the client to poll
for changes. for changes.
The flag $Processed was set on the message 101 by another The flag $Processed was set on the message 101 by another
client... client...
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852)) S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed)) S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: * 102 FETCH (MODSEQ (303181230852)) S: * 102 FETCH (MODSEQ (303181230852))
... ...
S: * 150 FETCH (MODSEQ (303181230852)) S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed S: a106 OK [MODIFIED 101] Conditional STORE failed
Example 10
Or the flag hasn't changed, but another has (note that this server Or the flag hasn't changed, but another has (note that this server
behaviour is discouraged. Server implementers should also see behaviour is discouraged. Server implementers should also see
Section 5)... Section 5)...
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852)) S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered)) S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
S: * 102 FETCH (MODSEQ (303181230852)) S: * 102 FETCH (MODSEQ (303181230852))
... ...
skipping to change at page 11, line 38 skipping to change at page 11, line 40
S: a106 OK [MODIFIED 101] Conditional STORE failed S: a106 OK [MODIFIED 101] Conditional STORE failed
...and the client retries the operation for the message 101 with ...and the client retries the operation for the message 101 with
the updated UNCHANGEDSINCE value the updated UNCHANGEDSINCE value
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956) C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852)) S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed S: b108 OK Conditional Store completed
Or the flag hasn't changed, but another has (nice server Or the flag hasn't changed, but another has (nice server behaviour.
behaviour. Server implementers should also see Section 5)... Server implementers should also see Section 5)...
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed) +FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852)) S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted
\Answered)) \Answered))
S: * 102 FETCH (MODSEQ (303181230852)) S: * 102 FETCH (MODSEQ (303181230852))
... ...
S: * 150 FETCH (MODSEQ (303181230852)) S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK Conditional STORE completed S: a106 OK Conditional STORE completed
Example 10
The following example is based on the example from the Section 4.2.3 The following example is based on the example from the Section 4.2.3
of [RFC2180] and demonstrates that the MODIFIED response code may be of [RFC2180] and demonstrates that the MODIFIED response code may be
also returned in the tagged NO response. also 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 and non-expunged messages; one message fails the UNCHANGEDSINCE
test. test.
C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN) C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN)
S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN)) S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
skipping to change at page 16, line 8 skipping to change at page 16, line 8
C: D390 NOOP C: D390 NOOP
S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
S: D390 OK Noop completed S: D390 OK Noop completed
Example 14 Example 14
Server implementers should also see Section 3.8 for additional Server implementers should also see Section 3.8 for additional
quality of implementation issues related to the FETCH command. quality of implementation issues related to the FETCH command.
3.3.3. MODSEQ Search Criterion in SEARCH 3.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-valzer> Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>
Messages that have modification values that are equal to or Messages that have modification values that are equal to or
greater than <mod-sequence-valzer>. This allows a client, for greater than <mod-sequence-valzer>. This allows a client, for
example, to find out which messages contain metadata items that example, to find out which messages contain metadata items that
have changed since the last time it updated its disconnected have changed since the last time it updated its disconnected
skipping to change at page 17, line 8 skipping to change at page 17, line 8
"\Draft" flag are returned in the search results. "\Draft" flag are returned in the search results.
Example 15 Example 15
C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000 C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000
S: * SEARCH S: * SEARCH
S: t OK Search complete, nothing found S: t OK Search complete, nothing found
Example 16 Example 16
3.3.4. Modified SEARCH Untagged Response 3.5. Modified SEARCH Untagged Response
Data: zero or more numbers Data: zero or more numbers
mod-sequence value (omitted if no match) mod-sequence value (omitted if no match)
This document extends syntax of the untagged SEARCH response to This document extends syntax of the untagged SEARCH response to
include the highest mod-sequence for all messages being returned. include the highest mod-sequence for all messages being returned.
If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH)
command and the server returns a non-empty SEARCH result, the server command and the server returns a non-empty SEARCH result, the server
MUST also append (to the end of the untagged SEARCH response) the MUST also append (to the end of the untagged SEARCH response) the
highest mod-sequence for all messages being returned. See highest mod-sequence for all messages being returned. See
Section 3.4 for examples. Section 3.5 for examples.
3.3.5. HIGHESTMODSEQ Status Data Items 3.6. HIGHESTMODSEQ Status Data Items
This document defines a new status data item: This document defines a new status data item:
HIGHESTMODSEQ The highest mod-sequence value of all messages in the HIGHESTMODSEQ The highest mod-sequence value of all messages in the
mailbox. This is the same value that is returned by the server in mailbox. This is the same value that is returned by the server in
the HIGHESTMODSEQ response code in an OK untagged response (see the HIGHESTMODSEQ response code in an OK untagged response (see
Section 3.1.1). If the server doesn't support the persistent Section 3.1.1). If the server doesn't support the persistent
storage of mod-sequences for the mailbox (see Section 3.1.2), the storage of mod-sequences for the mailbox (see Section 3.1.2), the
server MUST return 0 as the value of HIGHESTMODSEQ status data server MUST return 0 as the value of HIGHESTMODSEQ status data
item. item.
C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ) C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
HIGHESTMODSEQ 7011231777) HIGHESTMODSEQ 7011231777)
S: A042 OK STATUS completed S: A042 OK STATUS completed
Example 17 Example 17
3.3.6. CONDSTORE Parameter to SELECT and EXAMINE 3.7. CONDSTORE Parameter to SELECT and EXAMINE
The CONDSTORE extension defines a single optional select parameter, The CONDSTORE extension defines a single optional select parameter,
"CONDSTORE", which tells the server that it MUST include the MODSEQ "CONDSTORE", which tells the server that it MUST include the MODSEQ
fetch response data items in all subsequent unsolicited FETCH fetch response data items in all subsequent unsolicited FETCH
responses. responses.
The CONDSTORE parameter to SELECT/EXAMINE helps avoid a race The CONDSTORE parameter to SELECT/EXAMINE helps avoid a race
condition that might arise when one or more metadata items are condition that might arise when one or more metadata items are
modified in another session after the server has sent the modified in another session after the server has sent the
HIGHESTMODSEQ response code and before the client was able to issue a HIGHESTMODSEQ response code and before the client was able to issue a
skipping to change at page 18, line 20 skipping to change at page 18, line 20
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: * 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 715194045007] S: * OK [HIGHESTMODSEQ 715194045007]
S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled
Example 18 Example 18
3.3.7. Additional Quality-of-Implementation Issues 3.8. Additional Quality-of-Implementation Issues
Server implementations should follow the following rule, which Server implementations should follow the following rule, which
applies to any successfully completed STORE/UID STORE (with and applies to any successfully completed STORE/UID STORE (with and
without UNCHANGEDSINCE modifier), as well as to a FETCH command that without UNCHANGEDSINCE modifier), as well as to a FETCH command that
implicitly sets \Seen flag: implicitly sets \Seen flag:
Adding the flag when it is already present or removing when it is Adding the flag when it is already present or removing when it is
not present SHOULD NOT change the mod-sequence. not present SHOULD NOT change the mod-sequence.
This will prevent spurious client synchronization requests. This will prevent spurious client synchronization requests.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
capability =/ "CONDSTORE" capability =/ "CONDSTORE"
status-att =/ "HIGHESTMODSEQ" status-att =/ "HIGHESTMODSEQ"
;; extends non-terminal defined in RFC 3501. ;; extends non-terminal defined in RFC 3501.
status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer
;; extends non-terminal defined in [RFC4466]. ;; extends non-terminal defined in [RFC4466].
;; Value 0 denotes that the mailbox doesn't ;; Value 0 denotes that the mailbox doesn't
;; support persistent mod-sequences ;; support persistent mod-sequences
;; as described in Section 3.1.2 ;; as described in Section 3.1.2 [[Check the ref]]
store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer
;; Only a single "UNCHANGEDSINCE" may be ;; Only a single "UNCHANGEDSINCE" may be
;; specified in a STORE operation ;; specified in a STORE operation
fetch-modifier =/ chgsince-fetch-mod fetch-modifier =/ chgsince-fetch-mod
;; conforms to the generic "fetch-modifier" ;; conforms to the generic "fetch-modifier"
;; syntax defined in [RFC4466]. ;; syntax defined in [RFC4466].
chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value
skipping to change at page 22, line 19 skipping to change at page 22, line 19
Therefore, the server doesn't have to report MODIFIED to the client. Therefore, the server doesn't have to report MODIFIED to the client.
Instead, the server may set $Processed flag, update the mod-sequence Instead, the server may set $Processed flag, update the mod-sequence
for the message 101 once again and send an untagged FETCH response for the message 101 once again and send an untagged FETCH response
with new mod-sequence and flags: with new mod-sequence and flags:
S: * 101 FETCH (MODSEQ (303011130956) S: * 101 FETCH (MODSEQ (303011130956)
FLAGS ($Processed \Deleted \Answered)) FLAGS ($Processed \Deleted \Answered))
See also Section 3.8 for additional quality-of-implementation issues. See also Section 3.8 for additional quality-of-implementation issues.
6. Security Considerations 6. Long Command Lines
This document updates recommended line length limits specified in
Section 3.2.1.5 of [RFC2683]. While the advice in the first
paragraph of that section still applies ("use compact message/UID set
representations"), the 1000 octet limit suggested in the second
paragraph turned out to be quite problematic when the CONDSTORE
extension is used. The updated recommendation is as follows: a
client should limit the length of the command lines it generates to
approximately 8192 octets (including all quoted strings but not
including literals).
7. Security Considerations
It is believed that the Conditional STORE extension doesn't raise any It is believed that the Conditional STORE extension doesn't raise any
new security concerns that are not already discussed in [RFC3501]. new security concerns that are not already discussed in [RFC3501].
However, the availability of this extension may make it possible for 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 operation previously, making correct IMAP server implementation and operation
even more important. even more important.
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 IMAP capability. IANA has added This document defines the CONDSTORE IMAP capability. IANA has added
it to the registry accordingly. it to the registry accordingly.
8. Acknowledgements 9. Acknowledgements
Thank you to Steve Hole for co-editing RFC 4551. Thank you to Steve Hole for co-editing RFC 4551.
Thank you to Dave Cridland for helping to convert the original text Thank you to Dave Cridland for helping to convert the original text
RFC to xml2rfc format. RFC to xml2rfc format.
Some text was borrowed from "IMAP ANNOTATE Extension" [RFC5257] by Some text was borrowed from "IMAP ANNOTATE Extension" [RFC5257] by
Randall Gellens and Cyrus Daboo and from "ACAP -- Application Randall Gellens and Cyrus Daboo and from "ACAP -- Application
Configuration Access Protocol" [RFC2244] by Chris Newman and John Configuration Access Protocol" [RFC2244] by Chris Newman and John
Myers. Myers.
Many thanks to Randall Gellens for his thorough review of the Many thanks to Randall Gellens for his thorough review of the
document. document.
The authors also acknowledge the feedback provided by Cyrus Daboo, The authors also acknowledge the feedback provided by Cyrus Daboo,
Larry Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Larry Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen,
Timo Sirainen, Mark Crispin, Ned Freed, Ken Murchison, and Dave Timo Sirainen, Mark Crispin, Ned Freed, Ken Murchison, and Dave
Cridland. Cridland.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006. ABNF", RFC 4466, April 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
9.2. Informative References 10.2. Informative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC [RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
2180, July 1997. 2180, July 1997.
[RFC2244] Newman, C. and J.G. Myers, "ACAP -- Application [RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC
2683, September 1999.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005. RFC 4314, December 2005.
[RFC5257] Daboo, C. and R. Gellens, "Internet Message Access [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access
Protocol - ANNOTATE Extension", RFC 5257, June 2008. Protocol - ANNOTATE Extension", RFC 5257, June 2008.
Appendix A. Changes since RFC 4551 Appendix A. Changes since RFC 4551
Fixed errata 3401, 3506 and 3509. Fixed errata 3401, 3506 and 3509.
 End of changes. 26 change blocks. 
37 lines changed or deleted 53 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/