Network Working Group Arnt GulbrandsenInternet-Draft April 2014Intended Status: Proposed Standard The IMAP UIDONLY Extensiondraft-gulbrandsen-imap-uidonly-00.txtStatus of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions ofBCP 78 andBCP 79. Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 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 athttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html. This Internet-Draft expires in October 2014.Gulbrandsen Expires September 2014 [Page 1]
Internet-draft April 2014Abstract 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.1. 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.2. 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 dummyGulbrandsen 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.)5. Formal Syntax The following syntax specification uses the Augmented Backus-NaurGulbrandsen 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"6. Security Considerations This document is believed not to have any security implications.7. IANA Considerations The IANA is requested to add UIDONLY to the list of IMAP extensions,http://www.iana.org/assignments/imap4-capabilities.8. Acknowledgements Thanks to Brandon Long for helpful comments.9. 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.10. Author's Address Arnt Gulbrandsen Schweppermannstr. 8 D-81671 MuenchenGulbrandsen Expires September 2014 [Page 4]
Internet-draft April 2014 Germany Email: arnt@gulbrandsen.priv.noGulbrandsen Expires September 2014 [Page 5]
Internet-draft April 2014 (RFC Editor: Please delete everything after this point)Open Issues None.Changes since -00Gulbrandsen Expires September 2014 [Page 6] draft-gulbrandsen-imap-uidonly-00
Expired Internet-Draft (individual)
| Document | Document type | Expired Internet-Draft (individual) Expired & archived This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process. | |
|---|---|---|---|
| Select version | |||
| Author | Arnt Gulbrandsen Email authors | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Other formats |