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

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

> >> On Fri, 26 Feb 2021, Dave Crocker wrote:
> >> I'd flip it around.  What reason do we have to believe that any particular
> >> restricted vocabulary that we might define would be useful to users we
> >> don't know and who may not even speak any language we speak?
> >
> > cf, the reference to established practice, which is distinguished from
> > free-form text, which is what you now seem to be proposing

> I see a rule allowing a string of emoji, which we've heard is problematic,

With precious little evidence to back it up, and no suggestions at all as to a
useful alternative.

Here, why don't you try it yourself? Can you come up with a set of reaction
indicators and a way to structure them which:

(0) are fully and openly specified,

(1) enjoy widespread support in existing UI toolkits, both for display and
    composition, and

(2) can leverage considerable experience using them in similar applications?

I'm betting the answer is no.

Frankly, at this point I'm having a serious case of deja vu. The similarly of
this discussion and the charset discussion during the development and
deployment of MIME is nothing short of uncanny. And we ended up getting it
wrong - mind you, not wrong enough to refuse to accept Unicode and UTF-8 when
they became available, but not after wasting a ton of time, and wrong enough to
encumber our solutions with worthless crap like language indicators that AFAIK
nobody has ever used.

I am not going to make that mistake again.

What we're doing - again - is something the IETF really does have experience in
doing: Letting the best be the enemy of the good. (And this case I happen to
think the best is pure fantasy.)

> and a base-emoji rule which has an unupported assertion that it's five
> emoji developed from existing practice, although I'm not aware of any
> existing application that uses that set.  Do you have a reference?  In the
> apps I use, the set of emoji responses differs from one device to the next
> and is invariably very large, hundreds at least.

It's a very weak may. I think it's useful to have such an example in order to
make it clear that subsetting is allowed. Although a reference for the subset
would not hurt.

> > (which is odd, > given what stage of processing this draft is in.)

> I agree that it was extremely premature to last call this draft.

Sometimes a last call is what's needed to get people to engage. Dave
asked for comments several times, and got U+1F997. What were
we supposed to do?

				Ned

---

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

On 3/1/2021 2:13 PM, Ned Freed wrote:
>> and a base-emoji rule which has an unupported assertion that it's
>> five emoji developed from existing practice, although I'm not aware
>> of any existing application that uses that set.  Do you have a
>> reference?  In the apps I use, the set of emoji responses differs
>> from one device to the next and is invariably very large, hundreds
>> at least.
> 
> It's a very weak may. I think it's useful to have such an example in
>  order to make it clear that subsetting is allowed. Although a
> reference for the subset would not hurt.

Small additional point:

    1.  The base-emoji rule is there to give people something to use if 
they want a set and don't have one of their own.  It has no other role; 
it therefore does not matter where it came from.

    2.  It is intentional that there is no reference provided, because 
providing one would merely create an opportunity to debate whether that 
was the right set to choose.

    3.  If it makes folk feel better, let's call it "daves-emojis" or 
"random-emojis".

If someone want to claim that somehow one or another emoji in that set 
is a problem, they should do that.  If someone want to offer a nifty, 
superior set for the base-emoji rule, they should do that.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 1 Mar 2021 17:59:51 -0500

On Mon, 1 Mar 2021, Ned Freed wrote:

> With precious little evidence to back it up, and no suggestions at all as to 
> a useful alternative. ...

I can see two possibilities.  One is to say it's a single emoji, since 
that seems to be what reaction buttons in existing chat applications do. 
The other is to say that since it's an experiment, allow any UTF-8 string 
and let people see what's useful.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

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

On 3/1/2021 2:59 PM, John R Levine wrote:
>> With precious little evidence to back it up, and no suggestions at 
>> all as to a useful alternative. ...
>
> that seems to be what reaction buttons in existing chat applications 
> do. The other is to say that since it's an experiment, allow any UTF-8 
> string and let people see what's useful. 

John,

You might consider an eye exam, since apparently you can't see the 
possibility that is in the draft actually in front of you. Interesting 
astigmatism there. Or is it just tunnel vision?

And you seem not to have responded to the point that Ned made.

And your preferences seem to be only that, personal preferences. Rather 
than an argument for superior functionality, or unworkability for the 
current draft, or better still, established practice, of the sort the 
current draft represents.

I seem to recall your lobbying for these preferences during the 2-month 
discussion on ietf-822, last Fall, also.  I don't recall their getting 
traction then.

Single vs. multiple choices:  Having the carriage mechanism -- which is 
what this draft for -- permit multiple does not require implementations 
to support that, if they don't want to.  If the 'market' prefers to 
enforce selection of a single choice only, this spec will work just fine 
for them.

Emoji vs. free text. Other than uninterpreted, free text -- ie, no 
semantic context -- there is no existing practice for that.  If you feel 
otherwise, please document it.

d/

---

From: Ned Freed <[email-masked]>
Date: Mon, 01 Mar 2021 17:27:06 -0800 (PST)

> that seems to be what reaction buttons in existing chat applications do.

Ever hear of Slack? It most definitely allows for multiple reaction emoji. And
while I personally loathe Slack, it's (a) A very similar use-case and (b) Not
exactly unpopular.

