Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP)
draft-ietf-jmap-mdn-17

[Ballot comment]
A few minor comments:

** Section 2.  Per “This property MUST NOT be null for "MDN/send", but may be null in the response from the "MDN/parse" method”, should a normative MAY be used here instead (or would that conflict with RFC8098)

** Section 2.  The guidance to reference RFC8098 for further details is helpful.  In addition to the guidance on case sensitivity, I would have also would have benefit from a bit of prose on how to convert the fields names between this document and RFC8098.

[Ballot discuss]
This should be quite easy to resolve; I'm just not sure yet which
direction the resolution will be.

I think we should be a little more clear about whether the client can
override the finalRecipient calculation (or just provide a suggestion to
do so, or not give any input at all, etc.): the description of the
finalRecipient property of an MDN object says that "if set, it
overrides the value that would be calculated by the server from the
Identity", which to me suggests that the client could set something to
override the server (if the server sua sponte did something different
that would typically be an "exception", not an "override"), but later on
in Section 2.1 we say that "[w]hen sending the MDN, the server is in
charge of generating the "originalRecipient", "finalRecipient" and
"originalMessageId" fields according to the [RFC8098] specification.  I
do not see discussion in RFC 8098 of client intput into the server's
populating of this field, so I'm unsure whether/where the client has
input.

[Ballot comment]
Thank you for noting the `jq` validation in the sheperd writeup!

Section 1

  A client can have to deal with MDNs in different ways:

(editorial) "have to deal with" seems like it can be read as implying
obligation to do so (even though the majuscule "MUST" is not used); it
seems like this is just attempting to enumerate the cases in which an
MDN might be encountered or need to be interacted with.

  2.  When sending an email message, an MDN can be requested.  This
      must be done with the help of a header, and is already specified
      by [RFC8098] and can already be handled by [RFC8621] this way.

(nit?) "header" or "header field"?  (We get this a lot for HTTP and I've
forgotten if SMTP uses the same rule...)

  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.  [...]

(The "DeliveryStatus" member, in particular, right?)

Section 1.3

  The value of this "urn:ietf:params:jmap:mdn" property is an empty
  object in the account's "accountCapabilities" property.

I presume it's also an empty object in the server's "capabilities"
property as well (and we should probably say so).

Section 2

It's a little interesting to me that RFC 8261 did not define or mention
specific access to the User-Agent string but we need to have a specific
reportingUA here.  I do recognize that it's (an optional) part of the
RFC 8098 ABNF, and that RFC 8098 mentions the relevant security
considerations already.  Perhaps a subtle nudge in this section that the
"null" option may have better privacy properties would be appropriate.
(We may also revisit whether/what to include in the examples for
reportingUA.)

  o  finalRecipient: "String|null" Recipient for which the MDN is being
      issued.  if set, it overrides the value that would be calculated
      by the server from the Identity.

Could we get a couple more words to support the definite article?  (I am
not sure which Identity is "the" Identity just from this context; it is
only later on that we discover that there is an identityId in the
MDN/send arguments.)

  o  extensionFields: "String[String]|null" Object where keys are
      extension-field names and values are extension-field values.

I used process of elimination to conclude that these are RFC 8098
extension-field ABNF names/values; I don't know if there's a good way to
hint the reader of that fact.

  o  actionMode: "String" This MUST be one of the following strings:
      "manual-action" / "automatic-action"

  o  sendingMode: "String" This MUST be one of the following strings:
      "mdn-sent-manually" / "mdn-sent-automatically"

I recognize that this is entirely the responsibility of RFC 8098 and not
this document, but is it valid to combine "automatic-action" with
"mdn-sent-manually"?  I am not 100% I understand the semantics.

Section 2.1

                                The latter because of the implicit call
  to Email/set and the use of Identities, described below.  [...]

nit: does this sentence have a verb?

  The following already registered SetError would mean:

nit: these are the SetError types, right?

Section 3.x

It might be helpful to use a different creation ID for the different
classes of example (though not required by the protocol).

Section 3.1

            "extension": {
              "X-EXTENSION-EXAMPLE": "example.com"
            }

nit(?): somehow I thought X- extensions were generally thought to not be
needed/useful anymore.

Section 5

  In order to enforce trust regarding the relation between the user
  sending an email message and the identity of this user, the server
  SHOULD validate in conformance to the provided Identity that the user
  is permitted to use the finalRecipient value and return a
  forbiddenFrom error if not.

"enforce" and "SHOULD" are not words I usually see in combination.

[Ballot comment]
There are several places in the document where "header" should be changed to "header field".

In Section 2.1, I think this could be a bit clearer:

OLD:

The following already registered SetError would mean:

NEW:

In this context, the existing SetError values defined in [reference] are interpreted as follows:

In Sections 2.1 and 2.2:

This is totally a personal nit, and you're free to ignore me, but since I keep tripping on it I'll mention it: In various places, "id" is used as a word rather than an initialism, as in "The id of the account to use."  I keep reading this as the English term from psychoanalysis rather than a truncation of "identifier".  I'd probably be happier if the full word was used.  Also, in the first bullet of Section 2, it's capitalized as "Id"; we should probably be consistent.

In Section 3:

a) s/guaranty/guarantee/ (multiple instances)

