rfc4315.txt

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

Network Working Group                                         M. Crispin
Request for Comments: 4315                                 December 2005
Obsoletes: 2359
Category: Standards Track


      Internet Message Access Protocol (IMAP) - UIDPLUS extension

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.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The UIDPLUS extension of the Internet Message Access Protocol (IMAP)
   provides a set of features intended to reduce the amount of time and
   resources used by some client operations.  The features in UIDPLUS
   are primarily intended for disconnected-use clients.

1.  Introduction and Overview

   The UIDPLUS extension is present in any IMAP server implementation
   that returns "UIDPLUS" as one of the supported capabilities to the
   CAPABILITY command.

   The UIDPLUS extension defines an additional command.  In addition,
   this document recommends new status response codes in IMAP that
   SHOULD be returned by all server implementations, regardless of
   whether or not the UIDPLUS extension is implemented.

   The added facilities of the features in UIDPLUS are optimizations;
   clients can provide equivalent functionality, albeit less
   efficiently, by using facilities in the base protocol.

1.1.  Conventions Used in This Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.





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


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

   A "UID set" is similar to the [IMAP] sequence set; however, the "*"
   value for a sequence number is not permitted.

2.  Additional Commands

   The following command definition is an extension to [IMAP] section
   6.4.

2.1.  UID EXPUNGE Command

   Arguments:  sequence set

   Data:       untagged responses: EXPUNGE

   Result:     OK - expunge completed
               NO - expunge failure (e.g., permission denied)
               BAD - command unknown or arguments invalid

      The UID EXPUNGE command permanently removes all messages that both
      have the \Deleted flag set and have a UID that is included in the
      specified sequence set from the currently selected mailbox.  If a
      message either does not have the \Deleted flag set or has a UID
      that is not included in the specified sequence set, it is not
      affected.

      This command is particularly useful for disconnected use clients.
      By using UID EXPUNGE instead of EXPUNGE when resynchronizing with
      the server, the client can ensure that it does not inadvertantly
      remove any messages that have been marked as \Deleted by other
      clients between the time that the client was last connected and
      the time the client resynchronizes.

      If the server does not support the UIDPLUS capability, the client
      should fall back to using the STORE command to temporarily remove
      the \Deleted flag from messages it does not want to remove, then
      issuing the EXPUNGE command.  Finally, the client should use the
      STORE command to restore the \Deleted flag on the messages in
      which it was temporarily removed.

      Alternatively, the client may fall back to using just the EXPUNGE
      command, risking the unintended removal of some messages.






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


   Example:    C: A003 UID EXPUNGE 3000:3002
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: A003 OK UID EXPUNGE completed

3.  Additional Response Codes

   The following response codes are extensions to the response codes
   defined in [IMAP] section 7.1.  With limited exceptions, discussed
   below, server implementations that advertise the UIDPLUS extension
   SHOULD return these response codes.

   In the case of a mailbox that has permissions set so that the client
   can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the
   server SHOULD NOT send an APPENDUID or COPYUID response code as it
   would disclose information about the mailbox.

   In the case of a mailbox that has UIDNOTSTICKY status (as defined
   below), the server MAY omit the APPENDUID or COPYUID response code as
   it is not meaningful.

   If the server does not return the APPENDUID or COPYUID response
   codes, the client can discover this information by selecting the
   destination mailbox.  The location of messages placed in the
   destination mailbox by COPY or APPEND can be determined by using
   FETCH and/or SEARCH commands (e.g., for Message-ID or some unique
   marker placed in the message in an APPEND).

   APPENDUID

      Followed by the UIDVALIDITY of the destination mailbox and the UID
      assigned to the appended message in the destination mailbox,
      indicates that the message has been appended to the destination
      mailbox with that UID.

      If the server also supports the [MULTIAPPEND] extension, and if
      multiple messages were appended in the APPEND command, then the
      second value is a UID set containing the UIDs assigned to the
      appended messages, in the order they were transmitted in the
      APPEND command.  This UID set may not contain extraneous UIDs or
      the symbol "*".

         Note: the UID set form of the APPENDUID response code MUST NOT
         be used if only a single message was appended.  In particular,
         a server MUST NOT send a range such as 123:123.  This is
         because a client that does not support [MULTIAPPEND] expects
         only a single UID and not a UID set.



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


      UIDs are assigned in strictly ascending order in the mailbox
      (refer to [IMAP], section 2.3.1.1) and UID ranges are as in
      [IMAP]; in particular, note that a range of 12:10 is exactly
      equivalent to 10:12 and refers to the sequence 10,11,12.

      This response code is returned in a tagged OK response to the
      APPEND command.

   COPYUID

      Followed by the UIDVALIDITY of the destination mailbox, a UID set
      containing the UIDs of the message(s) in the source mailbox that
      were copied to the destination mailbox and containing the UIDs
      assigned to the copied message(s) in the destination mailbox,
      indicates that the message(s) have been copied to the destination
      mailbox with the stated UID(s).

      The source UID set is in the order the message(s) were copied; the
      destination UID set corresponds to the source UID set and is in
      the same order.  Neither of the UID sets may contain extraneous
      UIDs or the symbol "*".

      UIDs are assigned in strictly ascending order in the mailbox
      (refer to [IMAP], section 2.3.1.1) and UID ranges are as in
      [IMAP]; in particular, note that a range of 12:10 is exactly
      equivalent to 10:12 and refers to the sequence 10,11,12.

      This response code is returned in a tagged OK response to the COPY
      command.

   UIDNOTSTICKY

      The selected mailbox is supported by a mail store that does not
      support persistent UIDs; that is, UIDVALIDITY will be different
      each time the mailbox is selected.  Consequently, APPEND or COPY
      to this mailbox will not return an APPENDUID or COPYUID response
      code.

      This response code is returned in an untagged NO response to the
      SELECT command.

         Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
         This facility exists to support legacy mail stores in which it
         is technically infeasible to support persistent UIDs.  This
         should be avoided when designing new mail stores.






Crispin                     Standards Track                     [Page 4]