rfc5162.txt

广泛使用的邮件服务器！同时

Network Working Group                                        A. Melnikov
Request for Comments: 5162                                   D. Cridland
Category: Standards Track                                      Isode Ltd
                                                               C. Wilson
                                                                   Nokia
                                                              March 2008


          IMAP4 Extensions for Quick Mailbox 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.

Abstract

   This document defines an IMAP4 extension, which gives an IMAP client
   the ability to quickly resynchronize any previously opened mailbox as
   part of the SELECT command, without the need for server-side state or
   additional client round-trips.  This extension also introduces a new
   response that allows for a more compact representation of a list of
   expunged messages (and always includes the Unique Identifiers (UIDs)
   expunged).
























Melnikov, et al.            Standards Track                     [Page 1]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


Table of Contents

   1.  Introduction and Overview  . . . . . . . . . . . . . . . . . .  2
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  IMAP Protocol Changes  . . . . . . . . . . . . . . . . . . . .  4
     3.1.  QRESYNC Parameter to SELECT/EXAMINE  . . . . . . . . . . .  4
     3.2.  VANISHED UID FETCH Modifier  . . . . . . . . . . . . . . .  8
     3.3.  EXPUNGE Command  . . . . . . . . . . . . . . . . . . . . . 10
     3.4.  CLOSE Command  . . . . . . . . . . . . . . . . . . . . . . 11
     3.5.  UID EXPUNGE Command  . . . . . . . . . . . . . . . . . . . 11
     3.6.  VANISHED Response  . . . . . . . . . . . . . . . . . . . . 12
     3.7.  CLOSED Response Code . . . . . . . . . . . . . . . . . . . 15
   4.  Server Implementation Considerations . . . . . . . . . . . . . 15
     4.1.  Server Implementations That Don't Store Extra State  . . . 15
     4.2.  Server Implementations Storing Minimal State . . . . . . . 16
     4.3.  Additional State Required on the Server  . . . . . . . . . 16
   5.  Updated Synchronization Sequence . . . . . . . . . . . . . . . 17
   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     10.2. Informative References . . . . . . . . . . . . . . . . . . 22

1.  Introduction and Overview

   The [CONDSTORE] extension gives a disconnected client the ability to
   quickly resynchronize IMAP flag changes for previously seen messages.
   This can be done using the CHANGEDSINCE FETCH modifier once a mailbox
   is opened.  In order for the client to discover which messages have
   been expunged, the client still has to issue a UID FETCH or a UID
   SEARCH command.  This document defines an extension to [CONDSTORE]
   that allows a reconnecting client to perform full resynchronization,
   including discovery of expunged messages, in a single round-trip.
   This extension also introduces a new response, VANISHED, that allows
   for a more compact representation of a list of expunged messages.

   This extension can be useful for mobile clients that can experience
   frequent disconnects caused by environmental factors (battery life,
   signal strength, etc.).  Such clients need a way to quickly reconnect
   to the IMAP server, while minimizing delay experienced by the user as
   well as the amount of traffic (and hence the expense) generated by
   resynchronization.







Melnikov, et al.            Standards Track                     [Page 2]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   By extending the SELECT command to perform the additional
   resynchronization, this also allows clients to reduce concurrent
   connections to the IMAP server held purely for the sake of avoiding
   the resynchronization.

   The quick resync IMAP extension is present if an IMAP4 server returns
   "QRESYNC" as one of the supported capabilities to the CAPABILITY
   command.

   Servers supporting this extension MUST implement and advertise
   support for the [ENABLE] IMAP extension.  Also, the presence of the
   "QRESYNC" capability implies support for the [CONDSTORE] IMAP
   extension even if the CONDSTORE capability isn't advertised.  A
   server compliant with this specification is REQUIREd to support
   "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE
   enabling commands", as defined in [CONDSTORE], and have identical
   results), but there is no requirement for a compliant server to
   support "ENABLE CONDSTORE" by itself.  The "ENABLE QRESYNC"/"ENABLE
   QRESYNC CONDSTORE" command also tells the server that it SHOULD start
   sending VANISHED responses (see Section 3.6) instead of EXPUNGE
   responses.  This change remains in effect until the connection is
   closed.

   For compatibility with clients that only support the [CONDSTORE] IMAP
   extension, servers SHOULD advertise CONDSTORE in the CAPABILITY
   response as well.

   A client making use of this extension MUST issue "ENABLE QRESYNC"
   once it is authenticated.  A server MUST respond with a tagged BAD
   response if the QRESYNC parameter to the SELECT/EXAMINE command or
   the VANISHED UID FETCH modifier is specified and the client hasn't
   issued "ENABLE QRESYNC" in the current connection.

   This document puts additional requirements on a server implementing
   the [CONDSTORE] extension.  Each mailbox that supports persistent
   storage of mod-sequences, i.e., for which the server has sent a
   HIGHESTMODSEQ untagged OK response code on a successful SELECT/
   EXAMINE, MUST increment the per-mailbox mod-sequence when one or more
   messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the
   server MUST associate the incremented mod-sequence with the UIDs of
   the expunged messages.

   A client that supports CONDSTORE but not this extension might
   resynchronize a mailbox and discover that its HIGHESTMODSEQ has
   increased from the value cached by the client.  If the increase is
   only due to messages having been expunged since the client last
   synchronized, the client is likely to send a FETCH ...  CHANGEDSINCE
   command that returns no data.  Thus, a client that supports CONDSTORE



