idnits 2.17.1 draft-ietf-extra-imap-uniqueid-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 (March 30, 2018) is 2219 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: A later version (-16) exists of draft-ietf-jmap-mail-04 ** 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 30, 2018 5 Expires: October 1, 2018 7 IMAP Extension for unique identifiers 8 draft-ietf-extra-imap-uniqueid-00 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 October 1, 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 . . . . . . . . . . . . . . . . . . 7 56 7. Response Codes . . . . . . . . . . . . . . . . . . . . . . . 7 57 8. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 58 9. Implementation considerations . . . . . . . . . . . . . . . . 7 59 10. Future considerations . . . . . . . . . . . . . . . . . . . . 8 60 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 13. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 14.1. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 16. Normative References . . . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 IMAP stores are often used by many clients, which each cache 72 information locally about the server state so that they don't need to 73 download anything again. [RFC3501] defines that a mailbox can be 74 uniquely referenced by its name and UIDVALIDITY, and a message within 75 that mailbox can be uniquely referenced by its mailbox (name + 76 UIDVALIDITY) and UID. 78 Further, [RFC4315] defines a COPYUID response which allows a client 79 which copies messages between folders to know the mapping between the 80 UIDs in the source and destination mailboxes, and hence update its 81 local cache. 83 So a client which copies (or [RFC6851] moves) messages or renames 84 folders can update its local cache, but any other client connected to 85 the same store can not know with certainty that the messages are 86 identical, and so will re-download everything. 88 This extension adds new properties to a message (EMAILID) and mailbox 89 (MAILBOXID) which allow a client to quickly identify messages or 90 mailboxes which have been renamed by another client. 92 This extension also adds an optional thread identifier (THREADID) to 93 messages, which can be used by the server to indicate messages which 94 it has identified to be related. 96 2. Conventions Used In This Document 98 In examples, "C:" indicates lines sent by a client that is connected 99 to a server. "S:" indicates lines sent by the server to the client. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119] when they 104 appear in ALL CAPS. These words may also appear in this document in 105 lower case as plain English words, absent their normative meanings. 107 3. CAPABILITY Identification 109 IMAP servers that support this extension MUST include "UNIQUEID" in 110 the response list to the CAPABILITY command. 112 4. STATUS Command and Response Extensions 114 This extension defines one new status data item for the STATUS 115 command and response: 117 MAILBOXID A unique identifier for the mailbox. This identifier 118 SHOULD be retained when the mailbox is renamed. This identifer MUST 119 NOT be identical if the mailbox does not meet the invarients for a 120 mailbox with the same name and uidvalidity as a mailbox previously 121 reported to have this UIDVALIDITY. A server MUST NOT return two 122 mailboxes with the same MAILBOXID. 124 The value of the MAILBOXID is an opaque string of 1..255 bytes in 125 length. The MAILBOXID is server assigned and read-only. 127 The server MAY choose to create a MAILBOXID value in a way that does 128 not survive RENAME, (e.g. a digest of mailboxname + uidvalidity could 129 be used as a "MAILBOXID" and it would be legal, though of course 130 clients would not get the full benefits of this extension from such a 131 server). 133 Example: 135 C: 3 create foo 136 S: 3 OK Completed 137 C: 4 create bar 138 S: 4 OK Completed 139 C: 5 status foo (mailboxid uidvalidity) 140 S: * STATUS foo (UIDVALIDITY 1521472287 MAILBOXID 7uijf0bg4yeo51a7) 141 S: 5 OK Completed 142 C: 6 status bar (mailboxid uidvalidity) 143 S: * STATUS bar (UIDVALIDITY 1521472288 MAILBOXID u8vhi0uy16v5k99p) 144 S: 6 OK Completed 145 C: 7 rename foo renamed 146 S: * OK rename foo renamed 147 S: 7 OK Completed 148 C: 8 status renamed (mailboxid uidvalidity) 149 S: * STATUS renamed (UIDVALIDITY 1521472287 MAILBOXID 7uijf0bg4yeo51a7) 150 S: 8 OK Completed 151 C: 9 status bar (mailboxid uidvalidity) 152 S: * STATUS bar (UIDVALIDITY 1521472288 MAILBOXID u8vhi0uy16v5k99p) 153 S: 9 OK Completed 155 When the LIST-STATUS IMAP capability [RFC5819] is also available, the 156 STATUS command can be combined with the LIST command to further 157 improve efficiency. This way, the unique ids of many mailboxes can 158 be queried with just one LIST command. 160 Example: 162 C: 10 list "" "*" return (status (mailboxid)) 163 S: * LIST (\HasNoChildren) "." INBOX 164 S: * STATUS INBOX (MAILBOXID 2l3g6iiw520ruqo1mcspbfv2) 165 S: * LIST (\HasNoChildren) "." bar 166 S: * STATUS bar (MAILBOXID 0vfkeq1wzgse343kegel6glk) 167 S: * LIST (\HasNoChildren) "." renamed 168 S: * STATUS renamed (MAILBOXID 4jbgi9zgfnc9gtwu7qmkye45) 169 S: 10 OK Completed (0.001 secs 3 calls) 171 5. FETCH Command and Response Extensions 173 This extension defines two additional FETCH items on messages: 175 EMAILID A server allocated opaque string value (1..255 bytes) which 176 uniquely identifies the content of a single message. That is the 177 exact bytes of the RFC822 FETCH item. The server MUST NOT return the 178 same EMAILID for two different sets of bytes. The server SHOULD 179 return the same EMAILID for the same set of bytes. 181 The server SHOULD retain the same INTERNALDATE for messages with 182 the same EMAILID. 184 THREADID A server allocated opaque string value (1..255 bytes) which 185 is the same for messages which the server has, with its own 186 algorithm, decided are "related" in some way. This is generally 187 based on some combination of References, In-Reply-To and Subject but 188 the exact logic is left up to the server implementation. If the 189 mailbox does not support THREADID, it will return NIL for fetch. 191 THREADID MUST NOT change if EMAILID is the same. 193 Example: 195 C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733} 196 [...] 197 Subject: Message A 198 Message-ID: 199 [...] 200 S: 5 OK [APPENDUID 1521475658 1] Completed 202 C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793} 203 [...] 204 Subject: Re: Message A 205 Message-ID: 206 References: 207 [...] 208 S: 11 OK [APPENDUID 1521475658 2] Completed 210 C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736} 211 [...] 212 Subject: Message C 213 Message-ID: 214 [...] 215 S: 17 OK [APPENDUID 1521475658 3] Completed 217 C: 22 fetch 1:* (emailid threadid) 218 S: * 1 FETCH (EMAILID Md8976d99ac3275bb4e THREADID T4964b478a75b7ea9) 219 S: * 2 FETCH (EMAILID Mdd3c288836c4c7a762 THREADID T4964b478a75b7ea9) 220 S: * 3 FETCH (EMAILID Mf2e25fdc09b49ea703 THREADID T6311863d02dd95b5) 221 S: 22 OK Completed (0.000 sec) 223 C: 23 move 2 foo 224 S: * OK [COPYUID 1521475659 2 1] Completed 225 S: * 2 EXPUNGE 226 S: 23 OK Completed 228 C: 24 fetch 1:* (emailid threadid) 229 S: * 1 FETCH (EMAILID Md8976d99ac3275bb4e THREADID T4964b478a75b7ea9) 230 S: * 2 FETCH (EMAILID Mf2e25fdc09b49ea703 THREADID T6311863d02dd95b5) 231 S: 24 OK Completed (0.000 sec) 232 C: 25 select "foo" 234 C: 25 select "foo" 235 [...] 236 S: 25 OK [READ-WRITE] Completed 237 C: 26 fetch 1:* (emailid threadid) 238 S: * 1 FETCH (EMAILID Mdd3c288836c4c7a762 THREADID T4964b478a75b7ea9) 239 S: 26 OK Completed (0.000 sec) 241 6. SEARCH Command Extension 243 This extension defines two new search keys for the SEARCH command: 245 EMAILID blob Messages with the exactly matching EMAILID (bytes, does 246 not depend on charset, case IS significant) 248 THREADID blob Messages with the exactly matching THREADID (bytes, 249 does not depend on charset, case IS significant) 251 Example: (as if run before the MOVE above when the mailbox had 3 252 messages) 254 C: 27 search emailid Md8976d99ac3275bb4e918af4 255 S: * SEARCH 1 256 S: 27 OK Completed (1 msgs in 0.000 secs) 257 C: 28 search threadid T4964b478a75b7ea9 258 S: * SEARCH 1 2 259 S: 28 OK Completed (2 msgs in 0.000 secs) 261 7. Response Codes 263 This specification defines a new response code "MAILBOXID" to the 264 "CREATE" command. 266 Example: 268 C: 3 create foo 269 S: 3 OK [MAILBOXID 87nn6m5t8azrrrywp4qfxkez] Completed 271 8. Formal syntax 273 resp-text-code =/ "MAILBOXID" 275 uniqueid = 1*255(ALPHA / DIGIT / "_" / "-") 277 9. Implementation considerations 279 The case of RENAME INBOX may need special handling for unique ids. 281 It is OK to change the mailboxid on a folder RENAME, but you MUST NOT 282 ever re-use a MAILBOXID which has been shown to a client. 284 It is advisable (though not required) to have MAILBOXID be globally 285 unique, but they it is only required to be unique within a single 286 server. 288 If you have unique IDs larger than 255 bytes in a data store, it is 289 safe to use a cryptograhically strong hash to convert your IDs into a 290 MAILBOXID value to display for this extension. It may be worth 291 caching that value, as STATUS MAILBOXID is expected to be cheap for 292 the server to calculate. 294 Ideas for implementing EMAILID: 296 o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when moving 297 messages, but is guarantee unique. 299 o Digest of message content (RFC822 bytes) - expensive unless cached 301 o ID allocated at creation time - very efficient but requires 302 storage of an additional value. 304 Ideas for implementing THREADID: 306 o Derive from EMAILID of first seen message in the thread. 308 o ID allocated at creation time. 310 There is a need to index and look up reference/in-reply-to data 311 efficiently at message creation to efficiently find matching messages 312 for threading. Threading may be either across folders, or within 313 each folder only. The server has significant leeway here. 315 10. Future considerations 317 This extension is intentionally defined to be compatible with the 318 data model in [I-D.ietf-jmap-mail]. 320 A future extension could be proposed to give a way to SELECT a 321 mailbox by MAILBOXID rather than name. 323 An extension to allow fetching message content directly via EMAILID 324 and message listings by THREADID could be proposed. 326 11. IANA Considerations 328 The IANA is requested to add "UNIQUEID" to the "IMAP Capabilities" 329 registry located at . 332 12. Security Considerations 334 If globally unique identifiers are used as MAILBOXIDs on IMAP 335 folders, then it may be possible to tell when an account or folder 336 has been renamed, even if all the mail has been deleted, if the 337 folders themselves are retained. 339 13. TODO 341 o add ABNF 343 o consider whether IDs should be constrained to a smaller set of 344 allowed characters (in conjunction with JMAP group) 346 o consider whether STATUS response should be MAILBOXID ("value") to 347 allow non-integer responses. 349 14. Changes 351 14.1. 01 353 o renamed UNIQUEID (status item) to MAILBOXID 355 o renamed MSGID to EMAILID 357 o renamed THRID to THREADID 359 o added TODO section 361 15. Acknowledgments 363 The EXTRA working group at IETF. 365 The gmail team's X-GM-THRID and X-GM-MSGID implementation. 367 16. Normative References 369 [I-D.ietf-jmap-mail] 370 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-04 371 (work in progress), March 2018. 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 379 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 380 . 382 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 383 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 384 December 2005, . 386 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for 387 Returning STATUS Information in Extended LIST", RFC 5819, 388 DOI 10.17487/RFC5819, March 2010, 389 . 391 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 392 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 393 DOI 10.17487/RFC6851, January 2013, 394 . 396 Author's Address 398 Bron Gondwana (editor) 399 FastMail 400 Level 2, 114 William St 401 Melbourne VIC 3000 402 Australia 404 Email: brong@fastmailteam.com 405 URI: https://www.fastmail.com