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

[Barry Leiba <[e-mail]>]

Ben, I think the change made in -16 to the penultimate paragraph of
Section 2.1 should resolve your DISCUSS.  Can you check?  Thanks.

Barry

On Thu, Dec 10, 2020 at 1:24 PM Raphaël Ouazana <[e-mail]> wrote:
>
>
> 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.
>