Benjamin Kaduk has entered the following ballot position for draft-crocker-inreply-react-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-crocker-inreply-react/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I thought you were going to clean up whether the Content-Disposition was "React" or "Reaction" based on the gen-art review, but the document still seems internally inconsistent about it. https://mailarchive.ietf.org/arch/msg/gen-art/zun860KMrKdwqyKSWbrvWSPMuYM/ indicates that "React" was the intent, but Sections 2 and 4.1 still use "Reaction", while the IANA Considerations register "React". Section 3 uses lowercase "reaction" in the context of a "Content-Disposition" header field as well. Section 7 mentions a "Reaction capability". ---------------------------------------------------------------------- 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". Section 5 Given the difficulty of conclusively proving a negative, the value of stating "there is no analysis demonstrating it does" seems minimal. 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. 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. 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'. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
