idnits 2.17.1 draft-ietf-extra-imap-objectid-08.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 (Using the creation date from RFC3501, updated by this document, for RFC5378 checks: 1997-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2, 2018) is 1646 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) == Outdated reference: draft-ietf-jmap-mail has been published as RFC 8621 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EXTRA B. Gondwana, Ed. 3 Internet-Draft FastMail 4 Updates: 3501 (if approved) August 2, 2018 5 Intended status: Standards Track 6 Expires: February 3, 2019 8 IMAP Extension for object identifiers 9 draft-ietf-extra-imap-objectid-08 11 Abstract 13 This document updates RFC3501 (IMAP4rev1) with persistent identifiers 14 on mailboxes and messages to allow clients to more efficiently re-use 15 cached data when resources have changed location on the server. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 3, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 53 3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3 54 4. MAILBOXID object identifier . . . . . . . . . . . . . . . . . 3 55 4.1. New response code for CREATE . . . . . . . . . . . . . . 4 56 4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4 57 4.3. New attribute for STATUS . . . . . . . . . . . . . . . . 5 58 5. EMAILID object identifier and THREADID correlator . . . . . . 6 59 5.1. EMAILID identifier for identical messages . . . . . . . . 6 60 5.2. THREADID identifer for related messages . . . . . . . . . 6 61 5.3. New Message Data Items in FETCH and UID FETCH Commands . 7 62 6. New Filters on SEARCH command . . . . . . . . . . . . . . . . 10 63 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8. Implementation considerations . . . . . . . . . . . . . . . . 11 65 8.1. Assigning object identifiers . . . . . . . . . . . . . . 11 66 8.2. Interaction with special cases . . . . . . . . . . . . . 12 67 8.3. Client usage . . . . . . . . . . . . . . . . . . . . . . 12 68 9. Future considerations . . . . . . . . . . . . . . . . . . . . 13 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 12.1. draft-ietf-extra-imap-objectid-08 . . . . . . . . . . . 14 73 12.2. draft-ietf-extra-imap-objectid-07 . . . . . . . . . . . 14 74 12.3. draft-ietf-extra-imap-objectid-06 . . . . . . . . . . . 14 75 12.4. draft-ietf-extra-imap-objectid-05 . . . . . . . . . . . 15 76 12.5. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 15 77 12.6. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 15 78 12.7. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 16 79 12.8. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 16 80 12.9. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 16 81 12.10. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 16 82 12.11. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 17 83 12.12. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 17 84 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 85 13.1. Appendix 1: ideas for implementing object identifiers . 17 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 88 14.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 IMAP stores are often used by many clients. Each client may cache 94 data from the server so that they don't need to re-download 95 information. [RFC3501] defines that a mailbox can be uniquely 96 referenced by its name and UIDVALIDITY, and a message within that 97 mailbox can be uniquely referenced by its mailbox (name + 98 UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and 99 UID is guaranteed to be immutable. 101 [RFC4315] defines a COPYUID response which allows a client which 102 copies messages to know the mapping between the UIDs in the source 103 and destination mailboxes, and hence update its local cache. 105 If a mailbox is successfully renamed by a client, that client will 106 know that the same messages exist in the destination mailbox name as 107 previously existed in the source mailbox name. 109 The result is that the client which copies (or [RFC6851] moves) 110 messages or renames a mailbox can update its local cache, but any 111 other client connected to the same store can not know with certainty 112 that the messages are identical, and so will re-download everything. 114 This extension adds new properties to a message (EMAILID) and mailbox 115 (MAILBOXID) which allow a client to quickly identify messages or 116 mailboxes which have been renamed by another client. 118 This extension also adds an optional thread identifier (THREADID) to 119 messages, which can be used by the server to indicate messages which 120 it has identified to be related. A server that does not implement 121 threading will return NIL to all requests for THREADID. 123 2. Conventions Used In This Document 125 In examples, "C:" indicates lines sent by a client that is connected 126 to a server. "S:" indicates lines sent by the server to the client. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. CAPABILITY Identification 136 IMAP servers that support this extension MUST include "OBJECTID" in 137 the response list to the CAPABILITY command. 139 4. MAILBOXID object identifier 141 The MAILBOXID is a server-allocated unique identifer for each 142 mailbox. 144 The server MUST return the same MAILBOXID for a mailbox with the same 145 name and UIDVALIDITY. 147 The server MUST NOT report the same MAILBOXID for two mailboxes at 148 the same time. 150 The server MUST NOT reuse the same MAILBOXID for a mailbox which does 151 not obey all the invariants that [RFC3501] defines for a mailbox 152 which does not change name or UIDVALIDITY. 154 The server MUST keep the same MAILBOXID for the source and 155 destination when renaming a mailbox in a way which keeps the same 156 messages (but see [RFC3501] for the special case regarding renaming 157 of INBOX, which is treated as creating a new mailbox and moving the 158 messages) 160 4.1. New response code for CREATE 162 This document extends the CREATE command to have the response code 163 MAILBOXID on successful mailbox creation. 165 A server advertising the OBJECTID capability MUST include the 166 MAILBOXID response code in the tagged OK response to all successful 167 CREATE commands. 169 Syntax: "MAILBOXID" SP "(" objectid ")" 171 Response code in tagged OK for successful CREATE command. 173 Example: 175 C: 3 create foo 176 S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Completed 177 C: 4 create bar 178 S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)] Completed 179 C: 5 create foo 180 S: 5 NO Mailbox already exists 182 4.2. New OK Untagged Response for SELECT and EXAMINE 184 This document adds a new untagged response code to the SELECT and 185 EXAMINE commands. 187 A server advertising the OBJECTID capability MUST return an untagged 188 OK response with the MAILBOXID response code on all successful SELECT 189 and EXAMINE commands. 191 Syntax: "OK" SP "[" "MAILBOXID" SP "(" objectid ")" "]" SP text 192 Untagged OK response to SELECT or EXAMINE. 194 Example: 196 C: 27 select "foo" 197 [...] 198 S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok 199 [...] 200 S: 27 OK [READ-WRITE] Completed 202 4.3. New attribute for STATUS 204 This document adds the MAILBOXID attribute to the STATUS command 205 using the extended syntax defined in [RFC4466]. 207 A server that advertises the OBJECTID capability MUST support the 208 MAILBOXID status attribute. 210 Syntax: "MAILBOXID" 212 The attribute in the STATUS command. 214 Syntax: "MAILBOXID" SP "(" objectid ")" 216 The response item in the STATUS response contains the objectid 217 assigned by the server for this mailbox. 219 Example: 221 C: 6 status foo (mailboxid) 222 S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) 223 S: 6 OK Completed 224 C: 7 status bar (mailboxid) 225 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) 226 S: 7 OK Completed 227 C: 8 rename foo renamed 228 S: * OK rename foo renamed 229 S: 8 OK Completed 230 C: 9 status renamed (mailboxid) 231 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) 232 S: 9 OK Completed 233 C: 10 status bar (mailboxid) 234 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) 235 S: 10 OK Completed 237 When the LIST-STATUS IMAP capability defined in [RFC5819] is also 238 available, the STATUS command can be combined with the LIST command. 240 Example: 242 C: 11 list "" "*" return (status (mailboxid)) 243 S: * LIST (\HasNoChildren) "." INBOX 244 S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf)) 245 S: * LIST (\HasNoChildren) "." bar 246 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) 247 S: * LIST (\HasNoChildren) "." renamed 248 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) 249 S: 11 OK Completed (0.001 secs 3 calls) 251 5. EMAILID object identifier and THREADID correlator 253 5.1. EMAILID identifier for identical messages 255 The EMAILID data item is an objectid which uniquely identifies the 256 content of a single message. Anything which must remain immutable on 257 a {name, uidvalidity, uid} triple must also be the same between 258 messages with the same EMAILID. 260 The server MUST return the same EMAILID for the same triple, hence 261 EMAILID is immutable. 263 The server MUST return the same EMAILID as the source message for the 264 matching destination message in the COPYUID pairing after a COPY or 265 [RFC6851] MOVE command. 267 The server MAY assign the same EMAILID as an existing message upon 268 APPEND (e.g. if it detects that the new message has exactly identical 269 content to that of an existing message) 271 NOTE: EMAILID only identifies the immutable content of the message. 272 In particular, it is possible for different messages with the same 273 EMAILID to have different keywords. This document does not specify a 274 way to STORE by EMAILID. 276 5.2. THREADID identifer for related messages 278 The THREADID data item is an objectid which uniquely identifies a set 279 of messages which the server believes should be grouped together when 280 presented. 282 THREADID calculation is generally based on some combination of 283 References, In-Reply-To and Subject, but the exact logic is left up 284 to the server implementation. [RFC5256] describes some algorithms 285 that could be used, however this specfication does not mandate any 286 particular strategy. 288 The server MUST return the same THREADID for all messages with the 289 same EMAILID. 291 The server SHOULD return the same THREADID for related messages even 292 if they are in different mailboxes, e.g. messages which would appear 293 in the same thread if they were in the same mailbox SHOULD have the 294 same THREADID even if they are in different mailboxes. 296 The server MUST NOT change the THREADID of a message once reported. 298 THREADID is OPTIONAL; if the server doesn't support THREADID or is 299 unable to calculate relationships between messages, it MUST return 300 NIL to all FETCH responses for the THREADID data item, and a SEARCH 301 for THREADID MUST NOT match any messages. 303 The server MUST NOT use the same objectid value for both EMAILIDs and 304 THREADIDs. If they are stored with the same value internally, the 305 server can generate prefixed values (as shown in the examples below 306 with M and T prefixes) to avoid clashes. 308 5.3. New Message Data Items in FETCH and UID FETCH Commands 310 This document defines two FETCH items: 312 Syntax: "EMAILID" 314 The EMAILID message data item causes the server to return EMAILID 315 FETCH response data items. 317 Syntax: "THREADID" 319 The THREADID message data item causes the server to return THREADID 320 FETCH response data items. 322 And the following responses: 324 Syntax: "EMAILID" SP "(" objectid ")" 326 The EMAILID response data item contains the server-assigned objectid 327 for each message. 329 Syntax: "THREADID" SP "(" objectid ")" 331 The THREADID response data item contains the server-assigned objectid 332 for the set of related messages to which this message belongs. 334 Syntax: "THREADID" SP nil 335 The NIL value to the THREADID response data item is returned when 336 the server mailbox does not support THREADID calculation. 338 Example: 340 C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733} 341 [...] 342 Subject: Message A 343 Message-ID: 344 [...] 345 S: 5 OK [APPENDUID 1521475658 1] Completed 347 C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793} 348 [...] 349 Subject: Re: Message A 350 Message-ID: 351 References: 352 [...] 353 S: 11 OK [APPENDUID 1521475658 2] Completed 355 C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736} 356 [...] 357 Subject: Message C 358 Message-ID: 359 [...] 360 S: 17 OK [APPENDUID 1521475658 3] Completed 362 C: 22 fetch 1:* (emailid threadid) 363 S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9)) 364 S: * 2 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9)) 365 S: * 3 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5)) 366 S: 22 OK Completed (0.000 sec) 368 C: 23 move 2 foo 369 S: * OK [COPYUID 1521475659 2 1] Completed 370 S: * 2 EXPUNGE 371 S: 23 OK Completed 373 C: 24 fetch 1:* (emailid threadid) 374 S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9)) 375 S: * 2 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5)) 376 S: 24 OK Completed (0.000 sec) 377 C: 25 select "foo" 379 C: 25 select "foo" 380 [...] 381 S: 25 OK [READ-WRITE] Completed 382 C: 26 fetch 1:* (emailid threadid) 383 S: * 1 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9)) 384 S: 26 OK Completed (0.000 sec) 386 Example: (no THREADID support) 387 C: 26 fetch 1:* (emailid threadid) 388 S: * 1 FETCH (EMAILID (M00000001) THREADID NIL) 389 S: * 2 FETCH (EMAILID (M00000002) THREADID NIL) 390 S: 26 OK Completed (0.000 sec) 392 6. New Filters on SEARCH command 394 This document defines filters EMAILID and THREADID on the SEARCH 395 command. 397 Syntax: "EMAILID" SP objectid 399 Messages whose EMAILID is exactly the specified objectid. 401 Syntax: "THREADID" SP objectid 403 Messages whose THREADID is exactly the specified objectid. 405 Example: (as if run before the MOVE above when the mailbox had 3 406 messages) 408 C: 27 search emailid M6d99ac3275bb4e 409 S: * SEARCH 1 410 S: 27 OK Completed (1 msgs in 0.000 secs) 411 C: 28 search threadid T64b478a75b7ea9 412 S: * SEARCH 1 2 413 S: 28 OK Completed (2 msgs in 0.000 secs) 415 7. Formal syntax 417 The following syntax specification uses the Augmented Backus-Naur 418 Form (ABNF) [RFC5234] notation. Elements not defined here can be 419 found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and 420 IMAP ABNF extensions [RFC4466] specifications. 422 Except as noted otherwise, all alphabetic characters are case- 423 insensitive. The use of upper- or lowercase characters to define 424 token strings is for editorial clarity only. Implementations MUST 425 accept these strings in a case-insensitive fashion. 427 Please note specifically that objectid values are case sensitive. 429 capability =/ "OBJECTID" 431 fetch-att =/ "EMAILID" / "THREADID" 433 fetch-emailid-resp = "EMAILID" SP "(" objectid ")" 434 ; follows tagged-ext production from [@!RFC4466] 436 fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil ) 437 ; follows tagged-ext production from [@!RFC4466] 439 msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp 441 objectid = 1*255(ALPHA / DIGIT / "_" / "-") 442 ; characters in object identifiers are case 443 ; significant 445 resp-text-code =/ "MAILBOXID" SP "(" objectid ")" 446 ; incorporated before the expansion rule of 447 ; atom [SP 1*] 448 ; that appears in [@!RFC3501] 450 search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid 452 status-att =/ "MAILBOXID" 454 status-att-value =/ "MAILBOXID" SP "(" objectid ")" 455 ; follows tagged-ext production from [@!RFC4466] 457 8. Implementation considerations 459 8.1. Assigning object identifiers 461 All objectid values are allocated by the server. 463 In the interests of reducing the possibilities of encoding mistakes, 464 objectids are restricted to a safe subset of possible byte values, 465 and in order to allow clients to allocate storage, they are 466 restricted in length. 468 An objectid is a string of 1 to 255 characters from the following set 469 of 64 codepoints: a-z, A-Z, 0-9, '_', '-'. These characters are safe 470 to use in almost any context (e.g. filesystems, URIs, IMAP atoms). 471 These are the same characters defined as base64url in [RFC4648]. 473 For maximum safety, servers should also follow defensive allocation 474 strategies to avoid creating risks where glob completion or data type 475 detection may be present (e.g. on filesystems or in spreadsheets). 476 In particular it is wise to avoid: 478 o ids starting with - 480 o ids starting with digits 482 o ids which contain only digits 484 o ids which differ only by ASCII case (A vs a) 486 o the specific sequence of 3 characters NIL in any case (as this 487 sequence can be confused with the IMAP protocol expression of the 488 null value) 490 A good solution to these issues is to prefix every ID with a single 491 alphabetical character. 493 8.2. Interaction with special cases 495 The case of RENAME INBOX may need special handling, as it has special 496 behaviour as defined in [RFC3501] section 6.3.5. 498 It is advisable (though not required) to have MAILBOXID be globally 499 unique, but it is only required to be unique within messages offered 500 to a single client login to a single server hostname. For example, a 501 proxy which aggregates multiple independent servers MUST NOT 502 advertise the OBJECTID capability unless it can guarantee that 503 different objects will never use the same identifiers, even if 504 backend object identifiers collide. 506 8.3. Client usage 508 Servers that implement both RFC 6154 and this specification should 509 optimize their execution of command like UID SEARCH OR EMAILID 1234 510 EMAILID 4321. 512 Clients can assume that searching the all-mail mailbox using OR/ 513 EMAILID or OR/THREADID is a fast way to find messages again if some 514 other client has moved them out of the mailbox where they were 515 previously seen. 517 Clients that cache data offline should fetch the EMAILID of all new 518 messages to avoid re-downloading already cached message details. 520 Clients should fetch the MAILBOXID for any new mailboxes before 521 discarding cache data for any mailbox which is no longer present on 522 the server, so that they can detect renames and avoid re-downloading 523 data. 525 9. Future considerations 527 This extension is intentionally defined to be compatible with the 528 data model in [I-D.ietf-jmap-mail]. 530 A future extension could be proposed to give a way to SELECT a 531 mailbox by MAILBOXID rather than name. 533 A future extension to [RFC5228] could allow fileinto by MAILBOXID 534 rather than name. 536 An extension to allow fetching message content directly via EMAILID 537 and message listings by THREADID could be proposed. 539 10. IANA Considerations 541 IANA is requested to add "OBJECTID" to the "IMAP Capabilities" 542 registry located at with a Reference of [[THIS RFC]]. 545 IANA is requested to add "MAILBOXID" to the "IMAP Response Codes" 546 registry located at with a Reference of [[THIS RFC]]. 549 11. Security Considerations 551 It is strongly advised that servers generate OBJECTIDs which are safe 552 to use as filesystem names, and unlikely to be auto-detected as 553 numbers. See implementation considerations. 555 If a digest is used for ID generation, it must have a collision 556 resistent property, so server implementations are advised to monitor 557 current security research and choose secure digests. As the IDs are 558 generated by the server, it will be possible to migrate to a new hash 559 by just using the new algorith when creating new IDs. This is 560 particularly true if a prefix is used on each ID, which can be 561 changed when the algorithm changes. 563 The use of a digest for ID generation may be used as proof that a 564 particular sequence of bytes was seen by the server, however this is 565 only a risk if IDs are leaked to clients who don't have permission to 566 fetch the data directly. Servers that are expected to handle highly 567 sensitive data should consider this when choosing how to create IDs. 569 See also the security considerations in [RFC3501] section 11. 571 12. Changes 573 To be removed by the editor before publication 575 12.1. draft-ietf-extra-imap-objectid-08 577 o added reference to RFC4648 for base64url (Adam Roach review) 579 o less prescriptive instruction for digests (Adam Roach review) 581 o minor punctuation fix (Alissa Cooper review) 583 o clarified SHOULD around THREADID in different mailboxes (Alissa 584 Cooper review) 586 o clarified that objectids are case sensitive (Eric Rescorla review) 588 o clarified why NIL is a bad objectid (Eric Rescorla review) 590 o upper case OPTIONAL for threadid (Pete Resnick genart review) 592 o missing word in object identifiers clash (Pete Resnick genart 593 review) 595 12.2. draft-ietf-extra-imap-objectid-07 597 o updated boilerplate to RFC8174 (Benjamin Kaduk review) 599 o fixed spelling of invariants (Benjamin Kaduk review) 601 o block quoted ABNF for better text formatting (Benjamin Kaduk 602 review) 604 o clarified that servers can just switch to a new digest without 605 changing old IDs (Benjamin Kaduk review) 607 o changed use of folder to mailbox to avoid confusion (Warren Kumari 608 review) 610 o made both IANA requests say "reference of this RFC" (Warren Kumari 611 review) 613 12.3. draft-ietf-extra-imap-objectid-06 615 o fixed one more missing space in ABNF (ad review) 617 o made one more MUST for mailbox being retained on rename (genart 618 review) 620 o updated ABNF to also extend msg-att-static (validator review) 622 o lowercased NIL => nil in ABNF (validator review) 624 12.4. draft-ietf-extra-imap-objectid-05 626 o changed some SHOULD to lower case in advice sections (genart 627 review) 629 o clarified that THREADID MUST NOT change 631 12.5. draft-ietf-extra-imap-objectid-04 633 o described NIL THREADID in more detail (ad review) 635 o made RFC5256 a normative reference (ad review) 637 o fixed ABNF missing quote (ad review) 639 o documented hash upgrade process (ad review) 641 o referenced RFC3501 for INBOX rename (ad review) 643 o referenced RFC3501 security considerations (secdir review) 645 o turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability 646 (genart review) 648 o remove suggested algorithms which are no longer legitimate (genart 649 review) 651 o updated proxy advice to suggest rewriting ids (genart review) 653 o fixed minor gramatical issues (genart review) 655 o required that EMAILID and THREADID are not identical (own 656 decision) 658 12.6. draft-ietf-extra-imap-objectid-03 660 o added RFC3501 to Abstract 662 o updated [[THIS RFC]] to not fail idnits 664 o changed jmap-mail to be informative rather than normative 666 o shortened IDs to stop wrapping and outdents in IMAP examples 668 12.7. draft-ietf-extra-imap-objectid-02 670 o added "Client usage" section 672 12.8. draft-ietf-extra-imap-objectid-01 674 o added "updates" for RFC3501 676 o fixed domains in thread example 678 o described threading in more detail 680 o added IANA request for Response Code 682 o clarified RFC2119 references 684 o simplified some waffle in wording 686 o added security consideration to choose good digest 688 o added MAILBOXID-UID suggestion for EMAILID generation 690 o updated ABNF normative reference to RFC5234 692 12.9. draft-ietf-extra-imap-objectid-00 694 o renamed draft to be objectid rather than uniqueid 696 o renamed UNIQUEID (capability) to OBJECTID 698 o restricted objectid to 64 safe characters 700 o added security considerations and advice about choosing objectid 702 o wrapped all responses in () for RFC4466 compatibility 704 o signifiant rewrite of all sections 706 12.10. draft-ietf-extra-imap-uniqueid-00 708 o renamed draft to be an EXTRA document 710 o added example for LIST RETURN STATUS 712 o started work on ABNF 714 o attempted to add response codes for EMAILID and THREADID 716 12.11. draft-gondwana-imap-uniqueid-01 718 o renamed UNIQUEID (status item) to MAILBOXID 720 o renamed MSGID to EMAILID 722 o renamed THRID to THREADID 724 o added TODO section 726 12.12. draft-gondwana-imap-uniqueid-00 728 o initial upload with names UNIQUEID/MSGID/THRID 730 13. Acknowledgments 732 The EXTRA working group at IETF. In particular feedback from Arnt 733 Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek. 735 The Gmail X-GM-THRID and X-GM-MSGID implementation as currently 736 defined at . 739 Dovecot X-GUID implementation. 741 13.1. Appendix 1: ideas for implementing object identifiers 743 Ideas for calculating MAILBOXID: 745 o [RFC4122] UUID 747 o Server assigned sequence number (guaranteed not to be reused) 749 Ideas for implementing EMAILID: 751 o Digest of message content (RFC822 bytes) - expensive unless cached 753 o [RFC4122] UUID 755 o Server assigned sequence number (guaranteed not to be reused) 757 Ideas for implementing THREADID: 759 o Derive from EMAILID of first seen message in the thread. 761 o [RFC4122] UUID 763 o Server assigned sequence number (guaranteed not to be reused) 764 There is a need to index and look up reference/in-reply-to data at 765 message creation to efficiently find matching messages for threading. 766 Threading may be either across mailboxes, or within each mailbox 767 only. The server has significant leeway here. 769 14. References 771 14.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 779 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 780 . 782 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 783 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 784 December 2005, . 786 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 787 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 788 . 790 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 791 Filtering Language", RFC 5228, DOI 10.17487/RFC5228, 792 January 2008, . 794 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 795 Specifications: ABNF", STD 68, RFC 5234, 796 DOI 10.17487/RFC5234, January 2008, 797 . 799 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access 800 Protocol - SORT and THREAD Extensions", RFC 5256, 801 DOI 10.17487/RFC5256, June 2008, 802 . 804 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for 805 Returning STATUS Information in Extended LIST", RFC 5819, 806 DOI 10.17487/RFC5819, March 2010, 807 . 809 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 810 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 811 DOI 10.17487/RFC6851, January 2013, 812 . 814 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 815 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 816 May 2017, . 818 14.2. Informative References 820 [I-D.ietf-jmap-mail] 821 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-06 822 (work in progress), July 2018. 824 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 825 Unique IDentifier (UUID) URN Namespace", RFC 4122, 826 DOI 10.17487/RFC4122, July 2005, 827 . 829 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 830 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 831 . 833 Author's Address 835 Bron Gondwana (editor) 836 FastMail 837 Level 2, 114 William St 838 Melbourne VIC 3000 839 Australia 841 Email: brong@fastmailteam.com 842 URI: https://www.fastmail.com