rfc4549.txt

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

Network Working Group                                   A. Melnikov, Ed.
Request for Comments: 4549                                    Isode Ltd.
Category: Informational                                        June 2006


       Synchronization Operations for Disconnected IMAP4 Clients

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document attempts to address some of the issues involved in
   building a disconnected IMAP4 client.  In particular, it deals with
   the issues of what might be called the "driver" portion of the
   synchronization tool: the portion of the code responsible for issuing
   the correct set of IMAP4 commands to synchronize the disconnected
   client in the way that is most likely to make the human who uses the
   disconnected client happy.

   This note describes different strategies that can be used by
   disconnected clients and shows how to use IMAP protocol in order to
   minimize the time of the synchronization process.

   This note also lists IMAP extensions that a server should implement
   in order to provide better synchronization facilities to disconnected
   clients.

















Melnikov                     Informational                      [Page 1]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Design Principles ...............................................3
   3. Overall Picture of Synchronization ..............................4
   4. Mailbox Synchronization Steps and Strategies ....................7
      4.1. Checking UID Validity ......................................7
      4.2. Synchronizing Local Changes with the Server ................8
           4.2.1. Uploading Messages to the Mailbox ...................8
           4.2.2. Optimizing "move" and "copy" Operations .............9
           4.2.3. Replaying Local Flag Changes .......................14
           4.2.4. Processing Mailbox Compression (EXPUNGE) Requests ..15
           4.2.5. Closing a Mailbox ..................................17
      4.3. Details of "Normal" Synchronization of a Single Mailbox ...18
           4.3.1. Discovering New Messages and Changes to Old
                  Messages ...........................................18
           4.3.2. Searching for "Interesting" Messages. ..............20
           4.3.3. Populating Cache with "Interesting" Messages. ......21
           4.3.4. User-Initiated Synchronization .....................22
      4.4. Special Case: Descriptor-Only Synchronization .............22
      4.5. Special Case: Fast New-Only Synchronization ...............23
      4.6. Special Case: Blind FETCH .................................23
   5. Implementation Considerations ..................................24
      5.1. Error Recovery during Playback ............................26
      5.2. Quality of Implementation Issues ..........................28
      5.3. Optimizations .............................................28
   6. IMAP Extensions That May Help ..................................30
      6.1. CONDSTORE Extension .......................................30
   7. Security Considerations ........................................33
   8. References .....................................................33
      8.1. Normative References ......................................33
      8.2. Informative References ....................................34
   9. Acknowledgements ...............................................34

















Melnikov                     Informational                      [Page 2]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


1.  Introduction

   Several recommendations presented in this document are generally
   applicable to all types of IMAP clients.  However, this document
   tries to concentrate on disconnected mail clients [IMAP-MODEL].  It
   also suggests some IMAP extensions* that should be implemented by
   IMAP servers in order to make the life of disconnected clients
   easier.  In particular, the [UIDPLUS] extension was specifically
   designed to streamline certain disconnected operations, like
   expunging, uploading, and copying messages (see Sections 4.2.1,
   4.2.2.1, and 4.2.4).

   Readers of this document are also strongly advised to read RFC 2683
   [RFC2683].

   * Note that the functionality provided by the base IMAP protocol
     [IMAP4] is sufficient to perform basic synchronization.

1.1.  Conventions Used in This Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.  Long lines in examples are broken for
   editorial clarity.

   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 RFC 2119 [KEYWORDS].

   Let's call an IMAP command idempotent if the result of executing the
   command twice sequentially is the same as the result of executing the
   command just once.

2.  Design Principles

   All mailbox state or content information stored on the disconnected
   client should be viewed strictly as a cache of the state of the
   server.  The "master" state remains on the server, just as it would
   with an interactive IMAP4 client.  The one exception to this rule is
   that information about the state of the disconnected client's cache
   (the state includes flag changes while offline and during scheduled
   message uploads) remains on the disconnected client: that is, the
   IMAP4 server is not responsible for remembering the state of the
   disconnected IMAP4 client.

   We assume that a disconnected client is a client that, for whatever
   reason, wants to minimize the length of time that it is "on the
   phone" to the IMAP4 server.  Often this will be because the client is
   using a dialup connection, possibly with very low bandwidth, but



