Skip to main content

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
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]