Melnikov, et al.            Standards Track                     [Page 3]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   but not this extension might incur a penalty of an unneeded round-
   trip when resynchronizing some mailboxes (those that have had
   messages expunged but no flag changes since the last
   synchronization).

   This extra round-trip is only incurred by clients that support
   CONDSTORE but not this extension, and only when a mailbox has had
   messages expunged but no flag changes to non-expunged messages.
   Since CONDSTORE is a relatively new extension, it is thought likely
   that clients that support it will also support this extension.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.  If a single "C:" or "S:" label applies to
   multiple lines, then the line breaks between those lines are for
   editorial clarity only and are not part of the actual protocol
   exchange.  The five characters [...] means that something has been
   elided.

   Understanding of the IMAP message sequence numbers and UIDs and the
   EXPUNGE response [RFC3501] is essential when reading this document.

3.  IMAP Protocol Changes

3.1.  QRESYNC Parameter to SELECT/EXAMINE

   The Quick Resynchronization parameter to SELECT/EXAMINE commands has
   four arguments:

   o  the last known UIDVALIDITY,

   o  the last known modification sequence,

   o  the optional set of known UIDs, and

   o  an optional parenthesized list of known sequence ranges and their
      corresponding UIDs.

   A server MUST respond with a tagged BAD response if the Quick
   Resynchronization parameter to SELECT/EXAMINE command is specified
   and the client hasn't issued "ENABLE QRESYNC" in the current
   connection.




Melnikov, et al.            Standards Track                     [Page 4]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   Before opening the specified mailbox, the server verifies all
   arguments for syntactic validity.  If any parameter is not
   syntactically valid, the server returns the tagged BAD response, and
   the mailbox remains unselected.  Once the check is done, the server
   opens the mailbox as if no SELECT/EXAMINE parameters are specified
   (this is subject to processing of other parameters as defined in
   other extensions).  In particular this means that the server MUST
   send all untagged responses as specified in Sections 6.3.1 and 6.3.2
   of [RFC3501].

   After that, the server checks the UIDVALIDITY value provided by the
   client.  If the provided UIDVALIDITY doesn't match the UIDVALIDITY
   for the mailbox being opened, then the server MUST ignore the
   remaining parameters and behave as if no dynamic message data
   changed.  The client can discover this situation by comparing the
   UIDVALIDITY value returned by the server.  This behavior allows the
   client not to synchronize the mailbox or decide on the best
   synchronization strategy.

   Example: Attempting to resynchronize INBOX, but the provided
            UIDVALIDITY parameter doesn't match the current UIDVALIDITY
            value.

   C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000
            41,43:211,214:541))
            S: * 464 EXISTS
            S: * 3 RECENT
            S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
            S: * OK [UIDNEXT 550] Predicted next UID
            S: * OK [HIGHESTMODSEQ 90060128194045007]
            S: * OK [UNSEEN 12] Message 12 is first unseen
            S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
            S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
            \Deleted \Seen \*)] Permanent flags
            S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch

   Modification Sequence and UID Parameters:

   A server that doesn't support the persistent storage of mod-sequences
   for the mailbox MUST send the OK untagged response including the
   NOMODSEQ response code with every successful SELECT or EXAMINE
   command, as described in [CONDSTORE].  Such a server doesn't need to
   remember mod-sequences for expunged messages in the mailbox.  It MUST
   ignore the remaining parameters and behave as if no dynamic message
   data changed.

   If the provided UIDVALIDITY matches that of the selected mailbox, the
   server then checks the last known modification sequence.



Melnikov, et al.            Standards Track                     [Page 5]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   The server sends the client any pending flag changes (using FETCH
   responses that MUST contain UIDs) and expunges those that have
   occurred in this mailbox since the provided modification sequence.

   If the list of known UIDs was also provided, the server should only
   report flag changes and expunges for the specified messages.  If the
   client did not provide the list of UIDs, the server acts as if the
   client has specified "1:<maxuid>", where <maxuid> is the mailbox's
   UIDNEXT value minus 1.  If the mailbox is empty and never had any
   messages in it, then lack of the list of UIDs is interpreted as an
   empty set of UIDs.

   Thus, the client can process just these pending events and need not
   perform a full resynchronization.  Without the message sequence
   number matching information, the result of this step is semantically
   equivalent to the client issuing:
   tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE
   "mod-sequence-value" VANISHED)

   Example:
      C: A03 SELECT INBOX (QRESYNC (67890007
         90060115194045000 41,43:211,214:541))
      S: * OK [CLOSED]
      S: * 314 EXISTS
      S: * 15 RECENT
      S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
      S: * OK [UIDNEXT 567] Predicted next UID
      S: * OK [HIGHESTMODSEQ 90060115205545359]
      S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
      S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
      S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
         \Deleted \Seen \*)] Permanent flags
      S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540
      S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ
         (90060115194045001))
      S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ
         (90060115194045308))