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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
