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

Benjamin Kaduk <kaduk@mit.edu> Thu, 31 December 2020 18:17 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C983A0E1E; Thu, 31 Dec 2020 10:17:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDoGvh0YJJ-x; Thu, 31 Dec 2020 10:17:49 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446083A0E1D; Thu, 31 Dec 2020 10:17:48 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BVIHcre003862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Dec 2020 13:17:43 -0500
Date: Thu, 31 Dec 2020 10:17:38 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Raphaël Ouazana <rouazana@linagora.com>, Barry Leiba <barryleiba@computer.org>
Cc: The IESG <iesg@ietf.org>, IETF JMAP Mailing List <jmap@ietf.org>, draft-ietf-jmap-mdn@ietf.org, Bron Gondwana <brong@fastmailteam.com>
Message-ID: <20201231181738.GD93151@kduck.mit.edu>
References: <160193187289.4946.17482930539468511819@ietfa.amsl.com> <3490c237-bb9e-62df-9282-413ba44a1084@linagora.com> <CALaySJJ+MsbzDxC0VT0OHpVxosSTKQW7XjJBkQm9h2ayJvSpwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALaySJJ+MsbzDxC0VT0OHpVxosSTKQW7XjJBkQm9h2ayJvSpwQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/VEZtvvy6c27OISgc0KGa3j3PSpY>
Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and COMMENT)
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2020 18:17:51 -0000

Yes, it looks good, and I've updated my position in the datatracker.

Raphaël: thank you for the updates and your responses.

-Ben

On Wed, Dec 16, 2020 at 11:47:36AM -0500, Barry Leiba wrote:
> 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 <rouazana@linagora.com> 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.
> >