--- 1/draft-ietf-extra-imap-objectid-04.txt 2018-07-17 14:13:23.556684707 -0700 +++ 2/draft-ietf-extra-imap-objectid-05.txt 2018-07-17 14:13:23.592685582 -0700 @@ -1,19 +1,19 @@ EXTRA B. Gondwana, Ed. Internet-Draft FastMail Updates: 3501 (if approved) July 17, 2018 Intended status: Standards Track Expires: January 18, 2019 IMAP Extension for object identifiers - draft-ietf-extra-imap-objectid-04 + draft-ietf-extra-imap-objectid-05 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 @@ -62,34 +62,35 @@ 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-04 . . . . . . . . . . . 12 - 12.2. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13 - 12.3. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 13 - 12.4. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 13 - 12.5. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14 - 12.6. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14 - 12.7. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 14 - 12.8. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 14 - 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 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 + 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Appendix 1: ideas for implementing object identifiers . 15 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 - 14.2. Informative References . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 + 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 data from the server so that they don't need to re-download information. [RFC3501] defines that a mailbox can be uniquely referenced by its name and UIDVALIDITY, and a message within that mailbox can be uniquely referenced by its mailbox (name + UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and UID is guaranteed to be immutable. @@ -278,20 +279,22 @@ to the server implementation. [RFC5256] describes some algorithms that could be used, however this specfication does not mandate any particular strategy. The server MUST return the same THREADID for all messages with the same EMAILID. The server SHOULD return the same THREADID for related messages even if they are in different mailboxes. + The server MUST NOT change the THREADID of a message once reported. + THREADID is optional, if the server doesn't support THREADID or is unable to calculate relationships between messages, it MUST return NIL to all FETCH responses for the THREADID data item, and a SEARCH for THREADID MUST NOT match any messages. The server MUST NOT use the same objectid value for both EMAILIDs and THREADIDs. If they are stored with the same value internally, the server can generate prefixed values (as shown in the examples below with M and T prefixes) to avoid clashes. @@ -446,21 +449,21 @@ In the interests of reducing the possibilities of encoding mistakes, objectids are restricted to a safe subset of possible byte values, and in order to allow clients to allocate storage, they are restricted in length. An objectid is a string of 1 to 255 characters from the following set of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. These characters are safe to use in almost any context (e.g. filesystems, URIs, IMAP atoms). - For maximum safety, servers SHOULD also follow defensive allocation + For maximum safety, servers should also follow defensive allocation strategies to avoid creating risks where glob completion or data type detection may be present (e.g. on filesystems or in spreadsheets). In particular it is wise to avoid: o ids starting with - o ids starting with digits o ids which contain only digits @@ -478,33 +481,33 @@ It is advisable (though not required) to have MAILBOXID be globally unique, but it is only required to be unique within messages offered to a single client login to a single server hostname. For example, a proxy which aggregates multiple independent servers MUST NOT advertise the OBJECTID capability unless it can guarantee that different objects will never use the same identifiers, even if backend object collide. 8.3. Client usage - Servers that implement both RFC 6154 and this specification SHOULD + Servers that implement both RFC 6154 and this specification should optimize their execution of command like UID SEARCH OR EMAILID 1234 EMAILID 4321. Clients can assume that searching the all-mail mailbox using OR/ EMAILID or OR/THREADID is a fast way to find messages again if some other client has moved them out of the mailbox where they were previously seen. - Clients that cache data offline SHOULD fetch the EMAILID of all new + Clients that cache data offline should fetch the EMAILID of all new messages to avoid re-downloading already cached message details. - Clients SHOULD fetch the MAILBOXID for any new mailboxes before + Clients should fetch the MAILBOXID for any new mailboxes before discarding cache data for any mailbox which is no longer present on the server, so that they can detect renames and avoid re-downloading data. 9. Future considerations This extension is intentionally defined to be compatible with the data model in [I-D.ietf-jmap-mail]. A future extension could be proposed to give a way to SELECT a @@ -546,21 +549,28 @@ 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-04 +12.1. 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 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) @@ -572,42 +583,41 @@ 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.2. draft-ietf-extra-imap-objectid-03 +12.3. 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.3. draft-ietf-extra-imap-objectid-02 +12.4. draft-ietf-extra-imap-objectid-02 o added "Client usage" section -12.4. draft-ietf-extra-imap-objectid-01 +12.5. 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 @@ -606,55 +616,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.5. draft-ietf-extra-imap-objectid-00 +12.6. 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.6. draft-ietf-extra-imap-uniqueid-00 +12.7. 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.7. draft-gondwana-imap-uniqueid-01 +12.8. 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.8. draft-gondwana-imap-uniqueid-00 +12.9. 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