IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
RFC 4551

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

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 to