Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP)
RFC 9007

Document Type RFC - Proposed Standard (March 2021; No errata)
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