rfc5162.txt

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

   returned by the server and the server also returns the HIGHESTMODSEQ
   response code, then the server reports expunged messages and returns
   flag changes for all messages specified by the client in the UID set
   parameter (or for all messages in the mailbox, if the client omitted
   the UID set parameter).  At this point, the client is synchronized,
   except for maybe the new messages.

   If upon a successful SELECT/EXAMINE (QRESYNC) command the client
   receives a NOMODSEQ OK untagged response (instead of the
   HIGHESTMODSEQ response code), it MUST remove the last known
   HIGHESTMODSEQ value from its cache and follow the more general
   instructions in Section 3 of the [IMAP-DISC].

   At this point, the client is in sync with the server regarding old
   messages.  This client can now fetch information about new messages
   (if requested by the user).

   Step d) ("Server-to-client synchronization") in Section 4 of the
   [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is
   amended as follows:

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

   1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC]
       for more details) after issuing SELECT/EXAMINE (QRESYNC) command.

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

       *   empty the local cache of that mailbox;

       *   "forget" the cached HIGHESTMODSEQ value for the mailbox;







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


       *   remove any pending "actions" which refer to UIDs in that
           mailbox.  Note, this doesn't affect actions performed on
           client generated fake UIDs (see Section 5 of the
           [IMAP-DISC]);

   2)  Fetch the current "descriptors";

       I) Discover new messages.

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

   Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ
            value has changed on the server while the client was
            offline:

    C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198))
    S: * 172 EXISTS
    S: * 1 RECENT
    S: * OK [UNSEEN 12] Message 12 is first unseen
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: * OK [UIDNEXT 201] Predicted next UID
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
    S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
    S: * OK [HIGHESTMODSEQ 20010715194045007]
    S: * VANISHED (EARLIER) 1:5,7:8,10:15
    S: * 2 FETCH (UID 6 MODSEQ (20010715205008000)
        FLAGS (\Deleted))
    S: * 5 FETCH (UID 9 MODSEQ (20010715195517000)
        FLAGS ($NoJunk $AutoJunk $MDNSent))
       ...
    S: A142 OK [READ-WRITE] SELECT completed

6.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [ABNF].

   Non-terminals referenced but not defined below are as defined by
   [RFC3501], [CONDSTORE], or [IMAPABNF].

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.






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


   capability          =/ "QRESYNC"

   select-param        =  "QRESYNC" SP "(" uidvalidity SP
                       mod-sequence-value [SP known-uids]
                       [SP seq-match-data] ")"
                       ;; conforms to the generic select-param
                       ;; syntax defined in [IMAPABNF]

   seq-match-data      =  "(" known-sequence-set SP known-uid-set ")"

   uidvalidity         =  nz-number

   known-uids          =  sequence-set
                       ;; sequence of UIDs, "*" is not allowed

   known-sequence-set  =  sequence-set
                       ;; set of message numbers corresponding to
                       ;; the UIDs in known-uid-set, in ascending order.
                       ;; * is not allowed.

   known-uid-set       =  sequence-set
                       ;; set of UIDs corresponding to the messages in
                       ;; known-sequence-set, in ascending order.
                       ;; * is not allowed.

   message-data        =/ expunged-resp

   expunged-resp       =  "VANISHED" [SP "(EARLIER)"] SP known-uids

   rexpunges-fetch-mod =  "VANISHED"
                       ;; VANISHED UID FETCH modifier conforms
                       ;; to the fetch-modifier syntax
                       ;; defined in [IMAPABNF].  It is only
                       ;; allowed in the UID FETCH command.

   resp-text-code      =/ "CLOSED"

7.  Security Considerations

   As always, it is important to thoroughly test clients and servers
   implementing this extension, as it changes how the server reports
   expunged messages to the client.

   Security considerations relevant to [CONDSTORE] are relevant to this
   extension.

   This document doesn't raise any new security concerns not already
   raised by [CONDSTORE] or [RFC3501].



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


8.  IANA Considerations

   IMAP4 capabilities are registered by publishing a standards track or
   IESG approved experimental RFC.  The registry is currently located
   at:

      http://www.iana.org/assignments/imap4-capabilities

   This document defines the QRESYNC IMAP capability.  IANA has added
   this capability to the registry.

9.  Acknowledgments

   Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging
   creation of this document.

   Valuable comments, both in agreement and in dissent, were received
   from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen,
   Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp,
   Eric Rescorla, and Mike Zraly.

   This document takes substantial text from [RFC3501] by Mark Crispin.

10.  References

10.1.  Normative References

   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [CONDSTORE]  Melnikov, A. and S. Hole, "IMAP Extension for
                Conditional STORE Operation or Quick Flag Changes
                Resynchronization", RFC 4551, June 2006.

   [ENABLE]     Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
                ENABLE Extension", RFC 5161, March 2008.

   [IMAPABNF]   Melnikov, A. and C. Daboo, "Collected Extensions to
                IMAP4 ABNF", RFC 4466, April 2006.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3501]    Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
                4rev1", RFC 3501, March 2003.

   [UIDPLUS]    Crispin, M., "Internet Message Access Protocol (IMAP) -
                UIDPLUS extension", RFC 4315, December 2005.



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


10.2.  Informative References

   [IMAP-DISC]  Melnikov, A., Ed., "Synchronization Operations For
                Disconnected Imap4 Clients", RFC 4549, June 2006.

   [UNSELECT]   Melnikov, A., "Internet Message Access Protocol (IMAP)
                UNSELECT command", RFC 3691, February 2004.

Authors' Addresses

   Alexey Melnikov
   Isode Ltd
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   EMail: [e-mail]


   Dave Cridland
   Isode Ltd
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   EMail: [e-mail]


   Corby Wilson
   Nokia
   5 Wayside Rd.
   Burlington, MA  01803
   USA

   EMail: [e-mail]














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


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].












Melnikov, et al.            Standards Track                    [Page 23]