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

[Barry Leiba <[e-mail]>]

Raphaël, I've seen no response from you on this, and it's been around
six weeks.  Will you please address Ben's comments so we can move
ahead?

Thanks,
Barry

On Mon, Oct 5, 2020 at 5:04 PM Benjamin Kaduk via Datatracker
<[e-mail]> wrote:
>
> 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.
>
>
>