--- 1/draft-ietf-jmap-mdn-08.txt 2020-04-30 10:13:04.636355062 -0700 +++ 2/draft-ietf-jmap-mdn-09.txt 2020-04-30 10:13:04.660355672 -0700 @@ -1,18 +1,18 @@ JMAP R. Ouazana, Ed. Internet-Draft Linagora -Intended status: Standards Track March 19, 2020 -Expires: September 20, 2020 +Intended status: Standards Track April 30, 2020 +Expires: November 1, 2020 Handling Message Disposition Notification with JMAP - draft-ietf-jmap-mdn-08 + draft-ietf-jmap-mdn-09 Abstract This document specifies a data model for handling [RFC8098] MDN messages with a server using JMAP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -20,21 +20,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 20, 2020. + This Internet-Draft will expire on November 1, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -82,21 +82,21 @@ 1. When receiving an email, an MDN can be sent to the sender. This specification defines an MDN/send method to cover this case. 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 [RFC8098] and can already be handled by [RFC8621] this way. 3. When receiving an MDN, the MDN could be related to an existing sent mail. This is already covered by [RFC8621] in the - EmailSubmission object. Client could want to display detailed + EmailSubmission object. Client might want to display detailed information about a received MDN. This specification defines an MDN/parse method to cover this case. 1.1. Notational conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. @@ -200,23 +200,23 @@ The MDN/send method sends an [RFC5322] message from an MDN object. When calling this method the "using" property of the Request object MUST contain the capabilities "urn:ietf:params:jmap:mdn" and "urn:ietf:params:jmap:mail". The latter because of the implicit call to Email/set and the use of Identities, described below. The method takes the following arguments: o accountId: "Id" The id of the account to use. - o identity: "Id" The id of the Identity to associate with these MDN. - The server will use this identity to define the sender of the MDN - and to set the finalRecipient field. + o identityId: "Id" The id of the Identity to associate with these + MDN. The server will use this identity to define the sender of + the MDN and to set the finalRecipient field. o send: "Id[MDN]" A map of creation id (client specified) to MDN objects. 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 set by the client. This includes any @@ -254,21 +254,21 @@ o invalidProperties: The record given is invalid in some way. If the Account Id or Identity id given cannot be found, the MDN sending is rejected with an "invalidProperties" error. 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 "originalRecipient", "finalRecipient" and "originalMessageId" fields - accordingly to the [RFC8098] specification. + according to the [RFC8098] specification. After all items in the "MDN/send" invocation have been processed, a single implicit "Email/set" call MUST be made to set the "$mdnsent" keyword on "Email" objects referenced by "MDN" objects that have been successfully created (see [RFC3503] for more details). The response to this MUST be returned after the "MDN/send" response. 2.2. MDN/parse This method allows a client to parse blobs as [RFC5322] messages to @@ -312,20 +312,21 @@ 3. Samples 3.1. Sending an MDN for a received email A client can use the following request to send an MDN back to the sender: [[ "MDN/send", { "accountId": "ue150411c", + "identityId": "I64588216", "send": { "k1546": { "forEmailId": "Md45b47b4877521042cec0938", "subject": "Read receipt for: World domination", "textBody": "This receipt shows that the email has been displayed on your recipient's computer. There is no guaranty it has been read or understood.", "reportingUA": "linagora.com; OpenPaaS", "disposition": { "actionMode": "manual-action",