Skip to main content

Last Call Review of draft-crocker-inreply-react-07
review-crocker-inreply-react-07-genart-lc-worley-2021-01-27-00

Request Review of draft-crocker-inreply-react
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2021-02-12
Requested 2021-01-15
Authors Dave Crocker , Ricardo Signes , Ned Freed
I-D last updated 2021-01-27
Completed reviews Genart Last Call review of -07 by Dale R. Worley (diff)
Secdir Last Call review of -07 by Adam W. Montville (diff)
Assignment Reviewer Dale R. Worley
State Completed
Request Last Call review on draft-crocker-inreply-react by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/y-h4T3nF-d5wz9ZrMXiiGR3AT70
Reviewed revision 07 (document currently at 14)
Result Ready w/nits
Completed 2021-01-27
review-crocker-inreply-react-07-genart-lc-worley-2021-01-27-00
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.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document:  draft-crocker-inreply-react-07
Reviewer:  Dale R. Worley
Review Date:  2021-01-27
IETF LC End Date:  2021-02-12
IESG Telechat date:  [unknown]

Summary:
    This draft is basically ready for publication, but has nits that
    should be fixed before publication.

Nits/editorial comments:

1.  Introduction

   by marking basic emoji graphics

Probably intended to be "by marking with basic emoji graphics".

   Normative language, per [RFC8174]:

In most drafts, this material is placed in a separate section from the
Introduction.  Also, this draft contains a much longer version of this
boilerplate than is common.

2.  Reaction Content-Disposition

   If such a field is specified the content-type of the part MUST be:

Probably should be capitalized as "Content-Type".

   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.

   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.

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

4.1.  Example Message

   with a thumbs-up, affirmative response of:

   To: author@example.com
   From: recipient@example.com
   Date: Today, 29 February 2021 00:00:10 -800
   Message-id: 12345@example.com
   Subject: Meeting
   Mime-Version: 1.0 (1.0)
   Content-Type: text/plain; charset=utf-8
   Content-Disposition: Reaction

   {U+1F44E}

This example does contain an In-Reply-To header, contrary to the
specification.

4.2.  Example Display

   Message:    A complete message is often displayed with a tailored
      section for header-fields, enhancing the format and showing only
      selected header fields.  It might include one for reactions, again
      showing the symbol and a count.

I think it would be more accurate to expand "It might include one for
reactions ..." to "It might include a quasi-header summarizing the
reactions that have been received ...".  Then again, perhaps "one"
meant "a tailored section", which would be clarified differently.

5.  Security Considerations

   This specification defines a distinct label for specialized message
   content.

Perhaps s/label/Content-Disposition/.

6.  IANA Considerations

   The React MIME Content-Disposition parameter is registered, per
   [RFC2183]

I think s/React/Reaction/ is intended.

Comparing with
https://www.iana.org/assignments/cont-disp/cont-disp.xhtml, it would
be

   The Reaction MIME Content-Disposition value is registered, per [RFC2183]

    Content Disposition value:              Reaction
    Allowable parameters for this value:    (none)

7.  Experimental Goals

   o  Does the presence of the Reaction capability demonstrate
      additional security issues?

Perhaps s/demonstrate/create/.

[END]