draft-ietf-jmap-mdn-04.txt   draft-ietf-jmap-mdn-05.txt 
JMAP R. Ouazana, Ed. JMAP R. Ouazana, Ed.
Internet-Draft Linagora Internet-Draft Linagora
Intended status: Standards Track December 16, 2019 Intended status: Standards Track February 26, 2020
Expires: June 18, 2020 Expires: August 29, 2020
Handling Message Disposition Notification with JMAP Handling Message Disposition Notification with JMAP
draft-ietf-jmap-mdn-04 draft-ietf-jmap-mdn-05
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 June 18, 2020. This Internet-Draft will expire on August 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Addition to the capabilities object . . . . . . . . . . . 3 1.3. Addition to the capabilities object . . . . . . . . . . . 3
2. MDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. MDN/set . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. MDN/send . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. MDN/parse . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. MDN/parse . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Sending an MDN for a received email . . . . . . . . . . . 6 3.1. Sending an MDN for a received email . . . . . . . . . . . 7
3.2. Asking for MDN when sending an email . . . . . . . . . . 7 3.2. Asking for MDN when sending an email . . . . . . . . . . 8
3.3. Parsing a received MDN . . . . . . . . . . . . . . . . . 7 3.3. Parsing a received MDN . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
4.1. JMAP Capability Registration for "mdn" . . . . . . . . . 8 4.1. JMAP Capability Registration for "mdn" . . . . . . . . . 10
5. Security considerations . . . . . . . . . . . . . . . . . . . 8 4.2. JMAP Error Codes Registry . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. mdnAlreadySent . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 9 5. Security considerations . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic
protocol for synchronising data, such as mail, calendars or contacts, protocol for synchronising data, such as mail, calendars or contacts,
between a client and a server. It is optimised for mobile and web between a client and a server. It is optimised for mobile and web
environments, and aims to provide a consistent interface to different environments, and aims to provide a consistent interface to different
data types. data types.
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/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 could want to display detailed
information about a received MDN. This specification defines a 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 3, line 36 skipping to change at page 3, line 36
1.3. Addition to the capabilities object 1.3. Addition to the capabilities object
Capabilities are announced as part of the standard JMAP Session Capabilities are announced as part of the standard JMAP Session
resource; see [RFC8620], section 2. resource; see [RFC8620], section 2.
Support for the "MDN" data type and the "MDN/parse" method are Support for the "MDN" data type and the "MDN/parse" method are
represented by the capability "urn:ietf:params:jmap:mdn" being represented by the capability "urn:ietf:params:jmap:mdn" being
present in the "capabilities" property. The capability present in the "capabilities" property. The capability
"urn:ietf:params:jmap:mdn" being present in the "accountCapabilities" "urn:ietf:params:jmap:mdn" being present in the "accountCapabilities"
property of an account represents support for creating and sending property of an account represents support for creating and sending
MDN messages via the "MDN/set" method. Servers that include the MDN messages via the "MDN/send" method. Servers that include the
capability in one or more "accountCapabilities" properties MUST also capability in one or more "accountCapabilities" properties MUST also
include the property in the "capabilities" property. include the property in the "capabilities" property.
The value of this "urn:ietf:params:jmap:mdn" property is an empty The value of this "urn:ietf:params:jmap:mdn" property is an empty
object in both the JMAP session "capabilities" property and an object in both the JMAP session "capabilities" property and an
account's "accountCapabilities" property. account's "accountCapabilities" property.
2. MDN 2. MDN
An *MDN* object has the following properties: An *MDN* object has the following properties:
skipping to change at page 5, line 5 skipping to change at page 5, line 5
"manual-action" / "automatic-action" "manual-action" / "automatic-action"
o sendingMode: "String" This MUST be one of the following strings: o sendingMode: "String" This MUST be one of the following strings:
"MDN-sent-manually" / "MDN-sent-automatically" "MDN-sent-manually" / "MDN-sent-automatically"
o type: "String" This MUST be one of the following strings: o type: "String" This MUST be one of the following strings:
"deleted" / "dispatched" / "displayed" / "processed" "deleted" / "dispatched" / "displayed" / "processed"
See [RFC8098] for the exact meaning of these different fields. See [RFC8098] for the exact meaning of these different fields.
2.1. MDN/set 2.1. MDN/send
This is a standard "/set" method as described in [RFC8620] where only The MDN/send method sends an [RFC5322] message from an MDN object.
create is supported; any attempt to update/destroy MUST be rejected The capability "urn:ietf:params:jmap:mail" is implicitely required
with a "forbidden" SetError. while using this method. The method takes the following arguments:
The MDN/set method generates and sends an [RFC5322] message from an o accountId: "Id" The id of the account to use.
MDN object.
The client SHOULD NOT issue a MDN/set request if the message has the o send: "Id[MDN]" A map of creation id (client specified) to MDN
"$MDNSent" keyword set. In this case, the server MUST reject the objects.
submission with a standard "alreadyExists" SetError.
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 sent by the client. 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 successfully sent.
o notSent: "Id[MDNError]|null" A map of the creation id to an
MDNError object for each record that failed to be sent, or null if
all successful.
The following MDNError types are defined:
o mdnAlreadySent: The message has the "$MDNSent" keyword already
set.
o forbidden: MDN/send would violate an ACL or other permissions
policy.
o overQuota: MDN/send would exceed a server-defined limit on the
number or total size of sent MDN. It could include limitations on
sent emails.
o 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
emails.
o rateLimit: Too many MDN or emails have been created recently, and
a server-defined rate limit has been reached. It may work if
tried again later.
o invalidProperties: The record given is invalid in some way.
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 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. accordingly to the [RFC8098] specification.
After all items in the "MDN/set" 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/set" 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
get MDN objects. This can be used to parse and get detailed get MDN objects. This can be used to parse and get detailed
information about blobs referenced in the "mdnBlobIds" of the information about blobs referenced in the "mdnBlobIds" of the
EmailSubmission object, or any email the client could expect to be an EmailSubmission object, or any email the client could expect to be an
MDN. MDN.
The "forEmailId" property can be null or missing if the The "forEmailId" property can be null or missing if the
skipping to change at page 6, line 11 skipping to change at page 6, line 49
o parsed: "Id[MDN]|null" A map of blob id to parsed MDN o parsed: "Id[MDN]|null" A map of blob id to parsed MDN
representation for each successfully parsed blob, or null if none. representation for each successfully parsed blob, or null if none.
o notParsable: "Id[]|null" A list of ids given that corresponded to o notParsable: "Id[]|null" A list of ids given that corresponded to
blobs that could not be parsed as MDNs, or null if none. blobs that could not be parsed as MDNs, or null if none.
o notFound: "Id[]|null" A list of blob ids given that could not be o notFound: "Id[]|null" A list of blob ids given that could not be
found, or null if none. found, or null if none.
The following additional error may be returned instead of the MDN/
parse response:
o requestTooLarge: The number of ids requested by the client exceeds
the maximum number the server is willing to process in a single
method call.
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/set", { [[ "MDN/send", {
"accountId": "ue150411c", "accountId": "ue150411c",
"create": { "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",
"sendingMode": "MDN-sent-manually", "sendingMode": "MDN-sent-manually",
"type": "displayed" "type": "displayed"
} }
} }
} }
}, "0" ]] }, "0" ]]
If the email id matches an existing email without the "$MDNSent" If the email id matches an existing email without the "$MDNSent"
keyword, the server can answer: keyword, the server can answer:
[[ "MDN/set", { [[ "MDN/send", {
"accountId": "ue150411c", "accountId": "ue150411c",
"oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", "sent": {
"newState": "355421f6-8aed-4cf4-a0c4-7377e951af36",
"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" ],
[ "Email/set", {
"accountId": "ue150411c",
"oldState": "23",
"newState": "42",
"updated": {
"Md45b47b4877521042cec0938": {
"keywords": {
"$MDNSent": true
}
}
}
}, "0" ]]
If the "$MDNSent" keyword has already been set, the server can answer
an error:
[[ "MDN/send", {
"accountId": "ue150411c",
"notSent": {
"k1546": {
"type": "mdnAlreadySent",
"description" : "$MDNSent keyword is already present"
}
}
}, "0" ]]
3.2. Asking for MDN when sending an email 3.2. Asking for MDN when sending an email
This is done with the [RFC8621] "Email/set" "create" method. This is done with the [RFC8621] "Email/set" "create" 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,
"$draft": true "$draft": true
}, },
"from": [{ "from": [{
"name": "Joe Bloggs", "name": "Joe Bloggs",
"email": "joe@example.com" "email": "joe@example.com"
}], }],
"to": [{ "to": [{
"name": "John", "name": "John",
"email": "john@example.com" "email": "john@example.com"
}], }],
"header:Disposition-Notification-To": "joe@example.com", "header:Disposition-Notification-To:asText": "joe@example.com",
"subject": "World domination", "subject": "World domination",
... ...
} }
} }
}, "0" ]] }, "0" ]]
Note the specified "Disposition-Notification-To" header indicating Note the specified "Disposition-Notification-To" header indicating
where to send MDN back (usually the sender of the email). where to send MDN back (usually the sender of the email).
3.3. Parsing a received MDN 3.3. Parsing a received MDN
The client issues a parse request: The client issues a parse request:
[[ "MDN/parse", { [[ "MDN/parse", {
"accountId": "ue150411c", "accountId": "ue150411c",
skipping to change at page 8, line 26 skipping to change at page 10, line 26
"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": "<1521557867.2614.0.camel@apache.org>" "originalMessageId": "<1521557867.2614.0.camel@apache.org>"
} }
} }
}, "0" ]] }, "0" ]]
In case of a not found blobId, the server would respond:
[[ "MDN/parse", {
"accountId": "ue150411c",
"notFound": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]
}
}, "0" ]]
If the blobId has been found but is not parsable, the server would
respond:
[[ "MDN/parse", {
"accountId": "ue150411c",
"notParsable": [ "0f9f65ab-dc7b-4146-850f-6e4881093965" ]
}
}, "0" ]]
4. IANA Considerations 4. IANA Considerations
4.1. JMAP Capability Registration for "mdn" 4.1. JMAP Capability Registration for "mdn"
IANA will register the "mdn" JMAP Capability as follows: IANA will register the "mdn" JMAP Capability as follows:
Capability Name: "urn:ietf:params:jmap:mdn" Capability Name: "urn:ietf:params:jmap:mdn"
Specification document: this document Specification document: this document
Intended use: common Intended use: common
Change Controller: IETF Change Controller: IETF
Security and privacy considerations: this document, section 5. Security and privacy considerations: this document, section 5.
4.2. JMAP Error Codes Registry
The following subsection register one new error code in the "JMAP
Error Codes" registry, as defined in [RFC8620].
4.2.1. mdnAlreadySent
JMAP Error Code: mdnAlreadySent
Intended use: common
Change controller: IETF
Reference: This document, Section 2.1
Description: The message has the "$MDNSent" keyword already set. The
client MUST NOT try again to send an MDN for this message.
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
[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,
 End of changes. 25 change blocks. 
64 lines changed or deleted 168 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/