idnits 2.17.1 draft-ietf-extra-imap-objectid-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to mention this, which it should. 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 (May 26, 2018) is 2161 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) == Missing Reference: 'UIDVALIDITY 1524195797' is mentioned on line 193, but not defined == Missing Reference: 'THIS RFC' is mentioned on line 522, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-jmap-mail-05 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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) May 26, 2018 5 Intended status: Standards Track 6 Expires: November 27, 2018 8 IMAP Extension for object identifiers 9 draft-ietf-extra-imap-objectid-02 11 Abstract 13 This document adds new properties to IMAP mailboxes and messages to 14 allow clients to more efficiently re-use cached data for resources 15 which 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 November 27, 2018. 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-02 . . . . . . . . . . . 12 73 12.2. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 12 74 12.3. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 13 75 12.4. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 13 76 12.5. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 13 77 12.6. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 13 78 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 79 13.1. Appendix 1: ideas for implementing object identifiers . 14 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 14.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 IMAP stores are often used by many clients. Each client may cache 88 data from the server so that they don't need to re-download 89 information. [RFC3501] defines that a mailbox can be uniquely 90 referenced by its name and UIDVALIDITY, and a message within that 91 mailbox can be uniquely referenced by its mailbox (name + 92 UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and 93 UID is guaranteed to be immutable. 95 [RFC4315] defines a COPYUID response which allows a client which 96 copies messages to know the mapping between the UIDs in the source 97 and destination mailboxes, and hence update its local cache. 99 If a mailbox is successfully renamed, the client knows that the same 100 messages exist in the destination mailbox name as previously existed 101 in the source mailbox name. 103 The result is that the client which copies (or [RFC6851] moves) 104 messages or renames a mailbox can update its local cache, but any 105 other client connected to the same store can not know with certainty 106 that the messages are identical, and so will re-download everything. 108 This extension adds new properties to a message (EMAILID) and mailbox 109 (MAILBOXID) which allow a client to quickly identify messages or 110 mailboxes which have been renamed by another client. 112 This extension also adds an optional thread identifier (THREADID) to 113 messages, which can be used by the server to indicate messages which 114 it has identified to be related. 116 2. Conventions Used In This Document 118 In examples, "C:" indicates lines sent by a client that is connected 119 to a server. "S:" indicates lines sent by the server to the client. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119] when they 124 appear in ALL CAPS. These words may also appear in this document in 125 lower case as plain English words, absent their normative meanings. 127 3. CAPABILITY Identification 129 IMAP servers that support this extension MUST include "OBJECTID" in 130 the response list to the CAPABILITY command. 132 4. MAILBOXID object identifier 134 The MAILBOXID is a server-allocated unique identifer for each 135 mailbox. 137 The server SHOULD return the same MAILBOXID for a server with the 138 same mailbox name and UIDVALIDITY. This is almost MUST, but weakened 139 to allow for the possibility of loss of OBJECTID data during disaster 140 recovery while still keeping the name and UIDVALIDITY the same. 142 The server MUST NOT report the same MAILBOXID for two mailboxes at 143 the same time. 145 The server MUST NOT reuse the same MAILBOXID for a mailbox which does 146 not obey all the invarients that [RFC3501] defines for a mailbox 147 which does not change name or UIDVALIDITY. 149 The server MAY choose to create a MAILBOXID value in a way that does 150 not survive RENAME (e.g. a digest of name + uidvalidity could be 151 used), however the client then loses the major benefit of having an 152 identifier. 154 4.1. New response code for CREATE 156 This document extends the CREATE command to have the response code 157 MAILBOXID on successful mailbox creation. 159 A server advertising the OBJECTID capability MUST include the 160 MAILBOXID response code in the tagged OK response to all successful 161 CREATE commands. 163 Syntax: "MAILBOXID" SP "(" ")" 165 Response code in tagged OK for successful CREATE command. 167 Example: 169 C: 3 create foo 170 S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)] Completed 171 C: 4 create bar 172 S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)] Completed 173 C: 5 create foo 174 S: 5 NO Mailbox already exists 176 4.2. New OK Untagged Response for SELECT and EXAMINE 178 This document adds a new untagged response code to the SELECT and 179 EXAMINE commands. 181 A server advertising the OBJECTID capability MUST return an untagged 182 OK response with the MAILBOXID response code on all successful SELECT 183 and EXAMINE commands. 185 Syntax: "OK" SP "[" "MAILBOXID" SP "(" ")" "]" text 187 Untagged OK response to SELECT or EXAMINE. 189 Example: 191 C: 27 select "foo" 192 [...] 193 S: * OK [UIDVALIDITY 1524195797] Ok 194 S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)] Ok 195 [...] 196 S: 27 OK [READ-WRITE] Completed 198 4.3. New attribute for STATUS 200 This document adds the MAILBOXID attribute to the STATUS command 201 using the extended syntax defined in [RFC4466]. 203 A server that advertises the OBJECTID capability MUST support the 204 MAILBOXID status attribute. 206 Syntax: "MAILBOXID" 208 The attribute in the STATUS command. 210 Syntax: "MAILBOXID" SP "(" ")" 212 The response item in the STATUS response contains the objectid 213 assigned by the server for this mailbox. 215 Example: 217 C: 6 status foo (mailboxid) 218 S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)) 219 S: 6 OK Completed 220 C: 7 status bar (mailboxid) 221 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)) 222 S: 7 OK Completed 223 C: 8 rename foo renamed 224 S: * OK rename foo renamed 225 S: 8 OK Completed 226 C: 9 status renamed (mailboxid) 227 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)) 228 S: 9 OK Completed 229 C: 10 status bar (mailboxid) 230 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)) 231 S: 10 OK Completed 233 When the LIST-STATUS IMAP capability defined in [RFC5819] is also 234 available, the STATUS command can be combined with the LIST command. 236 Example: 238 C: 11 list "" "*" return (status (mailboxid)) 239 S: * LIST (\HasNoChildren) "." INBOX 240 S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf)) 241 S: * LIST (\HasNoChildren) "." bar 242 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)) 243 S: * LIST (\HasNoChildren) "." renamed 244 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)) 245 S: 11 OK Completed (0.001 secs 3 calls) 247 5. EMAILID object identifier and THREADID correlator 249 This document defines the data items EMAILID and THREADID on 250 messages. 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 SHOULD return the same EMAILID for the same UID triple. 260 As with MAILBOXID above, this is almost a MUST, but allows for the 261 possibility of loss of OBJECTID data in disaster recovery without 262 having to change UIDVALIDITY. 264 The server SHOULD return the same EMAILID for the exact same message 265 content in different folders after a COPY or [RFC6851] MOVE command. 267 The server MAY assign the same EMAILID as an existing message upon 268 APPEND if it detects that the new message has exactly identical 269 content to that existing message. 271 5.2. THREADID identifer for related messages 273 The THREADID data item is an objectid which uniquely identifies a set 274 of messages which the server believes should be grouped together when 275 presented. 277 THREADID calculation is generally based on some combination of 278 References, In-Reply-To and Subject, but the exact logic is left up 279 to the server implementation. [RFC5256] describes some algorithms 280 that MAY be used, however this specfication does not mandate any 281 particular strategy. 283 The server MUST return the same THREADID for all messages with the 284 same EMAILID. 286 The server SHOULD return the same THREADID for related messages even 287 if they are in different mailboxes. 289 THREADID is optional, if the server is unable to calculate 290 relationships between messages, it MUST return NIL to in all FETCH 291 responses for the THREADID data item, and a SEARCH for THREADID MUST 292 NOT match any messages. 294 The server MAY use the same objectid value for both EMAILID and 295 THREADID, for example the THREADID could be the EMAILID of the first 296 message that the server has seen in each thread. 298 5.3. New Message Data Items in FETCH and UID FETCH Commands 300 This document defines two FETCH items: 302 Syntax: EMAILID 304 The EMAILID message data item causes the server to return EMAILID 305 FETCH response data items. 307 Syntax: THREADID 309 The THREADID message data item causes the server to return THREADID 310 FETCH response data items. 312 And the following responses: 314 Syntax: EMAILID ( ) 316 The EMAILID response data item contains the server-assigned objectid 317 for each message. 319 Syntax: THREADID ( ) 321 The THREADID response data item contains the server-assigned objectid 322 for the set of related messages to which this message belongs. 324 Syntax: THREADID NIL 326 The NIL value to the THREADID response data item is returned when 327 the server mailbox does not support THREADID calculation. 329 Example: 331 C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733} 332 [...] 333 Subject: Message A 334 Message-ID: 335 [...] 336 S: 5 OK [APPENDUID 1521475658 1] Completed 338 C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793} 339 [...] 340 Subject: Re: Message A 341 Message-ID: 342 References: 343 [...] 344 S: 11 OK [APPENDUID 1521475658 2] Completed 346 C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736} 347 [...] 348 Subject: Message C 349 Message-ID: 350 [...] 351 S: 17 OK [APPENDUID 1521475658 3] Completed 353 C: 22 fetch 1:* (emailid threadid) 354 S: * 1 FETCH (EMAILID (M8976d99ac3275bb4e) THREADID (T4964b478a75b7ea9)) 355 S: * 2 FETCH (EMAILID (Md3c288836c4c7a762) THREADID (T4964b478a75b7ea9)) 356 S: * 3 FETCH (EMAILID (M2e25fdc09b49ea703) THREADID (T6311863d02dd95b5)) 357 S: 22 OK Completed (0.000 sec) 359 C: 23 move 2 foo 360 S: * OK [COPYUID 1521475659 2 1] Completed 361 S: * 2 EXPUNGE 362 S: 23 OK Completed 364 C: 24 fetch 1:* (emailid threadid) 365 S: * 1 FETCH (EMAILID (M8976d99ac3275bb4e) THREADID (T4964b478a75b7ea9)) 366 S: * 2 FETCH (EMAILID (M2e25fdc09b49ea703) THREADID (T6311863d02dd95b5)) 367 S: 24 OK Completed (0.000 sec) 368 C: 25 select "foo" 370 C: 25 select "foo" 371 [...] 372 S: 25 OK [READ-WRITE] Completed 373 C: 26 fetch 1:* (emailid threadid) 374 S: * 1 FETCH (EMAILID (Md3c288836c4c7a762) THREADID (T4964b478a75b7ea9)) 375 S: 26 OK Completed (0.000 sec) 377 Example: (no THREADID support) 378 C: 26 fetch 1:* (emailid threadid) 379 S: * 1 FETCH (EMAILID (M00000001) THREADID NIL) 380 S: * 2 FETCH (EMAILID (M00000002) THREADID NIL) 381 S: 26 OK Completed (0.000 sec) 383 6. New Filters on SEARCH command 385 This document defines filters EMAILID and THREADID on the SEARCH 386 command. 388 EMAILID 390 Messages whose EMAILID is exactly the specified objectid. 392 THREADID 394 Messages whose THREADID is exactly the specified objectid. 396 Example: (as if run before the MOVE above when the mailbox had 3 397 messages) 399 C: 27 search emailid M8976d99ac3275bb4e 400 S: * SEARCH 1 401 S: 27 OK Completed (1 msgs in 0.000 secs) 402 C: 28 search threadid T4964b478a75b7ea9 403 S: * SEARCH 1 2 404 S: 28 OK Completed (2 msgs in 0.000 secs) 406 7. Formal syntax 408 The following syntax specification uses the Augmented Backus-Naur 409 Form (ABNF) [RFC5234] notation. Elements not defined here can be 410 found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and 411 IMAP ABNF extensions [RFC4466] specifications. 413 Except as noted otherwise, all alphabetic characters are case- 414 insensitive. The use of upper- or lowercase characters to define 415 token strings is for editorial clarity only. Implementations MUST 416 accept these strings in a case-insensitive fashion. 418 capability =/ "OBJECTID" 420 fetch-att =/ "EMAILID" / "THREADID" 422 fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged- 423 ext production from [RFC4466] 424 fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID NIL 425 ; follows tagged-ext production from [RFC4466] 427 objectid = 1*255(ALPHA / DIGIT / "_" / "-") ; characters in object 428 identifiers are case ; significant 430 resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ; incorporated 431 before the expansion rule of ; atom [SP 1*] 432 ; that appears in [RFC3501] 434 search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid 436 status-att =/ "MAILBOXID" 438 status-att-value =/ "MAILBOXID" SP "(" objectid ")" ; follows tagged- 439 ext production from [RFC4466] 441 8. Implementation considerations 443 8.1. Assigning object identifiers 445 All objectid values are allocated by the server. 447 In the interests of reducing the possibilities of encoding mistakes, 448 objectids are restricted to a safe subset of possible byte values, 449 and in order to allow clients to allocate storage, they are 450 restricted in length. 452 An objectid is a string of 1 to 255 characters from the following set 453 of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. These characters are safe 454 to use in almost any context (e.g. filesystems, URIs, IMAP atoms). 456 For maximum safety, servers SHOULD also follow defensive allocation 457 strategies to avoid creating risks where glob completion or data type 458 detection may be present (e.g. on filesystems or in spreadsheets). 459 In particular it is wise to avoid: 461 o ids starting with - 463 o ids starting with digits 465 o ids which contain only digits 467 o ids which differ only by ASCII case (A vs a) 469 o the specific sequence of 3 characters NIL 470 A good solution to these issues is to prefix every ID with a single 471 alphabetical character. 473 8.2. Interaction with special cases 475 The case of RENAME INBOX may need special handling for unique ids. 477 It is advisable (though not required) to have MAILBOXID be globally 478 unique, but it is only required to be unique within messages offered 479 to a single client login to a single server hostname. For example, a 480 proxy which aggregates multiple independent servers MUST NOT 481 advertise the OBJECTID capability unless it can guarantee that the 482 backends will not use the same identifiers for different objects. 484 8.3. Client usage 486 Servers that implement both RFC 6154 and this specification SHOULD 487 optimize their execution of command like UID SEARCH OR EMAILID 1234 488 EMAILID 4321. 490 Clients can assume that searching the all-mail mailbox using OR/ 491 EMAILID or OR/THREADID is a fast way to find messages again if some 492 other client has moved them out of the mailbox where they were 493 previously seen. 495 Clients that cache data offline SHOULD fetch the EMAILID of all new 496 messages to avoid re-downloading already cached message details. 498 Clients SHOULD fetch the MAILBOXID for any new mailboxes before 499 discarding cache data for any mailbox which is no longer present on 500 the server, so that they can detect renames and avoid re-downloading 501 data. 503 9. Future considerations 505 This extension is intentionally defined to be compatible with the 506 data model in [I-D.ietf-jmap-mail]. 508 A future extension could be proposed to give a way to SELECT a 509 mailbox by MAILBOXID rather than name. 511 An extension to allow fetching message content directly via EMAILID 512 and message listings by THREADID could be proposed. 514 10. IANA Considerations 516 IANA is requested to add "OBJECTID" to the "IMAP Capabilities" 517 registry located at . 520 IANA is requested to add "MAILBOXID" to the "IMAP Response Codes" 521 registry located at with a Reference of [THIS RFC]. 524 11. Security Considerations 526 It is strongly advised that servers generate OBJECTIDs which are safe 527 to use as filesystem names, and unlikely to be auto-detected as 528 numbers. See implementation considerations. 530 If a digest is used for ID generation, it must have a collision 531 resistent property, so server implementations are advised to monitor 532 current security research and choose secure digests. 534 The use of a digest for ID generation may be used as proof that a 535 particular sequence of bytes was seen by the server. 537 12. Changes 539 To be removed by the editor before publication 541 12.1. draft-ietf-extra-imap-objectid-02 543 o added "Client usage" section 545 12.2. draft-ietf-extra-imap-objectid-01 547 o added "updates" for RFC3501 549 o fixed domains in thread example 551 o described threading in more detail 553 o added IANA request for Response Code 555 o clarified RFC2119 references 557 o simplified some waffle in wording 559 o added security consideration to choose good digest 561 o added MAILBOXID-UID suggestion for EMAILID generation 562 o updated ABNF normative reference to RFC5234 564 12.3. draft-ietf-extra-imap-objectid-00 566 o renamed draft to be objectid rather than uniqueid 568 o renamed UNIQUEID (capability) to OBJECTID 570 o restricted objectid to 64 safe characters 572 o added security considerations and advice about choosing objectid 574 o wrapped all responses in () for RFC4466 compatibility 576 o signifiant rewrite of all sections 578 12.4. draft-ietf-extra-imap-uniqueid-00 580 o renamed draft to be an EXTRA document 582 o added example for LIST RETURN STATUS 584 o started work on ABNF 586 o attempted to add response codes for EMAILID and THREADID 588 12.5. draft-gondwana-imap-uniqueid-01 590 o renamed UNIQUEID (status item) to MAILBOXID 592 o renamed MSGID to EMAILID 594 o renamed THRID to THREADID 596 o added TODO section 598 12.6. draft-gondwana-imap-uniqueid-00 600 o initial upload with names UNIQUEID/MSGID/THRID 602 13. Acknowledgments 604 The EXTRA working group at IETF. In particular feedback from Arnt 605 Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek. 607 The Gmail X-GM-THRID and X-GM-MSGID implementation as currently 608 defined at . 611 Dovecot X-GUID implementation. 613 13.1. Appendix 1: ideas for implementing object identifiers 615 Ideas for implementing MAILBOXID: 617 o Digest of (MailboxName/UIDVALIDITY) - not kept when renaming, but 618 is guaranteed unique and doesn't require storage. 620 o [RFC4122] UUID 622 o Server assigned sequence number (guaranteed not to be reused) 624 Ideas for implementing EMAILID: 626 o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying 627 messages, but is guaranteed unique and doesn't require storage. 629 o Concatenation of MAILBOXID-UID - for servers which store MAILBOXID 630 but not EMAILID. 632 o Digest of message content (RFC822 bytes) - expensive unless cached 634 o [RFC4122] UUID 636 o Server assigned sequence number (guaranteed not to be reused) 638 Ideas for implementing THREADID: 640 o Derive from EMAILID of first seen message in the thread. 642 o [RFC4122] UUID 644 o Server assigned sequence number (guaranteed not to be reused) 646 There is a need to index and look up reference/in-reply-to data at 647 message creation to efficiently find matching messages for threading. 648 Threading may be either across folders, or within each folder only. 649 The server has significant leeway here. 651 14. References 653 14.1. Normative References 655 [I-D.ietf-jmap-mail] 656 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-05 657 (work in progress), May 2018. 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, 661 DOI 10.17487/RFC2119, March 1997, 662 . 664 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 665 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 666 . 668 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 669 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 670 December 2005, . 672 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 673 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 674 . 676 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 677 Specifications: ABNF", STD 68, RFC 5234, 678 DOI 10.17487/RFC5234, January 2008, 679 . 681 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for 682 Returning STATUS Information in Extended LIST", RFC 5819, 683 DOI 10.17487/RFC5819, March 2010, 684 . 686 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 687 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 688 DOI 10.17487/RFC6851, January 2013, 689 . 691 14.2. Informative References 693 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 694 Unique IDentifier (UUID) URN Namespace", RFC 4122, 695 DOI 10.17487/RFC4122, July 2005, 696 . 698 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access 699 Protocol - SORT and THREAD Extensions", RFC 5256, 700 DOI 10.17487/RFC5256, June 2008, 701 . 703 Author's Address 705 Bron Gondwana (editor) 706 FastMail 707 Level 2, 114 William St 708 Melbourne VIC 3000 709 Australia 711 Email: brong@fastmailteam.com 712 URI: https://www.fastmail.com