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
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Replaces | draft-melnikov-imap-condstore | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4551 (Proposed Standard) | |
| 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
Show full document text