rfc4551.txt

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

   fetch-att           =/ fetch-mod-sequence
                          ;; modifies original IMAP4 fetch-att

   fetch-mod-sequence  = "MODSEQ"

   fetch-mod-resp      = "MODSEQ" SP "(" permsg-modsequence ")"

   msg-att-dynamic     =/ fetch-mod-resp



Melnikov & Hole             Standards Track                    [Page 19]

RFC 4551          IMAP Extension for Conditional STORE         June 2006


   search-key          =/ search-modsequence
                          ;; modifies original IMAP4 search-key
                          ;;
                          ;; This change applies to all commands
                          ;; referencing this non-terminal, in
                          ;; particular SEARCH.

   search-modsequence  = "MODSEQ" [search-modseq-ext] SP
                         mod-sequence-valzer

   search-modseq-ext   = SP entry-name SP entry-type-req

   resp-text-code      =/ "HIGHESTMODSEQ" SP mod-sequence-value /
                          "NOMODSEQ" /
                          "MODIFIED" SP set

   entry-name          = entry-flag-name

   entry-flag-name     = DQUOTE "/flags/" attr-flag DQUOTE
                          ;; each system or user defined flag <flag>
                          ;; is mapped to "/flags/<flag>".
                          ;;
                          ;; <entry-flag-name> follows the escape rules
                          ;; used by "quoted" string as described in
                          ;; Section 4.3 of [IMAP4], e.g., for the flag
                          ;; \Seen the corresponding <entry-name> is
                          ;; "/flags/\\seen", and for the flag
                          ;; $MDNSent, the corresponding <entry-name>
                          ;; is "/flags/$mdnsent".

   entry-type-resp     = "priv" / "shared"
                          ;; metadata item type

   entry-type-req      = entry-type-resp / "all"
                          ;; perform SEARCH operation on private
                          ;; metadata item, shared metadata item or both

   permsg-modsequence  = mod-sequence-value
                          ;; per message mod-sequence

   mod-sequence-value  = 1*DIGIT
                          ;; Positive unsigned 64-bit integer
                          ;; (mod-sequence)
                          ;; (1 <= n < 18,446,744,073,709,551,615)

   mod-sequence-valzer = "0" / mod-sequence-value

   search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")"



Melnikov & Hole             Standards Track                    [Page 20]

RFC 4551          IMAP Extension for Conditional STORE         June 2006


   select-param        =/ condstore-param
                          ;; conforms to the generic "select-param"
                          ;; non-terminal syntax defined in [IMAPABNF].

   condstore-param     = "CONDSTORE"

   mailbox-data        =/ "SEARCH" [1*(SP nz-number) SP
                          search-sort-mod-seq]

   attr-flag           = "\\Answered" / "\\Flagged" / "\\Deleted" /
                         "\\Seen" / "\\Draft" / attr-flag-keyword /
                         attr-flag-extension
                          ;; Does not include "\\Recent"

   attr-flag-extension = "\\" atom
                          ;; Future expansion.  Client implementations
                          ;; MUST accept flag-extension flags.  Server
                          ;; implementations MUST NOT generate
                          ;; flag-extension flags except as defined by
                          ;; future standard or standards-track
                          ;; revisions of [IMAP4].

   attr-flag-keyword   = atom

5.  Server Implementation Considerations

   This section describes how a server implementation that doesn't store
   separate per-metadata mod-sequences for different metadata items can
   avoid sending the MODIFIED response to any of the following
   conditional STORE operations:

      +FLAGS
      -FLAGS
      +FLAGS.SILENT
      -FLAGS.SILENT

   Note that the optimization described in this section can't be
   performed in case of a conditional STORE FLAGS operation.

   Let's use the following example.  The client has issued

      C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
         +FLAGS.SILENT ($Processed)

   When the server receives the command and parses it successfully, it
   iterates through the message set and tries to execute the conditional
   STORE command for each message.




Melnikov & Hole             Standards Track                    [Page 21]

RFC 4551          IMAP Extension for Conditional STORE         June 2006


   Each server internally works as a client, i.e., it has to cache the
   current state of all IMAP flags as it is known to the client.  In
   order to report flag changes to the client, the server compares the
   cached values with the values in its database for IMAP flags.

   Imagine that another client has changed the state of a flag \Deleted
   on the message 101 and that the change updated the mod-sequence for
   the message.  The server knows that the mod-sequence for the mailbox
   has changed; however, it also knows that:

   a) the client is not interested in \Deleted flag, as it hasn't
      included it in +FLAGS.SILENT operation; and

   b) the state of the flag $Processed hasn't changed (the server can
      determine this by comparing cached flag state with the state of
      the flag in the database).

   Therefore, the server doesn't have to report MODIFIED to the client.
   Instead, the server may set $Processed flag, update the mod-sequence
   for the message 101 once again and send an untagged FETCH response
   with new mod-sequence and flags:

      S: * 101 FETCH (MODSEQ (303011130956)
         FLAGS ($Processed \Deleted \Answered))

   See also Section 3.8 for additional quality-of-implementation issues.

6.  Security Considerations

   It is believed that the Conditional STORE extension doesn't raise any
   new security concerns that are not already discussed in [IMAP4].
   However, the availability of this extension may make it possible for
   IMAP4 to be used in critical applications it could not be used for
   previously, making correct IMAP server implementation and operation
   even more important.

7.  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 CONDSTORE IMAP capability.  IANA has added
   it to the registry accordingly.





Melnikov & Hole             Standards Track                    [Page 22]

RFC 4551          IMAP Extension for Conditional STORE         June 2006


8.  References

8.1.  Normative References

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

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

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

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

8.2.  Informative References

   [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
              Configuration Access Protocol", RFC 2244, November 1997.

   [ACL]      Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
              RFC 4314, December 2005.

   [ANN]      Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
              in Progress, March 2006.

   [NTP]      Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation and Analysis", RFC 1305,
              March 1992.

   [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
              2180, July 1997.

9.  Acknowledgements

   Some text was borrowed from "IMAP ANNOTATE Extension" [ANN] by
   Randall Gellens and Cyrus Daboo and from "ACAP -- Application
   Configuration Access Protocol" [ACAP] by Chris Newman and John Myers.

   Many thanks to Randall Gellens for his thorough review of the
   document.

   The authors also acknowledge the feedback provided by Cyrus Daboo,
   Larry Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen,
   Timo Sirainen, Mark Crispin, Ned Freed, Ken Murchison, and Dave
   Cridland.




Melnikov & Hole             Standards Track                    [Page 23]

RFC 4551          IMAP Extension for Conditional STORE         June 2006


Authors' Addresses

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex
   TW12 2BX,
   United Kingdom

   EMail: [e-mail]


   Steve Hole
   ACI WorldWide/MessagingDirect
   #1807, 10088 102 Ave
   Edmonton, AB
   T5J 2Z1
   Canada

   EMail: [e-mail]






























Melnikov & Hole             Standards Track                    [Page 24]

RFC 4551          IMAP Extension for Conditional STORE         June 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Melnikov & Hole             Standards Track                    [Page 25]