rfc4315.txt

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


RFC 4315                IMAP - UIDPLUS Extension           December 2005


   Example:    C: A003 APPEND saved-messages (\Seen) {297}
               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
               C: From: Fred Foobar <[e-mail]>
               C: Subject: afternoon meeting
               C: To: [e-mail]
               C: Message-Id: <[e-mail]>
               C: MIME-Version: 1.0
               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
               C:
               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
               C:
               S: A003 OK [APPENDUID 38505 3955] APPEND completed
               C: A004 COPY 2:4 meeting
               S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
               C: A005 UID COPY 305:310 meeting
               S: A005 OK No matching messages, so nothing copied
               C: A006 COPY 2 funny
               S: A006 OK Done
               C: A007 SELECT funny
               S: * 1 EXISTS
               S: * 1 RECENT
               S: * OK [UNSEEN 1] Message 1 is first unseen
               S: * OK [UIDVALIDITY 3857529045] Validity session-only
               S: * OK [UIDNEXT 2] Predicted next UID
               S: * NO [UIDNOTSTICKY] Non-persistent UIDs
               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
               S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
               S: A007 OK [READ-WRITE] SELECT completed

   In this example, A003 and A004 demonstrate successful appending and
   copying to a mailbox that returns the UIDs assigned to the messages.
   A005 is an example in which no messages were copied; this is because
   in A003, we see that message 2 had UID 304, and message 3 had UID
   319; therefore, UIDs 305 through 310 do not exist (refer to section
   2.3.1.1 of [IMAP] for further explanation).  A006 is an example of a
   message being copied that did not return a COPYUID; and, as expected,
   A007 shows that the mail store containing that mailbox does not
   support persistent UIDs.

4.  Formal Syntax

   Formal syntax is defined using ABNF [ABNF], which extends the ABNF
   rules defined in [IMAP].  The IMAP4 ABNF should be imported before
   attempting to validate these rules.

   append-uid      = uniqueid

   capability      =/ "UIDPLUS"



Crispin                     Standards Track                     [Page 5]

RFC 4315                IMAP - UIDPLUS Extension           December 2005


   command-select  =/ uid-expunge

   resp-code-apnd  = "APPENDUID" SP nz-number SP append-uid

   resp-code-copy  = "COPYUID" SP nz-number SP uid-set SP uid-set

   resp-text-code  =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"
                     ; incorporated before the expansion rule of
                     ;  atom [SP 1*<any TEXT-CHAR except "]">]
                     ; that appears in [IMAP]

   uid-expunge     = "UID" SP "EXPUNGE" SP sequence-set

   uid-set         = (uniqueid / uid-range) *("," uid-set)

   uid-range       = (uniqueid ":" uniqueid)
                     ; two uniqueid values and all values
                     ; between these two regards of order.
                     ; Example: 2:4 and 4:2 are equivalent.

   Servers that support [MULTIAPPEND] will have the following extension
   to the above rules:

   append-uid      =/ uid-set
                     ; only permitted if client uses [MULTIAPPEND]
                     ; to append multiple messages.

5.  Security Considerations

   The COPYUID and APPENDUID response codes return information about the
   mailbox, which may be considered sensitive if the mailbox has
   permissions set that permit the client to COPY or APPEND to the
   mailbox, but not SELECT or EXAMINE it.

   Consequently, these response codes SHOULD NOT be issued if the client
   does not have access to SELECT or EXAMINE the mailbox.

6.  IANA Considerations

   This document constitutes registration of the UIDPLUS capability in
   the imap4-capabilities registry, replacing [RFC2359].

7.  Normative References

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





Crispin                     Standards Track                     [Page 6]

RFC 4315                IMAP - UIDPLUS Extension           December 2005


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

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

   [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
                 MULTIAPPEND Extension", RFC 3502, March 2003.

8.  Informative References

   [RFC2359]     Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June
                 1998.

9.  Changes from RFC 2359

   This document obsoletes [RFC2359].  However, it is based upon that
   document, and takes substantial text from it (albeit with numerous
   clarifications in wording).

   [RFC2359] implied that a server must always return COPYUID/APPENDUID
   data; thus suggesting that in such cases the server should return
   arbitrary data if the destination mailbox did not support persistent
   UIDs.  This document adds the UIDNOTSTICKY response code to indicate
   that a mailbox does not support persistent UIDs, and stipulates that
   a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY
   (or APPEND) destination mailbox has UIDNOTSTICKY status.

Author's Address

   Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Avenue NE
   Seattle, WA  98105-4527

   Phone: [phone]
   EMail: [e-mail]













Crispin                     Standards Track                     [Page 7]

RFC 4315                IMAP - UIDPLUS Extension           December 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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 ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Crispin                     Standards Track                     [Page 8]