Last Call Review of draft-crocker-inreply-react-07

Request Review of draft-crocker-inreply-react
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2021-02-12
Requested 2021-01-15
Authors Dave Crocker, R. Signes, Ned Freed
Draft last updated 2021-01-27
Completed reviews Genart Last Call review of -07 by Dale Worley (diff)
Secdir Last Call review of -07 by Adam Montville (diff)
Assignment Reviewer Dale Worley 
State Completed
Review review-crocker-inreply-react-07-genart-lc-worley-2021-01-27
Posted at
Reviewed rev. 07 (document currently at 09)
Review result Ready with Nits
Review completed: 2021-01-27


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


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]

    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.

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:

   Date: Today, 29 February 2021 00:00:10 -800
   Subject: Meeting
   Mime-Version: 1.0 (1.0)
   Content-Type: text/plain; charset=utf-8
   Content-Disposition: Reaction


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

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

Perhaps s/label/Content-Disposition/.

6.  IANA Considerations

   The React MIME Content-Disposition parameter is registered, per

I think s/React/Reaction/ is intended.

Comparing with, it would

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