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. > >
- [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jma… Benjamin Kaduk via Datatracker
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Bron Gondwana
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Barry Leiba
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Raphaël Ouazana
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Raphaël Ouazana
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Barry Leiba
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk