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/