b) There's an extension in Section 3.1 starting with "X-" that should probably be revisited given BCP 178.

[Ballot comment]
Thank you for the work put into this document. It is clear and easy to read.

Please find below a couple of non-blocking COMMENT points.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 2 --
While I can guess what is meant by "foreign (non-Internet) message", a more formal description would probably be welcome.

-- Section 2.1 --
Wondering whether the values in this section are case sensitive? Section 2 clearly specifies that the fields must be lowercase. Is it useful to specify whether case is important in this section?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-jmap-mdn-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the JMAP Capabilities registry on the JSON Meta Application Protocol (JMAP) registry page located at:

https://www.iana.org/assignments/jmap/

a new registration is to be made as follows:

Capability Name: urn:ietf:params:jmap:mdn
Intended Use: common
Change Controller: IETF
Security and Privacy Considerations: [ RFC-to-be; Section 5 ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the JMAP Error Codes registry also on the JSON Meta Application Protocol (JMAP) registry page located at:

https://www.iana.org/assignments/jmap/

a new registration is to be made as follows:

JMAP Error Code: mdnAlreadySent
Intended Use: common
Change Controller: IETF
Description: The message has the "$mdnsent" keyword already set. The client MUST NOT try again to send an MDN for this message.
Reference: [ RFC-to-be; Section 2.1 ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-09-18):

From: The IESG
To: IETF-Announce
CC: barryleiba@gmail.com, jmap@ietf.org, Bron Gondwana , brong@fastmailteam.com, draft-ietf-jmap-mdn@ietf.org, jmap-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Handling Message Disposition Notification with JMAP) to Proposed Standard


The IESG has received a request from the JSON Mail Access Protocol WG (jmap)
to consider the following document: - 'Handling Message Disposition
Notification with JMAP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a data model for handling Message Disposition
  Notifications (MDNs, RFC 8098) in the JSON Meta Application Protocol
  (JMAP, RFCs 8620 and 8621).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/



No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for draft-ietf-jmap-mdn

1. This document is being requested as an Proposed Standard because it
  extends an existing Proposed Standard (RFC8621).  The request type
  is indicated in the title page header as "Standards Track".

2.

Technical Summary

  This spec extends JMAP-mail with an object representation for message
  delivery notification messages and allows the server to create and
  parse those notifications on behalf of the client.

Working Group Summary

  This document underwent numerous revisions in the working group.  As
  the first extension to the JMAP spec written by somebody other than
  the original authors, it's going to set the example that future
  extensions work from, and the authors did an excellent job of
  collating feedback and making sure their spec was consistent with
  the "JMAP way".

Document Quality

  This spec is quite easy to implement - there is a mostly complete
  implementation in the Cyrus IMAP server already.

Personnel

  Document Shepherd - Bron Gondwana (JMAP co-chair)
  Responsible Area Director - Barry Leiba


3. The Document Shepherd has read the document through in detail
  over many revisions including writing detailed reviews.

4. There are no concerns about reviews, this document has been
  well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be
  aware of.

7. The author has been contacted and confirmed that they have
  no IPR disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The IDnits tool has no complaints.

12. This document doesn't define anything which needs formal
    review outside the working group.

13. All references have been identified as either normative or
    informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The IANA considerations asks for an entry in the JMAP
    capabilities registry and an entry in the JMAP error
    codes registry.

18. There are no new IANA registries.

19. The JSON fragments were tested for syntax with the `jq`
    tool, and one mistake was found which can be fixed in
    editing - the example in section 3.3 is missing a double
    quote at the end of the text blobIds in `"blobIds: `.

20. There are no YANG models in this document.

Document Shepherd Write-Up for draft-ietf-jmap-mdn

1. This document is being requested as an Proposed Standard because it
  extends an existing Proposed Standard (RFC8621).  The request type
  is indicated in the title page header as "Standards Track".

2.

Technical Summary

  This spec extends JMAP-mail with an object representation for message
  delivery notification messages and allows the server to create and
  parse those notifications on behalf of the client.

Working Group Summary

  This document underwent numerous revisions in the working group.  As
  the first extension to the JMAP spec written by somebody other than
  the original authors, it's going to set the example that future
  extensions work from, and the authors did an excellent job of
  collating feedback and making sure their spec was consistent with
  the "JMAP way".

Document Quality

  This spec is quite easy to implement - there is a mostly complete
  implementation in the Cyrus IMAP server already.

Personnel

  Document Shepherd - Bron Gondwana (JMAP co-chair)
  Responsible Area Director - Barry Leiba


3. The Document Shepherd has read the document through in detail
  over many revisions including writing detailed reviews.

4. There are no concerns about reviews, this document has been
  well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be
  aware of.

7. The author has been contacted and confirmed that they have
  no IPR disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The IDnits tool has no complaints.

12. This document doesn't define anything which needs formal
    review outside the working group.

13. All references have been identified as either normative or
    informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The IANA considerations asks for an entry in the JMAP
    capabilities registry and an entry in the JMAP error
    codes registry.

18. There are no new IANA registries.

19. The JSON fragments were tested for syntax with the `jq`
    tool, and one mistake was found which can be fixed in
    editing - the example in section 3.3 is missing a double
    quote at the end of the text blobIds in `"blobIds: `.

20. There are no YANG models in this document.