< draft-ietf-extra-imap-objectid-03.txt		draft-ietf-extra-imap-objectid-04.txt >
	EXTRA B. Gondwana, Ed.		EXTRA B. Gondwana, Ed.
	Internet-Draft FastMail		Internet-Draft FastMail
	Updates: 3501 (if approved) May 28, 2018		Updates: 3501 (if approved) July 17, 2018
	Intended status: Standards Track		Intended status: Standards Track
	Expires: November 29, 2018		Expires: January 18, 2019
	IMAP Extension for object identifiers		IMAP Extension for object identifiers
	draft-ietf-extra-imap-objectid-03		draft-ietf-extra-imap-objectid-04
	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 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 29, 2018.		This Internet-Draft will expire on January 18, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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-03 . . . . . . . . . . . 12		12.1. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 12
	12.2. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 12		12.2. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13
	12.3. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 12		12.3. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 13
	12.4. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 13		12.4. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 13
	12.5. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 13		12.5. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14
	12.6. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 13		12.6. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14
	12.7. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 14		12.7. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 14
			12.8. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 14
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	13.1. Appendix 1: ideas for implementing object identifiers . 14		13.1. Appendix 1: ideas for implementing object identifiers . 15
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	14.1. Normative References . . . . . . . . . . . . . . . . . . 15		14.1. Normative References . . . . . . . . . . . . . . . . . . 15
	14.2. Informative References . . . . . . . . . . . . . . . . . 15		14.2. Informative References . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
	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.
	[RFC4315] defines a COPYUID response which allows a client which		[RFC4315] defines a COPYUID response which allows a client which
	copies messages to know the mapping between the UIDs in the source		copies messages to know the mapping between the UIDs in the source
	and destination mailboxes, and hence update its local cache.		and destination mailboxes, and hence update its local cache.
	If a mailbox is successfully renamed, the client knows that the same		If a mailbox is successfully renamed by a client, that client will
	messages exist in the destination mailbox name as previously existed		know that the same messages exist in the destination mailbox name as
	in the source mailbox name.		previously existed in the source mailbox name.
	The result is that the client which copies (or [RFC6851] moves)		The result is that the client which copies (or [RFC6851] moves)
	messages or renames a mailbox can update its local cache, but any		messages or renames a mailbox can update its local cache, but any
	other client connected to the same store can not know with certainty		other client connected to the same store can not know with certainty
	that the messages are identical, and so will re-download everything.		that the messages are identical, and so will re-download everything.
	This extension adds new properties to a message (EMAILID) and mailbox		This extension adds new properties to a message (EMAILID) and mailbox
	(MAILBOXID) which allow a client to quickly identify messages or		(MAILBOXID) which allow a client to quickly identify messages or
	mailboxes which have been renamed by another client.		mailboxes which have been renamed by another client.
	This extension also adds an optional thread identifier (THREADID) to		This extension also adds an optional thread identifier (THREADID) to
	messages, which can be used by the server to indicate messages which		messages, which can be used by the server to indicate messages which
	it has identified to be related.		it has identified to be related. A server that does not implement
			threading will return NIL to all requests for THREADID.
	2. Conventions Used In This Document		2. Conventions Used In This Document
	In examples, "C:" indicates lines sent by a client that is connected		In examples, "C:" indicates lines sent by a client that is connected
	to a server. "S:" indicates lines sent by the server to the client.		to a server. "S:" indicates lines sent by the server to the client.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119] when they		document are to be interpreted as described in [RFC2119] when they
	appear in ALL CAPS. These words may also appear in this document in		appear in ALL CAPS. These words may also appear in this document in
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 48 ¶
	3. CAPABILITY Identification		3. CAPABILITY Identification
	IMAP servers that support this extension MUST include "OBJECTID" in		IMAP servers that support this extension MUST include "OBJECTID" in
	the response list to the CAPABILITY command.		the response list to the CAPABILITY command.
	4. MAILBOXID object identifier		4. MAILBOXID object identifier
	The MAILBOXID is a server-allocated unique identifer for each		The MAILBOXID is a server-allocated unique identifer for each
	mailbox.		mailbox.
	The server SHOULD return the same MAILBOXID for a server with the		The server MUST return the same MAILBOXID for a mailbox with the same
	same mailbox name and UIDVALIDITY. This is almost MUST, but weakened		name and UIDVALIDITY.
	to allow for the possibility of loss of OBJECTID data during disaster
	recovery while still keeping the name and UIDVALIDITY the same.
	The server MUST NOT report the same MAILBOXID for two mailboxes at		The server MUST NOT report the same MAILBOXID for two mailboxes at
	the same time.		the same time.
	The server MUST NOT reuse the same MAILBOXID for a mailbox which does		The server MUST NOT reuse the same MAILBOXID for a mailbox which does
	not obey all the invarients that [RFC3501] defines for a mailbox		not obey all the invarients that [RFC3501] defines for a mailbox
	which does not change name or UIDVALIDITY.		which does not change name or UIDVALIDITY.
	The server MAY choose to create a MAILBOXID value in a way that does		The server SHOULD NOT change MAILBOXID when renaming a folder, as
	not survive RENAME (e.g. a digest of name + uidvalidity could be		this loses the main benefit of having a unique identifier.
	used), however the client then loses the major benefit of having an
	identifier.
	4.1. New response code for CREATE		4.1. New response code for CREATE
	This document extends the CREATE command to have the response code		This document extends the CREATE command to have the response code
	MAILBOXID on successful mailbox creation.		MAILBOXID on successful mailbox creation.
	A server advertising the OBJECTID capability MUST include the		A server advertising the OBJECTID capability MUST include the
	MAILBOXID response code in the tagged OK response to all successful		MAILBOXID response code in the tagged OK response to all successful
	CREATE commands.		CREATE commands.
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 16 ¶
	S: * LIST (\HasNoChildren) "." INBOX		S: * LIST (\HasNoChildren) "." INBOX
	S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))		S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))
	S: * LIST (\HasNoChildren) "." bar		S: * LIST (\HasNoChildren) "." bar
	S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))		S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
	S: * LIST (\HasNoChildren) "." renamed		S: * LIST (\HasNoChildren) "." renamed
	S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))		S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
	S: 11 OK Completed (0.001 secs 3 calls)		S: 11 OK Completed (0.001 secs 3 calls)
	5. EMAILID object identifier and THREADID correlator		5. EMAILID object identifier and THREADID correlator
	This document defines the data items EMAILID and THREADID on
	messages.
	5.1. EMAILID identifier for identical messages		5.1. EMAILID identifier for identical messages
	The EMAILID data item is an objectid which uniquely identifies the		The EMAILID data item is an objectid which uniquely identifies the
	content of a single message. Anything which must remain immutable on		content of a single message. Anything which must remain immutable on
	a {name, uidvalidity, uid} triple must also be the same between		a {name, uidvalidity, uid} triple must also be the same between
	messages with the same EMAILID.		messages with the same EMAILID.
	The server SHOULD return the same EMAILID for the same UID triple.		The server MUST return the same EMAILID for the same triple, hence
	As with MAILBOXID above, this is almost a MUST, but allows for the		EMAILID is immutable.
	possibility of loss of OBJECTID data in disaster recovery without
	having to change UIDVALIDITY.
	The server SHOULD return the same EMAILID for the exact same message		The server MUST return the same EMAILID as the source message for the
	content in different folders after a COPY or [RFC6851] MOVE command.		matching destination message in the COPYUID pairing after a COPY or
			[RFC6851] MOVE command.
	The server MAY assign the same EMAILID as an existing message upon		The server MAY assign the same EMAILID as an existing message upon
	APPEND if it detects that the new message has exactly identical		APPEND (e.g. if it detects that the new message has exactly identical
	content to that existing message.		content to that of an existing message)
			NOTE: EMAILID only identifies the immutable content of the message.
			In particular, it is possible for different messages with the same
			EMAILID to have different keywords. This document does not specify a
			way to STORE by EMAILID.
	5.2. THREADID identifer for related messages		5.2. THREADID identifer for related messages
	The THREADID data item is an objectid which uniquely identifies a set		The THREADID data item is an objectid which uniquely identifies a set
	of messages which the server believes should be grouped together when		of messages which the server believes should be grouped together when
	presented.		presented.
	THREADID calculation is generally based on some combination of		THREADID calculation is generally based on some combination of
	References, In-Reply-To and Subject, but the exact logic is left up		References, In-Reply-To and Subject, but the exact logic is left up
	to the server implementation. [RFC5256] describes some algorithms		to the server implementation. [RFC5256] describes some algorithms
	that MAY 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.
	THREADID is optional, if the server is unable to calculate		THREADID is optional, if the server doesn't support THREADID or is
	relationships between messages, it MUST return NIL to in all FETCH		unable to calculate relationships between messages, it MUST return
	responses for the THREADID data item, and a SEARCH for THREADID MUST		NIL to all FETCH responses for the THREADID data item, and a SEARCH
	NOT match any messages.		for THREADID MUST NOT match any messages.
	The server MAY use the same objectid value for both EMAILID and		The server MUST NOT use the same objectid value for both EMAILIDs and
	THREADID, for example the THREADID could be the EMAILID of the first		THREADIDs. If they are stored with the same value internally, the
	message that the server has seen in each thread.		server can generate prefixed values (as shown in the examples below
			with M and T prefixes) to avoid clashes.
	5.3. New Message Data Items in FETCH and UID FETCH Commands		5.3. New Message Data Items in FETCH and UID FETCH Commands
	This document defines two FETCH items:		This document defines two FETCH items:
	Syntax: EMAILID		Syntax: EMAILID
	The EMAILID message data item causes the server to return EMAILID		The EMAILID message data item causes the server to return EMAILID
	FETCH response data items.		FETCH response data items.
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 4 ¶
	insensitive. The use of upper- or lowercase characters to define		insensitive. The use of upper- or lowercase characters to define
	token strings is for editorial clarity only. Implementations MUST		token strings is for editorial clarity only. Implementations MUST
	accept these strings in a case-insensitive fashion.		accept these strings in a case-insensitive fashion.
	capability =/ "OBJECTID"		capability =/ "OBJECTID"
	fetch-att =/ "EMAILID" / "THREADID"		fetch-att =/ "EMAILID" / "THREADID"
	fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged-		fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged-
	ext production from [RFC4466]		ext production from [RFC4466]
	fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID NIL		fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID" NIL
	; follows tagged-ext production from [RFC4466]		; follows tagged-ext production from [RFC4466]
	objectid = 1*255(ALPHA / DIGIT / "_" / "-") ; characters in object		objectid = 1*255(ALPHA / DIGIT / "_" / "-") ; characters in object
	identifiers are case ; significant		identifiers are case ; significant
	resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ; incorporated		resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ; incorporated
	before the expansion rule of ; atom [SP 1*<any TEXT-CHAR except "]">]		before the expansion rule of ; atom [SP 1*<any TEXT-CHAR except "]">]
	; that appears in [RFC3501]		; that appears in [RFC3501]
	search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid		search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 9 ¶
	o ids which contain only digits		o ids which contain only digits
	o ids which differ only by ASCII case (A vs a)		o ids which differ only by ASCII case (A vs a)
	o the specific sequence of 3 characters NIL		o the specific sequence of 3 characters NIL
	A good solution to these issues is to prefix every ID with a single		A good solution to these issues is to prefix every ID with a single
	alphabetical character.		alphabetical character.
	8.2. Interaction with special cases		8.2. Interaction with special cases
	The case of RENAME INBOX may need special handling for unique ids.		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		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 the		advertise the OBJECTID capability unless it can guarantee that
	backends will not use the same identifiers for different objects.		different objects will never use the same identifiers, even if
			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
	skipping to change at page 11, line 45 ¶		skipping to change at page 11, line 47 ¶
	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
	mailbox by MAILBOXID rather than name.		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		An extension to allow fetching message content directly via EMAILID
	and message listings by THREADID could be proposed.		and message listings by THREADID could be proposed.
	10. IANA Considerations		10. IANA Considerations
	IANA is requested to add "OBJECTID" to the "IMAP Capabilities"		IANA is requested to add "OBJECTID" to the "IMAP Capabilities"
	registry located at <http://www.iana.org/assignments/imap-		registry located at <http://www.iana.org/assignments/imap-
	capabilities>.		capabilities>.
	IANA is requested to add "MAILBOXID" to the "IMAP Response Codes"		IANA is requested to add "MAILBOXID" to the "IMAP Response Codes"
	skipping to change at page 12, line 23 ¶		skipping to change at page 12, line 23 ¶
	codes> with a Reference of [[THIS RFC]].		codes> with a Reference of [[THIS RFC]].
	11. Security Considerations		11. Security Considerations
	It is strongly advised that servers generate OBJECTIDs which are safe		It is strongly advised that servers generate OBJECTIDs which are safe
	to use as filesystem names, and unlikely to be auto-detected as		to use as filesystem names, and unlikely to be auto-detected as
	numbers. See implementation considerations.		numbers. See implementation considerations.
	If a digest is used for ID generation, it must have a collision		If a digest is used for ID generation, it must have a collision
	resistent property, so server implementations are advised to monitor		resistent property, so server implementations are advised to monitor
	current security research and choose secure digests.		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 creating new IDs with the new algorithm. 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		The use of a digest for ID generation may be used as proof that a
	particular sequence of bytes was seen by the server.		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.
	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-03		12.1. 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)
			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.2. 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.2. draft-ietf-extra-imap-objectid-02		12.3. draft-ietf-extra-imap-objectid-02
	o added "Client usage" section		o added "Client usage" section
	12.3. draft-ietf-extra-imap-objectid-01		12.4. 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.4. draft-ietf-extra-imap-objectid-00		12.5. 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.5. draft-ietf-extra-imap-uniqueid-00		12.6. 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.6. draft-gondwana-imap-uniqueid-01		12.7. 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.7. draft-gondwana-imap-uniqueid-00		12.8. 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-
	extensions>.		extensions>.
	Dovecot X-GUID implementation.		Dovecot X-GUID implementation.
	13.1. Appendix 1: ideas for implementing object identifiers		13.1. Appendix 1: ideas for implementing object identifiers
	Ideas for implementing MAILBOXID:		Ideas for calculating MAILBOXID:
	o Digest of (MailboxName/UIDVALIDITY) - not kept when renaming, but
	is guaranteed unique and doesn't require storage.
	o [RFC4122] UUID		o [RFC4122] UUID
	o Server assigned sequence number (guaranteed not to be reused)		o Server assigned sequence number (guaranteed not to be reused)
	Ideas for implementing EMAILID:		Ideas for implementing EMAILID:
	o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying
	messages, but is guaranteed unique and doesn't require storage.
	o Concatenation of MAILBOXID-UID - for servers which store MAILBOXID
	but not EMAILID.
	o Digest of message content (RFC822 bytes) - expensive unless cached		o Digest of message content (RFC822 bytes) - expensive unless cached
	o [RFC4122] UUID		o [RFC4122] UUID
	o Server assigned sequence number (guaranteed not to be reused)		o Server assigned sequence number (guaranteed not to be reused)
	Ideas for implementing THREADID:		Ideas for implementing THREADID:
	o Derive from EMAILID of first seen message in the thread.		o Derive from EMAILID of first seen message in the thread.
	skipping to change at page 15, line 30 ¶		skipping to change at page 16, line 9 ¶
	<https://www.rfc-editor.org/info/rfc3501>.		<https://www.rfc-editor.org/info/rfc3501>.
	[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -		[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
	UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,		UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
	December 2005, <https://www.rfc-editor.org/info/rfc4315>.		December 2005, <https://www.rfc-editor.org/info/rfc4315>.
	[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4		[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
	ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,		ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
	<https://www.rfc-editor.org/info/rfc4466>.		<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		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<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		[RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for
	Returning STATUS Information in Extended LIST", RFC 5819,		Returning STATUS Information in Extended LIST", RFC 5819,
	DOI 10.17487/RFC5819, March 2010,		DOI 10.17487/RFC5819, March 2010,
	<https://www.rfc-editor.org/info/rfc5819>.		<https://www.rfc-editor.org/info/rfc5819>.
	[RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message		[RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message
	Access Protocol (IMAP) - MOVE Extension", RFC 6851,		Access Protocol (IMAP) - MOVE Extension", RFC 6851,
	DOI 10.17487/RFC6851, January 2013,		DOI 10.17487/RFC6851, January 2013,
	<https://www.rfc-editor.org/info/rfc6851>.		<https://www.rfc-editor.org/info/rfc6851>.
	14.2. Informative References		14.2. Informative References
	[I-D.ietf-jmap-mail]		[I-D.ietf-jmap-mail]
	Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-05		Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-06
	(work in progress), May 2018.		(work in progress), July 2018.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005,		DOI 10.17487/RFC4122, July 2005,
	<https://www.rfc-editor.org/info/rfc4122>.		<https://www.rfc-editor.org/info/rfc4122>.
	[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>.
	Author's Address		Author's Address
	Bron Gondwana (editor)		Bron Gondwana (editor)
	FastMail		FastMail
	Level 2, 114 William St		Level 2, 114 William St
	Melbourne VIC 3000		Melbourne VIC 3000
	Australia		Australia
	Email: brong@fastmailteam.com		Email: brong@fastmailteam.com
	URI: https://www.fastmail.com		URI: https://www.fastmail.com
End of changes. 39 change blocks.
	75 lines changed or deleted		111 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/