IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
RFC 4551
Document | Type |
RFC - Proposed Standard
(June 2006; Errata)
Obsoleted by RFC 7162
Updates RFC 3501
|
|
---|---|---|---|
Authors | Steve Hole , Alexey Melnikov | ||
Last updated | 2020-01-21 | ||
Replaces | draft-melnikov-imap-condstore | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4551 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Lisa Dusseault | ||
Send notices to | (None) |
Network Working Group A. Melnikov Request for Comments: 4551 Isode Ltd. Updates: 3501 S. Hole Category: Standards Track ACI WorldWide/MessagingDirect June 2006 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). Melnikov & Hole Standards Track [Page 1] RFC 4551 IMAP Extension for Conditional STORE June 2006 Table of Contents 1. Introduction and Overview ................................. 3 2. Conventions Used in This Document ......................... 5 3. IMAP Protocol Changes ..................................... 6 3.1. New OK untagged responses for SELECT and EXAMINE ......... 6 3.1.1. HIGHESTMODSEQ response code ............................ 6 3.1.2. NOMODSEQ response code ................................. 7 3.2. STORE and UID STORE Commands ............................. 7 3.3 FETCH and UID FETCH Commands ..............................13 3.3.1. CHANGEDSINCE FETCH modifier ............................13 3.3.2. MODSEQ message data item in FETCH Command ..............14 3.4. MODSEQ search criterion in SEARCH ........................16 3.5. Modified SEARCH untagged response ........................17 3.6. HIGHESTMODSEQ status data items ..........................17 3.7. CONDSTORE parameter to SELECT and EXAMINE ................18 3.8. Additional quality of implementation issues ..............18 4. Formal Syntax .............................................19 5. Server implementation considerations ......................21 6. Security Considerations ...................................22 7. IANA Considerations .......................................22 8. References ................................................23 8.1. Normative References .....................................23 8.2. Informative References ...................................23 9. Acknowledgements ..........................................23 Melnikov & Hole Standards Track [Page 2] RFC 4551 IMAP Extension for Conditional STORE June 2006 1. Introduction and Overview The Conditional STORE extension is present in any IMAP4 implementation that returns "CONDSTORE" as one of the supported capabilities in the CAPABILITY command response. An IMAP server that supports this extension MUST associate a positive unsigned 64-bit value called a modification sequence (mod-sequence) with every IMAP message. This is an opaque value updated by the server whenever a metadata item is modified. The server MUST guarantee that each STORE command performed on the same mailbox (including simultaneous stores to different metadata items from different connections) will get a different mod-sequence value. Also, for any two successful STORE operations performed in the same session on the same mailbox, the mod-sequence of the second completed operation MUST be greater than the mod-sequence of the first completed. Note that the latter rule disallows the use of the system clock as a mod-sequence, because if system time changes (e.g., an NTP [NTP] client adjusting the time), the next generated value might be less than the previous one. Mod-sequences allow a client that supports the CONDSTORE extension toShow full document text