Subject: Re: [Last-Call] New Version Notification for draft-crocker-inreply-react-07.txt

From: John C Klensin <[email-masked]>
Date: Mon, 01 Mar 2021 03:03:16 -0500

--On Monday, 01 March, 2021 15:58 +1100 Bron Gondwana
<[email-masked]> wrote:

> On Sat, Feb 27, 2021, at 09:54, John Levine wrote:
>> At this point I don't see any compelling reason to limit the
>> reactions to Unicode emoji and exclude text reactions like :-(
> 
> I can see the compelling reason, and it's because Dave is
> trying to define a vespa here, not a monster truck.

> Every attempt to bolt on more wheels, spoilers and giant
> chrome bumpers just because somebody might need them takes
> what was a very simple experiment and turns it back into the
> everything spec.

Bron, I agree with the principle and share your belief that what
was intended was an extremely modest and focused extension.
Certainly that is what the discussion that I think started in
September was about and I don't recall any discussion that would
have led to even a medium-sized limousine.

However, the specification as now written incorporates all or
UTS#51, a long (very long if the required supporting tables are
considered( specification of what several people outside the
IETF have described as a Unicode-based picture language of very
high complexity that is necessary to understand.  It defines
emoji combining and qualifying characters and has specific rules
about whether consecutive emoji code point combine into a single
graphic image or remain separate and whether, and how, that is
separated by ZWJ, and so on, including multiple types of
combining sequences each with its own rules.   

Incorporating UTS#51 that way probably should require text
about, for example, whether validation is required,  Being to
use what is permitted requires very different models of the Ux
than what I think most of us were anticipating and what is
justified by the type of current practice that has been pointed
to to justify this experiment.

That situation exists with  draft-crocker-inreply-react-09, with
no specification, a definition that essentially amounts to
"anything that UTS#51 allows is permitted and anything it does
not is prohibited".   Continuing with your metaphor, I don't see
a monster truck.  I see either that Vespa on which someone has
removed the rear wheel and tyre and replaced them with someone
over a meter in diameter without otherwise changing the vehicle
or someone having somehow attached a trailer hitch to the rear
fender and a six-horse trailer to the hitch.   Neither is likely
to work well unless people implement what they think the spec
was intended to say rather than what it does say.  I'm trying to
restore the possibility of functional Vespa-ness by making the
question of how much of UTS#51 a sensible implementation would
use, and what adjustments need to be made, part of the
experiment.  If we don't do that, the spec is due for a trip to
the mechanic to see if there is a way to cut the horse trailer
off and reinstall a proper-sized rear wheel.

Certainly some of the changes that have been proposed would take
us in the monster truck direction.  And, as Dave has suggested,
I think approving a simple, Vespa-sized, extension and then
seeing how much of the rest is needed.  But the current
specification, whether intentionally or not, does not meet that
goal of simplicity.

best,
   john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Mar 2021 06:06:44 -0800

On 3/1/2021 12:03 AM, John C Klensin wrote:
> high complexity that is necessary to understand. 

Discussion of this draft was conducted on the ietf-822 mailing list for 
two months, last September and October.  Early in October, the spec 
added the UTS#51 reference.

You participated in the ietf-822 discussion but did not raise any of the 
concerns you are now offering as being critical.  Nor did anyone else.

What has changed?

Above you make a claim to controversy about this specification.  I've 
looked and am not finding it.  Please provide a reference the rest of us 
can use to review it.

For all of the concerns you insist are fatal to the current 
specification, you have yet to offer an alternative that can be compared 
against it.

Suggestions for modifying the specification, to add various constraints 
or commentary surrounding the use of UTS#51 pertain to that external 
specification and not to its use here.

That is, you are pressing for having an IETF specification contain 
tutorial material about another standard body's work or to declare some 
constraint on the use of that work -- though we can't yet tell what 
constraint you would find satisfactory, in spite of your multiple, 
extended postings here.

There is a simple reality that that external work has been around for 
awhile and has field experience.  To the extent that there are nuances, 
complexities, or the like, that area of work has been developing it. 
The IETF hasn't and should not pretend to exercise expertise about it.

Then there is the small matter that this specification is intended as 
Experimental.  That's supposed to allow room for gaining experience.

If the horrors you fear do appear, we'll find out, won't we?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Mar 2021 12:20:49 -0500

I think it's best for us to back this up to John's note suggesting that we:

(1) Add a paragraph about emoji sequences (specifically, things that
might combine emoji characters in possibly problematic ways, such as
applying skin-tones, grouping several person symbols into one "family"
symbol, and the like), which would briefly explain why they can be
problematic and give an example or two.

(2) Add something to the experiment description (Section 7) that talks
about getting feedback about any understandability issues and culture
clashes.

I would see (1) as also leading us to eliminating emoji-sequence as a
normative construct (so, just leaving things as a string of emoji
characters, some of which could form an emoji sequence) and moving
TS51 to informative.

Are there real objections to that?  I'm sure we can quickly come up
with some brief text that accomplishes this and then move forward.

Barry

On Mon, Mar 1, 2021 at 9:07 AM Dave Crocker <[email-masked]> wrote:
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Ned Freed <[email-masked]>
Date: Mon, 01 Mar 2021 08:04:51 -0800 (PST)

> >> reactions to Unicode emoji and exclude text reactions like :-(

I can. Reactions have to have the proper appearance in a user interface. "Emoji
style" rendering is designed to meet that need, and it's the required default
for Unicode Emoji. So for the most part if you send an emoji to whatever UI
toolkit you're using you're likely to get something acceptable. Some non-Emoji
character, not so much.

Now, you can specify Emoji style rendering for any character (variation
selector 16, U+FEOF). The trouble is, it seems that almost nobody supports it.
(The likely reason for that is doing so not only requires having a huge number
of additional character forms, it also isn't at all obvious how you do stuff
like, say, maintain the distinction between single and double width characters.
AFAIK all of this is completely undefined.)

Amusingly, a similar problem occurs when you want Emoji to render as regular
text (U+FE0E). This isn't well supported either, but the good news is we don't
have to care.

> > trying to define a vespa here, not a monster truck.

Indeed. It may seem simple to open the door to any character, but it's really
a pretty major change.

> combining sequences each with its own rules.

This is only true if you're writing your own full-on Unicode rendering engine,
in which case I rather suspect that by the time you get to worrying about
UTS#51 you will have faced so many other problems getting past UTS#51 won't be
that difficult.

However, I would be *tremendously* surprised if anyone coding this in a user
agent would go to the trouble of writing such a renderer. And even if you're
writing the back end of such a thing, the odds are you're going to delegate the
handling of Unicode to a library like HarfBuzz. The odds of such a library not
having Emoji support are low.

And frankly, if for some reason this amount of coding necessary because
existing renderers lack some crucial ability, the experiment is guaranteed to
fail no matter what cautionary words we put in the text.

> to to justify this experiment.

We have a vast number of specifications, including most of the email ones, that
operate by specifying what must or should be emitted by compliant
implementations. Which is what this one does as well: We define what a valid
reaction part looks like, and that includes restricting the text content.

In few if any cases do we bother to say stuff like, "Implementations MUST
validate header fields containing addresses before displaying them" or,
"Implementations MUST validate a requirement that a particular MIME part is of
the proper  type". We leave it up to implementations to decide when this is
appropriate.

Maybe we should in fact be calling for validation where we think it's critical,
but we don't. And absent some really compelling reason why this case is
different - something I have not seen - an experiment in  sending reactions
around strikes me as exactly the wrong time to start.

> not is prohibited".

That's exactly the intent. And part of the justification for that is it lets
email implementors use off-the-shelf components written by people who have
already dealt with UTS#51 and everything else below it.

> Continuing with your metaphor, I don't see

Again, this assumes a start-from-scratch approach I am skeptical anyone
will use.

I will also point out that requiring implementation of a profile/subset of
UTS#51 may in fact complicate things rather than simplify them. Unless the
profile/subset can easily be expressed as some kind of pattern matching
operation - you have now significantly increased, rather than decreased the
difficuly of implementing this specification.

And to what end? If there was evidence that the widely used UI toolkits out
there can't handle some specific aspect of UTS#51 and this is likely to remain
the case indefinitely, then it might - and I emphasize might - be cause to
mention it in the specification. But I haven't seen such evidence - and I have
looked.

Indeed, what I have seen is a rather surprising degree of consistency with how
various agents render Emoji. To be sure, there are some annoying
inconsistencies like how some render most animals as faces whereas others
render the entire body, not to mention some oddities like how JoyPixels renders
bell pepper in red rather than green. But major omissions? Citations needed.

And given the extensibility of Unicode - extensibility that seems certain to be
used to increase the number of Emoji in the immediate future - you may end up
forcing implementations to maintain yet another copy of the Unicode  propety
table. I don't think this is a good idea.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 01 Mar 2021 14:22:50 -0500

Barry,

Thanks... and yes.  I want to again stress that I have not
proposed changing basic assumptions about the protocol, only to
clarify the range of the experiment and warn about a few
possible issues.  I've also realized, after reading Ned's note,
that I (and maybe Patrik) should perhaps have explained our
concerns a little bit differently.  I want to think about that a
bit more lest I post a quick response that confuses things
further but will try to explain later today.

    john

--On Monday, 01 March, 2021 12:20 -0500 Barry Leiba
<[email-masked]> wrote:

> (1) Add a paragraph about emoji sequences (specifically,
> things that might combine emoji characters in possibly
> problematic ways, such as applying skin-tones, grouping
> several person symbols into one "family" symbol, and the
> like), which would briefly explain why they can be problematic
> and give an example or two.
> 
> (2) Add something to the experiment description (Section 7)
> that talks about getting feedback about any understandability
> issues and culture clashes.
> 
> I would see (1) as also leading us to eliminating
> emoji-sequence as a normative construct (so, just leaving
> things as a string of emoji characters, some of which could
> form an emoji sequence) and moving TS51 to informative.
> 
> Are there real objections to that?  I'm sure we can quickly
> come up with some brief text that accomplishes this and then
> move forward.
> 
> Barry
> 
>> > However, the specification as now written incorporates all
>> > or UTS#51, a long (very long if the required supporting
>> > tables are considered( specification of what several people
>> > outside the IETF have described as a Unicode-based picture
>> > language of very high complexity that is necessary to
>> > understand.
>> 
>> 
>> 
>> Discussion of this draft was conducted on the ietf-822
>> mailing list for two months, last September and October.
>> Early in October, the spec added the UTS#51 reference.
>> 
>> You participated in the ietf-822 discussion but did not raise
>> any of the concerns you are now offering as being critical.
>> Nor did anyone else.
>> 
>> What has changed?
>> 
>> 
>> 
>> Above you make a claim to controversy about this
>> specification.  I've looked and am not finding it.  Please
>> provide a reference the rest of us can use to review it.
>> 
>> 
>> 
>> specification, you have yet to offer an alternative that can
>> be compared against it.
>> 
>> Suggestions for modifying the specification, to add various
>> constraints or commentary surrounding the use of UTS#51
>> pertain to that external specification and not to its use
>> here.
>> 
>> That is, you are pressing for having an IETF specification
>> contain tutorial material about another standard body's work
>> or to declare some constraint on the use of that work --
>> though we can't yet tell what constraint you would find
>> satisfactory, in spite of your multiple, extended postings
>> here.
>> 
>> 
>> 
>> There is a simple reality that that external work has been
>> around for awhile and has field experience.  To the extent
>> that there are nuances, complexities, or the like, that area
>> of work has been developing it. The IETF hasn't and should
>> not pretend to exercise expertise about it.
>> 
>> 
>> 
>> Then there is the small matter that this specification is
>> intended as Experimental.  That's supposed to allow room for
>> gaining experience.
>>

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 02 Mar 2021 08:00:30 +1100

You can already send arbitrary bytes over the wire, and nothing in this document changes that.

Indeed, you can already send an email with these exact sequence that Barry is mentioning here, and have it rendered "correctly" in the body of an email.

Recipients already need to sanity check anything coming in, and could block any sequence they don't like.

Literally the only point of a standards document referencing something like UTS#51 (apart from the initial guidance to allow people to create something compatible) is so that if something doesn't work, then in a discussion between the sender and the receiver there's a documented version of who is more correct.

I'm with Dave on this still - this whole discussion seems like some baulking at shadows which aren't there.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Mar 2021 20:15:29 -0800

> (1) Add a paragraph about emoji sequences (specifically, things that

This has been added to the end of Section 2:

Note:
     The "emoji" token looks simple. It isn't. Implementors are 
well-advised not to assume that emoji sequences are trivial to parse or 
validate. Among other concerns, an implementation of the Unicode 
Character Database is required. An emoji is more than a stand-in for a 
simple alternation of characters. Similarly, one emoji sequence is not 
interchangeable with, or equivalent to, another one, and comparisons 
require detailed understanding of the relevant Unicode mechanisms. Use 
of an existing Unicode implementation will typically prove extremely 
helpful, as will an understanding of the error modes that may arise from 
a chosen implementation.

d/

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 2 Mar 2021 15:48:41 +0900

Hello Dave, others,

Sorry to be late with my comments.

> helpful, as will an understanding of the error modes that may arise from 

I think this is a valuable addition. I was following the discussion for 
a long time, and wanted to point to the Unicode implementations already 
existing out there and the high probability that a mailer would use one 
of these, but Ned finally pointed this out ahead of me.

I'd probably move the "Use of an existing Unicode implementation ..." to 
the start of the paragraph, because we don't need to scare readers 
uselessly. It may also be helpful to point out that if somebody just 
implements base-emojis or any other smallish set of emoji, they don't 
have to go to great lengths in their implementation efforts.

I agree with whoever has mentioned it that "*octet* sequences" needs to 
be removed or replaced. I hope this has already happened.

I also agree that it's important to point out the fact that the same 
emoji can be interpreted in completely different ways in different 
cultures or even in the same culture or microculture. I was glad to see 
that there was some addition about this between -08 and -09, but I think 
it could (and SHOULD) be stronger. In particular, it should be pointed 
out that the same emoji can have completely contradictory meanings and 
offensive or obscene meanings in some cultures.

In terms of nits, I'm really unclear why section 4.1 (Example Message) 
is where it is. Also, the hyphen in "possibly-interesting" might be 
replaced by a space without loss of semantics.

Regards,    Martin.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 2 Mar 2021 05:20:34 -0800

On 3/1/2021 10:48 PM, Martin J. Dürst wrote:
> uselessly. 

Especially given the discussion that led up to the addition of this 
paragraph, my own view is that scaring the reader a bit, before telling 
then of an easy 'fix' is probably a good idea...

> be removed or replaced. I hope this has already happened.

The concern was to switch from 'byte' to 'octet'.  So octet is what the 
draft now uses.

> offensive or obscene meanings in some cultures.

Cultural sensitivities and misunderstandings are rife.  Any 
communication, of any sort, involving diverse participants, carries the 
onus of this concern.  It is not restricted or specialized to this 
mechanism.

> is where it is. 

After the specification content and before the pro forma sections on 
Security and IANA.  Seemed a natural placement.

> Also, the hyphen in "possibly-interesting" might be 

ack. tnx.

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Mar 2021 09:15:23 -0500

--On Tuesday, 02 March, 2021 05:20 -0800 Dave Crocker
<[email-masked]> wrote:

>> I agree with whoever has mentioned it that "*octet*
>> sequences" needs to  be removed or replaced. I hope this has
>> already happened.
> 
> The concern was to switch from 'byte' to 'octet'.  So octet is
> what the draft now uses.

Dave,

I don't know whose concern was to make that particular switch
and why, but my concern about either (and, I'm guessing,
Martin's) is that almost all Unicode code points (those outside
the ASCII range) require more than one octet to represent in any
encoding scheme.  For UTF-8, which the I-D requires, the number
of octets is variable.  So using "octet" as a unit of --well,
much of anything--is, at best, confusing.

   john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 2 Mar 2021 06:20:11 -0800

> much of anything--is, at best, confusing.

Oh goodie.  Another random, generic topic to bikeshed on.  How exciting.

John, Please point to specific text that you have objections to, please 
explain exactly what is problematic about it, and please provide 
specific text you propose to replace it with.  It would also be nice for 
you to explain what makes the replacement text superior.

d/

---

From: "Ricardo Signes" <[email-masked]>
Date: Tue, 02 Mar 2021 09:34:46 -0500

> much of anything--is, at best, confusing.

"octet" appears in two places.

One:

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

I would replace "octet" with "code point".  The referenced document only describes sequences of code points.  The encoding of those into octets is orthogonal, and will be described by the content-type and content-transfer-encoding jointly.  So, I think this change is a definite improvement to accuracy, and is worth making.

Two: 

   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.

I suggest the same change.  It's -maybe- more debatable.  But this document is describing what to do with the decoded content, because it doesn't describe anything about C-T-E or charset decoding.  We must assume that the decoding layer has done its job and now we either have a total error or a codepoint sequence.  (Some decode layers will have been instructed to hand back REPLACEMENT CHARACTER when the octet sequence was mangled, which will not be a valid emoji sequence, and everything works out.)

-- 
rjbs

---

From: Ned Freed <[email-masked]>
Date: Tue, 02 Mar 2021 08:27:42 -0800 (PST)

> I would replace "octet" with "code point".  The referenced document only
> describes sequences of code points.  The encoding of those into octets is
> orthogonal, and will be described by the content-type and
> content-transfer-encoding jointly.  So, I think this change is a definite
> improvement to accuracy, and is worth making.

Sigh. I noticed but then completely forgot about this. emoji_seq only goes as
far as code points, which leaves out the subsequent UTF-8 encoding.

More specifically, the base productions at the bottom of the ABNF are things
like:

  emoji_character := \p{Emoji}
  default_emoji_presentation_character := \p{Emoji_Presentation}
  default_text_presentation_character := \P{Emoji_Presentation}
  emoji_modifier := \p{Emoji_Modifier}

A definition in terms of a regexp that can apply to any encoding of Unicode.
Which of course makes sense in the context of this standard. Why get into
encoding when you don't have to?

For us the problem is when used as a production, many possible sets of octet
sequents are possible, and we need to select the right one. So the text is
actually incorrect, and needs to be fixed. I suggest:

    The rule emoji_sequence is inherited from [Emoji-Seq].  It defines a
    set of Unicode code point sequences, which must then be encoded as UTF-8.
    Each such sequence forms a single pictograph.

> I suggest the same change.  It's -maybe- more debatable.  But this document
> is describing what to do with the decoded content, because it doesn't describe
> anything about C-T-E or charset decoding.  We must assume that the decoding
> layer has done its job and now we either have a total error or a codepoint
> sequence.  (Some decode layers will have been instructed to hand back
> REPLACEMENT CHARACTER when the octet sequence was mangled, which will not be a
> valid emoji sequence, and everything works out.)

Given the clarification above I don't think a change here is strictly required,
but it wouldn't hurt to reemphasize the point about UTF-8. So:

   ... the corresponding UTF-8 encoded code points ...

would work. And it has the added benefit of not using the words "octet" or
"byte" that some find distastful. (The production of <whatever> is implicit in
the UtF-8 reference.)

Sorry for not catching this sooner.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 02 Mar 2021 17:54:17 +0100

Not exactly - here's the relevant excerpt (you responding to me):

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

   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.

I didn't belabour the point then, but I still much prefer "code points"
(or "emoji characters").  (I probably should not have added the
parenthesis - it's a bad habit of mine to bring up such tangents.)

-- 
venleg helsing,
Kjetil T.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Mar 2021 12:49:49 -0500

Authors, thanks for this text: I think it's good, and, at least to my
mind, covers what John Klensin was looking for.  John, can you live
with this text?

As to changing the list in Section 7, the more I talk with Dave about
it the more I become convinced that the third bullet is really all we
need.  It is broad and vague, but I'm not sure there's much value in
being more precise: as I read that bullet (now, for the 97th time, so
it's really deep in my brain at this point), it says that we're
looking for information about any issues that recipients have in
consuming the results of this... which would cover UI issues, user
confusion issues, issues involving cultural (mis-)understanding, and
so on.

John K, if you really think it's critical that we say more here, can
you please post a bullet or two of specific text that you'd like to
see added/changed?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Mar 2021 12:52:56 -0500

I think Ned's proposed fix here is exactly right.

Barry

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Mar 2021 14:33:09 -0500

Ned,

This works, as would almost anything else that gets rid of
things that imply specific-length objects like "octet" or "byte".

However (consider this background/ informational if you don't
want to make further changes)... My preference, given both the
heavy dependency on UTS#51 in particular and the Unicode specs
in particular would be to stick with Unicode terminology unless
we have a substantive need to depart from it.  That would imply
using "code point" throughout, partially to avoid getting tied
up with encodings or local representations.  In particular,
while the spec requires UTF-8 on the wire, these strings will
actually be processed my MUAs and libraries and many operating
systems do not store or use UTF-8 internally, making the UTF-8
emphasis confusing.

But I do not feel strongly about the above in this context, so,
again, your changes work for me.

    john

--On Tuesday, 02 March, 2021 08:27 -0800 Ned Freed
<[email-masked]> wrote:

>> > I don't know whose concern was to make that particular
>> > switch and why, but my concern about either (and, I'm
>> > guessing, Martin's) is that almost all Unicode code points
>> > (those outside the ASCII range) require more than one octet
>> > to represent in any encoding scheme.  For UTF-8, which the
>> > I-D requires, the number of octets is variable.  So using
>> > "octet" as a unit of --well, much of anything--is, at best,
>> > confusing.
> 
>>    The rule emoji_sequence is inherited from [Emoji-Seq].  It
>>    defines a set of octet sequences, each of which forms a
>>    single pictograph.
> 
>> I would replace "octet" with "code point".  The referenced
>> document only describes sequences of code points.  The
>> encoding of those into octets is orthogonal, and will be
>> described by the content-type and content-transfer-encoding
>> jointly.  So, I think this change is a definite improvement
>> to accuracy, and is worth making.
> 
> Sigh. I noticed but then completely forgot about this.
> emoji_seq only goes as far as code points, which leaves out
> the subsequent UTF-8 encoding.
> 
> More specifically, the base productions at the bottom of the
> ABNF are things like:
> 
>   default_emoji_presentation_character :=
> \p{Emoji_Presentation}   default_text_presentation_character
> := \P{Emoji_Presentation}   emoji_modifier :=
> \p{Emoji_Modifier}
> 
> A definition in terms of a regexp that can apply to any
> encoding of Unicode. Which of course makes sense in the
> context of this standard. Why get into encoding when you don't
> have to?
> 
> For us the problem is when used as a production, many possible
> sets of octet sequents are possible, and we need to select the
> right one. So the text is actually incorrect, and needs to be
> fixed. I suggest:
> 
>     The rule emoji_sequence is inherited from [Emoji-Seq].  It
> defines a     set of Unicode code point sequences, which must
> then be encoded as UTF-8.     Each such sequence forms a
> single pictograph.
> 
>> Two:
> 
>>    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.
> 
>> I suggest the same change.  It's -maybe- more debatable.  But
>> this document is describing what to do with the decoded
>> content, because it doesn't describe anything about C-T-E or
>> charset decoding.  We must assume that the decoding layer has
>> done its job and now we either have a total error or a
>> codepoint sequence.  (Some decode layers will have been
>> instructed to hand back REPLACEMENT CHARACTER when the octet
>> sequence was mangled, which will not be a valid emoji
>> sequence, and everything works out.)
> 
> Given the clarification above I don't think a change here is
> strictly required, but it wouldn't hurt to reemphasize the
> point about UTF-8. So:
> 
> would work. And it has the added benefit of not using the
> words "octet" or "byte" that some find distastful. (The
> production of <whatever> is implicit in the UtF-8 reference.)
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Mar 2021 14:36:37 -0500

To both One and Two:  

Exactly.  See the aside in my note to Ned for details of my
explanation, which parallels yours.

thanks,
   john

--On Tuesday, 02 March, 2021 09:34 -0500 Ricardo Signes
<[email-masked]> wrote:

>> Martin's) is that almost all Unicode code points (those
>> outside the ASCII range) require more than one octet to
>> represent in any encoding scheme.  For UTF-8, which the I-D
>> requires, the number of octets is variable.  So using "octet"
>> as a unit of --well, much of anything--is, at best, confusing.
> 
> jointly.  So, I think this change is a definite improvement to
> accuracy, and is worth making.
> 
> Two: 
> 
> using the system    default method for denoting an unallocated
> or undisplayable code    point.
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Mar 2021 15:01:41 -0500

--On Tuesday, 02 March, 2021 15:48 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

>...
>> Note:
>>      The "emoji" token looks simple. It isn't.
>>  Implementors are  well-advised not to assume that emoji
>> sequences are trivial to parse or  validate. Among other
>> concerns, an implementation of the Unicode  Character
>> Database is required. An emoji is more than a stand-in for a 
>> simple alternation of characters. Similarly, one emoji
>> sequence is not  interchangeable with, or equivalent to,
>> another one, and comparisons  require detailed understanding
>> of the relevant Unicode mechanisms. Use  of an existing
>> Unicode implementation will typically prove extremely 
>> helpful, as will an understanding of the error modes that may
>> arise from  a chosen implementation.
> 
> I think this is a valuable addition. I was following the
> discussion for a long time, and wanted to point to the Unicode
> implementations already existing out there and the high
> probability that a mailer would use one of these, but Ned
> finally pointed this out ahead of me.

Martin,

A question about the above.  When I first read the paragraph,
"implementation of the Unicode  Character Database" struck me as
strange, partially because I don't know what implementing a
database means.  I would have thought the better wording would
have been closer to "implementation of the rules of UTS#51 and
the associated tables".  Do you agree?  If you (or others who
are deeply steeped in Unicode) do not see a problem with the
existing text, I'm happy to just let it go.

>...
> It may also be helpful
> to point out that if somebody just implements base-emojis or
> any other smallish set of emoji, they don't have to go to
> great lengths in their implementation efforts.

I would favor that but do not think it is critical either.

thanks,
    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Mar 2021 16:08:08 -0500

--On Tuesday, 02 March, 2021 12:49 -0500 Barry Leiba
<[email-masked]> wrote:

> Authors, thanks for this text: I think it's good, and, at
> least to my mind, covers what John Klensin was looking for.
> John, can you live with this text?
> 
> As to changing the list in Section 7, the more I talk with
> Dave about it the more I become convinced that the third
> bullet is really all we need.  It is broad and vague, but I'm
> not sure there's much value in being more precise: as I read
> that bullet (now, for the 97th time, so it's really deep in my
> brain at this point), it says that we're looking for
> information about any issues that recipients have in consuming
> the results of this... which would cover UI issues, user
> confusion issues, issues involving cultural
> (mis-)understanding, and so on.
> 
> John K, if you really think it's critical that we say more
> here, can you please post a bullet or two of specific text
> that you'd like to see added/changed?

Barry,

I have also reread that text several times (perhaps 50 rather
than 97), agree that it can be read as including anything that
happens including catastrophic software failures, outbreaks of
disease, or, given the cultural issues, users being struck by
lightning, that cannot be absolutely proven to not be associated
in some odd way with this feature.  The one place that it is not
broad is that it singles out recipients and, if interpreted to
cover the emoji cases, operational problems for originators are
possible too. 

On the other hand, the IETF has usually tried to avoid getting
sucked into, or even wanting to hear complaints about, user
interface issues for reasons I vividly remember Dave explaining
forcefully to me and several others many year ago.  Because of
the semantics associated with emoji and their binding to
graphemes -- issues that do not arise with what we normally
consider "text", even text in logographic scripts -- this
specification comes very close to that territory.  I still think
we should move ahead with it, but believe that being clear that
we are interested in those issue would be useful (I'm not going
to try to make a case for "critical"). However, I don't think it
requires even an extra bullet; see the first suggestion below.

Two possible suggestions:

(1)  Change the third bullet to read:
 
	Does the presence of the Reaction capability create any
	operational problems, including problems associated with
	the handling of emoji characters, for message
	originators or recipients?

(2) Add an additional bullet, probably after the current third
one, reading something like:

	Does the use of emoji characters pose any special
	challenges in processing or to users, including the
	issues mentioned in Section NN above?  Do
	implementations prefer to support only a limited set of
	emoji (on either input or output) using a list similar
	to the <base-emojis> set or are users permitted to
	specify, and receivers expected to be able to render,
	the full range of emoji specified by UTS#51?

I think I (slightly) prefer the first, but the second smuggles
in an extra issue, one that others have implicitly raised in the
last 48 hours: what choices implementations make among those
implied by the paragraph starting "The rule base-emojis MAY be
used..." in Section 2.

To me clear, my motivations with regard to Section 7 are
different from those associated with issues in the rest of the
document.  For the others, my goal was to make the document
accurately reflect what the document was intended to specify.  I
believe that people being surprised that the document specified
only emoji and did not allow plain text and that others assumed
a pick list and a small repertoire are symptoms that it was no
clear enough (or that few people paid any attention to what it
actually specified it before the other issues were raised).
With regard to Section 7, however, my belief is that, if the
IETF is going to propose an experiment to the broader community,
we should strive to get as much information out of the
experiment as possible.  In that context, questions that people
don't think have been asked and problems they have not been told
to look out for and report seem less likely to generate good
feedback than our being somewhat more explicit.  I'll leave to
others whether that goal rises to "critical" or not.

     john

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Mar 2021 16:48:56 -0500

Thanks, John; having those suggestions to consider is really helpful.

Barry

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 3 Mar 2021 08:40:12 +0900

Hello Ned, others,

Thanks for your changes, they look great.

For the record, I do not think that "octet" or "byte" are in any way 
distasteful. It's just that they are appropriate in some contexts, but 
not in others, and your proposed text(s) fixes that.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 3 Mar 2021 09:16:47 +0900

Hello Dave, others,

On 02/03/2021 22:20, Dave Crocker wrote:
>> I'd probably move the "Use of an existing Unicode implementation ..." 
>> to the start of the paragraph, because we don't need to scare readers 
>> uselessly. 
> 
>> I agree with whoever has mentioned it that "*octet* sequences" needs 
>> to be removed or replaced. I hope this has already happened.
> 

If you don't understand the difference between 'byte'/'octet' and 'code 
point', I recommend careful reading e.g. of https://www.w3.org/TR/charmod/.

Fortunately, Ned understood what John and me and others were complaining 
about, and we are on the right way here.

>> cultures or even in the same culture or microculture. I was glad to 
>> see that there was some addition about this between -08 and -09, but I 
>> think it could (and SHOULD) be stronger. In particular, it should be 
>> pointed out that the same emoji can have completely contradictory 
>> meanings and offensive or obscene meanings in some cultures.
> 

Well, yes, but cultural sensitivity and the awareness for it in the case 
of images (in particular hand gestures) is quite a bit different from text.

First, it's very easy for humans to intuitively think that while people 
using different languages obviously would need different text, everybody 
should understand something like a "thumbs up".

Second, the chances for completely opposite or offensive meanings are 
significantly bigger in particular for hand gestures.

Third, this draft explicitly proposes hand gestures that have offensive 
meanings in some regions of the world, as opposed to just allowing such 
gestures as part of a general repertoire.

Fourth, it has been reported quite recently that some applications 
actually change the display of some of their reactions, for exactly the 
reason brought up here. As far as I understand, the draft doesn't 
propose any such thing (which may be okay as such). This situation is 
akin to a security issue with a known remedy where a draft would just 
talk about it in vague terms.

> Security and IANA.  Seemed a natural placement.

I was not asking about Section 4, for the placement of which you give 
good arguments above. I was specifically asking about Subsection 4.1. 
This is an example message showing *syntax*, unfathomably (at least to 
me) sandwiched between two (*) text pieces about *semantics* and usage.

(*) 1) the part of Section 4 that probably should be its own subsection 
before 4.1, and 2) Subsection 4.2.

Regards,   Martin.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2021 06:40:39 -0800

I'm finally able to get some time for this.  And I'm finding myself 
thinking of the interaction between ietf perspective and unicode 
perspective.  ietf perspective uses the term octet.  I think there can 
be some benefit in mixing the terms, to try to connect them, for the 
reader.  Consequently, I propose:

On 3/2/2021 6:34 AM, Ricardo Signes wrote:
> describes sequences of code points.  The encoding of those into octets 
> is orthogonal, and will be described by the content-type and 
> content-transfer-encoding jointly.  So, I think this change is a 
> definite improvement to accuracy, and is worth making.

NEW:

<t>The ABNF rule emoji_sequence is inherited from <xref 
target="Emoji-Seq"/>. It defines a set of octet sequences, each of which 
forms a single pictograph. The BNF syntax used in [Emoji-Seq] differs 
from <xref target="ABNF"/>, and MUST be interpreted as used in Unicode 
documentation. The referenced document describes these as sequences of 
code points.

> I suggest the same change.  It's -maybe- more debatable.  But this 

I find myself wanting to retain octet here.  Again, it makes a linkable 
between code point and octet explicit.  Further, this text involves raw 
data that can't be processed normally and octet has no semantics beyond 
saying 8-bit, whereas code point invokes substantial semantics.

Thoughts?

d/

---

From: Ned Freed <[email-masked]>
Date: Wed, 03 Mar 2021 07:02:51 -0800 (PST)

> 	originators or recipients?

I can already answer this one: Yes, of course it will create problems. The use
of inline emoji in regular email subject lines and text is creating problems as
I write this; it's nonsensical to think that moving those characters to a
different part with a slightly different label will change this in any way.
Indeed, if this proves popular it will likely cause more problems, not less.

As such, this isn't a valid way of assessing the experiment. The goal here
isn't to address the many issues with Unicode emoji; it's to add a new
capability to email. We believe that the best mechanism on which to base this
new capability is Unicode emoji, but that's in large part due to there being no
viable alternative.

I completely understand the desire to try and fix problems with Unicode in
general and problems with Unicode emoji in particular. But after watching these
attempts  play out over and over again, in specification after specification,
for the past 30 years (yes, it has been that long), and seen the results of our
attempts to address these issues, I've become convinced that this isn't even
the right venue, let alone the right specification, for that.

I also understand that when you don't see the changes you want happening on the
Unicode side of things, you want to warn everyone about the possible pitfalls. 

But we need to be realistic about what's possible here and what's not. For
better or worse, anyone implementing this is almost certainly going to use some
library or other to do all the Emoji handling. They'll use someone else's emoji
picker to select them, they'll use someone else's Unicode display code to
present them, and they will use someone else's regexp library to check them. 

Absent precise articulaion of things that can be done to address specific
issues we know exist given such an implementation strategy, any text we add is
unlikely to have any impact. And by the same token, in assesing the
experiment's results the only thing it's sensible to measure is whether or not
the specification got the specifics right.

All that said, we do need to know if the capability itself causes
operational problems, e.g., lots of clients can't properly deal with the
additional message parts. But this needs to be distinct from emoji/Unicode
issues.

> implied by the paragraph starting "The rule base-emojis MAY be

I think it's approprate to ask for an assessment of how many implementations
require subsetting, and if they do, what subsets they opted to use, and how.
But beyond that we're back in "things we can't fix" territory.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2021 10:28:45 -0800

On 3/2/2021 1:48 PM, Barry Leiba wrote:
> believe that people being surprised that...

Especially given our community tendency towards bikeshedding, there is a 
particular danger in trying to add narrow refinement to a list of 
questions in a section intended to get feedback about an experiment.

The questions need to be meaningful, of course, but this is really a 
survey instrument and these are difficult to do well.  In the absence of 
careful design, strong controls, and expertise in the black art of 
survey methodology, keeping these profoundly simple and simplistic is 
essential.

In engineering, we are taught to be careful about false precision. 10.1 
* 10.1 is 102.0, not 102.01.  Survey research has more complex and 
subtle versions of the same concern that it is easy to produce a 
misleading and inaccurate sense of precision claimed or implied.

Note that the sampling methodology for these question does not have any 
relationship to an actual experiment, and therefore neither do the 
responses.  So really, we are only asking a variation of "Tell us about 
using the specification."

Having reflected a bit about this, this morning, I now think it 
reasonable to add a bit more, but not really of the sort that has been 
discussed.

Here's what I propose:

>
>   7. Experimental Goals
>
> The basic, email-specific mechanics for this capability are 
> well-established and well-understood. Points of concern, therefore, are:
>
>   * Technical issues in using emojis within a message body part
>   * Market interest
>   * Usability
>
> So the questions to answer for this Experimental specification are:
>
>   * Is there demonstrated interest by MUA developers?
>   * If MUA developers add this capability, is it used by authors?
>   * Does the presence of the Reaction capability create any
>     operational problems for recipients?
>   * Does the presence of the Reaction capability demonstrate
>     additional security issues?
>   * What specific changes to the specification are needed?
>   * What other comments will aid in use of this mechanism?
>
> Please send comments to [email-masked].
>

d/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Mar 2021 13:43:32 -0500

> Having reflected a bit about this, this morning, I now think it reasonable to add a bit
> more, but not really of the sort that has been discussed.
>
> Here's what I propose:
>
> 7. Experimental Goals
>
> The basic, email-specific mechanics for this capability are well-established and
> well-understood. Points of concern, therefore, are:
>
> Technical issues in using emojis within a message body part
> Market interest
> Usability
>
> Is there demonstrated interest by MUA developers?
> If MUA developers add this capability, is it used by authors?
> Does the presence of the Reaction capability create any operational problems for
> recipients?
> Does the presence of the Reaction capability demonstrate additional security
> issues?
> What specific changes to the specification are needed?
> What other comments will aid in use of this mechanism?
>

For my part, I'm happy with that version.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2021 11:17:44 -0800

> gestures as part of a general repertoire.

Two responses:

1. The choices in that set already have global use

2. If someone doesn't like the set, then they shouldn't use it. It is 
intentional that the set does not have normative status.

3. If you think there is a better set to use, please specify it and 
circulate it.  There's nothing wrong with having additional sets defined 
and, in fact, I'd argue that the specification already encourages it.

> talk about it in vague terms.

Comparing a cultural affront to a security threat probably has some
appeal but in practical terms I fear it is not helpful.

>>> In terms of nits, I'm really unclear why section 4.1 (Example 
>>> Message) is where it is. 
>>

Talking about display of a message is aided by have a concrete example 
to consider.

d/

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 03 Mar 2021 20:41:42 +0100

On 3 Mar 2021, at 15:40, Dave Crocker wrote:

> I find myself wanting to retain octet here.  Again, it makes a linkable between code point and octet explicit.  Further, this text involves raw data that can't be processed normally and octet has no semantics beyond saying 8-bit, whereas code point invokes substantial semantics.
>
>
> Thoughts?

Let me say I think it is a bad idea to "mix" octet and character/code point. These two talks about two different layers in the architecture where what octets you use depends on (as other have said) what encoding you use etc.

So in IETF specifications when talking about text, you should talk either about octets or characters. And if you talk about octets you suddenly have to take care of changes of them, series of octets that can not be characters etc.

So no, not a mix please.

Why do you want to keep octet?

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Mar 2021 16:12:43 -0500

Ned,

At this point, I think we are suffering from a difference in
perspective rather than one the is more substantive.  To start,
I am convinced that the IETF could not fix any fundamental
issues with Unicode, including addressing "the many issues with
Unicode emoji", even if we had the expertise and energy to do so
-- and it is clear to me that we have neither -- so I am not
proposing to do that, in this document or anywhere else.  At the
same time, I see a tremendous amount of ignorance about those
issues and even about Unicode fundamentals around the IETF
(perhaps the other side of the "expertise and energy" coin) and
parts of the surrounding implementer community and do not see it
as desirable for a specification published in 2021 to encourage
that ignorance.  If I believed that the likely readers of this
specification were reasonably familiar with the issues, we would
not be having this discussion: a more or less general pointer in
the direction of Unicode and UTS#51 would be fine, just as
general pointers about ASCII have been for decades. If the
terminology was not quite right, everyone would know what was
intended and we'd just move on.  

However, from my point of view, the ignorance level is high
enough that the boundary between imprecise terminology or a
general pointer in the direction of Unicode and/or UTS#51 and a
trap for the unwary is rather thin.  

Some specifics below.

--On Wednesday, 03 March, 2021 07:02 -0800 Ned Freed
<[email-masked]> wrote:

>> interface issues for reasons I vividly remember Dave
>> explaining forcefully to me and several others many year ago.
>> Because of the semantics associated with emoji and their
>> binding to graphemes -- issues that do not arise with what we
>> normally consider "text", even text in logographic scripts --
>> this specification comes very close to that territory.  I
>> still think we should move ahead with it, but believe that
>> being clear that we are interested in those issue would be
>> useful (I'm not going to try to make a case for "critical").
>> However, I don't think it requires even an extra bullet; see
>> the first suggestion below.
> 
> I can already answer this one: Yes, of course it will create
> problems. The use of inline emoji in regular email subject
> lines and text is creating problems as I write this; it's
> nonsensical to think that moving those characters to a
> different part with a slightly different label will change
> this in any way. Indeed, if this proves popular it will likely
> cause more problems, not less.

Then drop the text I suggested for Section 7 and add text to
Section 2 that is a different phrasing of what you wrote above,
i.e., "We know this will cause problems in many implementation
because emoji have been problematic in other email-related
contexts for some time; implementers and those who support
products or other software that implements this extension should
be aware of those issues.".   If you could provide a few
(entirely informative) references to supplement that, so much
the better.  Or, if you prefer, the text might be "we advise
against anyone trying this experiment who is not already
familiar with Unicode and the implications of using emoji in
email or other contexts".

If we want the experiment to tell us anything at all, we should
not set up those who are not as experienced and knowledgeable as
the authors and some of those reading this to go off and try
this, call on some handy libraries whose properties they don't
understand, and then be surprised when they get complaints from
users (or, in the worst cases, regulators) about displaying
obscene gestures to small children.  That is, I hope, a lurid
and exaggerated scenario, but you know as well as I do that the
application author or providers is always the one to blame and
that "well, I just used library xyz" is rarely an effective
defense".

Or, if we know all the answers already and the only purpose of
the document is document the extension to Content-Disposition,
then maybe those who have been suggesting that we not try to
nail down the body part content at all beyond a general
suggestion, e.g., change 

	emoji = emoji_sequence
	emoji_sequence = { defined in [Emoji-Seq] }

to 

 emoji = 
	; whatever you, your users, and the available libraries
	; think is appropriate to put in the content to reflect
  ; a response and that the sender thinks or hopes the 
  ; receiver will be able to display appropriately.

Yes, I see more space between those two options than that above
implies.  But the the point is that we either think it necessary
to define what is really allowed and have the expectation that
the definitions will be enforced and adhered by conforming
implementations (or the libraries they choose to call) or we
don't and are really just hand-waving.  If it is the latter,
let's say that and move on.

> As such, this isn't a valid way of assessing the experiment.
> The goal here isn't to address the many issues with Unicode
> emoji; it's to add a new capability to email. We believe that
> the best mechanism on which to base this new capability is
> Unicode emoji, but that's in large part due to there being no
> viable alternative.

Seems reasonable to me.  See above.

> I completely understand the desire to try and fix problems
> with Unicode in general and problems with Unicode emoji in
> particular. But after watching these attempts  play out over
> and over again, in specification after specification, for the
> past 30 years (yes, it has been that long), and seen the
> results of our attempts to address these issues, I've become
> convinced that this isn't even the right venue, let alone the
> right specification, for that.

And we completely agree about that.  See above.

> I also understand that when you don't see the changes you want
> happening on the Unicode side of things, you want to warn
> everyone about the possible pitfalls. 

Not exactly.  First, while I have tried to keep it out of this
discussion because I don't think it is relevant, I believe that
Unicode has made a sufficient botch of emoji and the associated
picture language that I don't think it could fixed, or even
usefully and significantly changed, even if they wanted to.
Unicode is, for better or worse, the only plausible option we
have today and I think the odds of a better one emerging are
slight to none.  I think we can only figure out what to do with
what is given, work around problems when necessary, and try to
avoid stepping unawares into alligator-infested swamps.  So,
yes, that leads me to warning about possible pitfalls, but it
isn't because there are changes I'd like to see Unicode make in
this area that are not happening.

> But we need to be realistic about what's possible here and
> what's not. For better or worse, anyone implementing this is
> almost certainly going to use some library or other to do all
> the Emoji handling. They'll use someone else's emoji picker to
> select them, they'll use someone else's Unicode display code to

Ok.  Fine (and we agree).  But then let's say that rather than
putting in a piece of syntax, saying "{ defined in [Emoji-Seq]
}" and pretending that is a normative specification when we know
the reality is going to be "defined by whatever library and
emoji picker the implementation chooses or has thrust upon it".

> Absent precise articulaion of things that can be done to
> address specific issues we know exist given such an
> implementation strategy, any text we add is unlikely to have
> any impact. And by the same token, in assesing the
> experiment's results the only thing it's sensible to measure
> is whether or not the specification got the specifics right.

I very nearly agree.  But then we should not pretend to be
specifying something we are not really specifying.  Otherwise,
we are, as you sort of put it elsewhere, specifying an
experiment to which we already know the answer: that almost no
one is going to follow or implement

	emoji = emoji_sequence
	emoji_sequence = { defined in [Emoji-Seq] }

except by dumb luck associated with the libraries and tools they
pick and that there are going to be problems because we know
that already.  But then let's not pretend to specify things as
exactly as the above, by itself, implies that we have done.

> All that said, we do need to know if the capability itself
> causes operational problems, e.g., lots of clients can't
> properly deal with the additional message parts. But this
> needs to be distinct from emoji/Unicode issues.

No disagreement about that either.

>> in an extra issue, one that others have implicitly raised in
>> the last 48 hours: what choices implementations make among
>> those implied by the paragraph starting "The rule base-emojis
>> MAY be used..." in Section 2.
> 
> I think it's approprate to ask for an assessment of how many
> implementations require subsetting, and if they do, what
> subsets they opted to use, and how. But beyond that we're back
> in "things we can't fix" territory.

Agreed.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Mar 2021 16:23:29 -0500

--On Wednesday, 03 March, 2021 10:28 -0800 Dave Crocker
<[email-masked]> wrote:

>...
> Having reflected a bit about this, this morning, I now think
> it reasonable to add a bit more, but not really of the sort
> that has been discussed.

>>   * Technical issues in using emojis within a message body

This is a question, not a request for change, but isn't the
questions of whether a new Content-disposition value will be
accepted and whether implementations will handle an unrecognized
value in a a reasonable way an inherent part of this experiment
and hence a point of concern?

>>   * Does the presence of the Reaction capability
>>      create any operational problems for recipients?

That formulation works for me.

>> Please send comments to [email-masked].

Up to Barry but, if this discussion is considered part of a Last
Call and IESG review in progress, should it not remain on this
list so that, among other things, the IESG sees it?

thanks,
   john

---

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Mar 2021 16:30:52 -0500

Just on the point at the end:

Discussion of the text of this document belongs on the last-call list.
Discussion, later, of how the experiment went and whether we should move to
Proposed Standard with a revised version doesn’t, and I think putting that
back on the rfc822 list is the right approach.  If that leads to a PS
version, we’ll either put it into a working group or point both the
community and the IESG to that list to review/participate i the discussion.

Barry

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Mar 2021 16:36:44 -0500

Sorry, I had taken that "please discuss on" comment as referring
to discussion of the proposed text for the draft and not as part
of that text.

My error and sorry for adding to the confusion and noise.
    john

--On Wednesday, 03 March, 2021 16:30 -0500 Barry Leiba
<[email-masked]> wrote:

> Discussion of the text of this document belongs on the
> last-call list. Discussion, later, of how the experiment went
> and whether we should move to Proposed Standard with a revised
> version doesn't, and I think putting that back on the rfc822
> list is the right approach.  If that leads to a PS version,
> we'll either put it into a working group or point both the
>> accepted and whether implementations will handle an
>> unrecognized value in a a reasonable way an inherent part of
>> this experiment and hence a point of concern?
>> 
>> >>   demonstrate additional security issues?
>> Up to Barry but, if this discussion is considered part of a
>> Last Call and IESG review in progress, should it not remain
>> on this list so that, among other things, the IESG sees it?
>> 
>> thanks,
>>    john
>> 
>> 
>> 
>> 
>> 
>>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2021 14:35:55 -0800

...
> and hence a point of concern?

cf my recent posting about false precision.

> list so that, among other things, the IESG sees it?

sigh.  that line is part of the text going into the draft, to provide a 
venue for feedback after the document is published.  last-call is not an 
appropriate venue for such follow-up messages.

d/

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 4 Mar 2021 08:34:57 +0900

Hello John, others,

Sorry this reply is late; I didn't get around to it yesterday.

> existing text, I'm happy to just let it go.

"implementation of the Unicode Character Database" indeed sounds 
somewhat strange. A first expansion could be "implementation of an API 
that gives access to the character properties defined in the Unicode 
Character Database", which would probably sound a bit more natural.

Such an implementation can be as a direct API (similar to the old C 
stdlib isupper and friends), as part of a regular expression engine, or 
in some other, more targeted form (e.g. some API tailored to IDNs or 
so). Actually implementing it involves downloading and parsing the data 
Unicode provides, selecting the data needed, and converting it to a form 
that can be used by the target environment (e.g. programming language,...).

Hope this helps. Please feel free to ask more if necessary, but 
preferably in another venue.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 4 Mar 2021 20:47:12 +0900

Hello Dave, others,

On 03/03/2021 23:40, Dave Crocker wrote:
> reader.

This may be an okay 50'000 feet high summary, but is in no way 
appropriate for an actual protocol spec. Also, there are many ietf specs 
that use Unicode code points and many parts of Unicode that use the term 
octet. The term octet is as appropriate e.g. for MTU or HTTP 
Content-Length as it is for the result of encoding characters in UTF-8. 
The term codepoit (or code point) is as appropriate e.g. in RFC 3987 as 
it is somewhere in the Unicode spec.

"There may be some benefit of mixing the terms" sounds extremely vague, 
and the text below turns out that way. The connection between these 
terms has to be very precise.

> Consequently, I propose:
>> I would replace "octet" with "code point".  The referenced document 
>> only describes sequences of code points.  The encoding of those into 
>> octets is orthogonal, and will be described by the content-type and 
> forms a single pictograph.

Sorry, this is wrong. The ABNF rule in target Emoji-Seq does not define 
a set of octet sequences. It defines a set of codepoint sequences, and 
whether or how they end up as octet sequences is undefined in that document.

> The BNF syntax used in [Emoji-Seq] differs 

So how do you get octets from those codepoints? You don't say. Please 
just use the wording that Ned provided. That wording makes things clear.

> I find myself wanting to retain octet here.

It would be okay to leave it as is if you make the linkage explicit in 
the previous text by using the text provided by Ned.

Regards,   Martin.

> Again, it makes a linkable