--- 1/draft-ietf-extra-imap-objectid-05.txt 2018-07-19 14:13:10.629889654 -0700 +++ 2/draft-ietf-extra-imap-objectid-06.txt 2018-07-19 14:13:10.665890537 -0700 @@ -1,19 +1,19 @@ EXTRA B. Gondwana, Ed. Internet-Draft FastMail -Updates: 3501 (if approved) July 17, 2018 +Updates: 3501 (if approved) July 19, 2018 Intended status: Standards Track -Expires: January 18, 2019 +Expires: January 20, 2019 IMAP Extension for object identifiers - draft-ietf-extra-imap-objectid-05 + draft-ietf-extra-imap-objectid-06 Abstract This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 18, 2019. + This Internet-Draft will expire on January 20, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,29 +62,30 @@ 6. New Filters on SEARCH command . . . . . . . . . . . . . . . . 9 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Implementation considerations . . . . . . . . . . . . . . . . 10 8.1. Assigning object identifiers . . . . . . . . . . . . . . 10 8.2. Interaction with special cases . . . . . . . . . . . . . 11 8.3. Client usage . . . . . . . . . . . . . . . . . . . . . . 11 9. Future considerations . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 12.1. draft-ietf-extra-imap-objectid-05 . . . . . . . . . . . 12 - 12.2. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 13 - 12.3. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13 - 12.4. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 13 - 12.5. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 13 - 12.6. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14 - 12.7. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14 - 12.8. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 14 - 12.9. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 15 + 12.1. draft-ietf-extra-imap-objectid-06 . . . . . . . . . . . 12 + 12.2. draft-ietf-extra-imap-objectid-05 . . . . . . . . . . . 13 + 12.3. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 13 + 12.4. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13 + 12.5. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 14 + 12.6. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 14 + 12.7. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14 + 12.8. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14 + 12.9. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 15 + 12.10. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 15 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Appendix 1: ideas for implementing object identifiers . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 14.2. Informative References . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction IMAP stores are often used by many clients. Each client may cache @@ -141,22 +142,25 @@ The server MUST return the same MAILBOXID for a mailbox with the same name and UIDVALIDITY. The server MUST NOT report the same MAILBOXID for two mailboxes at the same time. The server MUST NOT reuse the same MAILBOXID for a mailbox which does not obey all the invarients that [RFC3501] defines for a mailbox which does not change name or UIDVALIDITY. - The server SHOULD NOT change MAILBOXID when renaming a folder, as - this loses the main benefit of having a unique identifier. + The server MUST keep the same MAILBOXID for the source and + destination when renaming a mailbox in a way which keeps the same + messages (but see [RFC3501] for the special case regarding renaming + of INBOX, which is treated as creating a new mailbox and moving the + messages) 4.1. New response code for CREATE This document extends the CREATE command to have the response code MAILBOXID on successful mailbox creation. A server advertising the OBJECTID capability MUST include the MAILBOXID response code in the tagged OK response to all successful CREATE commands. @@ -417,22 +421,24 @@ insensitive. The use of upper- or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "OBJECTID" fetch-att =/ "EMAILID" / "THREADID" fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged- ext production from [RFC4466] - fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID" NIL - ; follows tagged-ext production from [RFC4466] + fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil ) ; + follows tagged-ext production from [RFC4466] + + msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp objectid = 1*255(ALPHA / DIGIT / "_" / "-") ; characters in object identifiers are case ; significant resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ; incorporated before the expansion rule of ; atom [SP 1*] ; that appears in [RFC3501] search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid @@ -549,28 +555,39 @@ fetch the data directly. Servers that are expected to handle highly sensitive data should consider using a ID generation mechanism which doesn't derive from a digest. See also the security considerations in [RFC3501] section 11. 12. Changes To be removed by the editor before publication -12.1. draft-ietf-extra-imap-objectid-05 +12.1. draft-ietf-extra-imap-objectid-06 + + o fixed one more missing space in ABNF (ad review) + + o made one more MUST for mailbox being retained on rename (genart + review) + + o updated ABNF to also extend msg-att-static (validator review) + + o lowercased NIL => nil in ABNF (validator review) + +12.2. draft-ietf-extra-imap-objectid-05 o changed some SHOULD to lower case in advice sections (genart review) o clarified that THREADID MUST NOT change -12.2. draft-ietf-extra-imap-objectid-04 +12.3. draft-ietf-extra-imap-objectid-04 o described NIL THREADID in more detail (ad review) o made RFC5256 a normative reference (ad review) o fixed ABNF missing quote (ad review) o documented hash upgrade process (ad review) o referenced RFC3501 for INBOX rename (ad review) @@ -583,41 +600,42 @@ o remove suggested algorithms which are no longer legitimate (genart review) o updated proxy advice to suggest rewriting ids (genart review) o fixed minor gramatical issues (genart review) o required that EMAILID and THREADID are not identical (own decision) -12.3. draft-ietf-extra-imap-objectid-03 +12.4. draft-ietf-extra-imap-objectid-03 o added RFC3501 to Abstract o updated [[THIS RFC]] to not fail idnits o changed jmap-mail to be informative rather than normative o shortened IDs to stop wrapping and outdents in IMAP examples -12.4. draft-ietf-extra-imap-objectid-02 +12.5. draft-ietf-extra-imap-objectid-02 o added "Client usage" section -12.5. draft-ietf-extra-imap-objectid-01 +12.6. draft-ietf-extra-imap-objectid-01 o added "updates" for RFC3501 o fixed domains in thread example o described threading in more detail + o added IANA request for Response Code o clarified RFC2119 references o simplified some waffle in wording o added security consideration to choose good digest o added MAILBOXID-UID suggestion for EMAILID generation @@ -616,55 +634,55 @@ o clarified RFC2119 references o simplified some waffle in wording o added security consideration to choose good digest o added MAILBOXID-UID suggestion for EMAILID generation o updated ABNF normative reference to RFC5234 -12.6. draft-ietf-extra-imap-objectid-00 +12.7. draft-ietf-extra-imap-objectid-00 o renamed draft to be objectid rather than uniqueid o renamed UNIQUEID (capability) to OBJECTID o restricted objectid to 64 safe characters o added security considerations and advice about choosing objectid o wrapped all responses in () for RFC4466 compatibility o signifiant rewrite of all sections -12.7. draft-ietf-extra-imap-uniqueid-00 +12.8. draft-ietf-extra-imap-uniqueid-00 o renamed draft to be an EXTRA document o added example for LIST RETURN STATUS o started work on ABNF o attempted to add response codes for EMAILID and THREADID -12.8. draft-gondwana-imap-uniqueid-01 +12.9. draft-gondwana-imap-uniqueid-01 o renamed UNIQUEID (status item) to MAILBOXID o renamed MSGID to EMAILID o renamed THRID to THREADID o added TODO section -12.9. draft-gondwana-imap-uniqueid-00 +12.10. draft-gondwana-imap-uniqueid-00 o initial upload with names UNIQUEID/MSGID/THRID 13. Acknowledgments The EXTRA working group at IETF. In particular feedback from Arnt Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek. The Gmail X-GM-THRID and X-GM-MSGID implementation as currently defined at