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

[Alissa Cooper]

Dale, thanks for your review. Dave, all, thanks for your responses. It looks 
like the issues are close to cleared up. I entered a No Objection ballot.

Alissa


> On Feb 10, 2021, at 8:30 AM, Dave Crocker  wrote:
> 
> On 2/8/2021 7:42 PM, Dale R. Worley wrote:
>> After sending my previous message, I realized that I had gone to length
>> explaining why I considered the term "accompanying" to be ill-defined,
>> but I had forgotten to mention that in my review, I'd added "Or perhaps
>> this should be forward-referenced to the discussion in section 3."  Just
>> adding a reference to section 3 would clarify it, because section 3
>> covers the matter well.
>> Another version that would be good is "The emoji(s) express a
>> recipient's summary reaction to the specific message referenced by the
>> In-Reply-To header field of the message in which it is present."
> 
> 
> Here's the latest version:
> 
> 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]. For processing details, see Section 
> 3.
> 
> 
> 
> d/
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dave Crocker]

On 2/8/2021 7:42 PM, Dale R. Worley wrote:

After sending my previous message, I realized that I had gone to length
explaining why I considered the term "accompanying" to be ill-defined,
but I had forgotten to mention that in my review, I'd added "Or perhaps
this should be forward-referenced to the discussion in section 3."  Just
adding a reference to section 3 would clarify it, because section 3
covers the matter well.

Another version that would be good is "The emoji(s) express a
recipient's summary reaction to the specific message referenced by the
In-Reply-To header field of the message in which it is present."



Here's the latest version:

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]. For processing 
details, see Section 3.




d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dale R. Worley]

Dave Crocker  writes:
> I suppose a clarification could be added along the lines of:
>
> OLD:
> The emoji(s) express a recipient's summary reaction to the specific
> message referenced by the accompanying In-Reply-To header field.
> [Mail-Fmt].
>
> 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.

After sending my previous message, I realized that I had gone to length
explaining why I considered the term "accompanying" to be ill-defined,
but I had forgotten to mention that in my review, I'd added "Or perhaps
this should be forward-referenced to the discussion in section 3."  Just
adding a reference to section 3 would clarify it, because section 3
covers the matter well.

Another version that would be good is "The emoji(s) express a
recipient's summary reaction to the specific message referenced by the
In-Reply-To header field of the message in which it is present."

Dale

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dave Crocker]

On 1/30/2021 3:13 PM, Ned Freed wrote:

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


Having seen no objections, I've replaced the draft's existing text with 
Ned's proposed alternative.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dave Crocker]

On 1/31/2021 2:16 PM, Dale R. Worley wrote:

Dave Crocker  writes:

On 1/27/2021 6:32 PM, Dale Worley via Datatracker wrote:

 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.


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.


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:
   The emoji(s) express a recipient's summary reaction to the specific
   message referenced by the accompanying In-Reply-To header field.
   [Mail-Fmt].

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.




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.


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




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.


see above?



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


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


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 

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

[Dale R. Worley]

Dave Crocker  writes:
> On 1/27/2021 6:32 PM, Dale Worley via Datatracker wrote:
>> Reviewer: Dale Worley
>> Review result: Ready with Nits

First to deal with the straightfoward points:

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

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.

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

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

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

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.

Now for the messy part:

> The rule emoji_sequence is inherited from [Emoji-Seq].  It permits
> 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 

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

[Ned Freed]

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 emoji_sequence is inherited from [Emoji-Seq].  It permits
  one or more bytes to form a single presentation image.

  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.

  The emoji(s) express a recipient's summary reaction to the specific
  message referenced by the accompanying In-Reply-To header field.
  [Mail-Fmt].

  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.

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.

  The emoji(s) express a recipient's summary reaction to the specific
  message referenced by the accompanying In-Reply-To header field.
  [Mail-Fmt].

  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



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/



--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Barry Leiba]

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


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




>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dale Worley via Datatracker]

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

.

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: aut...@example.com
   From: recipi...@example.com
   Date: Today, 29 February 2021 00:00:10 -800
   Message-id: 12...@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]



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art