idnits 2.17.1 draft-gulbrandsen-imap-uidonly-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2014) is 3664 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UIDNEXT 10240902' is mentioned on line 119, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 5162 (Obsoleted by RFC 7162) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Arnt Gulbrandsen 3 Internet-Draft April 2014 4 Intended Status: Proposed Standard 6 The IMAP UIDONLY Extension 7 draft-gulbrandsen-imap-uidonly-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Copyright (c) 2014 IETF Trust and the persons identified as the 15 document authors. All rights reserved. 17 This document is subject to BCP 78 and the IETF Trust's Legal 18 Provisions Relating to IETF Documents 19 (http://trustee.ietf.org/license-info) in effect on the date of 20 publication of this document. Please review these documents 21 carefully, as they describe your rights and restrictions with respect 22 to this document. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 36 Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft expires in October 2014. 41 Abstract 43 Opening a large mailbox in IMAP can take mailbox; 30 seconds is 44 realistic if the mailbox contains ten million messages. Most of that 45 time is needed to number the messages consecutively. 47 This extension provides a way to avoid having to number the messages 48 consecutively. 50 1. Conventions Used in This Document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Formal syntax is defined by [RFC5234]. 58 Example lines prefaced by "C:" are sent by the client and ones 59 prefaced by "S:" by the server. The five characters [...] means that 60 something has been elided. 62 2. Overview 64 Some/many clients do not use IMAP MSNs at all, and rely entirely on 65 UIDs. Some servers (notably gmail) take a long time to open very 66 large mailboxes, since they have to compute an MSN for each message. 68 This extension allows a client to declare that it only uses UIDs, and 69 that the server can skip all processing related to MSNs. 71 A client declares that it wishes to use this extension with the 72 command ENABLE UIDONLY. 74 3.1. Client requirements 76 A client hat has issued ENABLE UIDONLY cannot use MSNs in any 77 commands. This means that it MUST NOT use the FETCH, STORE and SEARCH 78 commmands, that it MUST NOT use MSNs as search-key in the UID SEARCH 79 command, and that it MUST NOT expect to receive an EXISTS response. 81 While the client will still receive MSNs, it MUST NOT expect them to 82 mean anything. (RFC editor: Remove this parenthesis. It seems to be 83 easier to add support for UIDONLY by disregarding parsed MSNs than to 84 change both the parser and the layer above, so I chose to leave dummy 85 MSNs in.) 87 3.1. Server requirements 89 These rules apply from the time the server has received an ENABLE 90 command that enables UIDONLY until the TCP connection is closed. 92 The server MUST send the number 999999999999999 when it needs to send 93 an MSN. [RFC Editor: Change 999999999999999 to the number of this 94 RFC.] 96 The server MUST send the UID data item in all FETCH responses, 97 including untagged FETCH responses. 99 The server MUST respond with BAD to any command that uses an MSN, 100 including a UID SEARCH command that uses MSNs. This search command 101 would retrieve the UID of the last message: 103 C: a uid search * 104 S: a BAD [CLIENTBUG] You promised not to use MSNs 106 The following alternative is legal, since in this case the * is a UID 107 rather than an MSN: 109 C: a uid search uid * 110 C: * SEARCH 10240901 111 S: a OK done 113 The server MUST NOT send EXISTS responses at any time (not even 114 during SELECT/EXAMINE processing), and MUST send UIDNEXT when it 115 would have sent EXISTS. For example: 117 C: a idle 118 S: + 119 S: * OK [UIDNEXT 10240902] next UID 121 The server MUST send VANISHED responses (see [RFC5162], section 3.6) 122 where it would ordinarily send EXPUNGED responses. ([RFC5162] defines 123 a large extension called Quick Resync, of which VANISHED is a small 124 part. Note that neither the server nor the client need support or use 125 Quick Resync in general.) 127 5. Formal Syntax 129 The following syntax specification uses the Augmented Backus-Naur 130 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the 131 non-terminal "capability". 133 Except as noted otherwise, all alphabetic characters are case- 134 insensitive. The use of upper or lower case characters to define 135 token strings is for editorial clarity only. Implementations MUST 136 accept these strings in a case-insensitive fashion. 138 capability =/ "UIDONLY" 140 6. Security Considerations 142 This document is believed not to have any security implications. 144 7. IANA Considerations 146 The IANA is requested to add UIDONLY to the list of IMAP extensions, 147 http://www.iana.org/assignments/imap4-capabilities. 149 8. Acknowledgements 151 Thanks to Brandon Long for helpful comments. 153 9. Normative References 155 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 156 Requirement Levels", RFC 2119, Harvard University, March 157 1997. 159 [RFC3501] Crispin, "Internet Message Access Protocol - Version 160 4rev1", RFC 3501, University of Washington, June 2003. 162 [RFC5162] Melnikov, A. and D. Cridland, "IMAP4 Extensions for Quick 163 Mailbox Resynchronization", RFC 5162, March 2008. 165 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 166 Specifications: ABNF", RFC 5234, January 2008. 168 10. Author's Address 170 Arnt Gulbrandsen 171 Schweppermannstr. 8 172 D-81671 Muenchen 173 Germany 175 Email: arnt@gulbrandsen.priv.no 176 (RFC Editor: Please delete everything after this point) 178 Open Issues 180 None. 182 Changes since -00