draft-ietf-jmap-mdn-14.txt		draft-ietf-jmap-mdn-15.txt
	JMAP R. Ouazana, Ed.		JMAP R. Ouazana, Ed.
	Internet-Draft Linagora		Internet-Draft Linagora
	Intended status: Standards Track July 24, 2020		Intended status: Standards Track July 27, 2020
	Expires: January 25, 2021		Expires: January 28, 2021
	Handling Message Disposition Notification with JMAP		Handling Message Disposition Notification with JMAP
	draft-ietf-jmap-mdn-14		draft-ietf-jmap-mdn-15
	Abstract		Abstract
	This document specifies a data model for handling Message Disposition		This document specifies a data model for handling Message Disposition
	Notifications (MDNs, RFC 8098) in the JSON Meta Application Protocol		Notifications (MDNs, RFC 8098) in the JSON Meta Application Protocol
	(JMAP, RFCs 8620 and 8621).		(JMAP, RFCs 8620 and 8621).
	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 32 ¶		skipping to change at page 1, line 32 ¶
	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 25, 2021.		This Internet-Draft will expire on January 28, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 6, line 44 ¶		skipping to change at page 6, line 44 ¶
	o invalidProperties: The record given is invalid in some way.		o invalidProperties: The record given is invalid in some way.
	The following is a new SetError:		The following is a new SetError:
	o mdnAlreadySent: The message has the "$mdnsent" keyword already		o mdnAlreadySent: The message has the "$mdnsent" keyword already
	set.		set.
	If the accountId or identityId given cannot be found, the method call		If the accountId or identityId given cannot be found, the method call
	is rejected with an "invalidArguments" error.		is rejected with an "invalidArguments" error.
	The client SHOULD NOT issue an MDN/send request if the message has		The client MUST NOT issue an MDN/send request if the message has the
	the "$mdnsent" keyword set.		"$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
	according to the [RFC8098] specification.		according to the [RFC8098] specification.
	The client is expected to explicitly update each "Email" for which an		The client is expected to explicitly update each "Email" for which an
	"MDN/send" has been invoked in order to set the "$mdnsent" keyword on		"MDN/send" has been invoked in order to set the "$mdnsent" keyword on
	these messages. To ensure that, the server MUST reject an "MDN/send"		these messages. To ensure that, the server MUST reject an "MDN/send"
	which does not result in setting the keyword "$mdnsent". Thus the		which does not result in setting the keyword "$mdnsent". Thus the
	server MUST check that the "onSuccessUpdateEmail" property of the		server MUST check that the "onSuccessUpdateEmail" property of the
End of changes. 4 change blocks.
	6 lines changed or deleted		6 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/