idnits 2.17.00 (12 Aug 2021) /tmp/idnits19650/draft-gondwana-imap-uniqueid-01.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 (March 19, 2018) is 1523 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) == Outdated reference: draft-ietf-jmap-mail has been published as RFC 8621 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EXTRA B. Gondwana, Ed. 3 Internet-Draft FastMail 4 Intended status: Standards Track March 19, 2018 5 Expires: September 20, 2018 7 IMAP Extension for unique identifiers 8 draft-gondwana-imap-uniqueid-01 10 Abstract 12 This document adds new properties to IMAP mailboxes and messages to 13 allow clients to more efficiently re-use cached data for resources 14 which have changed location on the server. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 20, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 52 3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3 53 4. STATUS Command and Response Extensions . . . . . . . . . . . 3 54 5. FETCH Command and Response Extensions . . . . . . . . . . . . 4 55 6. SEARCH Command Extension . . . . . . . . . . . . . . . . . . 6 56 7. Implementation considerations . . . . . . . . . . . . . . . . 6 57 8. Future considerations . . . . . . . . . . . . . . . . . . . . 7 58 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 11. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 12.1. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 64 14. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 IMAP stores are often used by many clients, which each cache 70 information locally about the server state so that they don't need to 71 download anything again. [RFC3501] defines that a mailbox can be 72 uniquely referenced by its name and UIDVALIDITY, and a message within 73 that mailbox can be uniquely referenced by its mailbox (name + 74 UIDVALIDITY) and UID. 76 Further, [RFC4315] defines a COPYUID response which allows a client 77 which copies messages between folders to know the mapping between the 78 UIDs in the source and destination mailboxes, and hence update its 79 local cache. 81 So a client which copies (or [RFC6851] moves) messages or renames 82 folders can update its local cache, but any other client connected to 83 the same store can not know with certainty that the messages are 84 identical, and so will re-download everything. 86 This extension adds new properties to a message (EMAILID) and mailbox 87 (MAILBOXID) which allow a client to quickly identify messages or 88 mailboxes which have been renamed by another client. 90 This extension also adds an optional thread identifier (THREADID) to 91 messages, which can be used by the server to indicate messages which 92 it has identified to be related. 94 2. Conventions Used In This Document 96 In examples, "C:" indicates lines sent by a client that is connected 97 to a server. "S:" indicates lines sent by the server to the client. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119] when they 102 appear in ALL CAPS. These words may also appear in this document in 103 lower case as plain English words, absent their normative meanings. 105 3. CAPABILITY Identification 107 IMAP servers that support this extension MUST include "UNIQUEID" in 108 the response list to the CAPABILITY command. 110 4. STATUS Command and Response Extensions 112 This extension defines one new status data item for the STATUS 113 command and response: 115 MAILBOXID A unique identifier for the mailbox. This identifier 116 SHOULD be retained when the mailbox is renamed. This identifer MUST 117 NOT be identical if the mailbox does not meet the invarients for a 118 mailbox with the same name and uidvalidity as a mailbox previously 119 reported to have this UIDVALIDITY. A server MUST NOT return two 120 mailboxes with the same MAILBOXID. 122 The value of the MAILBOXID is an opaque string of 1..255 bytes in 123 length. The MAILBOXID is server assigned and read-only. 125 The server MAY choose to create a MAILBOXID value in a way that does 126 not survive RENAME, (e.g. a digest of mailboxname + uidvalidity could 127 be used as a "MAILBOXID" and it would be legal, though of course 128 clients would not get the full benefits of this extension from such a 129 server). 131 Example: 133 C: 3 create foo 134 S: 3 OK Completed 135 C: 4 create bar 136 S: 4 OK Completed 137 C: 5 status foo (mailboxid uidvalidity) 138 S: * STATUS foo (UIDVALIDITY 1521472287 MAILBOXID 7uijf0bg4yeo51a7) 139 S: 5 OK Completed 140 C: 6 status bar (mailboxid uidvalidity) 141 S: * STATUS bar (UIDVALIDITY 1521472288 MAILBOXID u8vhi0uy16v5k99p) 142 S: 6 OK Completed 143 C: 7 rename foo renamed 144 S: * OK rename foo renamed 145 S: 7 OK Completed 146 C: 8 status renamed (mailboxid uidvalidity) 147 S: * STATUS renamed (UIDVALIDITY 1521472287 MAILBOXID 7uijf0bg4yeo51a7) 148 S: 8 OK Completed 149 C: 9 status bar (mailboxid uidvalidity) 150 S: * STATUS bar (UIDVALIDITY 1521472288 MAILBOXID u8vhi0uy16v5k99p) 151 S: 9 OK Completed 153 When the LIST-STATUS IMAP capability [RFC5819] is also available, the 154 STATUS command can be combined with the LIST command to further 155 improve efficiency. This way, the unique ids of many mailboxes can 156 be queried with just one LIST command. 158 5. FETCH Command and Response Extensions 160 This extension defines two additional FETCH items on messages: 162 EMAILID A server allocated opaque string value (1..255 bytes) which 163 uniquely identifies the content of a single message. That is the 164 exact bytes of the RFC822 FETCH item. The server MUST NOT return the 165 same EMAILID for two different sets of bytes. The server SHOULD 166 return the same EMAILID for the same set of bytes. 168 The server SHOULD retain the same INTERNALDATE for messages with 169 the same EMAILID. 171 THREADID A server allocated opaque string value (1..255 bytes) which 172 is the same for messages which the server has, with its own 173 algorithm, decided are "related" in some way. This is generally 174 based on some combination of References, In-Reply-To and Subject but 175 the exact logic is left up to the server implementation. If the 176 mailbox does not support THREADID, it will return NIL for fetch. 178 THREADID MUST NOT change if EMAILID is the same. 180 Example: 182 C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733} 183 [...] 184 Subject: Message A 185 Message-ID: 186 [...] 187 S: 5 OK [APPENDUID 1521475658 1] Completed 189 C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793} 190 [...] 191 Subject: Re: Message A 192 Message-ID: 193 References: 194 [...] 195 S: 11 OK [APPENDUID 1521475658 2] Completed 197 C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736} 198 [...] 199 Subject: Message C 200 Message-ID: 201 [...] 202 S: 17 OK [APPENDUID 1521475658 3] Completed 204 C: 22 fetch 1:* (emailid threadid) 205 S: * 1 FETCH (EMAILID Md8976d99ac3275bb4e THREADID T4964b478a75b7ea9) 206 S: * 2 FETCH (EMAILID Mdd3c288836c4c7a762 THREADID T4964b478a75b7ea9) 207 S: * 3 FETCH (EMAILID Mf2e25fdc09b49ea703 THREADID T6311863d02dd95b5) 208 S: 22 OK Completed (0.000 sec) 210 C: 23 move 2 foo 211 S: * OK [COPYUID 1521475659 2 1] Completed 212 S: * 2 EXPUNGE 213 S: 23 OK Completed 215 C: 24 fetch 1:* (emailid threadid) 216 S: * 1 FETCH (EMAILID Md8976d99ac3275bb4e THREADID T4964b478a75b7ea9) 217 S: * 2 FETCH (EMAILID Mf2e25fdc09b49ea703 THREADID T6311863d02dd95b5) 218 S: 24 OK Completed (0.000 sec) 219 C: 25 select "foo" 221 C: 25 select "foo" 222 [...] 223 S: 25 OK [READ-WRITE] Completed 224 C: 26 fetch 1:* (emailid threadid) 225 S: * 1 FETCH (EMAILID Mdd3c288836c4c7a762 THREADID T4964b478a75b7ea9) 226 S: 26 OK Completed (0.000 sec) 228 6. SEARCH Command Extension 230 This extension defines two new search keys for the SEARCH command: 232 EMAILID blob Messages with the exactly matching EMAILID (bytes, does 233 not depend on charset, case IS significant) 235 THREADID blob Messages with the exactly matching THREADID (bytes, 236 does not depend on charset, case IS significant) 238 Example: (as if run before the MOVE above when the mailbox had 3 239 messages) 241 C: 27 search emailid Md8976d99ac3275bb4e918af4 242 S: * SEARCH 1 243 S: 27 OK Completed (1 msgs in 0.000 secs) 244 C: 28 search threadid T4964b478a75b7ea9 245 S: * SEARCH 1 2 246 S: 28 OK Completed (2 msgs in 0.000 secs) 248 7. Implementation considerations 250 The case of RENAME INBOX may need special handling for unique ids. 252 It is OK to change the mailboxid on a folder RENAME, but you MUST NOT 253 ever re-use a MAILBOXID which has been shown to a client. 255 It is advisable (though not required) to have MAILBOXID be globally 256 unique, but they it is only required to be unique within a single 257 server. 259 If you have unique IDs larger than 255 bytes in a data store, it is 260 safe to use a cryptograhically strong hash to convert your IDs into a 261 MAILBOXID value to display for this extension. It may be worth 262 caching that value, as STATUS MAILBOXID is expected to be cheap for 263 the server to calculate. 265 Ideas for implementing EMAILID: 267 o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when moving 268 messages, but is guarantee unique. 270 o Digest of message content (RFC822 bytes) - expensive unless cached 272 o ID allocated at creation time - very efficient but requires 273 storage of an additional value. 275 Ideas for implementing THREADID: 277 o Derive from EMAILID of first seen message in the thread. 279 o ID allocated at creation time. 281 There is a need to index and look up reference/in-reply-to data 282 efficiently at message creation to efficiently find matching messages 283 for threading. Threading may be either across folders, or within 284 each folder only. The server has significant leeway here. 286 8. Future considerations 288 This extension is intentionally defined to be compatible with the 289 data model in [I-D.ietf-jmap-mail]. 291 A future extension could be proposed to give a way to SELECT a 292 mailbox by MAILBOXID rather than name. 294 An extension to allow fetching message content directly via EMAILID 295 and message listings by THREADID could be proposed. 297 9. IANA Considerations 299 The IANA is requested to add "UNIQUEID" to the "IMAP Capabilities" 300 registry located at . 303 10. Security Considerations 305 If globally unique identifiers are used as MAILBOXIDs on IMAP 306 folders, then it may be possible to tell when an account or folder 307 has been renamed, even if all the mail has been deleted, if the 308 folders themselves are retained. 310 11. TODO 312 o add ABNF 314 o consider whether IDs should be constrained to a smaller set of 315 allowed characters (in conjunction with JMAP group) 317 12. Changes 319 12.1. 01 321 o renamed UNIQUEID (status item) to MAILBOXID 323 o renamed MSGID to EMAILID 324 o renamed THRID to THREADID 326 o added TODO section 328 13. Acknowledgments 330 The EXTRA working group at IETF. 332 The gmail team's X-GM-THRID and X-GM-MSGID implementation. 334 14. Normative References 336 [I-D.ietf-jmap-mail] 337 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-04 338 (work in progress), March 2018. 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, 342 DOI 10.17487/RFC2119, March 1997, 343 . 345 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 346 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 347 . 349 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 350 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 351 December 2005, . 353 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for 354 Returning STATUS Information in Extended LIST", RFC 5819, 355 DOI 10.17487/RFC5819, March 2010, 356 . 358 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 359 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 360 DOI 10.17487/RFC6851, January 2013, 361 . 363 Author's Address 364 Bron Gondwana (editor) 365 FastMail 366 Level 2, 114 William St 367 Melbourne VIC 3000 368 Australia 370 Email: brong@fastmailteam.com 371 URI: https://www.fastmail.com