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

[Raphaël Ouazana <[e-mail]>]

Le 05/10/2020 à 23:04, Benjamin Kaduk via Datatracker a écrit :
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This should be quite easy to resolve; I'm just not sure yet which
> direction the resolution will be.
>
Discussed on the list, this should has been fixed in the last draft.
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> 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.
Replaced by "come across". Not being native English speaker, the 
distinction is subtle for me, I hope it's better.
>
>     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...)
Fixed
>
>     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?)
The "mdnBlobIds" member is enough explicit for me to not have to write it.
> 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).
Fixed.
> 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.)
Added.
>     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.)
Added.
>
>     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.
I tried to add a hint.
>
>     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.

Yes it is explained in RFC 8098 :

"manual-action [...] (This might include the case when the user has 
manually configured her MUA to automatically respond to valid MDN 
requests.)"

> 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?
Fixed.
>
>     The following already registered SetError would mean:
>
> nit: these are the SetError types, right?
Fixed.
> 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).
Fixed.
> Section 3.1
>
>               "extension": {
>                 "X-EXTENSION-EXAMPLE": "example.com"
>               }
>
> nit(?): somehow I thought X- extensions were generally thought to not be
> needed/useful anymore.
Fixed.
> 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.
Fixed, I meant reinforce.