idnits 2.17.1 draft-ietf-extra-imap-objectid-06.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 (July 19, 2018) is 2079 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: A later version (-16) exists of draft-ietf-jmap-mail-06 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) July 19, 2018 5 Intended status: Standards Track 6 Expires: January 20, 2019 8 IMAP Extension for object identifiers 9 draft-ietf-extra-imap-objectid-06 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 January 20, 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 . . . . . . . . . . . . . . . . 9 63 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. Implementation considerations . . . . . . . . . . . . . . . . 10 65 8.1. Assigning object identifiers . . . . . . . . . . . . . . 10 66 8.2. Interaction with special cases . . . . . . . . . . . . . 11 67 8.3. Client usage . . . . . . . . . . . . . . . . . . . . . . 11 68 9. Future considerations . . . . . . . . . . . . . . . . . . . . 11 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 12.1. draft-ietf-extra-imap-objectid-06 . . . . . . . . . . . 12 73 12.2. draft-ietf-extra-imap-objectid-05 . . . . . . . . . . . 13 74 12.3. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 13 75 12.4. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13 76 12.5. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 14 77 12.6. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 14 78 12.7. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14 79 12.8. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14 80 12.9. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 15 81 12.10. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 15 82 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 83 13.1. Appendix 1: ideas for implementing object identifiers . 15 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 14.2. Informative References . . . . . . . . . . . . . . . . . 17 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 IMAP stores are often used by many clients. Each client may cache 92 data from the server so that they don't need to re-download 93 information. [RFC3501] defines that a mailbox can be uniquely 94 referenced by its name and UIDVALIDITY, and a message within that 95 mailbox can be uniquely referenced by its mailbox (name + 96 UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and 97 UID is guaranteed to be immutable. 99 [RFC4315] defines a COPYUID response which allows a client which 100 copies messages to know the mapping between the UIDs in the source 101 and destination mailboxes, and hence update its local cache. 103 If a mailbox is successfully renamed by a client, that client will 104 know that the same messages exist in the destination mailbox name as 105 previously existed in the source mailbox name. 107 The result is that the client which copies (or [RFC6851] moves) 108 messages or renames a mailbox can update its local cache, but any 109 other client connected to the same store can not know with certainty 110 that the messages are identical, and so will re-download everything. 112 This extension adds new properties to a message (EMAILID) and mailbox 113 (MAILBOXID) which allow a client to quickly identify messages or 114 mailboxes which have been renamed by another client. 116 This extension also adds an optional thread identifier (THREADID) to 117 messages, which can be used by the server to indicate messages which 118 it has identified to be related. A server that does not implement 119 threading will return NIL to all requests for THREADID. 121 2. Conventions Used In This Document 123 In examples, "C:" indicates lines sent by a client that is connected 124 to a server. "S:" indicates lines sent by the server to the client. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119] when they 129 appear in ALL CAPS. These words may also appear in this document in 130 lower case as plain English words, absent their normative meanings. 132 3. CAPABILITY Identification 134 IMAP servers that support this extension MUST include "OBJECTID" in 135 the response list to the CAPABILITY command. 137 4. MAILBOXID object identifier 139 The MAILBOXID is a server-allocated unique identifer for each 140 mailbox. 142 The server MUST return the same MAILBOXID for a mailbox with the same 143 name and UIDVALIDITY. 145 The server MUST NOT report the same MAILBOXID for two mailboxes at 146 the same time. 148 The server MUST NOT reuse the same MAILBOXID for a mailbox which does 149 not obey all the invarients that [RFC3501] defines for a mailbox 150 which does not change name or UIDVALIDITY. 152 The server MUST keep the same MAILBOXID for the source and 153 destination when renaming a mailbox in a way which keeps the same 154 messages (but see [RFC3501] for the special case regarding renaming 155 of INBOX, which is treated as creating a new mailbox and moving the 156 messages) 158 4.1. New response code for CREATE 160 This document extends the CREATE command to have the response code 161 MAILBOXID on successful mailbox creation. 163 A server advertising the OBJECTID capability MUST include the 164 MAILBOXID response code in the tagged OK response to all successful 165 CREATE commands. 167 Syntax: "MAILBOXID" SP "(" ")" 169 Response code in tagged OK for successful CREATE command. 171 Example: 173 C: 3 create foo 174 S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Completed 175 C: 4 create bar 176 S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)] Completed 177 C: 5 create foo 178 S: 5 NO Mailbox already exists 180 4.2. New OK Untagged Response for SELECT and EXAMINE 182 This document adds a new untagged response code to the SELECT and 183 EXAMINE commands. 185 A server advertising the OBJECTID capability MUST return an untagged 186 OK response with the MAILBOXID response code on all successful SELECT 187 and EXAMINE commands. 189 Syntax: "OK" SP "[" "MAILBOXID" SP "(" ")" "]" text 191 Untagged OK response to SELECT or EXAMINE. 193 Example: 195 C: 27 select "foo" 196 [...] 197 S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok 198 [...] 199 S: 27 OK [READ-WRITE] Completed 201 4.3. New attribute for STATUS 203 This document adds the MAILBOXID attribute to the STATUS command 204 using the extended syntax defined in [RFC4466]. 206 A server that advertises the OBJECTID capability MUST support the 207 MAILBOXID status attribute. 209 Syntax: "MAILBOXID" 211 The attribute in the STATUS command. 213 Syntax: "MAILBOXID" SP "(" ")" 215 The response item in the STATUS response contains the objectid 216 assigned by the server for this mailbox. 218 Example: 220 C: 6 status foo (mailboxid) 221 S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) 222 S: 6 OK Completed 223 C: 7 status bar (mailboxid) 224 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) 225 S: 7 OK Completed 226 C: 8 rename foo renamed 227 S: * OK rename foo renamed 228 S: 8 OK Completed 229 C: 9 status renamed (mailboxid) 230 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) 231 S: 9 OK Completed 232 C: 10 status bar (mailboxid) 233 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) 234 S: 10 OK Completed 236 When the LIST-STATUS IMAP capability defined in [RFC5819] is also 237 available, the STATUS command can be combined with the LIST command. 239 Example: 241 C: 11 list "" "*" return (status (mailboxid)) 242 S: * LIST (\HasNoChildren) "." INBOX 243 S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf)) 244 S: * LIST (\HasNoChildren) "." bar 245 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) 246 S: * LIST (\HasNoChildren) "." renamed 247 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) 248 S: 11 OK Completed (0.001 secs 3 calls) 250 5. EMAILID object identifier and THREADID correlator 252 5.1. EMAILID identifier for identical messages 254 The EMAILID data item is an objectid which uniquely identifies the 255 content of a single message. Anything which must remain immutable on 256 a {name, uidvalidity, uid} triple must also be the same between 257 messages with the same EMAILID. 259 The server MUST return the same EMAILID for the same triple, hence 260 EMAILID is immutable. 262 The server MUST return the same EMAILID as the source message for the 263 matching destination message in the COPYUID pairing after a COPY or 264 [RFC6851] MOVE command. 266 The server MAY assign the same EMAILID as an existing message upon 267 APPEND (e.g. if it detects that the new message has exactly identical 268 content to that of an existing message) 270 NOTE: EMAILID only identifies the immutable content of the message. 271 In particular, it is possible for different messages with the same 272 EMAILID to have different keywords. This document does not specify a 273 way to STORE by EMAILID. 275 5.2. THREADID identifer for related messages 277 The THREADID data item is an objectid which uniquely identifies a set 278 of messages which the server believes should be grouped together when 279 presented. 281 THREADID calculation is generally based on some combination of 282 References, In-Reply-To and Subject, but the exact logic is left up 283 to the server implementation. [RFC5256] describes some algorithms 284 that could be used, however this specfication does not mandate any 285 particular strategy. 287 The server MUST return the same THREADID for all messages with the 288 same EMAILID. 290 The server SHOULD return the same THREADID for related messages even 291 if they are in different mailboxes. 293 The server MUST NOT change the THREADID of a message once reported. 295 THREADID is optional, if the server doesn't support THREADID or is 296 unable to calculate relationships between messages, it MUST return 297 NIL to all FETCH responses for the THREADID data item, and a SEARCH 298 for THREADID MUST NOT match any messages. 300 The server MUST NOT use the same objectid value for both EMAILIDs and 301 THREADIDs. If they are stored with the same value internally, the 302 server can generate prefixed values (as shown in the examples below 303 with M and T prefixes) to avoid clashes. 305 5.3. New Message Data Items in FETCH and UID FETCH Commands 307 This document defines two FETCH items: 309 Syntax: EMAILID 311 The EMAILID message data item causes the server to return EMAILID 312 FETCH response data items. 314 Syntax: THREADID 316 The THREADID message data item causes the server to return THREADID 317 FETCH response data items. 319 And the following responses: 321 Syntax: EMAILID ( ) 323 The EMAILID response data item contains the server-assigned objectid 324 for each message. 326 Syntax: THREADID ( ) 328 The THREADID response data item contains the server-assigned objectid 329 for the set of related messages to which this message belongs. 331 Syntax: THREADID NIL 333 The NIL value to the THREADID response data item is returned when 334 the server mailbox does not support THREADID calculation. 336 Example: 338 C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733} 339 [...] 340 Subject: Message A 341 Message-ID: 342 [...] 343 S: 5 OK [APPENDUID 1521475658 1] Completed 345 C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793} 346 [...] 347 Subject: Re: Message A 348 Message-ID: 349 References: 350 [...] 351 S: 11 OK [APPENDUID 1521475658 2] Completed 353 C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736} 354 [...] 355 Subject: Message C 356 Message-ID: 357 [...] 358 S: 17 OK [APPENDUID 1521475658 3] Completed 360 C: 22 fetch 1:* (emailid threadid) 361 S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9)) 362 S: * 2 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9)) 363 S: * 3 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5)) 364 S: 22 OK Completed (0.000 sec) 366 C: 23 move 2 foo 367 S: * OK [COPYUID 1521475659 2 1] Completed 368 S: * 2 EXPUNGE 369 S: 23 OK Completed 371 C: 24 fetch 1:* (emailid threadid) 372 S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9)) 373 S: * 2 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5)) 374 S: 24 OK Completed (0.000 sec) 375 C: 25 select "foo" 377 C: 25 select "foo" 378 [...] 379 S: 25 OK [READ-WRITE] Completed 380 C: 26 fetch 1:* (emailid threadid) 381 S: * 1 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9)) 382 S: 26 OK Completed (0.000 sec) 384 Example: (no THREADID support) 385 C: 26 fetch 1:* (emailid threadid) 386 S: * 1 FETCH (EMAILID (M00000001) THREADID NIL) 387 S: * 2 FETCH (EMAILID (M00000002) THREADID NIL) 388 S: 26 OK Completed (0.000 sec) 390 6. New Filters on SEARCH command 392 This document defines filters EMAILID and THREADID on the SEARCH 393 command. 395 EMAILID 397 Messages whose EMAILID is exactly the specified objectid. 399 THREADID 401 Messages whose THREADID is exactly the specified objectid. 403 Example: (as if run before the MOVE above when the mailbox had 3 404 messages) 406 C: 27 search emailid M6d99ac3275bb4e 407 S: * SEARCH 1 408 S: 27 OK Completed (1 msgs in 0.000 secs) 409 C: 28 search threadid T64b478a75b7ea9 410 S: * SEARCH 1 2 411 S: 28 OK Completed (2 msgs in 0.000 secs) 413 7. Formal syntax 415 The following syntax specification uses the Augmented Backus-Naur 416 Form (ABNF) [RFC5234] notation. Elements not defined here can be 417 found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and 418 IMAP ABNF extensions [RFC4466] specifications. 420 Except as noted otherwise, all alphabetic characters are case- 421 insensitive. The use of upper- or lowercase characters to define 422 token strings is for editorial clarity only. Implementations MUST 423 accept these strings in a case-insensitive fashion. 425 capability =/ "OBJECTID" 427 fetch-att =/ "EMAILID" / "THREADID" 429 fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged- 430 ext production from [RFC4466] 431 fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil ) ; 432 follows tagged-ext production from [RFC4466] 434 msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp 436 objectid = 1*255(ALPHA / DIGIT / "_" / "-") ; characters in object 437 identifiers are case ; significant 439 resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ; incorporated 440 before the expansion rule of ; atom [SP 1*] 441 ; that appears in [RFC3501] 443 search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid 445 status-att =/ "MAILBOXID" 447 status-att-value =/ "MAILBOXID" SP "(" objectid ")" ; follows tagged- 448 ext production from [RFC4466] 450 8. Implementation considerations 452 8.1. Assigning object identifiers 454 All objectid values are allocated by the server. 456 In the interests of reducing the possibilities of encoding mistakes, 457 objectids are restricted to a safe subset of possible byte values, 458 and in order to allow clients to allocate storage, they are 459 restricted in length. 461 An objectid is a string of 1 to 255 characters from the following set 462 of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. These characters are safe 463 to use in almost any context (e.g. filesystems, URIs, IMAP atoms). 465 For maximum safety, servers should also follow defensive allocation 466 strategies to avoid creating risks where glob completion or data type 467 detection may be present (e.g. on filesystems or in spreadsheets). 468 In particular it is wise to avoid: 470 o ids starting with - 472 o ids starting with digits 474 o ids which contain only digits 476 o ids which differ only by ASCII case (A vs a) 478 o the specific sequence of 3 characters NIL 479 A good solution to these issues is to prefix every ID with a single 480 alphabetical character. 482 8.2. Interaction with special cases 484 The case of RENAME INBOX may need special handling, as it has special 485 behaviour as defined in [RFC3501] section 6.3.5. 487 It is advisable (though not required) to have MAILBOXID be globally 488 unique, but it is only required to be unique within messages offered 489 to a single client login to a single server hostname. For example, a 490 proxy which aggregates multiple independent servers MUST NOT 491 advertise the OBJECTID capability unless it can guarantee that 492 different objects will never use the same identifiers, even if 493 backend object collide. 495 8.3. Client usage 497 Servers that implement both RFC 6154 and this specification should 498 optimize their execution of command like UID SEARCH OR EMAILID 1234 499 EMAILID 4321. 501 Clients can assume that searching the all-mail mailbox using OR/ 502 EMAILID or OR/THREADID is a fast way to find messages again if some 503 other client has moved them out of the mailbox where they were 504 previously seen. 506 Clients that cache data offline should fetch the EMAILID of all new 507 messages to avoid re-downloading already cached message details. 509 Clients should fetch the MAILBOXID for any new mailboxes before 510 discarding cache data for any mailbox which is no longer present on 511 the server, so that they can detect renames and avoid re-downloading 512 data. 514 9. Future considerations 516 This extension is intentionally defined to be compatible with the 517 data model in [I-D.ietf-jmap-mail]. 519 A future extension could be proposed to give a way to SELECT a 520 mailbox by MAILBOXID rather than name. 522 A future extension to [RFC5228] could allow fileinto by MAILBOXID 523 rather than name. 525 An extension to allow fetching message content directly via EMAILID 526 and message listings by THREADID could be proposed. 528 10. IANA Considerations 530 IANA is requested to add "OBJECTID" to the "IMAP Capabilities" 531 registry located at . 534 IANA is requested to add "MAILBOXID" to the "IMAP Response Codes" 535 registry located at with a Reference of [[THIS RFC]]. 538 11. Security Considerations 540 It is strongly advised that servers generate OBJECTIDs which are safe 541 to use as filesystem names, and unlikely to be auto-detected as 542 numbers. See implementation considerations. 544 If a digest is used for ID generation, it must have a collision 545 resistent property, so server implementations are advised to monitor 546 current security research and choose secure digests. As the IDs are 547 generated by the server, it will be possible to migrate to a new hash 548 by just creating new IDs with the new algorithm. This is 549 particularly true if a prefix is used on each ID, which can be 550 changed when the algorithm changes. 552 The use of a digest for ID generation may be used as proof that a 553 particular sequence of bytes was seen by the server, however this is 554 only a risk if IDs are leaked to clients who don't have permission to 555 fetch the data directly. Servers that are expected to handle highly 556 sensitive data should consider using a ID generation mechanism which 557 doesn't derive from a digest. 559 See also the security considerations in [RFC3501] section 11. 561 12. Changes 563 To be removed by the editor before publication 565 12.1. draft-ietf-extra-imap-objectid-06 567 o fixed one more missing space in ABNF (ad review) 569 o made one more MUST for mailbox being retained on rename (genart 570 review) 572 o updated ABNF to also extend msg-att-static (validator review) 574 o lowercased NIL => nil in ABNF (validator review) 576 12.2. draft-ietf-extra-imap-objectid-05 578 o changed some SHOULD to lower case in advice sections (genart 579 review) 581 o clarified that THREADID MUST NOT change 583 12.3. draft-ietf-extra-imap-objectid-04 585 o described NIL THREADID in more detail (ad review) 587 o made RFC5256 a normative reference (ad review) 589 o fixed ABNF missing quote (ad review) 591 o documented hash upgrade process (ad review) 593 o referenced RFC3501 for INBOX rename (ad review) 595 o referenced RFC3501 security considerations (secdir review) 597 o turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability 598 (genart review) 600 o remove suggested algorithms which are no longer legitimate (genart 601 review) 603 o updated proxy advice to suggest rewriting ids (genart review) 605 o fixed minor gramatical issues (genart review) 607 o required that EMAILID and THREADID are not identical (own 608 decision) 610 12.4. draft-ietf-extra-imap-objectid-03 612 o added RFC3501 to Abstract 614 o updated [[THIS RFC]] to not fail idnits 616 o changed jmap-mail to be informative rather than normative 618 o shortened IDs to stop wrapping and outdents in IMAP examples 620 12.5. draft-ietf-extra-imap-objectid-02 622 o added "Client usage" section 624 12.6. draft-ietf-extra-imap-objectid-01 626 o added "updates" for RFC3501 628 o fixed domains in thread example 630 o described threading in more detail 632 o added IANA request for Response Code 634 o clarified RFC2119 references 636 o simplified some waffle in wording 638 o added security consideration to choose good digest 640 o added MAILBOXID-UID suggestion for EMAILID generation 642 o updated ABNF normative reference to RFC5234 644 12.7. draft-ietf-extra-imap-objectid-00 646 o renamed draft to be objectid rather than uniqueid 648 o renamed UNIQUEID (capability) to OBJECTID 650 o restricted objectid to 64 safe characters 652 o added security considerations and advice about choosing objectid 654 o wrapped all responses in () for RFC4466 compatibility 656 o signifiant rewrite of all sections 658 12.8. draft-ietf-extra-imap-uniqueid-00 660 o renamed draft to be an EXTRA document 662 o added example for LIST RETURN STATUS 664 o started work on ABNF 666 o attempted to add response codes for EMAILID and THREADID 668 12.9. draft-gondwana-imap-uniqueid-01 670 o renamed UNIQUEID (status item) to MAILBOXID 672 o renamed MSGID to EMAILID 674 o renamed THRID to THREADID 676 o added TODO section 678 12.10. draft-gondwana-imap-uniqueid-00 680 o initial upload with names UNIQUEID/MSGID/THRID 682 13. Acknowledgments 684 The EXTRA working group at IETF. In particular feedback from Arnt 685 Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek. 687 The Gmail X-GM-THRID and X-GM-MSGID implementation as currently 688 defined at . 691 Dovecot X-GUID implementation. 693 13.1. Appendix 1: ideas for implementing object identifiers 695 Ideas for calculating MAILBOXID: 697 o [RFC4122] UUID 699 o Server assigned sequence number (guaranteed not to be reused) 701 Ideas for implementing EMAILID: 703 o Digest of message content (RFC822 bytes) - expensive unless cached 705 o [RFC4122] UUID 707 o Server assigned sequence number (guaranteed not to be reused) 709 Ideas for implementing THREADID: 711 o Derive from EMAILID of first seen message in the thread. 713 o [RFC4122] UUID 715 o Server assigned sequence number (guaranteed not to be reused) 716 There is a need to index and look up reference/in-reply-to data at 717 message creation to efficiently find matching messages for threading. 718 Threading may be either across folders, or within each folder only. 719 The server has significant leeway here. 721 14. References 723 14.1. Normative References 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 731 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 732 . 734 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 735 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 736 December 2005, . 738 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 739 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 740 . 742 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 743 Filtering Language", RFC 5228, DOI 10.17487/RFC5228, 744 January 2008, . 746 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 747 Specifications: ABNF", STD 68, RFC 5234, 748 DOI 10.17487/RFC5234, January 2008, 749 . 751 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access 752 Protocol - SORT and THREAD Extensions", RFC 5256, 753 DOI 10.17487/RFC5256, June 2008, 754 . 756 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for 757 Returning STATUS Information in Extended LIST", RFC 5819, 758 DOI 10.17487/RFC5819, March 2010, 759 . 761 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 762 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 763 DOI 10.17487/RFC6851, January 2013, 764 . 766 14.2. Informative References 768 [I-D.ietf-jmap-mail] 769 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-06 770 (work in progress), July 2018. 772 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 773 Unique IDentifier (UUID) URN Namespace", RFC 4122, 774 DOI 10.17487/RFC4122, July 2005, 775 . 777 Author's Address 779 Bron Gondwana (editor) 780 FastMail 781 Level 2, 114 William St 782 Melbourne VIC 3000 783 Australia 785 Email: brong@fastmailteam.com 786 URI: https://www.fastmail.com