[Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-jmap-mdn-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/



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


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