Hi Dave, On Thu, Mar 04, 2021 at 06:42:58AM -0800, Dave Crocker wrote: > On 3/3/2021 11:11 AM, Benjamin Kaduk wrote: > > 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... > > The current text in the draft is: > > > 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. > > I read 'both' as referring to "the emoji(s)" and "the accompanying > In-Reply-To header field". And that's what is intended. Thank you for answering my question about what the "both" is intended to refer to. It's a shame that it took four round trips to get around to that. > If you are reading it differently, I don't understand how and why. Well, my whole point at the start is that I don't know how to properly read it. My ballot position included "my best guess" as to what was intended (which, to be fair, does not have to always bear much resemblance to what the words on the page actually say). So ... I don't understand why you're writing comments that come across as saying that the text is perfect as-is and I was wrong to have even asked a question about it. As an aside, this does not seem like the first time that I have tried to comment on how "the words on the page" may not quite map up to what you intended to convey, and it is not the first time that we've taken several round trips to clarify that that is the main focus of my comment. Is there something that one or both of us could change in order to make such communication more efficient? > If you are reading it the same as I am, I don't understand what the > confusion is. The sentence starts out by talking about a "summary reaction" to a "specific message" and the "accompanying In-Reply-To header field". There are three things listed, and I have to pick two in order for "both" to apply. (On the face of it, of course, requiring both the message that is being responded to and the In-Reply-To header field to be present before doing anything would make the mechanism pretty weird, but that requires knowledge of the protocol and not just parsing the sentence.) Furthermore, this sentence uses "the message" twice (once as "the specific message"), to refer to two different messages. This further complicates the job of the reader in parsing the sentence, and the writer can help by providing clear descriptors to justify the respective uses of the definite article. And finally, we have the "recipient" being an entity who is *generating* a (reaction) message, which is a mismatch for the normal meanings of those terms. So, my suggestion would be to take OLD: 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. NEW: The emoji(s) express a recipient's summary reaction to a specific message. The message being reacted to is referenced by the accompanying In-Reply-To header field; both the emoji(s) and the header field must be present in order to indicate a reaction. [Mail-Fmt]. For processing details, see Section 3. (I'm also a bit confused that we are specifically mentioning that the header and content have to be present, but not mentioning the content-disposition as a mandatory element. Yes, this spec is only about the content-disposition and we wouldn't be randomly talking about other things, but if we want a nice tidy list of what's required, making it comprehensive would not be so hard.) > >>>> 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. > > I said indirectly. > > Unfortunately, I am not understanding what it is about the current > wording that is sufficiently deficient and important to warrant this > extent of discussion. It's redundant. If there was analysis demonstrating there is new attack surface, we would reference it. Since you are so fond of asking for specific proposed text, I will be so bold as to suggest something here without being specifically asked: OLD: The fact that this content is structured might seem to make it a new threat surface, but there is no analysis demonstrating that it does. OLD: This new content has a specific structure, but this structure is not believed to present a new threat surface. As another aside, I'm also a bit surprised to see your note about "this extent of discussion". I think that two round-trips is acceptable for basically any comment, and we're not writing long essays about this point. About other points, sure, but not this one. After all, once the RFC is published it is immutable, so this is our only chance to spend effort on the topic. > > >>>> 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. > > On the offchance my response wasn't clear, I was referring to the cited > details for those registries, not the text in this draft specification. > I read your comment as observing some issues with the way the registries > were organized and I was agreeing with you. But, of course, that's > outside the scope of this draft. Well, I was actually trying to refer to the text in this draft specification. Specifically, the part where it is telling IANA to do things that IANA can't actually do given the current state of the registry. Assuming that we want the final RFC to reflect what IANA actually did, this text will need to change at some point. In general, if I am making a comment about something other than the draft being evaluated, I will preface it explicitly as a "side note", "tangent", or similar. But perhaps this gets back into the recurring issue that I mentioned above of it taking multiple round-trips for the two of us to actually agree on what is being commented on, and the same question about how to make communication more efficient applies. > I do not see that changes are needed in the the draft's Section 6. If > you feel otherwise, please suggest the changes. How about OLD: Content-Disposition parameter name: Reaction Allowable values for this parameter: (none) Description: Permit a recipient to respond by signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic NEW: Content-Disposition value name: Reaction Description: Permit a recipient to respond by signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic Reference: [this document] Thanks, Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call