draft-ietf-jmap-mdn-02.txt		draft-ietf-jmap-mdn-03.txt
	JMAP R. Ouazana, Ed.		JMAP R. Ouazana, Ed.
	Internet-Draft Linagora		Internet-Draft Linagora
	Intended status: Standards Track July 19, 2019		Intended status: Standards Track November 20, 2019
	Expires: January 20, 2020		Expires: May 23, 2020
	Handling Message Disposition Notification with JMAP		Handling Message Disposition Notification with JMAP
	draft-ietf-jmap-mdn-02		draft-ietf-jmap-mdn-03
	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 January 20, 2020.		This Internet-Draft will expire on May 23, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 44 ¶		skipping to change at page 2, line 44 ¶
	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/set 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 [I-D.ietf-jmap-mail] this		[RFC8098] and can already be handled by [RFC8621] this way.
	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 [I-D.ietf-jmap-mail] in		sent mail. This is already covered by [RFC8621] in the
	the EmailSubmission object. Client could want to display		EmailSubmission object. Client could want to display detailed
	detailed information about a received MDN. This specification		information about a received MDN. This specification defines a
	defines a 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.
	Type signatures, examples and property descriptions in this document		Type signatures, examples and property descriptions in this document
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 41 ¶
	"created": {		"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" ],
	3.2. Asking for MDN when sending an email		3.2. Asking for MDN when sending an email
	This is done with the [I-D.ietf-jmap-mail] "Email/set" _create_		This is done with the [RFC8621] "Email/set" _create_ method.
	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,
	skipping to change at page 9, line 6 ¶		skipping to change at page 9, line 6 ¶
	Security and privacy considerations: this document, section 5.		Security and privacy considerations: this document, section 5.
	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
	[I-D.ietf-jmap-mail]
	Jenkins, N. and C. Newman, "JMAP (JSON Meta Application
	Protocol) for Mail", draft-ietf-jmap-mail-16 (work in
	progress), March 2019.
	[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,
	<https://www.rfc-editor.org/info/rfc3503>.		<https://www.rfc-editor.org/info/rfc3503>.
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 28 ¶
	<https://www.rfc-editor.org/info/rfc5322>.		<https://www.rfc-editor.org/info/rfc5322>.
	[RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition		[RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
	Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,		Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
	February 2017, <https://www.rfc-editor.org/info/rfc8098>.		February 2017, <https://www.rfc-editor.org/info/rfc8098>.
	[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application		[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
	Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July		Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
	2019, <https://www.rfc-editor.org/info/rfc8620>.		2019, <https://www.rfc-editor.org/info/rfc8620>.
			[RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application
			Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621,
			August 2019, <https://www.rfc-editor.org/info/rfc8621>.
	6.2. Informative References		6.2. Informative References
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	Author's Address		Author's Address
	Raphael Ouazana (editor)		Raphael Ouazana (editor)
	Linagora		Linagora
End of changes. 8 change blocks.
	17 lines changed or deleted		14 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/