IMAP Extension for object identifiers
draft-ietf-extra-imap-objectid-07
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8474.
|
|
---|---|---|---|
Author | Bron Gondwana | ||
Last updated | 2018-07-31 | ||
Replaces | draft-ietf-extra-imap-uniqueid | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Telechat review
(of
-06)
by Pete Resnick
Ready w/nits
GENART Last Call review
(of
-03)
by Pete Resnick
Almost ready
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Jiankang Yao | ||
Shepherd write-up | Show Last changed 2018-06-21 | ||
IESG | IESG state | Became RFC 8474 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date |
(None)
Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Alexey Melnikov | ||
Send notices to | Jiankang Yao <yaojk@cnnic.cn>;aamelnikov@fastmail.fm | ||
IANA | IANA review state | IANA OK - Actions Needed |
draft-ietf-extra-imap-objectid-07
#x27;-'. 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 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: Gondwana Expires February 1, 2019 [Page 10] Internet-Draft IMAP ObjectID July 2018 o ids starting with - o ids starting with digits o ids which contain only digits o ids which differ only by ASCII case (A vs a) o the specific sequence of 3 characters NIL A good solution to these issues is to prefix every ID with a single alphabetical character. 8.2. Interaction with special cases The case of RENAME INBOX may need special handling, as it has special behaviour as defined in [RFC3501] section 6.3.5. 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 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 messages to avoid re-downloading already cached message details. 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. Gondwana Expires February 1, 2019 [Page 11] Internet-Draft IMAP ObjectID July 2018 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 mailbox by MAILBOXID rather than name. A future extension to [RFC5228] could allow fileinto by MAILBOXID rather than name. An extension to allow fetching message content directly via EMAILID and message listings by THREADID could be proposed. 10. IANA Considerations IANA is requested to add "OBJECTID" to the "IMAP Capabilities" registry located at <http://www.iana.org/assignments/imap- capabilities> with a Reference of [[THIS RFC]]. IANA is requested to add "MAILBOXID" to the "IMAP Response Codes" registry located at <https://www.iana.org/assignments/imap-response- codes> with a Reference of [[THIS RFC]]. 11. Security Considerations It is strongly advised that servers generate OBJECTIDs which are safe to use as filesystem names, and unlikely to be auto-detected as numbers. See implementation considerations. If a digest is used for ID generation, it must have a collision resistent property, so server implementations are advised to monitor current security research and choose secure digests. As the IDs are generated by the server, it will be possible to migrate to a new hash by just using the new algorith when creating new IDs. This is particularly true if a prefix is used on each ID, which can be changed when the algorithm changes. The use of a digest for ID generation may be used as proof that a particular sequence of bytes was seen by the server, however this is only a risk if IDs are leaked to clients who don't have permission to 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. Gondwana Expires February 1, 2019 [Page 12] Internet-Draft IMAP ObjectID July 2018 12. Changes To be removed by the editor before publication 12.1. draft-ietf-extra-imap-objectid-07 o updated boilerplate to RFC8174 (Benjamin Kaduk review) o fixed spelling of invariants (Benjamin Kaduk review) o block quoted ABNF for better text formatting (Benjamin Kaduk review) o clarified that servers can just switch to a new digest without changing old IDs (Benjamin Kaduk review) o changed use of folder to mailbox to avoid confusion (Warren Kumari review) o made both IANA requests say "reference of this RFC" (Warren Kumari review) 12.2. 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.3. 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.4. 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) Gondwana Expires February 1, 2019 [Page 13] Internet-Draft IMAP ObjectID July 2018 o documented hash upgrade process (ad review) o referenced RFC3501 for INBOX rename (ad review) o referenced RFC3501 security considerations (secdir review) o turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability (genart review) 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.5. 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.6. draft-ietf-extra-imap-objectid-02 o added "Client usage" section 12.7. 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 Gondwana Expires February 1, 2019 [Page 14] Internet-Draft IMAP ObjectID July 2018 o added MAILBOXID-UID suggestion for EMAILID generation o updated ABNF normative reference to RFC5234 12.8. 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.9. 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.10. 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.11. 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. Gondwana Expires February 1, 2019 [Page 15] Internet-Draft IMAP ObjectID July 2018 The Gmail X-GM-THRID and X-GM-MSGID implementation as currently defined at <https://developers.google.com/gmail/imap/imap- extensions>. Dovecot X-GUID implementation. 13.1. Appendix 1: ideas for implementing object identifiers Ideas for calculating MAILBOXID: o [RFC4122] UUID o Server assigned sequence number (guaranteed not to be reused) Ideas for implementing EMAILID: o Digest of message content (RFC822 bytes) - expensive unless cached o [RFC4122] UUID o Server assigned sequence number (guaranteed not to be reused) Ideas for implementing THREADID: o Derive from EMAILID of first seen message in the thread. o [RFC4122] UUID o Server assigned sequence number (guaranteed not to be reused) There is a need to index and look up reference/in-reply-to data at message creation to efficiently find matching messages for threading. Threading may be either across mailboxes, or within each mailbox only. The server has significant leeway here. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>. Gondwana Expires February 1, 2019 [Page 16] Internet-Draft IMAP ObjectID July 2018 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, December 2005, <https://www.rfc-editor.org/info/rfc4315>. [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, <https://www.rfc-editor.org/info/rfc4466>. [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, <https://www.rfc-editor.org/info/rfc5228>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, DOI 10.17487/RFC5256, June 2008, <https://www.rfc-editor.org/info/rfc5256>. [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for Returning STATUS Information in Extended LIST", RFC 5819, DOI 10.17487/RFC5819, March 2010, <https://www.rfc-editor.org/info/rfc5819>. [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, <https://www.rfc-editor.org/info/rfc6851>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 14.2. Informative References [I-D.ietf-jmap-mail] Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-06 (work in progress), July 2018. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>. Gondwana Expires February 1, 2019 [Page 17] Internet-Draft IMAP ObjectID July 2018 Author's Address Bron Gondwana (editor) FastMail Level 2, 114 William St Melbourne VIC 3000 Australia Email: brong@fastmailteam.com URI: https://www.fastmail.com Gondwana Expires February 1, 2019 [Page 18]