draft-ietf-jmap-mdn-04.txt		draft-ietf-jmap-mdn-05.txt
	JMAP R. Ouazana, Ed.		JMAP R. Ouazana, Ed.
	Internet-Draft Linagora		Internet-Draft Linagora
	Intended status: Standards Track December 16, 2019		Intended status: Standards Track February 26, 2020
	Expires: June 18, 2020		Expires: August 29, 2020
	Handling Message Disposition Notification with JMAP		Handling Message Disposition Notification with JMAP
	draft-ietf-jmap-mdn-04		draft-ietf-jmap-mdn-05
	Abstract		Abstract
	This document specifies a data model for handling [RFC8098] MDN		This document specifies a data model for handling [RFC8098] MDN
	messages with a server using JMAP.		messages with a server using JMAP.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	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 June 18, 2020.		This Internet-Draft will expire on August 29, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational conventions . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Addition to the capabilities object . . . . . . . . . . . 3		1.3. Addition to the capabilities object . . . . . . . . . . . 3
	2. MDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. MDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. MDN/set . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. MDN/send . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. MDN/parse . . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. MDN/parse . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Sending an MDN for a received email . . . . . . . . . . . 6		3.1. Sending an MDN for a received email . . . . . . . . . . . 7
	3.2. Asking for MDN when sending an email . . . . . . . . . . 7		3.2. Asking for MDN when sending an email . . . . . . . . . . 8
	3.3. Parsing a received MDN . . . . . . . . . . . . . . . . . 7		3.3. Parsing a received MDN . . . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	4.1. JMAP Capability Registration for "mdn" . . . . . . . . . 8		4.1. JMAP Capability Registration for "mdn" . . . . . . . . . 10
	5. Security considerations . . . . . . . . . . . . . . . . . . . 8		4.2. JMAP Error Codes Registry . . . . . . . . . . . . . . . . 11
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2.1. mdnAlreadySent . . . . . . . . . . . . . . . . . . . 11
	6.1. Normative References . . . . . . . . . . . . . . . . . . 9		5. Security considerations . . . . . . . . . . . . . . . . . . . 11
	6.2. Informative References . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . 11
			6.2. Informative References . . . . . . . . . . . . . . . . . 12
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic		JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic
	protocol for synchronising data, such as mail, calendars or contacts,		protocol for synchronising data, such as mail, calendars or contacts,
	between a client and a server. It is optimised for mobile and web		between a client and a server. It is optimised for mobile and web
	environments, and aims to provide a consistent interface to different		environments, and aims to provide a consistent interface to different
	data types.		data types.
	MDN are defined in [RFC8098] and are used as "read receipts",		MDN are defined in [RFC8098] and are used as "read receipts",
	"acknowledgements", or "receipt notifications".		"acknowledgements", or "receipt notifications".
	A client can have to deal with MDN in different ways:		A client can have to deal with MDN in different ways:
	1. When receiving an email, an MDN can be sent to the sender. This		1. When receiving an email, an MDN can be sent to the sender. This
	specification defines an MDN/set method to cover this case.		specification defines an MDN/send method to cover this case.
	2. When sending an email, an MDN can be requested. This must be		2. When sending an email, an MDN can be requested. This must be
	done with the help of a header, and is already specified by		done with the help of a header, and is already specified by
	[RFC8098] and can already be handled by [RFC8621] this way.		[RFC8098] and can already be handled by [RFC8621] this way.
	3. When receiving an MDN, the MDN could be related to an existing		3. When receiving an MDN, the MDN could be related to an existing
	sent mail. This is already covered by [RFC8621] in the		sent mail. This is already covered by [RFC8621] in the
	EmailSubmission object. Client could want to display detailed		EmailSubmission object. Client could want to display detailed
	information about a received MDN. This specification defines a		information about a received MDN. This specification defines an
	MDN/parse method to cover this case.		MDN/parse method to cover this case.
	1.1. Notational conventions		1.1. Notational conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	1.3. Addition to the capabilities object		1.3. Addition to the capabilities object
	Capabilities are announced as part of the standard JMAP Session		Capabilities are announced as part of the standard JMAP Session
	resource; see [RFC8620], section 2.		resource; see [RFC8620], section 2.
	Support for the "MDN" data type and the "MDN/parse" method are		Support for the "MDN" data type and the "MDN/parse" method are
	represented by the capability "urn:ietf:params:jmap:mdn" being		represented by the capability "urn:ietf:params:jmap:mdn" being
	present in the "capabilities" property. The capability		present in the "capabilities" property. The capability
	"urn:ietf:params:jmap:mdn" being present in the "accountCapabilities"		"urn:ietf:params:jmap:mdn" being present in the "accountCapabilities"
	property of an account represents support for creating and sending		property of an account represents support for creating and sending
	MDN messages via the "MDN/set" method. Servers that include the		MDN messages via the "MDN/send" method. Servers that include the
	capability in one or more "accountCapabilities" properties MUST also		capability in one or more "accountCapabilities" properties MUST also
	include the property in the "capabilities" property.		include the property in the "capabilities" property.
	The value of this "urn:ietf:params:jmap:mdn" property is an empty		The value of this "urn:ietf:params:jmap:mdn" property is an empty
	object in both the JMAP session "capabilities" property and an		object in both the JMAP session "capabilities" property and an
	account's "accountCapabilities" property.		account's "accountCapabilities" property.
	2. MDN		2. MDN
	An *MDN* object has the following properties:		An *MDN* object has the following properties:
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	"manual-action" / "automatic-action"		"manual-action" / "automatic-action"
	o sendingMode: "String" This MUST be one of the following strings:		o sendingMode: "String" This MUST be one of the following strings:
	"MDN-sent-manually" / "MDN-sent-automatically"		"MDN-sent-manually" / "MDN-sent-automatically"
	o type: "String" This MUST be one of the following strings:		o type: "String" This MUST be one of the following strings:
	"deleted" / "dispatched" / "displayed" / "processed"		"deleted" / "dispatched" / "displayed" / "processed"
	See [RFC8098] for the exact meaning of these different fields.		See [RFC8098] for the exact meaning of these different fields.
	2.1. MDN/set		2.1. MDN/send
	This is a standard "/set" method as described in [RFC8620] where only		The MDN/send method sends an [RFC5322] message from an MDN object.
	create is supported; any attempt to update/destroy MUST be rejected		The capability "urn:ietf:params:jmap:mail" is implicitely required
	with a "forbidden" SetError.		while using this method. The method takes the following arguments:
	The MDN/set method generates and sends an [RFC5322] message from an		o accountId: "Id" The id of the account to use.
	MDN object.
	The client SHOULD NOT issue a MDN/set request if the message has the		o send: "Id[MDN]" A map of creation id (client specified) to MDN
	"$MDNSent" keyword set. In this case, the server MUST reject the		objects.
	submission with a standard "alreadyExists" SetError.
			The response has the following arguments:
			o accountId: "Id" The id of the account used for the call.
			o sent: "Id[MDN]|null" A map of creation id to MDN containing any
			properties that were not sent by the client. This includes any
			properties that were omitted by the client and thus set to a
			default by the server. This argument is null if no MDN objects
			were successfully sent.
			o notSent: "Id[MDNError]|null" A map of the creation id to an
			MDNError object for each record that failed to be sent, or null if
			all successful.
			The following MDNError types are defined:
			o mdnAlreadySent: The message has the "$MDNSent" keyword already
			set.
			o forbidden: MDN/send would violate an ACL or other permissions
			policy.
			o overQuota: MDN/send would exceed a server-defined limit on the
			number or total size of sent MDN. It could include limitations on
			sent emails.
			o tooLarge: MDN/send would result in an MDN that exceeds a server-
			defined limit for the maximum size of an MDN, or more generally on
			emails.
			o rateLimit: Too many MDN or emails have been created recently, and
			a server-defined rate limit has been reached. It may work if
			tried again later.
			o invalidProperties: The record given is invalid in some way.
			The client SHOULD NOT issue an MDN/send request if the message has
			the "$MDNSent" keyword set.
	When sending the MDN, the server is in charge of generating the		When sending the MDN, the server is in charge of generating the
	"originalRecipient", "finalRecipient" and "originalMessageId" fields		"originalRecipient", "finalRecipient" and "originalMessageId" fields
	accordingly to the [RFC8098] specification.		accordingly to the [RFC8098] specification.
	After all items in the "MDN/set" invocation have been processed, a		After all items in the "MDN/send" invocation have been processed, a
	single implicit "Email/set" call MUST be made to set the "$MDNSent"		single implicit "Email/set" call MUST be made to set the "$MDNSent"
	keyword on "Email" objects referenced by "MDN" objects that have been		keyword on "Email" objects referenced by "MDN" objects that have been
	successfully created (see [RFC3503] for more details). The response		successfully created (see [RFC3503] for more details). The response
	to this MUST be returned after the "MDN/set" response.		to this MUST be returned after the "MDN/send" response.
	2.2. MDN/parse		2.2. MDN/parse
	This method allows a client to parse blobs as [RFC5322] messages to		This method allows a client to parse blobs as [RFC5322] messages to
	get MDN objects. This can be used to parse and get detailed		get MDN objects. This can be used to parse and get detailed
	information about blobs referenced in the "mdnBlobIds" of the		information about blobs referenced in the "mdnBlobIds" of the
	EmailSubmission object, or any email the client could expect to be an		EmailSubmission object, or any email the client could expect to be an
	MDN.		MDN.
	The "forEmailId" property can be null or missing if the		The "forEmailId" property can be null or missing if the
	skipping to change at page 6, line 11 ¶		skipping to change at page 6, line 49 ¶
	o parsed: "Id[MDN]|null" A map of blob id to parsed MDN		o parsed: "Id[MDN]|null" A map of blob id to parsed MDN
	representation for each successfully parsed blob, or null if none.		representation for each successfully parsed blob, or null if none.
	o notParsable: "Id[]|null" A list of ids given that corresponded to		o notParsable: "Id[]|null" A list of ids given that corresponded to
	blobs that could not be parsed as MDNs, or null if none.		blobs that could not be parsed as MDNs, or null if none.
	o notFound: "Id[]|null" A list of blob ids given that could not be		o notFound: "Id[]|null" A list of blob ids given that could not be
	found, or null if none.		found, or null if none.
			The following additional error may be returned instead of the MDN/
			parse response:
			o requestTooLarge: The number of ids requested by the client exceeds
			the maximum number the server is willing to process in a single
			method call.
	3. Samples		3. Samples
	3.1. Sending an MDN for a received email		3.1. Sending an MDN for a received email
	A client can use the following request to send an MDN back to the		A client can use the following request to send an MDN back to the
	sender:		sender:
	[[ "MDN/set", {		[[ "MDN/send", {
	"accountId": "ue150411c",		"accountId": "ue150411c",
	"create": {		"send": {
	"k1546": {		"k1546": {
	"forEmailId": "Md45b47b4877521042cec0938",		"forEmailId": "Md45b47b4877521042cec0938",
	"subject": "Read receipt for: World domination",		"subject": "Read receipt for: World domination",
	"textBody": "This receipt shows that the email has been		"textBody": "This receipt shows that the email has been
	displayed on your recipient's computer. There is no		displayed on your recipient's computer. There is no
	guaranty it has been read or understood.",		guaranty it has been read or understood.",
	"reportingUA": "linagora.com; OpenPaaS",		"reportingUA": "linagora.com; OpenPaaS",
	"disposition": {		"disposition": {
	"actionMode": "manual-action",		"actionMode": "manual-action",
	"sendingMode": "MDN-sent-manually",		"sendingMode": "MDN-sent-manually",
	"type": "displayed"		"type": "displayed"
	}		}
	}		}
	}		}
	}, "0" ]]		}, "0" ]]
	If the email id matches an existing email without the "$MDNSent"		If the email id matches an existing email without the "$MDNSent"
	keyword, the server can answer:		keyword, the server can answer:
	[[ "MDN/set", {		[[ "MDN/send", {
	"accountId": "ue150411c",		"accountId": "ue150411c",
	"oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21",		"sent": {
	"newState": "355421f6-8aed-4cf4-a0c4-7377e951af36",
	"created": {
	"k1546": {		"k1546": {
	"finalRecipient": "rfc822; john@example.com",		"finalRecipient": "rfc822; john@example.com",
	"originalMessageId": "<1521557867.2614.0.camel@apache.org>"		"originalMessageId": "<1521557867.2614.0.camel@apache.org>"
	}		}
	}		}
	}, "0" ],		}, "0" ],
			[ "Email/set", {
			"accountId": "ue150411c",
			"oldState": "23",
			"newState": "42",
			"updated": {
			"Md45b47b4877521042cec0938": {
			"keywords": {
			"$MDNSent": true
			}
			}
			}
			}, "0" ]]
			If the "$MDNSent" keyword has already been set, the server can answer
			an error:
			[[ "MDN/send", {
			"accountId": "ue150411c",
			"notSent": {
			"k1546": {
			"type": "mdnAlreadySent",
			"description" : "$MDNSent keyword is already present"
			}
			}
			}, "0" ]]
	3.2. Asking for MDN when sending an email		3.2. Asking for MDN when sending an email
	This is done with the [RFC8621] "Email/set" "create" method.		This is done with the [RFC8621] "Email/set" "create" method.
	[[ "Email/set", {		[[ "Email/set", {
	"accountId": "ue150411c",		"accountId": "ue150411c",
	"create": {		"create": {
	"k1546": {		"k1546": {
	"mailboxIds": {		"mailboxIds": {
	"2ea1ca41b38e": true		"2ea1ca41b38e": true
	},		},
	"keywords": {		"keywords": {
	"$seen": true,		"$seen": true,
	"$draft": true		"$draft": true
	},		},
	"from": [{		"from": [{
	"name": "Joe Bloggs",		"name": "Joe Bloggs",
	"email": "joe@example.com"		"email": "joe@example.com"
	}],		}],
	"to": [{		"to": [{
	"name": "John",		"name": "John",
	"email": "john@example.com"		"email": "john@example.com"
	}],		}],
	"header:Disposition-Notification-To": "joe@example.com",		"header:Disposition-Notification-To:asText": "joe@example.com",
	"subject": "World domination",		"subject": "World domination",
	...		...
	}		}
	}		}
	}, "0" ]]		}, "0" ]]
	Note the specified "Disposition-Notification-To" header indicating		Note the specified "Disposition-Notification-To" header indicating
	where to send MDN back (usually the sender of the email).		where to send MDN back (usually the sender of the email).
	3.3. Parsing a received MDN		3.3. Parsing a received MDN
	The client issues a parse request:		The client issues a parse request:
	[[ "MDN/parse", {		[[ "MDN/parse", {
	"accountId": "ue150411c",		"accountId": "ue150411c",
	skipping to change at page 8, line 26 ¶		skipping to change at page 10, line 26 ¶
	"actionMode": "manual-action",		"actionMode": "manual-action",
	"sendingMode": "MDN-sent-manually",		"sendingMode": "MDN-sent-manually",
	"type": "displayed"		"type": "displayed"
	}		}
	"finalRecipient": "rfc822; john@example.com",		"finalRecipient": "rfc822; john@example.com",
	"originalMessageId": "<1521557867.2614.0.camel@apache.org>"		"originalMessageId": "<1521557867.2614.0.camel@apache.org>"
	}		}
	}		}
	}, "0" ]]		}, "0" ]]
			In case of a not found blobId, the server would respond:
			[[ "MDN/parse", {
			"accountId": "ue150411c",
			"notFound": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]
			}
			}, "0" ]]
			If the blobId has been found but is not parsable, the server would
			respond:
			[[ "MDN/parse", {
			"accountId": "ue150411c",
			"notParsable": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]
			}
			}, "0" ]]
	4. IANA Considerations		4. IANA Considerations
	4.1. JMAP Capability Registration for "mdn"		4.1. JMAP Capability Registration for "mdn"
	IANA will register the "mdn" JMAP Capability as follows:		IANA will register the "mdn" JMAP Capability as follows:
	Capability Name: "urn:ietf:params:jmap:mdn"		Capability Name: "urn:ietf:params:jmap:mdn"
	Specification document: this document		Specification document: this document
	Intended use: common		Intended use: common
	Change Controller: IETF		Change Controller: IETF
	Security and privacy considerations: this document, section 5.		Security and privacy considerations: this document, section 5.
			4.2. JMAP Error Codes Registry
			The following subsection register one new error code in the "JMAP
			Error Codes" registry, as defined in [RFC8620].
			4.2.1. mdnAlreadySent
			JMAP Error Code: mdnAlreadySent
			Intended use: common
			Change controller: IETF
			Reference: This document, Section 2.1
			Description: The message has the "$MDNSent" keyword already set. The
			client MUST NOT try again to send an MDN for this message.
	5. Security considerations		5. Security considerations
	The same considerations regarding MDN (see [RFC8098] and [RFC3503])		The same considerations regarding MDN (see [RFC8098] and [RFC3503])
	apply to this document.		apply to this document.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3503] Melnikov, A., "Message Disposition Notification (MDN)		[RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
	profile for Internet Message Access Protocol (IMAP)",		profile for Internet Message Access Protocol (IMAP)",
	RFC 3503, DOI 10.17487/RFC3503, March 2003,		RFC 3503, DOI 10.17487/RFC3503, March 2003,
End of changes. 25 change blocks.
	64 lines changed or deleted		168 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/