< draft-ietf-qresync-rfc5162bis-09.txt   draft-ietf-qresync-rfc5162bis-10.txt >
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Obsoletes: 4551, 5162 (if approved) D. Cridland Obsoletes: 4551, 5162 (if approved) D. Cridland
Updates: 2683 (if approved) Arcode Inc Updates: 2683 (if approved) Arcode Inc
Intended status: Standards Track January 13, 2014 Intended status: Standards Track January 30, 2014
Expires: July 17, 2014 Expires: August 3, 2014
IMAP Extensions for Conditional STORE Operation or Quick Flag Changes IMAP Extensions for Conditional STORE Operation or Quick Flag Changes
Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization
(QRESYNC) (QRESYNC)
draft-ietf-qresync-rfc5162bis-09.txt draft-ietf-qresync-rfc5162bis-10.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 efficiently synchronize mailboxes. These clients need a mechanism to efficiently synchronize
state changes for messages within the mailbox. state changes for messages within the mailbox.
Initially defined in RFC 4551, The Conditional Store facility Initially defined in RFC 4551, The Conditional Store facility
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 July 17, 2014. This Internet-Draft will expire on August 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 3, line 20 skipping to change at page 3, line 20
3.2.2. Advertising support for QRESYNC . . . . . . . . . . . 25 3.2.2. Advertising support for QRESYNC . . . . . . . . . . . 25
3.2.3. Use of ENABLE . . . . . . . . . . . . . . . . . . . . 25 3.2.3. Use of ENABLE . . . . . . . . . . . . . . . . . . . . 25
3.2.4. Additional requirements on QRESYNC servers . . . . . 26 3.2.4. Additional requirements on QRESYNC servers . . . . . 26
3.2.5. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . 26 3.2.5. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . 26
3.2.6. VANISHED UID FETCH Modifier . . . . . . . . . . . . . 30 3.2.6. VANISHED UID FETCH Modifier . . . . . . . . . . . . . 30
3.2.7. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 32 3.2.7. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 32
3.2.8. CLOSE Command . . . . . . . . . . . . . . . . . . . . 33 3.2.8. CLOSE Command . . . . . . . . . . . . . . . . . . . . 33
3.2.9. UID EXPUNGE Command . . . . . . . . . . . . . . . . . 34 3.2.9. UID EXPUNGE Command . . . . . . . . . . . . . . . . . 34
3.2.10. VANISHED Response . . . . . . . . . . . . . . . . . . 35 3.2.10. VANISHED Response . . . . . . . . . . . . . . . . . . 35
3.2.11. CLOSED Response Code . . . . . . . . . . . . . . . . 38 3.2.11. CLOSED Response Code . . . . . . . . . . . . . . . . 38
4. Long Command Lines . . . . . . . . . . . . . . . . . . . . . 38 4. Long Command Lines (Update to RFC 2683) . . . . . . . . . . . 38
5. QRESYNC Server Implementation Considerations . . . . . . . . 39 5. QRESYNC Server Implementation Considerations . . . . . . . . 39
5.1. Server Implementations That Don't Store Extra State . . . 39 5.1. Server Implementations That Don't Store Extra State . . . 39
5.2. Server Implementations Storing Minimal State . . . . . . 39 5.2. Server Implementations Storing Minimal State . . . . . . 39
5.3. Additional State Required on the Server . . . . . . . . . 39 5.3. Additional State Required on the Server . . . . . . . . . 40
6. Updated Synchronization Sequence . . . . . . . . . . . . . . 40 6. Updated Synchronization Sequence . . . . . . . . . . . . . . 41
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 43 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References . . . . . . . . . . . . . . . . . . 47 10.1. Normative References . . . . . . . . . . . . . . . . . . 48
10.2. Informative References . . . . . . . . . . . . . . . . . 48 10.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 48 Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 49
Appendix B. Changes since RFC 5162 . . . . . . . . . . . . . . . 49 Appendix B. Changes since RFC 5162 . . . . . . . . . . . . . . . 50
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 50 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
Often, multiple IMAP [RFC3501] clients need to coordinate changes to Often, multiple IMAP [RFC3501] 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 client representing multiple users behalf of the same user, and client representing multiple users
accessing shared mailboxes. These clients need a mechanism to accessing shared mailboxes. These clients need a mechanism to
synchronize state changes for messages within the mailbox. The synchronize state changes for messages within the mailbox. The
Conditional Store ("CONDSTORE") facility allows a client to quickly Conditional Store ("CONDSTORE") facility allows a client to quickly
resynchronize mailbox flag changes. resynchronize mailbox flag changes.
skipping to change at page 16, line 36 skipping to change at page 16, line 36
Server implementers should also see Section 3.1.11 for additional Server implementers should also see Section 3.1.11 for additional
quality of implementation issues related to the STORE command. quality of implementation issues related to the STORE command.
3.1.4. FETCH and UID FETCH Commands 3.1.4. FETCH and UID FETCH Commands
3.1.4.1. CHANGEDSINCE FETCH Modifier 3.1.4.1. CHANGEDSINCE FETCH Modifier
This document defines the following FETCH modifier (see Section 2.4 This document defines the following FETCH modifier (see Section 2.4
of [RFC4466]): of [RFC4466]):
CHANGEDSINCE <mod-sequence> CHANGEDSINCE FETCH modifier allows to CHANGEDSINCE <mod-sequence> CHANGEDSINCE FETCH modifier allows the
further subset the list of messages described by sequence set. client to further subset the list of messages described by
The information described by message data items is only returned sequence set. The information described by message data items is
for messages that have mod-sequence bigger than <mod-sequence>. only returned for messages that have mod-sequence bigger than
<mod-sequence>.
When CHANGEDSINCE FETCH modifier is specified, it implicitly adds When CHANGEDSINCE FETCH modifier is specified, it implicitly adds
MODSEQ FETCH message data item (Section 3.1.4.2). MODSEQ FETCH message data item (Section 3.1.4.2).
C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345)
S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk
$MDNSent)) $MDNSent))
S: s100 OK FETCH completed S: s100 OK FETCH completed
skipping to change at page 24, line 37 skipping to change at page 24, line 37
persistent storage of mod-sequences, i.e., for which the server would persistent storage of mod-sequences, i.e., for which the server would
send a HIGHESTMODSEQ untagged OK response code on a successful SELECT send a HIGHESTMODSEQ untagged OK response code on a successful SELECT
/EXAMINE, MUST increment the per-mailbox mod-sequence when one or /EXAMINE, MUST increment the per-mailbox mod-sequence when one or
more messages are expunged due to EXPUNGE, UID EXPUNGE, CLOSE or MOVE more messages are expunged due to EXPUNGE, UID EXPUNGE, CLOSE or MOVE
[RFC6851]; the server MUST associate the incremented mod-sequence [RFC6851]; the server MUST associate the incremented mod-sequence
with the UIDs of the expunged messages. Additionally, if the server with the UIDs of the expunged messages. Additionally, if the server
also supports the IMAP METADATA extension [RFC5464], it MUST also supports the IMAP METADATA extension [RFC5464], it MUST
increment the per-mailbox mod-sequence when SETMETADATA successfully increment the per-mailbox mod-sequence when SETMETADATA successfully
changes an annotation on the corresponding mailbox. changes an annotation on the corresponding mailbox.
Server implementing QRESYNC MUST send untagged events to client in a A server implementing QRESYNC MUST send untagged events to a client
way that client doesn't lose any changes in case of connectivity in a way that the client doesn't lose any changes in case of
loss. In particular this means that if server sends MODSEQ FETCH connectivity loss. In particular this means that if the server sends
data items while EXPUNGE (or VANISHED) replies with lower mod- MODSEQ FETCH data items while EXPUNGE (or VANISHED) replies with
sequences are being delayed, the server MUST send HIGHESTMODSEQ lower mod-sequences are being delayed, the server MUST send
response code with a lower value than the EXPUNGE's mod-sequence. HIGHESTMODSEQ response code with a lower value than the EXPUNGE's
See example in Section 6. mod-sequence. See example in Section 6.
3.2.1. Impact on CONDSTORE-only clients 3.2.1. Impact on CONDSTORE-only clients
A client that supports CONDSTORE but not QRESYNC might resynchronize A client that supports CONDSTORE but not QRESYNC might resynchronize
a mailbox and discover that its HIGHESTMODSEQ has increased from the a mailbox and discover that its HIGHESTMODSEQ has increased from the
value cached by the client. If the increase is only due to messages value cached by the client. If the increase is only due to messages
having been expunged since the client last synchronized, the client having been expunged since the client last synchronized, the client
is likely to send a FETCH ... CHANGEDSINCE command that returns no is likely to send a FETCH ... CHANGEDSINCE command that returns no
data. Thus, a client that supports CONDSTORE but not QRESYNC might data. Thus, a client that supports CONDSTORE but not QRESYNC might
incur a penalty of an unneeded round-trip when resynchronizing some incur a penalty of an unneeded round-trip when resynchronizing some
skipping to change at page 38, line 42 skipping to change at page 38, line 42
previously opened mailbox (which was closed) and the newly selected previously opened mailbox (which was closed) and the newly selected
mailbox: all responses before the CLOSED response code relate to the mailbox: all responses before the CLOSED response code relate to the
mailbox that was closed, and all subsequent responses relate to the mailbox that was closed, and all subsequent responses relate to the
newly opened mailbox. newly opened mailbox.
There is no need to return the CLOSED response code on completion of There is no need to return the CLOSED response code on completion of
the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose
purpose is to close the currently selected mailbox without opening a purpose is to close the currently selected mailbox without opening a
new one. new one.
4. Long Command Lines 4. Long Command Lines (Update to RFC 2683)
While [RFC3501] doesn't specify a specific line length limit, several
server implementations chose to implement the recommended line length
limit suggested in Section 3.2.1.5 of [RFC2683] in order to protect
from Denial-of-Service attacks. When the line length limit is
exceeded such servers return BAD response (as required by [RFC3501]
in case of a syntactic error) and may even close the connection.
Clients that support CONDSTORE/QRESYNC extensions can trigger this
limit by sending a long UID sequence (previously returned by the
server) in an extended SELECT or FETCH command.
This document updates recommended line length limits specified in This document updates recommended line length limits specified in
Section 3.2.1.5 of [RFC2683]. While the advice in the first Section 3.2.1.5 of [RFC2683]. While the advice in the first
paragraph of that section still applies ("use compact message/UID set paragraph of that section still applies ("use compact message/UID set
representations"), the 1000 octet limit suggested in the second representations"), the 1000 octet limit suggested in the second
paragraph turned out to be quite problematic when the CONDSTORE and/ paragraph turned out to be quite problematic when the CONDSTORE and/
or QRESYNC extension is used. The updated recommendation is as or QRESYNC extension is used.
follows: a client should limit the length of the command lines it
generates to approximately 8192 octets (including all quoted strings The updated recommendation is as follows: a client should limit the
but not including literals). length of the command lines it generates to approximately 8192 octets
(including all quoted strings but not including literals). If the
client is unable to group things into ranges so that the command line
is within that length, it should split the request into multiple
commands. The client should use literals instead of long quoted
strings, in order to keep the command length down.
5. QRESYNC Server Implementation Considerations 5. QRESYNC Server Implementation Considerations
This section describes a minimalist implementation, a moderate This section describes a minimalist implementation, a moderate
implementation, and an example of a full implementation. implementation, and an example of a full implementation.
5.1. Server Implementations That Don't Store Extra State 5.1. Server Implementations That Don't Store Extra State
Strictly speaking, a server implementation that doesn't remember mod- Strictly speaking, a server implementation that doesn't remember mod-
sequences associated with expunged messages can be considered sequences associated with expunged messages can be considered
skipping to change at page 41, line 5 skipping to change at page 41, line 20
Also, note that if the UIDVALIDITY of the mailbox changes or if the Also, note that if the UIDVALIDITY of the mailbox changes or if the
mailbox is deleted, then any state associated with expunged messages mailbox is deleted, then any state associated with expunged messages
doesn't need to be preserved and SHOULD be deleted. doesn't need to be preserved and SHOULD be deleted.
6. Updated Synchronization Sequence 6. Updated Synchronization Sequence
This section updates the description of optimized synchronization in This section updates the description of optimized synchronization in
Section 6.1 of the [IMAP-DISC]. Section 6.1 of the [IMAP-DISC].
An advanced disconnected mail client SHOULD use the QRESYNC and An advanced disconnected mail client SHOULD use the QRESYNC extension
CONDSTORE extensions when they are supported by the server. The when it is supported by the server, and SHOULD use CONDSTORE if it is
client uses the value from the HIGHESTMODSEQ OK response code supported and QRESYNC is not. The client uses the value from the
received on mailbox opening to determine if it needs to HIGHESTMODSEQ OK response code received on mailbox opening to
resynchronize. Once the synchronization is complete, it MUST cache determine if it needs to resynchronize. Once the synchronization is
the received value (unless the mailbox UIDVALIDITY value has changed; complete, it MUST cache the received value (unless the mailbox
see below). The client MUST update its copy of the HIGHESTMODSEQ UIDVALIDITY value has changed; see below). The client MUST update
value whenever the server sends a subsequent HIGHESTMODSEQ OK its copy of the HIGHESTMODSEQ value whenever the server sends a
response code. subsequent HIGHESTMODSEQ OK response code.
After completing a full synchronization, the client MUST also take After completing a full synchronization, the client MUST also take
note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ
response codes received from the server. Whenever the client response codes received from the server. Whenever the client
receives a tagged response to a command, it checks the received receives a tagged response to a command, it checks the received
unsolicited responses to calculate the new HIGHESTMODSEQ value. If unsolicited responses to calculate the new HIGHESTMODSEQ value. If
the HIGHESTMODSEQ response code is received, the client MUST use it the HIGHESTMODSEQ response code is received, the client MUST use it
even if it has seen higher mod-sequences. Otherwise, the client even if it has seen higher mod-sequences. Otherwise, the client
calculates the highest value among all MODSEQ FETCH data items calculates the highest value among all MODSEQ FETCH data items
received since the last tagged response. If this value is bigger received since the last tagged response. If this value is bigger
skipping to change at page 50, line 19 skipping to change at page 51, line 14
Editorial corrections. Editorial corrections.
Appendix C. Acknowledgements Appendix C. Acknowledgements
Thank you to Steve Hole for co-editing RFC 4551. Thank you to Steve Hole for co-editing RFC 4551.
In this revision of the document the authors also acknowledge the In this revision of the document the authors also acknowledge the
feedback provided by Timo Sirainen, Jan Kundrat, Pete Maclean, Barry feedback provided by Timo Sirainen, Jan Kundrat, Pete Maclean, Barry
Leiba, Eliot Lear, Chris Newman, Claudio Allocchio, Michael Slusarz, Leiba, Eliot Lear, Chris Newman, Claudio Allocchio, Michael Slusarz,
Bron Gondwana, Hoa V. DINH and Mark Crispin. Bron Gondwana, Arnt Gulbrandsen, David Black and Hoa V. DINH.
Mark Crispin contributed to RFC 4551 and RFC 5162 that this document
is replacing, and that much of his contribution remains in this
merged document.
See also RFC 4551 for the list of people who contributed to earlier See also RFC 4551 for the list of people who contributed to earlier
version of this RFC. version of this RFC.
Authors' Addresses Authors' Addresses
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
 End of changes. 11 change blocks. 
43 lines changed or deleted 63 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/