Subject: [Last-Call] Genart last call review of draft-crocker-inreply-react-07

From: Dale Worley via Datatracker <[email-masked]>
Date: Wed, 27 Jan 2021 18:32:43 -0800

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: [email-masked]
   From: [email-masked]
   Date: Today, 29 February 2021 00:00:10 -800
   Message-id: [email-masked]
   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]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Jan 2021 19:35:52 -0800

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

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

> display them normally (rather than as an unallocated or undisplayable

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.

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

> 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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 27 Jan 2021 22:45:16 -0500

> be read as meaning multiple.

I’m guessing that Dale is thinking that this is like composed characters,
such as creating “á” from “a” plus combining acute accent.  The thing is,
though, it’s not that.  What Dave is describing (perhaps an example in the
text would help explain) is the sort of thing that’s unique to emoji,
wherein the emojis for man followed by woman followed by boy, each of which
is a separate emoji character that would be displayed as it seems, will
often be rendered as a single image of a family, just because they’re coded
together.

I thunk the text that Dave has is correct — certainly more correct than the
suggestion, which would imply character composition rather than the image
composition that’s being discussed here.

I don’t think a change to the text will really help, but a “(for example,
...)” might.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Jan 2021 19:49:42 -0800

On 1/27/2021 7:45 PM, Barry Leiba wrote:
> 
> I thunk the text that Dave has is correct — certainly more correct than 
> the suggestion, which would imply character composition rather than the 
> image composition that’s being discussed here.
> 
> I don’t think a change to the text will really help, but a “(for 
> example, ...)” might.

Barry, thanks.

However to the extent that there's any misunderstanding of the text by 
one thoughtful, experienced reader, there's likely to be more.  I've no 
idea how to make it clearer or more robust, though.

d/

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 28 Jan 2021 09:21:23 +0100

> be read as meaning multiple.

One small change here which will reduce the amount of confusion is to
avoid the word "byte".  Indeed, it is *not* possible for the sequence
to be only one byte, since there are no Unicode code points in the
range U+0000 U+007F with the Emoji property set.

So, use "emoji characters" or "code points" instead?

(I tend to avoid the use of "byte" in favour of "octet" to forestall
complaints from the old DEC-10, DEC-20 and Cray users anyway ☺)

> meant for, but I also might be misunderstanding.

Probably, but I think it bears saying something about how to handle
code points without the Emoji property set.  IMHO they should be
handled as undisplayable.

> process bytes that are illegal here.

The above suggestion would still allow the implementer sufficient lee-
way.

-- 
venleg helsing,
Kjetil T.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Jan 2021 08:31:34 -0800

> complaints from the old DEC-10, DEC-20 and Cray users anyway ☺)

Well, indeed, my entrenched use of byte probably gets in the way, here...

I want the term to be more low-level and physical, than abstract or 
conceptual.  That is, I'd like the term to be outside of the Unicode 
specialized terminology.  To that end, I think octet works well.

> handled as undisplayable.

This steps into user interface design, more than interoperable emoji 
labeling and transport.

As such, it's outside of this specification and outside of the IETF's 
expertise.

d/

---

From: "John Levine" <[email-masked]>
Date: 29 Jan 2021 15:53:30 -0500

>As such, it's outside of this specification and outside of the IETF's 

The Unicode consortium adds new emoji and combinations several times a
year, so depending on how often people update their software it is
common for a sender's and a recipient's systems to disagree about what
are valid emoji. This is not a tarpit we need to step in.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Jan 2021 13:00:37 -0800

> are valid emoji. This is not a tarpit we need to step in.

The language is intended to cover this sort of version mismatch, without 
saying anything about the UI aspects of how it's dealt with, beyond 
recommending that the site do whatever it normally does with Unicode it 
does not current understand.

d/

---

From: Ned Freed <[email-masked]>
Date: Sat, 30 Jan 2021 15:13:25 -0800 (PST)

I'm having a little difficulty following the discussion of the text, so I 
took a look at the text itself. It currently (-07) says:

   The rule base-emojis MAY be used as a simple, common list, or
   'vocabulary' of emojis.  It was developed from some existing
   practice, in social networking, and is therefore intended for use.
   However support for it is not required.  Having providers and
   consumers employ a common set will facilitate user interoperability,
   but different sets of users might want to have different, common
   (shared) sets.

There are a few problems here. First, TR#51 actually uses the term "image" in
an incompatible way - specifically, it's used to refer to emojis directly
represented by actual images, not ones experssed in Unicode itself. I think the
correct term to use here is "pictograph".

Second, since I'm one of those "old DEC-10 people" and know what ILDB and IDPB
mean, I think "octet" is a better term than "byte". But I can live with "byte"
if that's the consensus.

Third, as previously noted, you always need more than one octet to encode
an emoji, and the text should reflect that.

Fourth, there's a bit of awkwardness to the second paragraph. "intended for
use" where? What does support mean? 

Finally, I think a couple of word choices could be better. So how about:

   The rule emoji_sequence is inherited from [Emoji-Seq].  It
   defines a set of octet sequences, each of which forms a single pictograph.

   The rule base-emojis MAY be used as a simple, common list, or
   'vocabulary' of emojis.  It was developed from some existing
   practice, in social networking, and is therefore intended for
   such use. However support for it as a base vocabulary is not required.
   Having providers and consumers employ a common set will facilitate
   user interoperability, but different sets of users might want to have
   different, common (shared) sets.

   Reference to unallocated code points SHOULD NOT be treated as an
   error; the corresponding octets SHOULD be processed using the system
   default method for denoting an unallocated or undisplayable code point.

				Ned

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 31 Jan 2021 17:16:48 -0500

