< draft-ietf-extra-imap-objectid-04.txt		draft-ietf-extra-imap-objectid-05.txt >
	EXTRA B. Gondwana, Ed.		EXTRA B. Gondwana, Ed.
	Internet-Draft FastMail		Internet-Draft FastMail
	Updates: 3501 (if approved) July 17, 2018		Updates: 3501 (if approved) July 17, 2018
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 18, 2019		Expires: January 18, 2019
	IMAP Extension for object identifiers		IMAP Extension for object identifiers
	draft-ietf-extra-imap-objectid-04		draft-ietf-extra-imap-objectid-05
	Abstract		Abstract
	This document updates RFC3501 (IMAP4rev1) with persistent identifiers		This document updates RFC3501 (IMAP4rev1) with persistent identifiers
	on mailboxes and messages to allow clients to more efficiently re-use		on mailboxes and messages to allow clients to more efficiently re-use
	cached data when resources have changed location on the server.		cached data when resources have changed location on the server.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	6. New Filters on SEARCH command . . . . . . . . . . . . . . . . 9		6. New Filters on SEARCH command . . . . . . . . . . . . . . . . 9
	7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Implementation considerations . . . . . . . . . . . . . . . . 10		8. Implementation considerations . . . . . . . . . . . . . . . . 10
	8.1. Assigning object identifiers . . . . . . . . . . . . . . 10		8.1. Assigning object identifiers . . . . . . . . . . . . . . 10
	8.2. Interaction with special cases . . . . . . . . . . . . . 11		8.2. Interaction with special cases . . . . . . . . . . . . . 11
	8.3. Client usage . . . . . . . . . . . . . . . . . . . . . . 11		8.3. Client usage . . . . . . . . . . . . . . . . . . . . . . 11
	9. Future considerations . . . . . . . . . . . . . . . . . . . . 11		9. Future considerations . . . . . . . . . . . . . . . . . . . . 11
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 12		11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	12.1. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 12		12.1. draft-ietf-extra-imap-objectid-05 . . . . . . . . . . . 12
	12.2. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13		12.2. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 13
	12.3. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 13		12.3. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13
	12.4. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 13		12.4. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 13
	12.5. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14		12.5. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 13
	12.6. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14		12.6. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14
	12.7. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 14		12.7. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14
	12.8. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 14		12.8. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 14
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		12.9. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 15
			13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	13.1. Appendix 1: ideas for implementing object identifiers . 15		13.1. Appendix 1: ideas for implementing object identifiers . 15
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	14.1. Normative References . . . . . . . . . . . . . . . . . . 15		14.1. Normative References . . . . . . . . . . . . . . . . . . 16
	14.2. Informative References . . . . . . . . . . . . . . . . . 16		14.2. Informative References . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	IMAP stores are often used by many clients. Each client may cache		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		data from the server so that they don't need to re-download
	information. [RFC3501] defines that a mailbox can be uniquely		information. [RFC3501] defines that a mailbox can be uniquely
	referenced by its name and UIDVALIDITY, and a message within that		referenced by its name and UIDVALIDITY, and a message within that
	mailbox can be uniquely referenced by its mailbox (name +		mailbox can be uniquely referenced by its mailbox (name +
	UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and		UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and
	UID is guaranteed to be immutable.		UID is guaranteed to be immutable.
	skipping to change at page 7, line 8 ¶		skipping to change at page 7, line 8 ¶
	to the server implementation. [RFC5256] describes some algorithms		to the server implementation. [RFC5256] describes some algorithms
	that could be used, however this specfication does not mandate any		that could be used, however this specfication does not mandate any
	particular strategy.		particular strategy.
	The server MUST return the same THREADID for all messages with the		The server MUST return the same THREADID for all messages with the
	same EMAILID.		same EMAILID.
	The server SHOULD return the same THREADID for related messages even		The server SHOULD return the same THREADID for related messages even
	if they are in different mailboxes.		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		THREADID is optional, if the server doesn't support THREADID or is
	unable to calculate relationships between messages, it MUST return		unable to calculate relationships between messages, it MUST return
	NIL to all FETCH responses for the THREADID data item, and a SEARCH		NIL to all FETCH responses for the THREADID data item, and a SEARCH
	for THREADID MUST NOT match any messages.		for THREADID MUST NOT match any messages.
	The server MUST NOT use the same objectid value for both EMAILIDs and		The server MUST NOT use the same objectid value for both EMAILIDs and
	THREADIDs. If they are stored with the same value internally, the		THREADIDs. If they are stored with the same value internally, the
	server can generate prefixed values (as shown in the examples below		server can generate prefixed values (as shown in the examples below
	with M and T prefixes) to avoid clashes.		with M and T prefixes) to avoid clashes.
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 36 ¶
	In the interests of reducing the possibilities of encoding mistakes,		In the interests of reducing the possibilities of encoding mistakes,
	objectids are restricted to a safe subset of possible byte values,		objectids are restricted to a safe subset of possible byte values,
	and in order to allow clients to allocate storage, they are		and in order to allow clients to allocate storage, they are
	restricted in length.		restricted in length.
	An objectid is a string of 1 to 255 characters from the following set		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		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).		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		strategies to avoid creating risks where glob completion or data type
	detection may be present (e.g. on filesystems or in spreadsheets).		detection may be present (e.g. on filesystems or in spreadsheets).
	In particular it is wise to avoid:		In particular it is wise to avoid:
	o ids starting with -		o ids starting with -
	o ids starting with digits		o ids starting with digits
	o ids which contain only digits		o ids which contain only digits
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 22 ¶
	It is advisable (though not required) to have MAILBOXID be globally		It is advisable (though not required) to have MAILBOXID be globally
	unique, but it is only required to be unique within messages offered		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		to a single client login to a single server hostname. For example, a
	proxy which aggregates multiple independent servers MUST NOT		proxy which aggregates multiple independent servers MUST NOT
	advertise the OBJECTID capability unless it can guarantee that		advertise the OBJECTID capability unless it can guarantee that
	different objects will never use the same identifiers, even if		different objects will never use the same identifiers, even if
	backend object collide.		backend object collide.
	8.3. Client usage		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		optimize their execution of command like UID SEARCH OR EMAILID 1234
	EMAILID 4321.		EMAILID 4321.
	Clients can assume that searching the all-mail mailbox using OR/		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		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		other client has moved them out of the mailbox where they were
	previously seen.		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.		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		discarding cache data for any mailbox which is no longer present on
	the server, so that they can detect renames and avoid re-downloading		the server, so that they can detect renames and avoid re-downloading
	data.		data.
	9. Future considerations		9. Future considerations
	This extension is intentionally defined to be compatible with the		This extension is intentionally defined to be compatible with the
	data model in [I-D.ietf-jmap-mail].		data model in [I-D.ietf-jmap-mail].
	A future extension could be proposed to give a way to SELECT a		A future extension could be proposed to give a way to SELECT a
	skipping to change at page 12, line 42 ¶		skipping to change at page 12, line 42 ¶
	fetch the data directly. Servers that are expected to handle highly		fetch the data directly. Servers that are expected to handle highly
	sensitive data should consider using a ID generation mechanism which		sensitive data should consider using a ID generation mechanism which
	doesn't derive from a digest.		doesn't derive from a digest.
	See also the security considerations in [RFC3501] section 11.		See also the security considerations in [RFC3501] section 11.
	12. Changes		12. Changes
	To be removed by the editor before publication		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 described NIL THREADID in more detail (ad review)
	o made RFC5256 a normative reference (ad review)		o made RFC5256 a normative reference (ad review)
	o fixed ABNF missing quote (ad review)		o fixed ABNF missing quote (ad review)
	o documented hash upgrade process (ad review)		o documented hash upgrade process (ad review)
	o referenced RFC3501 for INBOX rename (ad review)		o referenced RFC3501 for INBOX rename (ad review)
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 16 ¶
	o described NIL THREADID in more detail (ad review)		o described NIL THREADID in more detail (ad review)
	o made RFC5256 a normative reference (ad review)		o made RFC5256 a normative reference (ad review)
	o fixed ABNF missing quote (ad review)		o fixed ABNF missing quote (ad review)
	o documented hash upgrade process (ad review)		o documented hash upgrade process (ad review)
	o referenced RFC3501 for INBOX rename (ad review)		o referenced RFC3501 for INBOX rename (ad review)
	o referenced RFC3501 security considerations (secdir review)		o referenced RFC3501 security considerations (secdir review)
	o turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability		o turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability
	(genart review)		(genart review)
	o remove suggested algorithms which are no longer legitimate (genart		o remove suggested algorithms which are no longer legitimate (genart
	review)		review)
	o updated proxy advice to suggest rewriting ids (genart review)		o updated proxy advice to suggest rewriting ids (genart review)
	o fixed minor gramatical issues (genart review)		o fixed minor gramatical issues (genart review)
	o required that EMAILID and THREADID are not identical (own		o required that EMAILID and THREADID are not identical (own
	decision)		decision)
	12.2. draft-ietf-extra-imap-objectid-03		12.3. draft-ietf-extra-imap-objectid-03
	o added RFC3501 to Abstract		o added RFC3501 to Abstract
	o updated [[THIS RFC]] to not fail idnits		o updated [[THIS RFC]] to not fail idnits
	o changed jmap-mail to be informative rather than normative		o changed jmap-mail to be informative rather than normative
	o shortened IDs to stop wrapping and outdents in IMAP examples		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		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 added "updates" for RFC3501
	o fixed domains in thread example		o fixed domains in thread example
	o described threading in more detail		o described threading in more detail
	o added IANA request for Response Code		o added IANA request for Response Code
	o clarified RFC2119 references		o clarified RFC2119 references
	o simplified some waffle in wording		o simplified some waffle in wording
	o added security consideration to choose good digest		o added security consideration to choose good digest
	o added MAILBOXID-UID suggestion for EMAILID generation		o added MAILBOXID-UID suggestion for EMAILID generation
	o updated ABNF normative reference to RFC5234		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 draft to be objectid rather than uniqueid
	o renamed UNIQUEID (capability) to OBJECTID		o renamed UNIQUEID (capability) to OBJECTID
	o restricted objectid to 64 safe characters		o restricted objectid to 64 safe characters
	o added security considerations and advice about choosing objectid		o added security considerations and advice about choosing objectid
	o wrapped all responses in () for RFC4466 compatibility		o wrapped all responses in () for RFC4466 compatibility
	o signifiant rewrite of all sections		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 renamed draft to be an EXTRA document
	o added example for LIST RETURN STATUS		o added example for LIST RETURN STATUS
	o started work on ABNF		o started work on ABNF
	o attempted to add response codes for EMAILID and THREADID		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 UNIQUEID (status item) to MAILBOXID
	o renamed MSGID to EMAILID		o renamed MSGID to EMAILID
	o renamed THRID to THREADID		o renamed THRID to THREADID
	o added TODO section		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		o initial upload with names UNIQUEID/MSGID/THRID
	13. Acknowledgments		13. Acknowledgments
	The EXTRA working group at IETF. In particular feedback from Arnt		The EXTRA working group at IETF. In particular feedback from Arnt
	Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek.		Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek.
	The Gmail X-GM-THRID and X-GM-MSGID implementation as currently		The Gmail X-GM-THRID and X-GM-MSGID implementation as currently
	defined at <https://developers.google.com/gmail/imap/imap-		defined at <https://developers.google.com/gmail/imap/imap-
End of changes. 18 change blocks.
	27 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/