| < 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/ | ||||