> the message header.  That is, it will be in the header of the response 

Given that we're deailing with multipart messages, an In-Reply-To header
could be stuck in the message header but it could also be stuck in the
headers of any part.  I don't know if it's ever done, but certainly,
it's plausible that if I include a reply which I had received as an
attachment to another email I send, the In-Reply-To header in the
received e-mail would show up as a header to the attachment part, not
my message as a whole.

In general, the situation is one of unlimited complexity.

I'm not particular what rules you want to specify, just that when I'm
looking at a part with this Content-Disposition that is somewhere in a
multipart structure (possibly without parts), that it's clear which sets
of headers I need to examine to find the In-Reply-Header.

Now I think in reality, it either has to be in the headers of the part
with disposition "reaction", or in the multipart containing that part.
But whatever the rule is, it should be stated.

> encountering such a code point.  The text here is merely trying to say 

The text is a constraint, though.  It *requires* (sort of) that if the
bytes in the part form a character which the receiver considers
unallocated, it *should not* reject the whole message as being
ill-formed.  The implementation has great freedom in how to display the
caracter, but the message as a whole "SHOULD NOT be treated as an
error".

> process bytes that are illegal here.

Perhaps that is what you intend, and if so, the text is correct.  But it
seems to me that if the bytes form a code point that the receiver
considers to be allocated but not an emoji, it should be under the same
constraint that it should not reject the message as a whole as erroneous.

>     one or more bytes to form a single presentation image.

First, let me say I keep a rigid category distinction between
bytes/octets and characters.  And in this situation, it seems like there
are *three* layers of composition between bytes and displayed items:

- The UTF-8 encoding groups bytes into code points, which are generally
  Unicode "characters".

- The code points can be composed (by Unicode rules) into characters.
  As Barry explains, "as creating “á” from “a” plus combining acute
  accent".  But I'm not so familiar with how that is done and how that
  affects exactly what the word "character" means.  (I also do not know
  whether any emoji code point participates in Unicode composition, but
  a sender can certainly compose reactions containing code points that
  participate in composition, and there probably is no guarantee that
  Unicode will never do such a thing with emoji.)

- Groups of characters may be displayed as single images.  As Barry
  explains, "the sort of thing that’s unique to emoji, wherein the
  emojis for man followed by woman followed by boy, each of which is a
  separate emoji character that would be displayed as it seems, will
  often be rendered as a single image of a family".

Composing these processes, it takes bytes/octets (the encoded form of
the "reaction" part) into a sequence of displayed images.

When I wrote my review, I was aware only of the first composition layer.
But now, it's not clear to me what the sentence "It permits one or more
bytes to form a single presentation image." is intended to say.  The
combining of bytes to form an image may happen at any of the three
layers, and it seems to me that the entire process would be better
described as "It permits one or more bytes to form one or more
presentation images."  But maybe you're trying to say something more
specific.

Dale

---

From: Dave Crocker <[email-masked]>
Date: Sun, 31 Jan 2021 15:16:19 -0800

> In general, the situation is one of unlimited complexity.

RFC 5322's definition of the In-Reply-To field has it being optionally 
present in the message header:

       message     =  fields *( CRLF *text )       ; Everything after
                                                  ;  first null line
                                                  ;  is message body

      fields      =    dates                      ; Creation time,
                       source                     ;  author id & one
                     1*destination                ;  address required
                      *optional-field             ;  others optional

      optional-field =
                  /  "In-Reply-To"       ":"  *(phrase / msg-id)

As such, it's location is not as random or varied as you seem to think. 
  Also note that the In-Reply-To field has long history and is already 
well-integrated into MUAs.

So, the complexity is quite limited.

My guess is that you are confusing the variable venues possible for the 
emoji-sequence with the far less variable venue of In-Reply-To.

I suppose a clarification could be added along the lines of:

OLD:

NEW:
    The emoji(s) express a recipient's summary reaction to the specific
    message referenced by the accompanying In-Reply-To header field, for
    the message in which they both are present. [Mail-Fmt].

If a message is nested within a message, that defines a hard reference 
boundary.  Something inside the nested message does not refer to the 
containing message, for example.

> of headers I need to examine to find the In-Reply-Header.

Perhaps you could offer an example or two of messages that you see as 
creating ambiguity or other confusion?

> But whatever the rule is, it should be stated.

see above?

> caracter, but the message as a whole "SHOULD NOT be treated as an

Since this specification pertains to processing of some octets, rather 
than having anything to do with overall processing of the message, I am 
not understanding your concern.

A system that might reject an entire message because the system is 
unhappy with one or another of the octets in the message is playing its 
own game, which has little or nothing to do with Internet standards, I 
believe.

> constraint that it should not reject the message as a whole as erroneous.

I think you are describing a system that is not implementing the 
specification carefully.  Or, perhaps, is going beyond the scope of the 
specification.

> Now for the messy part:
...
> presentation images."  But maybe you're trying to say something more

(Note that we've settled on 'octet' rather than 'byte' or 'character'.)

The text using that word is correct, because it is referring to -- for 
this context -- the lowest-level of data object.

Some things that get displayed do in fact take a single octet. Others 
take more.

That there might be an interesting internal sub-structure to the 
interpretation of a string of octets is highly relevant to the display 
or semantic processing of that string, but I believe it's not relevant 
to the point covered by the text in question.

d/