Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP)
RFC 9007
Document | Type |
RFC - Proposed Standard
(March 2021; No errata)
Was draft-ietf-jmap-mdn (jmap WG)
|
|
---|---|---|---|
Author | Raphaël Ouazana | ||
Last updated | 2021-03-22 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication (wg milestone: Jun 2020 - Submit Message Dispo... ) | |
Document shepherd | Bron Gondwana | ||
Shepherd write-up | Show (last changed 2020-07-03) | ||
IESG | IESG state | RFC 9007 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Barry Leiba | ||
Send notices to | Bron Gondwana <brong@fastmailteam.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack | ||
IANA expert review state | Expert Reviews OK |
Internet Engineering Task Force (IETF) R. Ouazana, Ed. Request for Comments: 9007 Linagora Category: Standards Track March 2021 ISSN: 2070-1721 Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) Abstract This document specifies a data model for handling Message Disposition Notifications (MDNs) (see RFC 8098) in the JSON Meta Application Protocol (JMAP) (see RFCs 8620 and 8621). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9007. Copyright Notice Copyright (c) 2021 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Notational Conventions 1.2. Terminology 1.3. Addition to the Capabilities Object 2. MDN 2.1. MDN/send 2.2. MDN/parse 3. Samples 3.1. Sending an MDN for a Received Email Message 3.2. Asking for an MDN When Sending an Email Message 3.3. Parsing a Received MDN 4. IANA Considerations 4.1. JMAP Capability Registration for "mdn" 4.2. JMAP Error Codes Registration for "mdnAlreadySent" 5. Security Considerations 6. Normative References Author's Address 1. Introduction JMAP ("The JSON Meta Application Protocol (JMAP)" [RFC8620]) is a generic protocol for synchronising data, such as mail, calendars, or contacts, between a client and a server. It is optimised for mobile and web environments, and it provides a consistent interface to different data types. JMAP for Mail ("The JSON Meta Application Protocol (JMAP) for Mail" [RFC8621]) specifies a data model for synchronising email data with a server using JMAP. Clients can use this to efficiently search, access, organise, and send messages. Message Disposition Notifications (MDNs) are defined in [RFC8098] and are used as "read receipts", "acknowledgements", or "receipt notifications". A client can come across MDNs in different ways: 1. When receiving an email message, an MDN can be sent to the sender. This specification defines an "MDN/send" method to cover this case. 2. When sending an email message, an MDN can be requested. This must be done with the help of a header field, as already specified by [RFC8098]; the header field can already be handled by guidance in [RFC8621]. 3. When receiving an MDN, the MDN could be related to an existing sent message. This is already covered by [RFC8621] in the EmailSubmission object. A 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. Type signatures, examples, and property descriptions in this document follow the conventions established in Section 1.1 of [RFC8620]. Data types defined in the core specification are also used in this document. Servers MUST support all properties specified for the new data types defined in this document. 1.2. Terminology The same terminology is used in this document as in the core JMAP specification. Because keywords are case insensitive in IMAP but case sensitive in JMAP, the "$mdnsent" keyword MUST always be used in lowercase. 1.3. Addition to the Capabilities Object Capabilities are announced as part of the standard JMAP Session resource; see [RFC8620], Section 2. This defines a new capability,Show full document text