idnits 2.17.00 (12 Aug 2021) /tmp/idnits20065/draft-ietf-extra-imap-objectid-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 24, 2018) is 1487 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 190, but not defined == Missing Reference: 'THIS RFC' is mentioned on line 509, but not defined == Outdated reference: draft-ietf-jmap-mail has been published as RFC 8621 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EXTRA B. Gondwana 3 Internet-Draft FastMail 4 Intended status: Standards Track April 24, 2018 5 Expires: October 26, 2018 7 IMAP Extension for object identifiers 8 draft-ietf-extra-imap-objectid-01 10 Abstract 12 This document adds new properties to IMAP mailboxes and messages to 13 allow clients to more efficiently re-use cached data for resources 14 which have changed location on the server. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 26, 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. MAILBOXID object identifier . . . . . . . . . . . . . . . . . 3 54 4.1. New response code for CREATE . . . . . . . . . . . . . . 4 55 4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4 56 4.3. New attribute for STATUS . . . . . . . . . . . . . . . . 5 57 5. EMAILID object identifier and THREADID correlator . . . . . . 6 58 5.1. EMAILID identifier for identical messages . . . . . . . . 6 59 5.2. THREADID identifer for related messages . . . . . . . . . 6 60 5.3. New Message Data Items in FETCH and UID FETCH Commands . 7 61 6. New Filters on SEARCH command . . . . . . . . . . . . . . . . 9 62 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. Implementation considerations . . . . . . . . . . . . . . . . 10 64 8.1. Assigning object identifiers . . . . . . . . . . . . . . 10 65 8.2. Interaction with special cases . . . . . . . . . . . . . 11 66 9. Future considerations . . . . . . . . . . . . . . . . . . . . 11 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 12.1. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 12 71 12.2. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 12 72 12.3. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 13 73 12.4. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 13 74 12.5. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 13 75 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 13.1. Appendix 1: ideas for implementing object identifiers . 13 77 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 14.2. Informative References . . . . . . . . . . . . . . . . . 15 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 IMAP stores are often used by many clients. Each client may cache 85 data from the server so that they don't need to re-download 86 information. [RFC3501] defines that a mailbox can be uniquely 87 referenced by its name and UIDVALIDITY, and a message within that 88 mailbox can be uniquely referenced by its mailbox (name + 89 UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and 90 UID is guaranteed to be immutable. 92 [RFC4315] defines a COPYUID response which allows a client which 93 copies messages to know the mapping between the UIDs in the source 94 and destination mailboxes, and hence update its local cache. 96 If a mailbox is successfully renamed, the client knows that the same 97 messages exist in the destination mailbox name as previously existed 98 in the source mailbox name. 100 The result is that the client which copies (or [RFC6851] moves) 101 messages or renames a mailbox can update its local cache, but any 102 other client connected to the same store can not know with certainty 103 that the messages are identical, and so will re-download everything. 105 This extension adds new properties to a message (EMAILID) and mailbox 106 (MAILBOXID) which allow a client to quickly identify messages or 107 mailboxes which have been renamed by another client. 109 This extension also adds an optional thread identifier (THREADID) to 110 messages, which can be used by the server to indicate messages which 111 it has identified to be related. 113 2. Conventions Used In This Document 115 In examples, "C:" indicates lines sent by a client that is connected 116 to a server. "S:" indicates lines sent by the server to the client. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119] when they 121 appear in ALL CAPS. These words may also appear in this document in 122 lower case as plain English words, absent their normative meanings. 124 3. CAPABILITY Identification 126 IMAP servers that support this extension MUST include "OBJECTID" in 127 the response list to the CAPABILITY command. 129 4. MAILBOXID object identifier 131 The MAILBOXID is a server-allocated unique identifer for each 132 mailbox. 134 The server SHOULD return the same MAILBOXID for a server with the 135 same mailbox name and UIDVALIDITY. This is almost MUST, but weakened 136 to allow for the possibility of loss of OBJECTID data during disaster 137 recovery while still keeping the name and UIDVALIDITY the same. 139 The server MUST NOT report the same MAILBOXID for two mailboxes at 140 the same time. 142 The server MUST NOT reuse the same MAILBOXID for a mailbox which does 143 not obey all the invarients that [RFC3501] defines for a mailbox 144 which does not change name or UIDVALIDITY. 146 The server MAY choose to create a MAILBOXID value in a way that does 147 not survive RENAME (e.g. a digest of name + uidvalidity could be 148 used), however the client then loses the major benefit of having an 149 identifier. 151 4.1. New response code for CREATE 153 This document extends the CREATE command to have the response code 154 MAILBOXID on successful mailbox creation. 156 A server advertising the OBJECTID capability MUST include the 157 MAILBOXID response code in the tagged OK response to all successful 158 CREATE commands. 160 Syntax: "MAILBOXID" SP "(" ")" 162 Response code in tagged OK for successful CREATE command. 164 Example: 166 C: 3 create foo 167 S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)] Completed 168 C: 4 create bar 169 S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)] Completed 170 C: 5 create foo 171 S: 5 NO Mailbox already exists 173 4.2. New OK Untagged Response for SELECT and EXAMINE 175 This document adds a new untagged response code to the SELECT and 176 EXAMINE commands. 178 A server advertising the OBJECTID capability MUST return an untagged 179 OK response with the MAILBOXID response code on all successful SELECT 180 and EXAMINE commands. 182 Syntax: "OK" SP "[" "MAILBOXID" SP "(" ")" "]" text 184 Untagged OK response to SELECT or EXAMINE. 186 Example: 188 C: 27 select "foo" 189 [...] 190 S: * OK [UIDVALIDITY 1524195797] Ok 191 S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)] Ok 192 [...] 193 S: 27 OK [READ-WRITE] Completed 195 4.3. New attribute for STATUS 197 This document adds the MAILBOXID attribute to the STATUS command 198 using the extended syntax defined in [RFC4466]. 200 A server that advertises the OBJECTID capability MUST support the 201 MAILBOXID status attribute. 203 Syntax: "MAILBOXID" 205 The attribute in the STATUS command. 207 Syntax: "MAILBOXID" SP "(" ")" 209 The response item in the STATUS response contains the objectid 210 assigned by the server for this mailbox. 212 Example: 214 C: 6 status foo (mailboxid) 215 S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)) 216 S: 6 OK Completed 217 C: 7 status bar (mailboxid) 218 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)) 219 S: 7 OK Completed 220 C: 8 rename foo renamed 221 S: * OK rename foo renamed 222 S: 8 OK Completed 223 C: 9 status renamed (mailboxid) 224 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)) 225 S: 9 OK Completed 226 C: 10 status bar (mailboxid) 227 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)) 228 S: 10 OK Completed 230 When the LIST-STATUS IMAP capability defined in [RFC5819] is also 231 available, the STATUS command can be combined with the LIST command. 233 Example: 235 C: 11 list "" "*" return (status (mailboxid)) 236 S: * LIST (\HasNoChildren) "." INBOX 237 S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf)) 238 S: * LIST (\HasNoChildren) "." bar 239 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)) 240 S: * LIST (\HasNoChildren) "." renamed 241 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)) 242 S: 11 OK Completed (0.001 secs 3 calls) 244 5. EMAILID object identifier and THREADID correlator 246 This document defines the data items EMAILID and THREADID on 247 messages. 249 5.1. EMAILID identifier for identical messages 251 The EMAILID data item is an objectid which uniquely identifies the 252 content of a single message. Anything which must remain immutable on 253 a {name, uidvalidity, uid} triple must also be the same between 254 messages with the same EMAILID. 256 The server SHOULD return the same EMAILID for the same UID triple. 257 As with MAILBOXID above, this is almost a MUST, but allows for the 258 possibility of loss of OBJECTID data in disaster recovery without 259 having to change UIDVALIDITY. 261 The server SHOULD return the same EMAILID for the exact same message 262 content in different folders after a COPY or [RFC6851] MOVE command. 264 The server MAY assign the same EMAILID as an existing message upon 265 APPEND if it detects that the new message has exactly identical 266 content to that existing message. 268 5.2. THREADID identifer for related messages 270 The THREADID data item is an objectid which uniquely identifies a set 271 of messages which the server believes should be grouped together when 272 presented. 274 THREADID calculation is generally based on some combination of 275 References, In-Reply-To and Subject, but the exact logic is left up 276 to the server implementation. [RFC5256] describes some algorithms 277 that MAY be used, however this specfication does not mandate any 278 particular strategy. 280 The server MUST return the same THREADID for all messages with the 281 same EMAILID. 283 The server SHOULD return the same THREADID for related messages even 284 if they are in different mailboxes. 286 THREADID is optional, if the server is unable to calculate 287 relationships between messages, it MUST return NIL to in all FETCH 288 responses for the THREADID data item, and a SEARCH for THREADID MUST 289 NOT match any messages. 291 The server MAY use the same objectid value for both EMAILID and 292 THREADID, for example the THREADID could be the EMAILID of the first 293 message that the server has seen in each thread. 295 5.3. New Message Data Items in FETCH and UID FETCH Commands 297 This document defines two FETCH items: 299 Syntax: EMAILID 301 The EMAILID message data item causes the server to return EMAILID 302 FETCH response data items. 304 Syntax: THREADID 306 The THREADID message data item causes the server to return THREADID 307 FETCH response data items. 309 And the following responses: 311 Syntax: EMAILID ( ) 313 The EMAILID response data item contains the server-assigned objectid 314 for each message. 316 Syntax: THREADID ( ) 318 The THREADID response data item contains the server-assigned objectid 319 for the set of related messages to which this message belongs. 321 Syntax: THREADID NIL 323 The NIL value to the THREADID response data item is returned when 324 the server mailbox does not support THREADID calculation. 326 Example: 328 C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733} 329 [...] 330 Subject: Message A 331 Message-ID: 332 [...] 333 S: 5 OK [APPENDUID 1521475658 1] Completed 335 C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793} 336 [...] 337 Subject: Re: Message A 338 Message-ID: 339 References: 340 [...] 341 S: 11 OK [APPENDUID 1521475658 2] Completed 343 C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736} 344 [...] 345 Subject: Message C 346 Message-ID: 347 [...] 348 S: 17 OK [APPENDUID 1521475658 3] Completed 350 C: 22 fetch 1:* (emailid threadid) 351 S: * 1 FETCH (EMAILID (M8976d99ac3275bb4e) THREADID (T4964b478a75b7ea9)) 352 S: * 2 FETCH (EMAILID (Md3c288836c4c7a762) THREADID (T4964b478a75b7ea9)) 353 S: * 3 FETCH (EMAILID (M2e25fdc09b49ea703) THREADID (T6311863d02dd95b5)) 354 S: 22 OK Completed (0.000 sec) 356 C: 23 move 2 foo 357 S: * OK [COPYUID 1521475659 2 1] Completed 358 S: * 2 EXPUNGE 359 S: 23 OK Completed 361 C: 24 fetch 1:* (emailid threadid) 362 S: * 1 FETCH (EMAILID (M8976d99ac3275bb4e) THREADID (T4964b478a75b7ea9)) 363 S: * 2 FETCH (EMAILID (M2e25fdc09b49ea703) THREADID (T6311863d02dd95b5)) 364 S: 24 OK Completed (0.000 sec) 365 C: 25 select "foo" 367 C: 25 select "foo" 368 [...] 369 S: 25 OK [READ-WRITE] Completed 370 C: 26 fetch 1:* (emailid threadid) 371 S: * 1 FETCH (EMAILID (Md3c288836c4c7a762) THREADID (T4964b478a75b7ea9)) 372 S: 26 OK Completed (0.000 sec) 374 Example: (no THREADID support) 375 C: 26 fetch 1:* (emailid threadid) 376 S: * 1 FETCH (EMAILID (M00000001) THREADID NIL) 377 S: * 2 FETCH (EMAILID (M00000002) THREADID NIL) 378 S: 26 OK Completed (0.000 sec) 380 6. New Filters on SEARCH command 382 This document defines filters EMAILID and THREADID on the SEARCH 383 command. 385 EMAILID 387 Messages whose EMAILID is exactly the specified objectid. 389 THREADID 391 Messages whose THREADID is exactly the specified objectid. 393 Example: (as if run before the MOVE above when the mailbox had 3 394 messages) 396 C: 27 search emailid M8976d99ac3275bb4e 397 S: * SEARCH 1 398 S: 27 OK Completed (1 msgs in 0.000 secs) 399 C: 28 search threadid T4964b478a75b7ea9 400 S: * SEARCH 1 2 401 S: 28 OK Completed (2 msgs in 0.000 secs) 403 7. Formal syntax 405 The following syntax specification uses the Augmented Backus-Naur 406 Form (ABNF) [RFC5234] notation. Elements not defined here can be 407 found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and 408 IMAP ABNF extensions [RFC4466] specifications. 410 Except as noted otherwise, all alphabetic characters are case- 411 insensitive. The use of upper- or lowercase characters to define 412 token strings is for editorial clarity only. Implementations MUST 413 accept these strings in a case-insensitive fashion. 415 capability =/ "OBJECTID" 417 fetch-att =/ "EMAILID" / "THREADID" 419 fetch-emailid-resp = "EMAILID" SP "(" objectid ")" 421 ; follows tagged-ext production from [@!RFC4466] 423 fetch-threadid-resp = "THREADID" SP "(" objectid ")" / 425 "THREADID NIL 426 ; follows tagged-ext production from [@!RFC4466] 428 objectid = 1*255(ALPHA / DIGIT / "_" / "-") 430 ; characters in object identifiers are case 431 ; significant 433 resp-text-code =/ "MAILBOXID" SP "(" objectid ")" 435 ; incorporated before the expansion rule of 436 ; atom [SP 1*<any TEXT-CHAR except "]">] 437 ; that appears in [@!RFC3501] 439 search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid 441 status-att =/ "MAILBOXID" 443 status-att-value =/ "MAILBOXID" SP "(" objectid ")" 445 ; follows tagged-ext production from [@!RFC4466] 447 8. Implementation considerations 449 8.1. Assigning object identifiers 451 All objectid values are allocated by the server. 453 In the interests of reducing the possibilities of encoding mistakes, 454 objectids are restricted to a safe subset of possible byte values, 455 and in order to allow clients to allocate storage, they are 456 restricted in length. 458 An objectid is a string of 1 to 255 characters from the following set 459 of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. These characters are safe 460 to use in almost any context (e.g. filesystems, URIs, IMAP atoms). 462 For maximum safety, servers SHOULD also follow defensive allocation 463 strategies to avoid creating risks where glob completion or data type 464 detection may be present (e.g. on filesystems or in spreadsheets). 465 In particular it is wise to avoid: 467 o ids starting with - 469 o ids starting with digits 470 o ids which contain only digits 472 o ids which differ only by ASCII case (A vs a) 474 o the specific sequence of 3 characters NIL 476 A good solution to these issues is to prefix every ID with a single 477 alphabetical character. 479 8.2. Interaction with special cases 481 The case of RENAME INBOX may need special handling for unique ids. 483 It is advisable (though not required) to have MAILBOXID be globally 484 unique, but it is only required to be unique within messages offered 485 to a single client login to a single server hostname. For example, a 486 proxy which aggregates multiple independent servers MUST NOT 487 advertise the OBJECTID capability unless it can guarantee that the 488 backends will not use the same identifiers for different objects. 490 9. Future considerations 492 This extension is intentionally defined to be compatible with the 493 data model in [I-D.ietf-jmap-mail]. 495 A future extension could be proposed to give a way to SELECT a 496 mailbox by MAILBOXID rather than name. 498 An extension to allow fetching message content directly via EMAILID 499 and message listings by THREADID could be proposed. 501 10. IANA Considerations 503 IANA is requested to add "OBJECTID" to the "IMAP Capabilities" 504 registry located at . 507 IANA is requested to add "MAILBOXID" to the "IMAP Response Codes" 508 registry located at with a Reference of [THIS RFC]. 511 11. Security Considerations 513 It is strongly advised that servers generate OBJECTIDs which are safe 514 to use as filesystem names, and unlikely to be auto-detected as 515 numbers. See implementation considerations. 517 If a digest is used for ID generation, it must have a collision 518 resistent property, so server implementations are advised to monitor 519 current security research and choose secure digests. 521 The use of a digest for ID generation may be used as proof that a 522 particular sequence of bytes was seen by the server. 524 12. Changes 526 To be removed by the editor before publication 528 12.1. draft-ietf-extra-imap-objectid-01 530 o added "updates" for RFC3501 532 o fixed domains in thread example 534 o described threading in more detail 536 o added IANA request for Response Code 538 o clarified RFC2119 references 540 o simplified some waffle in wording 542 o added security consideration to choose good digest 544 o added MAILBOXID-UID suggestion for EMAILID generation 546 o updated ABNF normative reference to RFC5234 548 12.2. draft-ietf-extra-imap-objectid-00 550 o renamed draft to be objectid rather than uniqueid 552 o renamed UNIQUEID (capability) to OBJECTID 554 o restricted objectid to 64 safe characters 556 o added security considerations and advice about choosing objectid 558 o wrapped all responses in () for RFC4466 compatibility 560 o signifiant rewrite of all sections 562 12.3. draft-ietf-extra-imap-uniqueid-00 564 o renamed draft to be an EXTRA document 566 o added example for LIST RETURN STATUS 568 o started work on ABNF 570 o attempted to add response codes for EMAILID and THREADID 572 12.4. draft-gondwana-imap-uniqueid-01 574 o renamed UNIQUEID (status item) to MAILBOXID 576 o renamed MSGID to EMAILID 578 o renamed THRID to THREADID 580 o added TODO section 582 12.5. draft-gondwana-imap-uniqueid-00 584 o initial upload with names UNIQUEID/MSGID/THRID 586 13. Acknowledgments 588 The EXTRA working group at IETF. In particular feedback from Arnt 589 Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek. 591 The Gmail X-GM-THRID and X-GM-MSGID implementation as currently 592 defined at . 595 Dovecot X-GUID implementation. 597 13.1. Appendix 1: ideas for implementing object identifiers 599 Ideas for implementing MAILBOXID: 601 o Digest of (MailboxName/UIDVALIDITY) - not kept when renaming, but 602 is guaranteed unique and doesn't require storage. 604 o [RFC4122] UUID 606 o Server assigned sequence number (guaranteed not to be reused) 608 Ideas for implementing EMAILID: 610 o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying 611 messages, but is guaranteed unique and doesn't require storage. 613 o Concatenation of MAILBOXID-UID - for servers which store MAILBOXID 614 but not EMAILID. 616 o Digest of message content (RFC822 bytes) - expensive unless cached 618 o [RFC4122] UUID 620 o Server assigned sequence number (guaranteed not to be reused) 622 Ideas for implementing THREADID: 624 o Derive from EMAILID of first seen message in the thread. 626 o [RFC4122] UUID 628 o Server assigned sequence number (guaranteed not to be reused) 630 There is a need to index and look up reference/in-reply-to data at 631 message creation to efficiently find matching messages for threading. 632 Threading may be either across folders, or within each folder only. 633 The server has significant leeway here. 635 14. References 637 14.1. Normative References 639 [I-D.ietf-jmap-mail] 640 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-04 641 (work in progress), March 2018. 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 649 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 650 . 652 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 653 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 654 December 2005, . 656 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 657 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 658 . 660 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 661 Specifications: ABNF", STD 68, RFC 5234, 662 DOI 10.17487/RFC5234, January 2008, 663 . 665 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for 666 Returning STATUS Information in Extended LIST", RFC 5819, 667 DOI 10.17487/RFC5819, March 2010, 668 . 670 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 671 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 672 DOI 10.17487/RFC6851, January 2013, 673 . 675 14.2. Informative References 677 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 678 Unique IDentifier (UUID) URN Namespace", RFC 4122, 679 DOI 10.17487/RFC4122, July 2005, 680 . 682 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access 683 Protocol - SORT and THREAD Extensions", RFC 5256, 684 DOI 10.17487/RFC5256, June 2008, 685 . 687 Author's Address 689 Bron Gondwana 690 FastMail 691 Level 2, 114 William St 692 Melbourne VIC 3000 693 Australia 695 Email: brong@fastmailteam.com 696 URI: https://www.fastmail.com