Hi Barry, I checked the -09 and it covers the discuss bits just fine. I wasn't in a hurry to clear my discuss, though, since the nature of the ongoing discussions last week would arguably make for a discuss in its own right. However, that does not excuse me for failing to respond to Dave's responses to my comments; see inline for those. On Wed, Mar 03, 2021 at 01:15:44PM -0500, Barry Leiba wrote: > Ben, Dave will be making another update to the draft to address your > COMMENT stuff. Will you please check your DISCUSS and update > accordingly (version -09 should be consistently using "REACTION" (not > "REACT") for the content-disposition. > > Thanks, > Barry > > On Thu, Feb 25, 2021 at 3:29 PM Dave Crocker <dcrocker@xxxxxxxxx> wrote: > > > > On 2/25/2021 11:11 AM, Benjamin Kaduk wrote: > > > Could you please confirm whether the lack of response to the COMMENT > > > section was intentional and no further comments are forthcoming? > > > > The drats just keep on coming. Sorry. It was completely NOT > > intentional. I stopped at the Discuss and forgot that there might be > > Comments. > > > > So... > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > The emoji(s) express a recipient's summary reaction to the specific > > > message referenced by the accompanying In-Reply-To header field, for > > > the message in which they both are present. [Mail-Fmt]. For > > > processing details, see Section 3. > > > > > > I don't think I understand what "for the message in which they both are > > > present" is intended to mean (specifically "for the message"). My best guess > > > is that "when both 'Content-Disposition: Reaction' and 'In-Reply-To:' are > > > present in a message, these are the semantics; if 'Content-Disposition: > > > Reaction' is present without 'In-Reply-To:', the semantics are undefined". > > > > Given that MIME can have a hierarchy that includes messages within > > messages within the body, there is bit of a challenge in how to get the > > references precise and accurate here. This language has been reworked a > > couple of times, but better wording would be... better. Offerings will > > be eagerly considered. > > > > In hierarchy terms, the Reaction information needs to be at the same > > message 'level' as the In-reply-to: that it's associated with. I expect that I (both when I wrote that and now) am failing to truly appreciate the subtleties involved in the MIME hierarchy. My comment was intended to be more of an editorial one, though -- I was failing to come up with a clear binding as to which specific "message" was being indicated and how the other parts relate to it. Your clarification about being at the same level helps, so let me take a stab at naming things and writing down relationships, with the goal of eventually being able to craft some text that reflects that. There's some message A that came into being somehow; we don't care about that. Some entity X decides to react to A, and creates a new message B. Message B contains a "Content-Disposition: Reaction" header field and "In-Reply-To: A" header field, in order to be the reaction message. In order for a reaction to be conveyed, the existing text says "both are present". Having just written the above, I now am thinking maybe the "both" that are present are the two header fields Content-Disposition and In-Reply-To? Or maybe it is the emojis in the content of this part and the In-Reply-To header field? Or does the "both" refer to the messages A and B? I'm not actually sure that my confusion trying to interpret this text has much to do with complicated MIME hierarchies, having written the above... > > > > > Section 5 > > > > > > Given the difficulty of conclusively proving a negative, the value of > > > stating "there is no analysis demonstrating it does" seems minimal. > > > > Matching the minimal threat? The presumed minimal threat, yes. > > But seriously, if there IS an analysis I/we don't know of it. Absent > > that, what else can we say? We could say nothing? Or "it is currently believed that the specific structure of this content does not introduce any additional threat surface" > > Remembering that this is targeting Experimental, I'll suggest that the > > real purpose of that minimal comment is to highlight the issue and, even > > more indirectly, to solicit analyses. If we want to solicit analysis, then I'd suggest "a detailed analysis of this question has not yet been performed" or similar. > > > > > This specification defines a distinct Content-Disposition value, for > > > specialized message content. Processing that handles the content > > > differently from other content in the message body might introduce > > > vulnerabilities. > > > > > > The potential for new implementation vulnerabilities when new code is > > > added for the specialized processing seems clear; it seems there may > > > also be human-factor vulnerabilities depending on how the information is > > > displayed, which may be less obvious to some readers and thus worth a > > > dedicated mention. > > > > Ack. Here's what I've added: > > > > <t>This specification defines a distinct > > Content-Disposition value, for specialized message > > content. Processing that handles the content > > differently from other content in the message > > body might introduce vulnerabilities. Since this > > capability is likely to produce new user > > interaction features, that might also produce new > > social engineering vulnerabilities?</t> Okay, thanks. > > > Section 6 > > > > > > The IANA is request to register the React MIME Content-Disposition > > > parameter, per [RFC2183] > > > > > > Content-Disposition parameter name: React > > > > > > Allowable values for this parameter: (none) > > > > > > At https://www.iana.org/assignments/cont-disp/cont-disp.xhtml I see > > > distinct registries for "Content Disposition Values" and "Content > > > Disposition Parameters". > > > It notably does not have any columns relating what parameters are > > > allowed for use with a given value. > > > > I hadn't re-read the spec in detail, for this effort, but now that I > > have, yeah, I suspect a number of things could have been done better in > > the specification and the administration of it. I suspect this falls > > under the cover of "actual practice takes care of such niceties even > > when the formalities didn't." There is a step for the authors/ADs/IANA to figure out what needs to happen and check that it happened correctly, yes. Writing it up clearly in the RFC helps everyone else that didn't get to be a part of that exchange, though. > > > > > My undersatnding is that "React" is intended to be a "content > > > disposition value" and that no changes to the "content disposition > > > parameters" registry is to be made (and thus that the last quoted line > > > serves no purpose for IANA). Some prose discussion, separate from the > > > registration, that no parameters are used with the content-disposition > > > value, would of course be welcome. > > > > > > I also note that all of the existing entries in the "content disposition > > > values" registry are written in all lowercase form, but "React" contains > > > the majuscule 'R'. > > > > Oh my. That level of attention to detail might be offensive, if it were > > not so useful. > > > > As in: good catch. Fixed. > > > > > > Again, I apologize for having missed the Comments initially. And thanks > > for making them. I'm happy they were useful. Sorry to have taken a week to get back to you about them. -Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