Melnikov                     Informational                      [Page 3]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   sometimes it might just be that the human is in a hurry to catch an
   airplane, or some other event beyond our control.  Whatever the
   reason, we assume that we must make efficient use of the network
   connection, both in the usual sense (not generating spurious traffic)
   and in the sense that we would prefer not to have the connection
   sitting idle while the client and/or the server is performing
   strictly local computation or I/O.  Another, perhaps simpler way of
   stating this is that we assume that network connections are
   "expensive".

   Practical experience with disconnected mail systems has shown that
   there is no single synchronization strategy that is appropriate for
   all cases.  Different humans have different preferences, and the same
   human's preference will vary depending both on external circumstance
   (how much of a hurry the human is in today) and on the value that the
   human places on the messages being transferred.  The point here is
   that there is no way that the synchronization program can guess
   exactly what the human wants to do, so the human will have to provide
   some guidance.

   Taken together, the preceding two principles lead to the conclusion
   that the synchronization program must make its decisions based on
   some kind of guidance provided by the human, by selecting the
   appropriate options in the user interface or through some sort of
   configuration file.  Almost certainly, it should not pause for I/O
   with the human in the middle of the synchronization process.  The
   human will almost certainly have several different configurations for
   the synchronization program, for different circumstances.

   Since a disconnected client has no way of knowing what changes might
   have occurred to the mailbox while it was disconnected, message
   numbers are not useful to a disconnected client.  All disconnected
   client operations should be performed using UIDs, so that the client
   can be sure that it and the server are talking about the same
   messages during the synchronization process.

3.  Overall Picture of Synchronization

   The basic strategy for synchronization is outlined below.  Note that
   the real strategy may vary from one application to another or may
   depend on a synchronization mode.

   a) Process any "actions" that were pending on the client that were
      not associated with any mailbox.  (In particular sending messages
      composed offline with SMTP.  This is not part of IMAP
      synchronization, but it is mentioned here for completeness.)





Melnikov                     Informational                      [Page 4]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   b) Fetch the current list of "interesting" mailboxes.  (The
      disconnected client should allow the user to skip this step
      completely.)

   c) "Client-to-server synchronization": for each IMAP "action" that
      was pending on the client, do the following:

      1) If the action implies opening a new mailbox (any operation that
         operates on messages), open the mailbox.  Check its UID
         validity value (see Section 4.1 for more details) returned in
         the UIDVALIDITY response code.  If the UIDVALIDITY value
         returned by the server differs, the client MUST empty the local
         cache of the mailbox and remove any pending "actions" that
         refer to UIDs in that mailbox (and consider them failed).  Note
         that this doesn't affect actions performed on client-generated
         fake UIDs (see Section 5).

      2) Perform the action.  If the action is to delete a mailbox
         (DELETE), make sure that the mailbox is closed first (see also
         Section 3.4.12 of [RFC2683]).

   d) "Server-to-client synchronization": for each mailbox that requires
      synchronization, do the following:

      1) Check the mailbox UIDVALIDITY (see Section 4.1 for more
         details) with SELECT/EXAMINE/STATUS.

         If UIDVALIDITY value returned by the server differs, the client
         MUST

         * empty the local cache of that mailbox;
         * remove any pending "actions" that refer to UIDs in that
           mailbox and consider them failed; and
         * skip step 2-II.

      2) Fetch the current "descriptors";

         I)  Discover new messages.

         II) Discover changes to old messages.

      3) Fetch the bodies of any "interesting" messages that the client
         doesn't already have.

   e) Close all open mailboxes not required for further operations (if
      staying online) or disconnect all open connections (if going
      offline).




Melnikov                     Informational                      [Page 5]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   Terms used:

   "Actions" are queued requests that were made by the human to the
   client's Mail User Agent (MUA) software while the client was
   disconnected.

   We define "descriptors" as a set of IMAP4 FETCH data items.
   Conceptually, a message's descriptor is that set of information that
   allows the synchronization program to decide what protocol actions
   are necessary to bring the local cache to the desired state for this
   message; since this decision is really up to the human, this
   information probably includes at least a few header fields intended
   for human consumption.  Exactly what will constitute a descriptor
   depends on the client implementation.  At a minimum, the descriptor
   contains the message's UID and FLAGS.  Other likely candidates are
   the RFC822.SIZE, RFC822.HEADER, BODYSTRUCTURE, or ENVELOPE data
   items.

   Comments:

   1) The list of actions should be ordered.  For example, if the human
      deletes message A1 in mailbox A, then expunges mailbox A, and then
      deletes message A2 in mailbox A, the human will expect that
      message A1 is gone and that message A2 is still present but is now
      deleted.

      By processing all the actions before proceeding with
      synchronization, we avoid having to compensate for the local MUA's
      changes to the server's state.  That is, once we have processed
      all the pending actions, the steps that the client must take to
      synchronize itself will be the same no matter where the changes to
      the server's state originated.

   2) Steps a and b can be performed in parallel.  Alternatively, step a
      can be performed after d.

   3) On step b, the set of "interesting" mailboxes pretty much has to
      be determined by the human.  What mailboxes belong to this set may
      vary between different IMAP4 sessions with the same server,
      client, and human.  An interesting mailbox can be a mailbox
      returned by LSUB command (see Section 6.3.9 of [IMAP4]).  The
      special mailbox "INBOX" SHOULD be in the default set of mailboxes
      that the client considers interesting.  However, providing the
      ability to ignore INBOX for a particular session or client may be
      valuable for some mail filtering strategies.