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. > > > > 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? > > But seriously, if there IS an analysis I/we don't know of it. Absent > that, what else can we say? > > 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. > > > > 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> > > > 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." > > > > 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. > > d/ > > -- > Dave Crocker > dcrocker@xxxxxxxxx > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@xxxxxxxxxxxx > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
