Diff: rfc9007xml2.original.xml

	rfc9007xml2.original.xml	rfc9007.xml
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>

	<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
	<rfc ipr="trust200902" category="std" docName="draft-ietf-jmap-mdn-17">
	<?rfc toc="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc private=""?>
	<?rfc topblock="yes"?>
	<?rfc comments="no"?>
	<front>
	<title abbrev="JMAP MDN handling">Handling Message Disposition Notification with
	JMAP</title>

	<author role="editor" initials="R.O." surname="Ouazana" fullname="Raphaël Ouazan
	a">
	<organization>Linagora</organization>
	<address>
	<postal>
	<street>100 Terrasse Boieldieu – Tour Franklin</street>
	<city>Paris - La Défense CEDEX</city>
	<code>92042</code>
	<country>France</country>
	<region></region>
	</postal>
	<phone></phone>
	<email>rouazana@linagora.com</email>
	<uri>https://www.linagora.com</uri>
	</address>
	</author>
	<date year="2021" month="January" day="28"/>

	<area>Applications</area>
	<workgroup>JMAP</workgroup>
	<keyword>JMAP</keyword>
	<keyword>JSON</keyword>
	<keyword>email</keyword>
	<keyword>MDN</keyword>


	<abstract>	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<t>This document specifies a data model for handling Message Disposition Notific
	ations (MDNs, RFC 8098) in the JSON Meta Application Protocol (JMAP, RFCs 8620 a
	nd 8621).
	</t>
	</abstract>


	</front>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-jmap-mdn-17" number="9007" obsoletes="" updates="" submissionType="IETF" c ategory="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" so rtRefs="true" version="3">


	<middle>	<!-- xml2rfc v2v3 conversion 3.5.0 -->


	<section anchor="introduction" title="Introduction">	<front>
	<t>JMAP (<xref target="RFC8620"/> – JSON Meta Application Protocol) is a generic	<title abbrev="JMAP MDN handling">Handling Message Disposition Notification
	protocol for synchronising data, such as mail, calendars or contacts, between a	with JSON Meta Application Protocol (JMAP)</title>
	client and a server. It is optimised for mobile and web environments, and provi	<seriesInfo name="RFC" value="9007"/>
	des a consistent interface to different data types.	<author role="editor" initials="R." surname="Ouazana" fullname="Raphaël Ouaz
	</t>	ana">
	<t>JMAP for Mail (<xref target="RFC8621"/> - The JSON Meta Application Protocol	<organization>Linagora</organization>
	(JMAP) for Mail) specifies a data model for synchronising email data with a serv	<address>
	er using JMAP. Clients can use this to efficiently search, access, organise, and	<postal>
	send messages.	<street>100 Terrasse Boieldieu - Tour Franklin</street>
	</t>	<city>Paris - La Défense CEDEX</city>
	<t>Message Disposition Notifications (MDNs) are defined in <xref target="RFC8098	<code>92042</code>
	"/> and are used as "read receipts", "acknowledgements", or	<country>France</country>
	"receipt notifications".	<region/>
	</t>	</postal>
	<t>A client can come across MDNs in different ways:	<phone/>
		<email>rouazana@linagora.com</email>
		<uri>https://www.linagora.com</uri>
		</address>
		</author>
		<date year="2021" month="March"/>
		<area>Applications</area>
		<workgroup>JMAP</workgroup>
		<keyword>JMAP</keyword>
		<keyword>JSON</keyword>
		<keyword>email</keyword>
		<keyword>MDN</keyword>
		<abstract>
		<t>This document specifies a data model for handling Message Disposition N
		otifications (MDNs) (see RFC 8098) in the JSON Meta Application Protocol (JMAP)
		(see RFCs 8620 and 8621).
	</t>	</t>

	<t>	</abstract>
	<list style="numbers">	</front>
	<t>When receiving an email message, an MDN can be sent to the sender. This speci	<middle>
	fication defines an MDN/send method to cover this case.</t>	<section anchor="introduction" numbered="true" toc="default">
	<t>When sending an email message, an MDN can be requested. This must be done wit	<name>Introduction</name>
	h the help of a header field, and is already specified by <xref target="RFC8098"	<t>JMAP (<xref target="RFC8620" format="title"/> <xref target="RFC8620" fo
	/> and can already be handled by <xref target="RFC8621"/> this way.</t>	rmat="default"/>) is a generic protocol for synchronising data, such as mail, ca
	<t>When receiving an MDN, the MDN could be related to an existing sent message.	lendars, or contacts, between a client and a server. It is optimised for mobile
	This is already covered by <xref target="RFC8621"/> in the EmailSubmission objec	and web environments, and it provides a consistent interface to different data t
	t. A client might want to display detailed information about a received MDN. Thi	ypes.
	s specification defines an MDN/parse method to cover this case.</t>
	</list>
	</t>	</t>

		<t>JMAP for Mail (<xref target="RFC8621" format="title"/> <xref target="RF
	<section anchor="notational-conventions" title="Notational conventions">	C8621" format="default"/>) specifies a data model for synchronising email data w
	<t>The key words "MUST", "MUST NOT", "REQUIRED", &	ith a server using JMAP. Clients can use this to efficiently search, access, org
	quot;SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT&qu	anise, and send messages.
	ot;, "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they a
	ppear in all capitals, as shown here.
	</t>	</t>

	<t>Type signatures, examples and property descriptions in this document follow t he conventions established in section 1.1 of <xref target="RFC8620"/>. Data type s defined in the core specification are also used in this document.	<t>Message Disposition Notifications (MDNs) are defined in <xref target="R FC8098" format="default"/> and are used as "read receipts", "acknowledgements", or "receipt notifications".
	</t>	</t>

	<t>Servers MUST support all properties specified for the new data types defined in this document.	<t>A client can come across MDNs in different ways:
	</t>	</t>

	</section>	<ol spacing="normal" type="1"><li>When receiving an email message, an MDN can be sent to the sender. This specification defines an "MDN/send" method to cover th is case.</li>


	<section anchor="terminology" title="Terminology">	<li>When sending an email message, an MDN can be requested. This must be
	<t>The same terminology is used in this document as in the core JMAP specificati	done with the help of a header field, as already specified by <xref target="RFC
	on.	8098" format="default"/>; the header field can already be handled by guidance in
		<xref target="RFC8621" format="default"/>.</li>
		<li>When receiving an MDN, the MDN could be related to an existing sent
		message. This is already covered by <xref target="RFC8621" format="default"/> in
		the EmailSubmission object. A client might want to display detailed information
		about a received MDN. This specification defines an "MDN/parse" method to cover
		this case.</li>
		</ol>
		<section anchor="notational-conventions" numbered="true" toc="default">
		<name>Notational Conventions</name>
		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		<t>Type signatures, examples, and property descriptions in this document
		follow the conventions established in <xref target="RFC8620" section="1.1" sect
		ionFormat="of" format="default"/>. Data types defined in the core specification
		are also used in this document.
	</t>	</t>

	<t>Because keywords are case-insensitive in IMAP but case-sensitive in JMAP, the "$mdnsent" keyword MUST always be used in lowercase.	<t>Servers <bcp14>MUST</bcp14> support all properties specified for the new data types defined in this document.
	</t>	</t>

	</section>	</section>
		<section anchor="terminology" numbered="true" toc="default">
	<section anchor="addition-to-the-capabilities-object" title="Addition to the cap	<name>Terminology</name>
	abilities object">	<t>The same terminology is used in this document as in the core JMAP spe
	<t>Capabilities are announced as part of the standard JMAP Session resource; see	cification.
	<xref target="RFC8620"/>, section 2. This defines a new capability, "urn:i
	etf:params:jmap:mdn".
	</t>	</t>

	<t>The capability "urn:ietf:params:jmap:mdn" being present in the &quo	<t>Because keywords are case insensitive in IMAP but case sensitive in J
	t;accountCapabilities" property of an account represents support for the &q	MAP, the <tt>$mdnsent</tt> keyword <bcp14>MUST</bcp14> always be used in lowerca
	uot;MDN" data type, parsing MDNs via the "MDN/parse" method, and	se.
	creating and sending MDN messages via the "MDN/send" method.
	Servers that include the capability in one or more "accountCapabilities&quo
	t; properties MUST also include the property in the "capabilities" pro
	perty.
	</t>	</t>

	<t>The value of this "urn:ietf:params:jmap:mdn" property is an empty o	</section>
	bject both in the account's "accountCapabilities" property and in the	<section anchor="addition-to-the-capabilities-object" numbered="true" toc=
	"capabilities" property.	"default">
		<name>Addition to the Capabilities Object</name>
		<t>Capabilities are announced as part of the standard JMAP Session resou
		rce; see <xref target="RFC8620" section="2" sectionFormat="comma" format="defaul
		t"/>. This defines a new capability, "urn:ietf:params:jmap:mdn".
	</t>	</t>

	</section>	<t>The capability "urn:ietf:params:jmap:mdn" being present in the "accou
	</section>	ntCapabilities" property of an account represents support for the "MDN" data typ
		e, parsing MDNs via the "MDN/parse" method, and creating and sending MDN message
	<section anchor="mdn" title="MDN">	s via the "MDN/send" method.
	<t>An <spanx style="strong">MDN</spanx> object has the following properties:	Servers that include the capability in one or more "accountCapabilities" propert
		ies <bcp14>MUST</bcp14> also include the property in the "capabilities" property
		.
	</t>	</t>

	<t>	<t>The value of this "urn:ietf:params:jmap:mdn" property is an empty obj
	<list style="symbols">	ect both in the account's "accountCapabilities" property and in the "capabilitie
	<t>forEmailId: <spanx style="verb">Id\|null</spanx>	s" property.
	Email id of the received message this MDN is relative to. This property MUST NOT
	be null for "MDN/send", but MAY be null in the response from the &quo
	t;MDN/parse" method.</t>
	<t>subject: <spanx style="verb">String\|null</spanx>
	Subject used as <spanx style="verb">Subject</spanx> header field for this MDN.</
	t>
	<t>textBody: <spanx style="verb">String\|null</spanx>
	Human readable part of the MDN, as plain text.</t>
	<t>includeOriginalMessage: <spanx style="verb">Boolean</spanx> (default: false).
	If <spanx style="verb">true</spanx>, the content of the original message will a
	ppear in the third component of the multipart/report generated for the MDN. See
	<xref target="RFC8098"/> for details and security considerations.</t>
	<t>reportingUA: <spanx style="verb">String\|null</spanx>
	Name of the MUA creating this MDN. It is used to build the MDN Report part of th
	e MDN. Note that a <spanx style="verb">null</spanx> value may have better privac
	y properties.</t>
	<t>disposition: <spanx style="verb">Disposition</spanx>
	Object containing the diverse MDN disposition options.</t>
	<t>mdnGateway: <spanx style="verb">String\|null</spanx> (server-set)
	Name of the gateway or MTA that translated a foreign (non-Internet) message disp
	osition notification into this MDN.</t>
	<t>originalRecipient: <spanx style="verb">String\|null</spanx> (server-set)
	Original recipient address as specified by the sender of the message for which t
	he MDN is being issued.</t>
	<t>finalRecipient: <spanx style="verb">String\|null</spanx>
	Recipient for which the MDN is being issued. If set, it overrides the value tha
	t would be calculated by the server from the Identity defined in the "MDN/S
	end" method, unless explicitly set by the client.</t>
	<t>originalMessageId: <spanx style="verb">String\|null</spanx> (server-set)
	Message-ID (the <xref target="RFC5322"/> header field, not the JMAP id) of the m
	essage for which the MDN is being issued.</t>
	<t>error: <spanx style="verb">String[]\|null</spanx> (server-set)
	Additional information in the form of text messages when the "error" d
	isposition modifier appears.</t>
	<t>extensionFields: <spanx style="verb">String[String]\|null</spanx>
	Object where keys are extension-field names and values are extension-field value
	s (see <xref target="RFC8098"/> Section 3.3).</t>
	</list>
	</t>	</t>

	<t>A <spanx style="strong">Disposition</spanx> object has the following properti	</section>
	es:	</section>
		<section anchor="mdn" numbered="true" toc="default">
		<name>MDN</name>
		<t>An <strong>MDN</strong> object has the following properties:
	</t>	</t>

	<t>	<ul spacing="normal">
	<list style="symbols">	<li><t>forEmailId: <tt>Id\|null</tt></t>
	<t>actionMode: <spanx style="verb">String</spanx>	<t>The Email id of the received message to which this MDN is related. This prope
	This MUST be one of the following strings: "manual-action" / "aut	rty <bcp14>MUST NOT</bcp14> be null for "MDN/send" but <bcp14>MAY</bcp14> be nul
	omatic-action"</t>	l in the response from the "MDN/parse" method.</t></li>
	<t>sendingMode: <spanx style="verb">String</spanx>	<li><t>subject: <tt>String\|null</tt></t>
	This MUST be one of the following strings: "mdn-sent-manually" / &quot	<t>The subject used as "Subject" header field for this MDN.</t></li>
	;mdn-sent-automatically"</t>	<li><t>textBody: <tt>String\|null</tt></t>
	<t>type: <spanx style="verb">String</spanx>	<t>The human-readable part of the MDN, as plain text.</t></li>
	This MUST be one of the following strings: "deleted" / "dispatche	<li><t>includeOriginalMessage: <tt>Boolean</tt> (default: false)</t>
	d" / "displayed" / "processed"</t>	<t>If <tt>true</tt>, the content of the original message will appear in the thir
	</list>	d component of the multipart/report generated for the MDN. See <xref target="RFC
		8098" format="default"/> for details and security considerations.</t></li>
		<li><t>reportingUA: <tt>String\|null</tt></t>
		<t>The name of the Mail User Agent (MUA) creating this MDN. It is used to build
		the MDN report part of the MDN. Note that a <tt>null</tt> value may have better
		privacy properties.</t></li>
		<li><t>disposition: <tt>Disposition</tt></t>
		<t>The object containing the diverse MDN disposition options.</t></li>
		<li><t>mdnGateway: <tt>String\|null</tt> (server-set)</t>
		<t>The name of the gateway or Message Transfer Agent (MTA) that translated a for
		eign (non-Internet) message disposition notification into this MDN.</t></li>
		<li><t>originalRecipient: <tt>String\|null</tt> (server-set)</t>
		<t>The original recipient address as specified by the sender of the message for
		which the MDN is being issued.</t></li>
		<li><t>finalRecipient: <tt>String\|null</tt></t>
		<t>The recipient for which the MDN is being issued. If set, it overrides the va
		lue that would be calculated by the server from the Identity defined in the "MDN
		/send" method, unless explicitly set by the client.</t></li>
		<li><t>originalMessageId: <tt>String\|null</tt> (server-set)</t>
		<t>The "Message-ID" header field <xref target="RFC5322" format="default"/> (not
		the JMAP id) of the message for which the MDN is being issued.</t></li>
		<li><t>error: <tt>String[]\|null</tt> (server-set)</t>
		<t>Additional information in the form of text messages when the "error" disposit
		ion modifier appears.</t></li>
		<li><t>extensionFields: <tt>String[String]\|null</tt></t>
		<t>The object where keys are extension-field names, and values are extension-fie
		ld values (see <xref target="RFC8098" section="3.3" sectionFormat="comma" format
		="default"/>).</t></li>
		</ul>
		<t>A <strong>Disposition</strong> object has the following properties:
	</t>	</t>

	<t>See <xref target="RFC8098"/> for the exact meaning of these different fields.	<ul spacing="normal">
	These fields are defined case insensitive in <xref target="RFC8098"/> but are c	<li><t>actionMode: <tt>String</tt></t>
	ase sensitive in this RFC and MUST be converted to lowercase by "MDN/parse&	<t>This <bcp14>MUST</bcp14> be one of the following strings: <tt>manual-action</
	quot;.	tt> / <tt>automatic-action</tt></t></li>
		<li><t>sendingMode: <tt>String</tt></t>
		<t>This <bcp14>MUST</bcp14> be one of the following strings: <tt>mdn-sent-manual
		ly</tt> / <tt>mdn-sent-automatically</tt></t></li>
		<li><t>type: <tt>String</tt></t>
		<t>This <bcp14>MUST</bcp14> be one of the following strings: <tt>deleted</tt> /
		<tt>dispatched</tt> / <tt>displayed</tt> / <tt>processed</tt></t></li>
		</ul>
		<t>See <xref target="RFC8098" format="default"/> for the exact meaning of
		these different fields. These fields are defined as case insensitive in <xref ta
		rget="RFC8098" format="default"/> but are case sensitive in this RFC and <bcp14>
		MUST</bcp14> be converted to lowercase by "MDN/parse".
	</t>	</t>

		<section anchor="mdnsend" numbered="true" toc="default">
	<section anchor="mdnsend" title="MDN/send">	<name>MDN/send</name>
	<t>The MDN/send method sends an <xref target="RFC5322"/> message from an MDN obj	<t>The "MDN/send" method sends a message in the style of <xref target="R
	ect. When calling this method the "using" property of the Request obje	FC5322" format="default"/> from an MDN object. When calling this method, the "us
	ct MUST contain the capabilities "urn:ietf:params:jmap:mdn" and "	ing" property of the Request object <bcp14>MUST</bcp14> contain the capabilities
	urn:ietf:params:jmap:mail"; the latter because of the implicit call to Emai	"urn:ietf:params:jmap:mdn" and "urn:ietf:params:jmap:mail"; the latter because
	l/set and the use of Identities, described below.	of the implicit call to "Email/set" and the use of Identity objects, which is de
		scribed below.
	The method takes the following arguments:	The method takes the following arguments:
	</t>	</t>

	<t>	<ul spacing="normal">
	<list style="symbols">	<li><t>accountId: <tt>Id</tt></t>
	<t>accountId: <spanx style="verb">Id</spanx>	<t>The id of the account to use.</t></li>
	The id of the account to use.</t>	<li><t>identityId: <tt>Id</tt></t>
	<t>identityId: <spanx style="verb">Id</spanx>	<t>The id of the Identity to associate with these MDNs. The server will use this
	The id of the Identity to associate with these MDNs. The server will use this id	identity to define the sender of the MDNs and to set the "finalRecipient" field
	entity to define the sender of the MDNs and to set the finalRecipient field.</t>	.</t></li>
	<t>send: <spanx style="verb">Id[MDN]</spanx>	<li><t>send: <tt>Id[MDN]</tt></t>
	A map of creation id (client specified) to MDN objects.</t>	<t>A map of the creation id (client specified) to MDN objects.</t></li>
	<t>onSuccessUpdateEmail: <spanx style="verb">Id[PatchObject]\|null</spanx>	<li><t>onSuccessUpdateEmail: <tt>Id[PatchObject]\|null</tt></t>
	A map of id to an object containing properties to update on the Email object ref	<t>A map of the id to an object containing properties to update on the Email obj
	erenced by the "MDN/send" if the sending succeeds. This will always be	ect referenced by the "MDN/send" if the sending succeeds. This will always be a
	a backward reference to the creation id (see example below in Section 3.1).</t>	backward reference to the creation id (see the example below in <xref target="se
	</list>	nding-an-mdn-for-a-received-email-message" format="default"/>).</t></li>
	</t>	</ul>
	<t>The response has the following arguments:	<t>The response has the following arguments:
	</t>
	<t>
	<list style="symbols">
	<t>accountId: <spanx style="verb">Id</spanx>
	The id of the account used for the call.</t>
	<t>sent: <spanx style="verb">Id[MDN]\|null</spanx>
	A map of creation id to MDN containing any properties that were not set by the c
	lient. 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 succes
	sfully sent.</t>
	<t>notSent: <spanx style="verb">Id[SetError]\|null</spanx>
	A map of the creation id to a SetError object for each record that failed to be
	sent, or null if all successful.</t>
	</list>
	</t>
	<t>In this context, the existing SetError types defined in <xref target="RFC8620
	"/> and <xref target="RFC8621"/> are interpreted as follows:
	</t>
	<t>
	<list style="symbols">
	<t>notFound: The reference Email id cannot be found, or has no valid "Dispo
	sition-Notification-To" header field.</t>
	<t>forbidden: MDN/send would violate an ACL or other permissions policy.</t>
	<t>forbiddenFrom: The user is not allowed to use the given finalRecipient proper
	ty.</t>
	<t>overQuota: MDN/send would exceed a server-defined limit on the number or tota
	l size of sent MDNs. It could include limitations on sent messages.</t>
	<t>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 email message.</t>
	<t>rateLimit: Too many MDNs or email messages have been created recently, and a
	server-defined rate limit has been reached. It may work if tried again later.</t
	>
	<t>invalidProperties: The record given is invalid in some way.</t>
	</list>
	</t>
	<t>The following is a new SetError:
	</t>
	<t>
	<list style="symbols">
	<t>mdnAlreadySent: The message has the <spanx style="verb">$mdnsent</spanx> keyw
	ord already set.</t>
	</list>
	</t>
	<t>If the accountId or identityId given cannot be found, the method call is reje
	cted with an <spanx style="verb">invalidArguments</spanx> error.
	</t>	</t>

	<t>The client MUST NOT issue an MDN/send request if the message has the <spanx s	<ul spacing="normal">
	tyle="verb">$mdnsent</spanx> keyword set.	<li><t>accountId: <tt>Id</tt></t>
		<t>The id of the account used for the call.</t></li>
		<li><t>sent: <tt>Id[MDN]\|null</tt></t>
		<t>A map of the creation id to an MDN containing any properties that were not se
		t by the client. This includes any properties that were omitted by the client an
		d thus set to a default by the server. This argument is null if no MDN objects w
		ere successfully sent.</t></li>
		<li><t>notSent: <tt>Id[SetError]\|null</tt></t>
		<t>A map of the creation id to a SetError object for each record that failed to
		be sent or null if all successful.</t></li>
		</ul>
		<t>In this context, the existing SetError types defined in <xref target=
		"RFC8620" format="default"/> and <xref target="RFC8621" format="default"/> are i
		nterpreted as follows:
	</t>	</t>

	<t>When sending the MDN, the server is in charge of generating the "origina	<dl spacing="normal">
	lRecipient" and "originalMessageId" fields according to the [RFC8	<dt>notFound:</dt><dd> The reference "forEmailId" cannot be found or h
	098] specification. "finalRecipient" will also generally be generated	as no valid "Disposition-Notification-To" header field.</dd>
	by the server based on the provided identity, but if specified by the client and	<dt>forbidden:</dt><dd> "MDN/send" would violate an Access Control Lis
	allowed (see Section 5) the server will use the client provided value.	t (ACL) or other permissions policy.</dd>
		<dt>forbiddenFrom:</dt><dd> The user is not allowed to use the given "
		finalRecipient" property.</dd>
		<dt>overQuota:</dt><dd> "MDN/send" would exceed a server-defined limit
		on the number or total size of sent MDNs. It could include limitations on sent
		messages.</dd>
		<dt>tooLarge:</dt><dd> "MDN/send" would result in an MDN that exceeds
		a server-defined limit for the maximum size of an MDN or more generally, on emai
		l message.</dd>
		<dt>rateLimit:</dt><dd> Too many MDNs or email messages have been crea
		ted recently, and a server-defined rate limit has been reached. It may work if t
		ried again later.</dd>
		<dt>invalidProperties:</dt><dd> The record given is invalid in some wa
		y.</dd>
		</dl>
		<t>The following is a new SetError:
	</t>	</t>

	<t>The client is expected to explicitly update each "Email" for which	<dl spacing="normal">
	an "MDN/send" has been invoked in order to set the "$mdnsent&quot	<dt>mdnAlreadySent:</dt><dd> The message has the <tt>$mdnsent</tt> key
	; keyword on these messages. To ensure that, the server MUST reject an "MDN	word already set.</dd>
	/send" which does not result in setting the keyword "$mdnsent". T	</dl>
	hus the server MUST check that the "onSuccessUpdateEmail" property of	<t>If the "accountId" or "identityId" given cannot be found, the method
	the method is correctly set to update this keyword.	call is rejected with an <tt>invalidArguments</tt> error.
	</t>	</t>

	</section>	<t>The client <bcp14>MUST NOT</bcp14> issue an "MDN/send" request if the
		message has the <tt>$mdnsent</tt> keyword set.
	<section anchor="mdnparse" title="MDN/parse">
	<t>This method allows a client to parse blobs as <xref target="RFC5322"/> messag
	es to get MDN objects. This can be used to parse and get detailed information ab
	out blobs referenced in the "mdnBlobIds" of the EmailSubmission object
	, or any email message the client could expect to be an MDN.
	</t>	</t>

	<t>The "forEmailId" property can be null or missing if the "origi nalMessageId" property is missing or does not refer to an existing message, or if the server cannot efficiently calculate the related message (for example, if several messages get the same "Message-Id" header field).	<t>When sending the MDN, the server is in charge of generating the "orig inalRecipient" and "originalMessageId" fields according to <xref target="RFC8098 " format="default"/>. "finalRecipient" will also generally be generated by the s erver based on the provided identity, but if specified by the client and allowed (see <xref target="security-considerations" format="default"/>), the server wil l use the client-provided value.
	</t>	</t>

	<t>The MDN/parse method takes the following arguments:	<t>The client is expected to explicitly update each "Email" for which an "MDN/send" has been invoked in order to set the <tt>$mdnsent</tt> keyword on th ese messages. To ensure that, the server <bcp14>MUST</bcp14> reject an "MDN/send " that does not result in setting the keyword <tt>$mdnsent</tt>. Thus, the serve r <bcp14>MUST</bcp14> check that the "onSuccessUpdateEmail" property of the meth od is correctly set to update this keyword.
	</t>	</t>

	<t>	</section>
	<list style="symbols">	<section anchor="mdnparse" numbered="true" toc="default">
	<t>accountId: <spanx style="verb">Id</spanx>	<name>MDN/parse</name>
	The id of the account to use.</t>	<t>This method allows a client to parse blobs as messages in the style o
	<t>blobIds: <spanx style="verb">Id[]</spanx>	f <xref target="RFC5322" format="default"/> to get MDN objects. This can be used
	The ids of the blobs to parse.</t>	to parse and get detailed information about blobs referenced in the "mdnBlobIds
	</list>	" of the EmailSubmission object or any email message the client could expect to
		be an MDN.
	</t>	</t>

	<t>The response has the following arguments:	<t>The "forEmailId" property can be null or missing if the "originalMess ageId" property is missing or does not refer to an existing message or if the se rver cannot efficiently calculate the related message (for example, if several m essages get the same "Message-ID" header field).
	</t>	</t>

	<t>	<t>The "MDN/parse" method takes the following arguments:
	<list style="symbols">
	<t>accountId: <spanx style="verb">Id</spanx>
	The id of the account used for the call.</t>
	<t>parsed: <spanx style="verb">Id[MDN]\|null</spanx>
	A map of blob id to parsed MDN representation for each successfully parsed blob,
	or null if none.</t>
	<t>notParsable: <spanx style="verb">Id[]\|null</spanx>
	A list of ids given that corresponded to blobs that could not be parsed as MDNs,
	or null if none.</t>
	<t>notFound: <spanx style="verb">Id[]\|null</spanx>
	A list of blob ids given that could not be found, or null if none.</t>
	</list>
	</t>	</t>

	<t>The following additional errors may be returned instead of the MDN/parse resp	<ul spacing="normal">
	onse:	<li><t>accountId: <tt>Id</tt></t>
		<t>The id of the account to use.</t></li>
		<li><t>blobIds: <tt>Id[]</tt></t>
		<t>The ids of the blobs to parse.</t></li>
		</ul>
		<t>The response has the following arguments:
	</t>	</t>

	<t>	<ul spacing="normal">
	<list style="symbols">	<li><t>accountId: <tt>Id</tt></t>
	<t>requestTooLarge: The number of ids requested by the client exceeds the maximu	<t>The id of the account used for the call.</t></li>
	m number the server is willing to process in a single method call.</t>	<li><t>parsed: <tt>Id[MDN]\|null</tt></t>
	<t>invalidArguments: If the accountId given cannot be found, the MDN parsing is	<t>A map of the blob id to a parsed MDN representation for each successfully par
	rejected with an <spanx style="verb">invalidArguments</spanx> error.</t>	sed blob or null if none.</t></li>
	</list>	<li><t>notParsable: <tt>Id[]\|null</tt></t>
		<t>A list of ids given that corresponds to blobs that could not be parsed as MDN
		s or null if none.</t></li>
		<li><t>notFound: <tt>Id[]\|null</tt></t>
		<t>A list of blob ids given that could not be found or null if none.</t></li>
		</ul>
		<t>The following additional errors may be returned instead of the "MDN/p
		arse" response:
	</t>	</t>

	</section>	<dl spacing="normal">
	</section>	<dt>requestTooLarge:</dt><dd>The number of ids requested by the client
		exceeds the maximum number the server is willing to process in a single method
	<section anchor="samples" title="Samples">	call.</dd>
		<dt>invalidArguments:</dt><dd> If the given "accountId" cannot be foun
	<section anchor="sending-an-mdn-for-a-received-email-message" title="Sending an	d, the MDN parsing is rejected with an <tt>invalidArguments</tt> error.</dd>
	MDN for a received email message">	</dl>
	<t>A client can use the following request to send an MDN back to the sender:	</section>
		</section>
		<section anchor="samples" numbered="true" toc="default">
		<name>Samples</name>
		<section anchor="sending-an-mdn-for-a-received-email-message" numbered="tr
		ue" toc="default">
		<name>Sending an MDN for a Received Email Message</name>
		<t>A client can use the following request to send an MDN back to the sen
		der:
	</t>	</t>

		<artwork align="center" name="" type="" alt=""><![CDATA[
	<figure align="center"><artwork align="center">
	[[ "MDN/send", {	[[ "MDN/send", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"identityId": "I64588216",	"identityId": "I64588216",
	"send": {	"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.",	guarantee it has been read or understood.",
	"reportingUA": "joes-pc.cs.example.com; Foomail 97.1",	"reportingUA": "joes-pc.cs.example.com; Foomail 97.1",
	"disposition": {	"disposition": {
	"actionMode": "manual-action",	"actionMode": "manual-action",
	"sendingMode": "mdn-sent-manually",	"sendingMode": "mdn-sent-manually",
	"type": "displayed"	"type": "displayed"
	},	},
	"extension": {	"extension": {
	"EXTENSION-EXAMPLE": "example.com"	"EXTENSION-EXAMPLE": "example.com"
	}	}
	}	}
	},	},
	"onSuccessUpdateEmail": {	"onSuccessUpdateEmail": {
	"#k1546": {	"#k1546": {
	"keywords/$mdnsent": true	"keywords/$mdnsent": true
	}	}
	}	}
	}, "0" ]]	}, "0" ]]

	</artwork></figure>	]]></artwork>
	<t>If the email id matches an existing email message without the <spanx style="v	<t>If the email id matches an existing email message without the <tt>$md
	erb">$mdnsent</spanx> keyword, the server can answer:	nsent</tt> keyword, the server can answer:
	</t>	</t>

		<artwork align="center" name="" type="" alt=""><![CDATA[
	<figure align="center"><artwork align="center">
	[[ "MDN/send", {	[[ "MDN/send", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"sent": {	"sent": {
	"k1546": {	"k1546": {
	"finalRecipient": "rfc822; john@example.com",	"finalRecipient": "rfc822; john@example.com",

	"originalMessageId": "<199509192301.23456@example.org>"	"originalMessageId": "<199509192301.23456@example.org>"
	}	}
	}	}
	}, "0" ],	}, "0" ],
	[ "Email/set", {	[ "Email/set", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"oldState": "23",	"oldState": "23",
	"newState": "42",	"newState": "42",
	"updated": {	"updated": {
	"Md45b47b4877521042cec0938": {}	"Md45b47b4877521042cec0938": {}
	}	}
	}, "0" ]]	}, "0" ]]

	</artwork></figure>	]]></artwork>
	<t>If the <spanx style="verb">$mdnsent</spanx> keyword has already been set, the	<t>If the <tt>$mdnsent</tt> keyword has already been set, the server can
	server can answer an error:	answer an error:
	</t>	</t>

		<artwork align="center" name="" type="" alt=""><![CDATA[
	<figure align="center"><artwork align="center">
	[[ "MDN/send", {	[[ "MDN/send", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"notSent": {	"notSent": {
	"k1546": {	"k1546": {
	"type": "mdnAlreadySent",	"type": "mdnAlreadySent",
	"description" : "$mdnsent keyword is already present"	"description" : "$mdnsent keyword is already present"
	}	}
	}	}
	}, "0" ]]	}, "0" ]]

	</artwork></figure>	]]></artwork>
	</section>	</section>
		<section anchor="asking-for-mdn-when-sending-an-email-message" numbered="t
	<section anchor="asking-for-mdn-when-sending-an-email-message" title="Asking for	rue" toc="default">
	MDN when sending an email message">	<name>Asking for an MDN When Sending an Email Message</name>
	<t>This is done with the <xref target="RFC8621"/> "Email/set" "cr	<t>This is done with the "Email/set" "create" method of <xref target="R
	eate" method.	FC8621" format="default"/>.
	</t>	</t>

		<artwork align="center" name="" type="" alt=""><![CDATA[
	<figure align="center"><artwork align="center">
	[[ "Email/set", {	[[ "Email/set", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"create": {	"create": {
	"k2657": {	"k2657": {
	"mailboxIds": {	"mailboxIds": {
	"2ea1ca41b38e": true	"2ea1ca41b38e": true
	},	},
	"keywords": {	"keywords": {
	"$seen": true,	"$seen": true,
	"$draft": true	"$draft": true

	skipping to change at line 338 ¶	skipping to change at line 313 ¶
	"to": [{	"to": [{
	"name": "John",	"name": "John",
	"email": "john@example.com"	"email": "john@example.com"
	}],	}],
	"header:Disposition-Notification-To:asText": "joe@example.com",	"header:Disposition-Notification-To:asText": "joe@example.com",
	"subject": "World domination",	"subject": "World domination",
	...	...
	}	}
	}	}
	}, "0" ]]	}, "0" ]]

	</artwork></figure>	]]></artwork>
	<t>Note the specified <spanx style="verb">Disposition-Notification-To</spanx> he	<t>Note the specified "Disposition-Notification-To" header field indicat
	ader field indicating where to send MDN back (usually the sender of the message)	ing where to send the MDN (usually the sender of the message).
	.
	</t>	</t>

	</section>	</section>
		<section anchor="parsing-a-received-mdn" numbered="true" toc="default">
	<section anchor="parsing-a-received-mdn" title="Parsing a received MDN">	<name>Parsing a Received MDN</name>
	<t>The client issues a parse request:	<t>The client issues a parse request:
	</t>	</t>

		<artwork align="center" name="" type="" alt=""><![CDATA[
	<figure align="center"><artwork align="center">
	[[ "MDN/parse", {	[[ "MDN/parse", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"blobIds": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]	"blobIds": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]
	}, "0" ]]	}, "0" ]]

	</artwork></figure>	]]></artwork>
	<t>The server responds:	<t>The server responds:
	</t>	</t>

		<artwork align="center" name="" type="" alt=""><![CDATA[
	<figure align="center"><artwork align="center">
	[[ "MDN/parse", {	[[ "MDN/parse", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"parsed": {	"parsed": {
	"0f9f65ab-dc7b-4146-850f-6e4881093965": {	"0f9f65ab-dc7b-4146-850f-6e4881093965": {
	"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.",	guarantee it has been read or understood.",
	"reportingUA": "joes-pc.cs.example.com; Foomail 97.1",	"reportingUA": "joes-pc.cs.example.com; Foomail 97.1",
	"disposition": {	"disposition": {
	"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": "<199509192301.23456@example.org>"	"originalMessageId": "<199509192301.23456@example.org>"
	}	}
	}	}
	}, "0" ]]	}, "0" ]]

	</artwork></figure>	]]></artwork>
	<t>In case of a not found blobId, the server would respond:	<t>In the case that a blob id is not found, the server would respond:
	</t>	</t>

		<artwork align="center" name="" type="" alt=""><![CDATA[
	<figure align="center"><artwork align="center">
	[[ "MDN/parse", {	[[ "MDN/parse", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"notFound": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]	"notFound": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]
	}, "0" ]]	}, "0" ]]

	</artwork></figure>	]]></artwork>
	<t>If the blobId has been found but is not parsable, the server would respond:	<t>If the blob id has been found but is not parsable, the server would r
		espond:
	</t>	</t>

		<artwork align="center" name="" type="" alt=""><![CDATA[
	<figure align="center"><artwork align="center">
	[[ "MDN/parse", {	[[ "MDN/parse", {
	"accountId": "ue150411c",	"accountId": "ue150411c",
	"notParsable": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]	"notParsable": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]
	}, "0" ]]	}, "0" ]]

	</artwork></figure>	]]></artwork>
	</section>	</section>
	</section>	</section>
		<section anchor="iana-considerations" numbered="true" toc="default">
	<section anchor="iana-considerations" title="IANA Considerations">	<name>IANA Considerations</name>
		<section anchor="jmap-capability-registration-for-mdn" numbered="true" toc
	<section anchor="jmap-capability-registration-for-mdn" title="JMAP Capability Re	="default">
	gistration for "mdn"">	<name>JMAP Capability Registration for "mdn"</name>
	<t>IANA will register the "mdn" JMAP Capability as follows:	<t>This section registers the "mdn" JMAP Capability in the "JMAP Capabil
	</t>	ities" registry as follows:
	<t>Capability Name: <spanx style="verb">urn:ietf:params:jmap:mdn</spanx>
	</t>
	<t>Specification document: this document
	</t>
	<t>Intended use: common
	</t>
	<t>Change Controller: IETF
	</t>
	<t>Security and privacy considerations: this document, section 5.
	</t>
	</section>

	<section anchor="jmap-error-codes-registry" title="JMAP Error Codes Registry">
	<t>This section registers one new error code in the "JMAP Error Codes"
	registry, as defined in <xref target="RFC8620"/>.
	</t>
	<t>JMAP Error Code: mdnAlreadySent
	</t>
	<t>Intended use: common
	</t>
	<t>Change controller: IETF
	</t>
	<t>Reference: This document, Section 2.1
	</t>	</t>

	<t>Description: The message has the <spanx style="verb">$mdnsent</spanx> keyword	<dl spacing="compact">
	already set. The client MUST NOT try again to send an MDN for this message.	<dt>Capability Name:</dt><dd> <tt>urn:ietf:params:jmap:mdn</tt>
		</dd>
		<dt>Intended Use:</dt><dd> common
		</dd>
		<dt>Change Controller:</dt><dd> IETF
		</dd>
		<dt>Security and Privacy Considerations:</dt><dd> This document, <xref t
		arget="security-considerations" format="default"/>.
		</dd>
		<dt>Reference:</dt><dd> This document
		</dd>
		</dl>
		</section>
		<section anchor="jmap-error-codes-registry" numbered="true" toc="default">
		<name>JMAP Error Codes Registration for "mdnAlreadySent"</name>
		<t>IANA has registered one new error code in the "JMAP Error Codes" regi
		stry, as defined in <xref target="RFC8620" format="default"/>.
	</t>	</t>

	</section>	<dl spacing="compact">
	</section>	<dt>JMAP Error Code:</dt><dd> mdnAlreadySent
		</dd>
	<section anchor="security-considerations" title="Security considerations">	<dt>Intended Use:</dt><dd> common
	<t>The same considerations regarding MDN (see <xref target="RFC8098"/> and <xref	</dd>
	target="RFC3503"/>) apply to this document.	<dt>Change Controller:</dt><dd> IETF
		</dd>
		<dt>Description:</dt><dd> The message has the <tt>$mdnsent</tt> keyword
		already set. The client <bcp14>MUST NOT</bcp14> try again to send an MDN for thi
		s message.
		</dd>
		<dt>Reference:</dt><dd> This document, <xref target="mdnsend" format="de
		fault"/>
		</dd>
		</dl>
		</section>
		</section>
		<section anchor="security-considerations" numbered="true" toc="default">
		<name>Security Considerations</name>
		<t>The same considerations regarding MDN (see <xref target="RFC8098" forma
		t="default"/> and <xref target="RFC3503" format="default"/>) apply to this docum
		ent.
	</t>	</t>

	<t>In order to reinforce trust regarding the relation between the user sending a n email message and the identity of this user, the server SHOULD validate in con formance to the provided Identity that the user is permitted to use the finalRec ipient value and return a forbiddenFrom error if not.	<t>In order to reinforce trust regarding the relation between the user sen ding an email message and the identity of this user, the server <bcp14>SHOULD</b cp14> validate in conformance to the provided Identity that the user is permitte d to use the "finalRecipient" value and return a <tt>forbiddenFrom</tt> error if not.
	</t>	</t>

	</section>	</section>
		</middle>
	</middle>	<back>
	<back>	<references>
	<references title="Normative References">	<name>Normative References</name>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	19.xml"?>	.2119.xml"/>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.35	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	03.xml"?>	.3503.xml"/>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.53	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	22.xml"?>	.5322.xml"/>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.80	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	98.xml"?>	.8098.xml"/>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	74.xml"?>	.8174.xml"/>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.86	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	20.xml"?>	.8620.xml"/>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.86	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	21.xml"?>	.8621.xml"/>
	</references>	</references>
		</back>
	</back>
	</rfc>	</rfc>

End of changes. 59 change blocks.
	411 lines changed or deleted	393 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/