[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
Obsoletes: 2359
Document: internet-drafts/draft-crispin-imap-rfc2359bis-03.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 24 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].

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

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 equivalent 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:  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 from the currently
        selected mailbox all messages that both have the \Deleted flag set
        and have a UID that is included in the specified sequence set.  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 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.  With limited exceptions, discussed
     below, server implementations that advertise the UIDPLUS extension
     SHOULD return these response codes.

     In the case of a mailbox which 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.

        UIDs are assigned strictly ascending 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
        which were copied to the destination mailbox, and a UID 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 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 strictly ascending 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 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 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 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 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.

5.   Formal Syntax

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

     append-uid      = uniqueid

     capability      =/ "UIDPLUS"

     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 "]">]
                       ; which appears in [IMAP]

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

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

     uid-range       = (uniqueid ":" uniqueid)
                       ; two non-equal uniqueid values and all
                       ; values between these two regards of order.
                       ; Example: 2:4 and 4:2 are equivalent.
                       ; These values MUST NOT be equal; e.g. 2:2
                       ; is not permitted.

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

     append-uid      =/ uid-set
                       ; only if multiple messages appended

Security Considerations

     The COPYUID and APPENDUID response codes return information about the
     mailbox.  These response codes SHOULD NOT be issused if the client
     does not have access to SELECT or EXAMINE the mailbox.

IANA Considerations

     This document constitutes registration of the UIDPLUS capability in
     the imap4-capabilities registry, replacing RFC 2359.

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.

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

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

Informative References

     [RFC-2359]    Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June
                   1988.

Acknowledgements

     This document obsoletes [RFC-2359].  However, it is based upon that
     document, and takes substantial text from it.

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/