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

Dale Worley via Datatracker <noreply@ietf.org> Thu, 28 January 2021 02:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D482A3A0839; Wed, 27 Jan 2021 18:32:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dale Worley via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: draft-crocker-inreply-react.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161180116375.12497.14607504902519078003@ietfa.amsl.com>
Reply-To: Dale Worley <worley@ariadne.com>
Date: Wed, 27 Jan 2021 18:32:43 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/y-h4T3nF-d5wz9ZrMXiiGR3AT70>
Subject: [Gen-art] Genart last call review of draft-crocker-inreply-react-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2021 02:32:44 -0000

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.

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]