On 1/27/2021 6:32 PM, Dale Worley via Datatracker wrote:
Reviewer: Dale Worley
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
Dale,
Thanks for the detailed comments.
Below are responses to the substantive notes. (I'm integrating the
editorial ones, of course; thanks for those.)
2. Reaction Content-Disposition
The rule emoji_sequence is inherited from [Emoji-Seq]. It permits
one or more bytes to form a single presentation image.
I haven't traced the definition of emoji_sequence, but it seems to be
essentially a set of Unicode characters that have one or another of
certain attributes. That is perfectly sensible. But if I understand
correctly, "emoji_sequence" is a sequence of characters, and you want
to say "In the UTF-8 encoding, some of these characters may be encoded
as multiple bytes." or something like that.
Sorry but I'm not understanding what clarity this provides, over the
existing text.
To the extent that your intent is to say that a) this is a subset of
UTF-8, and b) multiple bytes can be used, I think that's built into the
definition of emoji-sequence.
In fact, I had added the one or more text mostly to highlight the the
'sequence' can be only one byte, since 'sequence' would be expected to
be read as meaning multiple.
The emoji(s) express a recipient's summary reaction to the specific
message referenced by the accompanying In-Reply-To header field.
[Mail-Fmt].
This is not specific as to where the In-Reply-To header is. I assume
you want to say that it is a header of the parent multipart component
of "Reaction" part. Or perhaps this should be forward-referenced to
the discussion in section 3.
I don't understand the concern. An In-Reply-To header field is part of
the message header. That is, it will be in the header of the response
message.
(I did add the field to the example. Today's my day for getting lessons
on the importance of making examples more thoughtful and detailed. This
was the second...)
Reference to unallocated code points SHOULD NOT be treated as an
error; associated bytes SHOULD be processed using the system default
method for denoting an unallocated or undisplayable code point.
Code points that do not have the requisite attributes to qualify as
part of an emoji_sequence should also not be treated as an error,
although you probably want to allow the system to alternatively
display them normally (rather than as an unallocated or undisplayable
code point).
I think your comment addresses a different issue than the cited text is
meant for, but I also might be misunderstanding.
For whatever reasons, including not having been allocated by the Unicode
folks, or possibly by running an older system that thinks a code point
is not allocated, there is an issue of how the system should deal with
encountering such a code point. The text here is merely trying to say
"do whatever you do".
A different issue is encountering a code-point, here, that is outside of
the emoji-sequence set. The text doesn't try to tell the receiver how to
process bytes that are illegal here.
6. IANA Considerations
The React MIME Content-Disposition parameter is registered, per
[RFC2183]
I think s/React/Reaction/ is intended.
Turns out I meant 'react' as the label, so the anomaly was actually in
the later IANA section...
7. Experimental Goals
o Does the presence of the Reaction capability demonstrate
additional security issues?
Perhaps s/demonstrate/create/.
Well, ummm, it probably depends on whether the focus is theory or
practice. Either could make sense, but I'd intended to focus on seeing
whether actual experience is of a problem. Hence 'demonstrate'.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