I believe phpBB allows multiples as well, although I'm pretty sure it's emoji
support isn't Unicode based. With Drupal it depends on what module you use, but
only allowing one seems to be strongly correlated with only allowing a choice
from a small set.

> and let people see what's useful.

I've already explained why I think this is a really bad idea.

				Ned

---

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

> it therefore does not matter where it came from.

I like the simple base-emoji rule.  After all, to support the full set
of emojis as per the UTS51, you need Unicode 13 support, which is
relatively new.

E.g, I wanted to try out the Emoji properties in Perl regexps, and I
found this support was only introduced in Perl 5.32, released in June
2020.  Similarily, GNU libc got Unicode 13 support in August 2020.

So - base-emojis may be helpful to get traction for the extension.  But
the draft only concerns itself with restricting *sending* to base-
emojis.  It does not say explicitly that an implementation which only
understands received base-emojis is allowed or how it should behave
when it processes reaction emojis outside its repertoire.

Possible text, insert new point 4 in processing:

  4. If the part contains code points outside the implementation's
vocabulary, it MAY process them as undisplayable.

In light of this, I think it is a bit unfortunate that support for
base-emojis is not mandated, we can in theory get implementations with
no overlapping emojis in their vocabulary.  In practice, I don't think
this is a problem, however.  There is little or nothing gained from
explicitly leaving out the base-emojis from the implementation's known
set.

> was the right set to choose.

:-D

I like your set!

>     3.  If it makes folk feel better, let's call it "daves-emojis" or 

Perhaps we need a new IANA registry for this?

I jest, I jest!

-- 
venleg helsing,
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Tue, 02 Mar 2021 13:40:35 -0800 (PST)

> of emojis as per the UTS51, you need Unicode 13 support, which is

Let's put this into perspective. Unicode 13 added 5930 characters. The
overwhelming majority of those (4939 characters) were CJK. Only 65 emoji were
added. You can view them here:

   https://unicode.org/emoji/charts-13.0/emoji-released.html

Obviously experiences vary, but none of these are things I've missed having
available to express a reaction.

> 2020.  Similarily, GNU libc got Unicode 13 support in August 2020.

Given that Unicode 13 was released in March, 2020, that's actually quite
impressive.

> vocabulary, it MAY process them as undisplayable.

I think this assigns the base-emoji set a too much importance in the overall
scheme of things. But if the consensus is otherwise, I can live with it.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 03 Mar 2021 00:08:43 +0100

> available to express a reaction.

What?  U+1F9A4 \N{dodo} is highly relevant as a reaction! :)

But I was a bit confused.  For Perl's part, they did not implement
emoji properties until 5.32 as part of their incorporation of Unicode
13, since the Unicode Emoji wasn't included in Unicode proper until
13.0.  However, Unicode Emoji has, as a related standard, had these
mechanisms since its version 2.0 from November 2015.

> Given that Unicode 13 was released in March, 2020, that's actually quite

Well, GNU libc does not have support for the needed parts after all -
just the classic parts of Unicode :/

So...  access to sufficiently good library support for checking the
emoji properties may be spotty.

> scheme of things. But if the consensus is otherwise, I can live with it.

thanks.

-- 
venleg helsing,
Kjetil T.

---

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

Hello Kjetil,

> mechanisms since its version 2.0 from November 2015.

Emoji were always part of Unicode proper, some of them (e.g. the 
snowman) even way before they were called emoji. What changed between 
Unicode 12 and Unicode 13 is the location of some of the property data 
files in the data published by Unicode. That may have motivated Perl's 
change in implementation between these two versions.

[I know this because I'm in charge of the Ruby side of things; I have 
yet to update to Unicode 13.0, and the change in file location is one of 
the items on my plate.]

Regards,   Martin.

---

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

> scheme of things. But if the consensus is otherwise, I can live with it.

Defining a normative core is typically Very Good practice for a 
protocol, to ensure basic interoperability.

At this stage, however, I think we do not know enough about the way this 
will get used to be able to assign normative status to a core set of 
emojis.  "Basic interoperability" here has more to do with humans than 
computers.

If the Experiment produces clear guidance we can easily incorporate it 
to make give normative status to support for a core set of emojis.

d/

---

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

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

>>>    4. If the part contains code points outside the
>>>    implementation's vocabulary, it MAY process them as
>>> undisplayable.
>> I think this assigns the base-emoji set a too much importance
>> in the overall scheme of things. But if the consensus is
>> otherwise, I can live with it.
> 
> 
> Defining a normative core is typically Very Good practice for
> a protocol, to ensure basic interoperability.
> 
> At this stage, however, I think we do not know enough about
> the way this will get used to be able to assign normative
> status to a core set of emojis.  "Basic interoperability" here
> has more to do with humans than computers.
> 
> If the Experiment produces clear guidance we can easily
> incorporate it to make give normative status to support for a
> core set of emojis.

I agree but, if you expect the Experiment to possibly produce
clear guidance about what, if anything, should be in a
normative, possibly minimum, set of emoji to be supported,
should not one of the questions be "If you know and it seem
important, what emoji are you supporting and which ones are your
users actually using?" or something like that?

   john

---

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

> users actually using?" or something like that?

cf my recent posting about false precision.

d/