draft-ietf-jmap-mdn-08.txt   draft-ietf-jmap-mdn-09.txt 
JMAP R. Ouazana, Ed. JMAP R. Ouazana, Ed.
Internet-Draft Linagora Internet-Draft Linagora
Intended status: Standards Track March 19, 2020 Intended status: Standards Track April 30, 2020
Expires: September 20, 2020 Expires: November 1, 2020
Handling Message Disposition Notification with JMAP Handling Message Disposition Notification with JMAP
draft-ietf-jmap-mdn-08 draft-ietf-jmap-mdn-09
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 September 20, 2020. This Internet-Draft will expire on November 1, 2020.
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 2, line 50 skipping to change at page 2, line 50
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/send 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 might want to display detailed
information about a received MDN. This specification defines an 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 5, line 24 skipping to change at page 5, line 24
The MDN/send method sends an [RFC5322] message from an MDN object. The MDN/send method sends an [RFC5322] message from an MDN object.
When calling this method the "using" property of the Request object When calling this method the "using" property of the Request object
MUST contain the capabilities "urn:ietf:params:jmap:mdn" and MUST contain the capabilities "urn:ietf:params:jmap:mdn" and
"urn:ietf:params:jmap:mail". The latter because of the implicit call "urn:ietf:params:jmap:mail". The latter because of the implicit call
to Email/set and the use of Identities, described below. The method to Email/set and the use of Identities, described below. The method
takes the following arguments: takes the following arguments:
o accountId: "Id" The id of the account to use. o accountId: "Id" The id of the account to use.
o identity: "Id" The id of the Identity to associate with these MDN. o identityId: "Id" The id of the Identity to associate with these
The server will use this identity to define the sender of the MDN MDN. The server will use this identity to define the sender of
and to set the finalRecipient field. the MDN and to set the finalRecipient field.
o send: "Id[MDN]" A map of creation id (client specified) to MDN o send: "Id[MDN]" A map of creation id (client specified) to MDN
objects. objects.
The response has the following arguments: The response has the following arguments:
o accountId: "Id" The id of the account used for the call. 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 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 properties that were not set by the client. This includes any
skipping to change at page 6, line 30 skipping to change at page 6, line 30
o invalidProperties: The record given is invalid in some way. o invalidProperties: The record given is invalid in some way.
If the Account Id or Identity id given cannot be found, the MDN If the Account Id or Identity id given cannot be found, the MDN
sending is rejected with an "invalidProperties" error. sending is rejected with an "invalidProperties" error.
The client SHOULD NOT issue an MDN/send request if the message has The client SHOULD NOT issue an MDN/send request if the message has
the "$mdnsent" keyword set. 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. according to the [RFC8098] specification.
After all items in the "MDN/send" 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/send" 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
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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/send", { [[ "MDN/send", {
"accountId": "ue150411c", "accountId": "ue150411c",
"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.", guaranty it has been read or understood.",
"reportingUA": "linagora.com; OpenPaaS", "reportingUA": "linagora.com; OpenPaaS",
"disposition": { "disposition": {
"actionMode": "manual-action", "actionMode": "manual-action",
 End of changes. 7 change blocks. 
9 lines changed or deleted 10 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/