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

[Dave Crocker <[e-mail]>]

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.

If you are reading it differently, I don't understand how and why.

If you are reading it the same as I am, I don't understand what the 
confusion is.


>>>> 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.


>>>> 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.

I do not see that changes are needed in the the draft's Section 6.  If 
you feel otherwise, please suggest the changes.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net