Re: [Gen-art] Genart last call review of draft-crocker-inreply-react-07

[Dave Crocker <[e-mail]>]

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