idnits 2.17.00 (12 Aug 2021) /tmp/idnits10252/draft-melnikov-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (16 February 2022) is 87 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) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode 4 Intended status: Standards Track A. P. Achuthan 5 Expires: 20 August 2022 V. Nagulakonda 6 A. Singh 7 Yahoo! 8 L. Alves 9 16 February 2022 11 IMAP Extension for only using and returning UIDs 12 draft-melnikov-imap-uidonly-00 14 Abstract 16 The UIDONLY extension of the Internet Message Access Protocol (RFC 17 3501/RFC 9051) allows clients to request that all information about 18 mailbox changes is returned only using UIDs. Message numbers are not 19 going to be returned and can't be used once this extension is 20 enabled. This helps both clients and servers to reduce resource 21 usage required for maintenance of message number to UID map. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 20 August 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 69 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 70 3. The UIDONLY extension . . . . . . . . . . . . . . . . . . . . 3 71 3.1. Enabling UIDONLY extension . . . . . . . . . . . . . . . 3 72 3.2. Changes to FETCH/STORE/SEARCH . . . . . . . . . . . . . . 4 73 3.3. Changes to UID FETCH/UID STORE . . . . . . . . . . . . . 4 74 3.4. Changes to EXPUNGE/UID EXPUNGE . . . . . . . . . . . . . 4 75 3.5. Changes to how other mailbox changes are announced . . . 5 76 4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 79 6.1. Changes/additions to the IMAP4 capabilities registry . . 6 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 81 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction and Overview 86 This document defines an extension to the Internet Message Access 87 Protocol [RFC3501] for eliminating use of message numbers. This 88 extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 89 [RFC9051]. 91 The UIDONLY extension of the Internet Message Access Protocol (RFC 92 3501/RFC 9051) allows clients to request that servers only use and 93 return UIDs. This helps both clients and servers to reduce resource 94 usage required for maintenance of message number to UID map. 96 IMPLEMENTATION NOTE: this document is not yet at the state where it 97 is implementable. Please contact document authors if you want to 98 experiment with implementing UIDONLY. 100 2. Document Conventions 102 In protocol examples, this document uses a prefix of "C: " to denote 103 lines sent by the client to the server, and "S: " for lines sent by 104 the server to the client. Lines prefixed with "// " are comments 105 explaining the previous protocol line. These prefixes and comments 106 are not part of the protocol. Lines without any of these prefixes 107 are continuations of the previous line, and no line break is present 108 in the protocol unless specifically mentioned. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 Other capitalised words are IMAP keywords [RFC3501][RFC9051] or 117 keywords from this document. 119 3. The UIDONLY extension 121 An IMAP server advertises support for the UIDONLY extension by 122 including the "UIDONLY" capability in the CAPABILITY response/ 123 response code. 125 The UIDONLY extension affects how information about new, expunged or 126 changed messages is returned in unsolicited responses. In 127 partucular, it affects responses to UID FETCH/UID STORE/EXPUNGE/UID 128 EXPUNGE, as well as how unsolicited mailbox changes are announced. 130 The following subsections describe changes introduced by this 131 extension in more details. 133 3.1. Enabling UIDONLY extension 135 As the UIDONLY extension affects how information about new, expunged 136 or changed messages is returned in unsolicited responses, it has to 137 be enabled by the client first using the ENABLE command. 139 S: * OK [CAPABILITY IMAP4rev1 ENABLE CONDSTORE QRESYNC UIDONLY AUTH=SCRAM-SHA-256] 140 C: 01 ENABLE UIDONLY 141 S: * ENABLED UIDONLY 142 S: 01 OK ENABLE completed 144 3.2. Changes to FETCH/STORE/SEARCH 146 // Is this Ok or is this too restrictive? Should COPY/MOVE be 147 // restricted in the same way? 149 When UIDONLY is enabled, FETCH, STORE and SEARCH commands are 150 prohibited and MUST result in a tagged BAD response. Clients should 151 instead use UID FETCH, UID STORE and UID SEARCH respectively. 153 3.3. Changes to UID FETCH/UID STORE 155 When UIDONLY is enabled, all FETCH responses that would be returned 156 by UID FETCH/UID STORE are replaced by UIDFETCH responses. 158 Note that UIDFETCH response contains the same FETCH response data 159 items, except the UID, which is returned differently at the beginning 160 of a UIDFETCH response. Requesting UID FETCH data item is not an 161 error and this is just ignored. 163 C: 10 UID FETCH 25900:26600 (FLAGS) 164 [...] 165 S: * 25996 UIDFETCH (FLAGS (\Seen)) 166 S: * 25997 UIDFETCH (FLAGS (\Flagged \Answered)) 167 S: * 26600 UIDFETCH (FLAGS ()) 168 S: 10 OK FETCH completed 170 C: 11 UID FETCH 25900:26600 (UID FLAGS) 171 S: * 25900 UIDFETCH (FLAGS (\Seen)) 172 S: * 25902 UIDFETCH (FLAGS (\Flagged)) 173 S: * 26310 UIDFETCH (FLAGS (\Answered)) 174 S: * 26311 UIDFETCH (FLAGS ()) 175 S: * 26498 UIDFETCH (FLAGS (\Answered)) 176 [...] 177 S: 11 OK FETCH completed 179 3.4. Changes to EXPUNGE/UID EXPUNGE 181 When UIDONLY is enabled, all EXPUNGED responses that would be 182 returned by EXPUNGE/UID EXPUNGE are replaced by VANISHED responses, 183 as defined in [RFC7162]. Note that a server that implements UIDONLY 184 extension is not required to also implement CONDSTORE and/or QRESYNC 185 extensions. 187 C: 12 EXPUNGE 188 S: * VANISHED 405,407,410,425 189 S: 12 OK expunged 191 3.5. Changes to how other mailbox changes are announced 193 When UIDONLY is enabled, all changes to flags (and other dynamic 194 message attributes) are returned using UIDFETCH responses, instead of 195 FETCH responses. 197 Similarly, all expunged messages are announced using VANISHED 198 responses instead of EXPUNGE responses. 200 UID MOVE/UID COPY commands SHOULD return COPYUID response code, as 201 specified in [RFC4315]. 203 Use of UIDNOTSTICKY response code (see [RFC4315]) is not compatible 204 with the UIDONLY extension. I.e. a server that advertises UIDONLY 205 extension MUST NOT return UIDNOTSTICKY response code. 207 // Also need to think about interaction with CONDSTORE/QRESYNC in 208 // more details. CONDSTORE is compatible with UIDONLY, but QRESYNC 209 // might not be, due to existence of message numbers in SELECT 210 // QRESYNC. 212 4. Formal syntax 214 The following syntax specification uses the Augmented Backus-Naur 215 Form (ABNF) notation as specified in [ABNF]. 217 Non-terminals referenced but not defined below are as defined by 218 IMAP4 [RFC3501]. 220 Except as noted otherwise, all alphabetic characters are case- 221 insensitive. The use of upper or lower case characters to define 222 token strings is for editorial clarity only. Implementations MUST 223 accept these strings in a case-insensitive fashion. 225 SP = 227 capability =/ "UIDONLY" 228 ;; from [RFC3501] 230 message-data =/ uidfetch-resp 232 uidfetch-resp = uniqueid SP "UIDFETCH" SP msg-att 233 ;; UID msg-att is never used. It is replaced by the uniqueid 234 ;; at the beginning of the UIDFETCH response 236 message-data =/ expunged-resp 238 expunged-resp = 240 5. Security Considerations 242 TBD. 244 6. IANA Considerations 246 6.1. Changes/additions to the IMAP4 capabilities registry 248 IMAP4 capabilities are registered by publishing a standards track or 249 IESG approved Informational or Experimental RFC. The registry is 250 currently located at: 252 https://www.iana.org/assignments/imap4-capabilities 254 IANA is requested to add definition of the UIDONLY extension to point 255 to this document. 257 7. Acknowledgments 259 TBD. 261 8. Normative References 263 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 264 Syntax Specifications: ABNF", RFC 5234, January 2008, 265 . 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, 270 . 272 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 273 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 274 . 276 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 277 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 278 December 2005, . 280 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 281 Changes Resynchronization (CONDSTORE) and Quick Mailbox 282 Resynchronization (QRESYNC)", RFC 7162, 283 DOI 10.17487/RFC7162, May 2014, 284 . 286 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 287 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 288 May 2017, . 290 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 291 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 292 DOI 10.17487/RFC9051, August 2021, 293 . 295 Authors' Addresses 297 Alexey Melnikov 298 Isode Limited 300 Email: alexey.melnikov@isode.com 301 URI: https://www.isode.com 303 Arun Prakash Achuthan 304 Yahoo Inc. 306 Email: arunprakash@myyahoo.com 308 Vikram Nagulakonda 309 Yahoo Inc. 311 Email: nvikram_imap@yahoo.com 313 Ashutosh Singh 314 Yahoo Inc. 316 Email: ashutoshvsingh@yahoo.com 317 Luis Alves 319 Email: luis.alves@lafaspot.com