[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2359) 00 01 02 03 04 RFC 4315

Network Working Group                                         M. Crispin
INTERNET DRAFT: IMAP UIDPLUS extension                          May 2005
Document: internet-drafts/draft-crispin-imap-rfc2359bis-00.txt


         Internet Message Access Protocol (IMAP) - UIDPLUS extension

Status of this Memo

       By submitting this Internet-Draft, each author represents that
       any applicable patent or other IPR claims of which he or she is
       aware have been or will be disclosed, and any of which he or she
       becomes aware will be disclosed, in accordance with Section 6 of
       BCP 79.

       Internet-Drafts are working documents of the Internet Engineering
       Task Force (IETF), its areas, and its working groups.  Note that
       other groups may also distribute working documents as
       Internet-Drafts.

       Internet-Drafts are draft documents valid for a maximum of six months
       and may be updated, replaced, or obsoleted by other documents at any
       time.  It is inappropriate to use Internet-Drafts as reference
       material or to cite them other than as "work in progress."

       The list of current Internet-Drafts can be accessed at
       http://www.ietf.org/ietf/1id-abstracts.txt

       The list of Internet-Draft Shadow Directories can be accessed at
       http://www.ietf.org/shadow.html

       A revised version of this document will be submitted to the RFC
       editor as an Informational Document for the Internet Community.

       A revised version of this draft document will be submitted to the RFC
       editor as a Proposed Standard for the Internet Community.  Discussion
       and suggestions for improvement are requested, and should be sent to
       imapext@IMC.ORG.  This document will expire before 18 November 2005.
       Distribution of this memo is unlimited.

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.

Conventions Used in this Document

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

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

Introduction and Overview

       The UIDPLUS extension is present in any IMAP server implementation
       which 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 which
       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 the same functionality, albeit less efficiently,
       by using facilities in the base protocol.

1. Additional Commands

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

1.1 UID EXPUNGE Command

       Arguments:  message 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 from the currently
          selected mailbox all messages that both have the \Deleted flag set
          and have a UID that is included in the specified message set.  If
          a message either does not have the \Deleted flag set or is has a
          UID that is not included in the specified message set, it is not
          affected.

          This command may be used to ensure that a replayed EXPUNGE command
          does not remove any messages that have been marked as \Deleted
          between the time that the user requested the expunge operation and
          the time the server processes the command.

          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.  The
          client could alternatively fall back to using the EXPUNGE command,
          risking the unintended removal of some messages.

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

2. Additional Response Codes

       The following response codes are extensions to the response codes
       defined in [IMAP] section 7.1.  [IMAP] server implementations
       SHOULD return these response codes.

       A server which supports the UIDPLUS capability MUST return the
       APPENDUID or COPYUID response code as part of the tagged OK response
       to an APPEND or COPY command.  The exception is if the destination
       mailbox that has UIDNOTSTICKY status; in that case, the server MAY
       omit the APPENDUID or COPYUID response as it is not meaningful.

       If the server does not return these 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.
       A server can determine that a mailbox does not support persistent
       UIDs by observing that the UIDVALIDITY changes with multiple selects
       of the mailbox.

       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, then the
          second value is a message set containing the UIDs assigned to the
          appended messages, in the order they were assigned.  This message
          set may not contain extraneous UIDs or the symbol "*".

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

       COPYUID

          Followed by the UIDVALIDITY of the destination mailbox, a message
          set containing the UIDs of the message(s) in the source mailbox
          which were copied to the destination mailbox, and a message set
          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 message set is in the order the message(s) were copied;
          the destination message set corresponds to the source message set
          and is in the order the UID(s) were assigned.  Neither of the
          message sets may contain extraneous UIDs or the symbol "*".

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

       UIDNOTSTICKY

          The selected mailbox is supported by a mail store which 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 persistant UIDs.
             This should be avoided when designing new mail stores.

       Example:    C: A003 APPEND saved-messages (\Seen) {297}
                   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
                   C: From: Fred Foobar <foobar@example.com>
                   C: Subject: afternoon meeting
                   C: To: mooch@example.com
                   C: Message-Id: <B27397-0100000@example.com>
                   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 for this session
                   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 which 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 305 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.

5.   Formal Syntax

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

       The following modifications are made to the Formal Syntax in [IMAP]:

       resp_code_apnd  = "APPENDUID" SP nz_number SP append-uid

       append-uid      = uniqueid

       resp_code_copy  = "COPYUID" SP nz_number SP uid-set SP uid-set

       uid_expunge     = "UID" SP "EXPUNGE" SP sequence-set

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

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

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

       append-uid      =/ uid-set

Normative References

       [ABNF]        Crocker, D. and P. Overell, "Augmented BNF for Syntax
                     Specifications: ABNF", RFC 2234, November 1997.

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

       [RFC-2822]    Resnick, P., "Internet Message Format", RFC 2822, April
                     2001.

Informative References

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


7.   Security Considerations

       There are no known security issues with this extension.

Author's Address

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

       Phone: (206) 543-5762
       EMail: MRC@CAC.Washington.EDU


IPR Disclosure Acknowledgement

       By submitting this Internet-Draft, I certify that any applicable
       patent or other IPR claims of which I am aware have been disclosed,
       and any of which I become aware will be disclosed, in accordance with
       RFC 3668.


Intellectual Property Statement

       The IETF takes no position regarding the validity or scope of any
       intellectual property 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; neither does it represent that it
       has made any effort to identify any such rights. Information on the
       IETF's procedures with respect to rights in standards-track and
       standards-related documentation can be found in BCP-11. Copies of
       claims of rights made available for publication 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 implementors or users of this specification can
       be obtained from the IETF Secretariat.

       The IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights which may cover technology that may be required to practice
       this standard. Please address the information to the IETF Executive
       Director.


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-
       ipr@ietf.org.


Acknowledgement

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


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/