Re: [Last-Call] Benjamin Kaduk's Discuss on draft-crocker-inreply-react-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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