Network Working Group                                   Arnt Gulbrandsen
Internet-Draft                                                April 2014
Intended Status: Proposed Standard


                       The IMAP UIDONLY Extension
                 draft-gulbrandsen-imap-uidonly-00.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

   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.

   This Internet-Draft expires in October 2014.











Gulbrandsen              Expires September 2014                 [Page 1]

Internet-draft                                                April 2014


Abstract

   Opening a large mailbox in IMAP can take mailbox; 30 seconds is
   realistic if the mailbox contains ten million messages. Most of that
   time is needed to number the messages consecutively.

   This extension provides a way to avoid having to number the messages
   consecutively.


.  Conventions Used in This Document

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

   Formal syntax is defined by [RFC5234].

   Example lines prefaced by "C:" are sent by the client and ones
   prefaced by "S:" by the server. The five characters [...] means that
   something has been elided.


.  Overview

   Some/many clients do not use IMAP MSNs at all, and rely entirely on
   UIDs. Some servers (notably gmail) take a long time to open very
   large mailboxes, since they have to compute an MSN for each message.

   This extension allows a client to declare that it only uses UIDs, and
   that the server can skip all processing related to MSNs.

   A client declares that it wishes to use this extension with the
   command ENABLE UIDONLY.



3.1.  Client requirements

   A client hat has issued ENABLE UIDONLY cannot use MSNs in any
   commands. This means that it MUST NOT use the FETCH, STORE and SEARCH
   commmands, that it MUST NOT use MSNs as search-key in the UID SEARCH
   command, and that it MUST NOT expect to receive an EXISTS response.

   While the client will still receive MSNs, it MUST NOT expect them to
   mean anything. (RFC editor: Remove this parenthesis. It seems to be
   easier to add support for UIDONLY by disregarding parsed MSNs than to
   change both the parser and the layer above, so I chose to leave dummy



Gulbrandsen              Expires September 2014                 [Page 2]

Internet-draft                                                April 2014


   MSNs in.)


3.1.  Server requirements

   These rules apply from the time the server has received an ENABLE
   command that enables UIDONLY until the TCP connection is closed.

   The server MUST send the number 999999999999999 when it needs to send
   an MSN. [RFC Editor: Change 999999999999999 to the number of this
   RFC.]

   The server MUST send the UID data item in all FETCH responses,
   including untagged FETCH responses.

   The server MUST respond with BAD to any command that uses an MSN,
   including a UID SEARCH command that uses MSNs. This search command
   would retrieve the UID of the last message:

      C: a uid search *
      S: a BAD [CLIENTBUG] You promised not to use MSNs

   The following alternative is legal, since in this case the * is a UID
   rather than an MSN:

      C: a uid search uid *
      C: * SEARCH 10240901
      S: a OK done

   The server MUST NOT send EXISTS responses at any time (not even
   during SELECT/EXAMINE processing), and MUST send UIDNEXT when it
   would have sent EXISTS. For example:

      C: a idle
      S: +
      S: * OK [UIDNEXT 10240902] next UID

   The server MUST send VANISHED responses (see [RFC5162], section 3.6)
   where it would ordinarily send EXPUNGED responses. ([RFC5162] defines
   a large extension called Quick Resync, of which VANISHED is a small
   part. Note that neither the server nor the client need support or use
   Quick Resync in general.)



.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur



Gulbrandsen              Expires September 2014                 [Page 3]

Internet-draft                                                April 2014


   Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the
   non-terminal "capability".

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

       capability   =/ "UIDONLY"


.  Security Considerations

   This document is believed not to have any security implications.


.  IANA Considerations

   The IANA is requested to add UIDONLY to the list of IMAP extensions,
   http://www.iana.org/assignments/imap4-capabilities.


.  Acknowledgements

   Thanks to Brandon Long for helpful comments.


. Normative References

   [RFC2119]  Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, Harvard University, March
              1997.

   [RFC3501]  Crispin, "Internet Message Access Protocol - Version
              4rev1", RFC 3501, University of Washington, June 2003.

   [RFC5162]   Melnikov, A. and D. Cridland, "IMAP4 Extensions for Quick
              Mailbox Resynchronization", RFC 5162, March 2008.

   [RFC5234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, January 2008.


. Author's Address

   Arnt Gulbrandsen
   Schweppermannstr. 8
   D-81671 Muenchen



Gulbrandsen              Expires September 2014                 [Page 4]

Internet-draft                                                April 2014


   Germany

   Email: arnt@gulbrandsen.priv.no
















































Gulbrandsen              Expires September 2014                 [Page 5]

Internet-draft                                                April 2014


          (RFC Editor: Please delete everything after this point)


Open Issues

   None.


Changes since -00










































Gulbrandsen              Expires September 2014                 [Page 6]