Subject: Re: [Last-Call] Barry Leiba's Discuss on draft-crocker-inreply-react-08: (with DISCUSS)

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Feb 2021 08:49:44 -0800

Barry, et al,

On 2/24/2021 5:56 AM, Barry Leiba via Datatracker wrote:
> There were Internationalization issues raised by John Klensin and Patrik
> Fältström that need to bbe addressed, and I haven’t seen a response to them
> yet.  The primary one involves cross-cultural understanding of the meaning of
> emoji symbols, and, thus, weather it makes sense to use the emoji symbols
> themselves as protocol elements, rather than defining specific protocol
> elements and letting the implementation select emoji based on regional/cultural
> custom.

FORM:

 1. Copying the last-call list, to permit public participation in this
    Discuss
 2. For clarity and accuracy, a reference to prior online activity
    should point to the specific activity that is meant, rather than
    leaving the reader -- and, of course, worse, the author -- to guess
    what the reference is to, as I am having to do here. And the
    guessing is made more complicated when there are multiple possible
    venues, as there almost always is.  Note that neither John nor
    Patrick posted comments on the react- draft to the last-call mailing
    list.
 3. For the reference to John's concern I am guessing that your
    reference is to his only posting on the draft, in the ietf-822
    mailing list:
    https://mailarchive.ietf.org/arch/msg/ietf-822/hiuC3SbGvGhS0j_vAaEXAk3Hiu8/
 4. Of the 87 messages concerning the react- draft in the ietf-822
    mailing list, none is from Patrick.  So I can't even guess at the
    basis for your referencing him.
 5. John's note does not contain anything that seems to relate to the
    concern you raise.

SUBSTANCE:

Discussion of the draft quickly included a focus on I8N issues. This 
produced major improvements to the draft (and the addition of two 
co-authors.)

The question of flexibility in choice of emoticon vocabularies was 
discussed.  As I recall, the draft offered a small set of emoticons as a 
'core' set, but the draft didn't make clear it's role.  The current 
draft does.  In particular it clarifies that that small set is entirely 
optional and is provided for convenience. The relevant text is:

> 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 intended for similar 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.

Please especially note the last clause of the last sentence.

This leaves me unclear what the specific concern is that you have for 
the draft and, obviously, what would satisfy the concern.

To the extent that you might be questioning the spec's 'restricting' to 
only emojis, they are a widely-used convention; to the extent some 
groups want to use some other construct, they are playing in an entirely 
different sandbox.  Revising the specification to cover them will likely 
look like the generality of a MIME body-part.

By way of seeking some comfort in the generality of the current 
approach, I came across:

    https://emojipedia.org/chinese-new-year/

and clicked down to Moon Cake, to focus on a common cultural reference:

    https://emojipedia.org/moon-cake/

That page includes:

> /Moon Cake/ was approved as part of Unicode 11.0 
> <https://emojipedia.org/unicode-11.0/> in 2018 and added to Emoji 11.0 
> <https://emojipedia.org/emoji-11.0/> in 2018. 

Which should add some comfort to 'restricting' the specification to use 
of Unicode emojis.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Feb 2021 12:20:43 -0500

> Copying the last-call list, to permit public participation in this Discuss

Thank you.

> For clarity and accuracy, a reference to prior online activity should point to the specific activity that is meant, rather than leaving the reader -- and, of course, worse, the author -- to guess what the reference is to, as I am having to do here. And the guessing is made more complicated when there are multiple possible venues, as there almost always is.  Note that neither John nor Patrick posted comments on the react- draft to the last-call mailing list.

I'm sorry; this is my error: I hadn't noticed when I discussed this
with John and Patrik, but it was posted to the IESG, and not to a
public list.  I will ask them to engage in this thread.

The substantive part -- at least, the part that I think needs to be
discussed -- is this:

>>> If people want to send a "positive reaction" or "agree", that
>>> is not in all cultures using the same graphical symbol. My
>>> point was that if there was to be a "positive reaction" to be
>>> sent back as a response to an email, then that signal is to be
>>> sent back, but then what is graphically displayed might have
>>> to be different depending on culture.
>>>
>>> My example was the checkmark and x which has different meaning
>>> in Sweden and USA. The opposite meaning actually.
>>
>> To be sure I understand what you wrote -- because it may be
>> important elsewhere even if not to this spec -- if one starts giving
>> names to emoji that are not their standard Unicode names, e.g.,
>> "agree", then one should consider specifying alternative code points
>> and have some words about locale.
>
> Correct.
>
> If you take the "check mark" U+2713. That means in Sweden "Error" or
> "wrong". If you for example correct a series of questions in Sweden,
> the check mark means "zero points", "wrong" or "error". An "x" or "R"
> means "correct".
>
> In the US and Canada I have seen "check marks" meaning "ok", "done",
> "correct".

My response to that was this:

> That's an interesting wrinkle, which might speak to having (at least
> as an option) a verbal reaction, which could be rendered with an emoji
> character chosen within cultural context.

I know, for example, that the common "thumb up" gesture is offensive
in Iran, and the common gesture of making a circle with thumb and
index finger is "OK" in the U.S. and offensive in Brazil.

When someone clicks a "thumb up" in, say, Facebook, Facebook doesn't
store an emoji symbol as a reaction: it stores an indicator of a
positive reaction, and displays it in the UI as a symbol... and that
display choice can be localized.

I wonder, then, if it doesn't make more sense to send reactions as
defined protocol elements that can be localized, and a "Yes!" reaction
could show as a thumb-up emoji in locales where that's appropriate,
and as something else elsewhere.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Feb 2021 09:35:30 -0800

> and as something else elsewhere.

Barry,

Thanks for the clarification.  And, in fact, I now recall seeing this 
concern, but not by whom or where.

In any case, it's certainly an interesting conceptual issue.

It is also a completely different task than the current one has undertaken.

A notation for shared affect semantics could be a fun effort.  Not for 
the IETF, but for some group.  And 'fun' doesn't mean 'productive'. 
It's the sort of effort that is appealing but extremely difficult, for 
standardization.

Rather, the current effort seeks only to document and, eventually, 
standardize, *existing practice*, albeit from a different service 
environment.  This is always easier and more pragmatic.

That's not to deny that appeal of what you describe, merely that what 
you have described is a very different -- and far more difficult -- task.

There are a number of times, over the years, where similar choice has 
been made.  DNS country codes come to mind.  The thinking then proved 
quite useful and is, I think, the same here:  Some other group has a 
serious effort to standardize a difficult construct.  So let's just use 
their work.

That's what the current specification does.

d/

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Feb 2021 10:33:16 -0800 (PST)

> It is also a completely different task than the current one has undertaken.

It's also a draft of a prospectus for a potential series of research projects,
some of which nobody would dare undertake in the present political climate. It
isn't close to a research project, let alone an experiment. And it's light
years away from a possible standard.

Let's think about this for a moment. There are basically two ways to do this
with any sort of generality, one using existing emoji and the other not:

(1) Define a set of meta-emoji that map to specific emoji in a
    culture-specific way, and

(2) Develop a more abstract way of defining a set of semantic units
    repesentable in pictoral form and then develping culture-specific
    pictograms that actually experss them.

I'll first note that both of these approaches depend on there being some sort
of culture registry. Given that what one some people think defines a culture is
taken by the practitioners of that culture as a highly offensive
characterization, lots of luck doing that. (On a personal note, this Okie
doesn't much care for the term or the grouping it defines, its legitimacy as a
shared culture notwithstanding. A Boont may well feel differently about it, but
I'm not a Boont.)

But let's ignore the registry issue for a moment. (1) is principle doable,
although I'd implement it by documenting the reverse mapping and then inverting
it. But now you have something that has a lot in common with Han unification.
And we all know how that went, as well as how futile our attempts were to help
out with tagging so different pictograms could be used.

As for (2)... you would first have to define an appropriate universal semantic
space, in the process deciding whether or not to include pictographs like, say,
"I Can't Breathe Barney". Once this space is defined you would think have to
parameterize and discretize it in some way. I can already hear the linguist's
laughter.

Looks to me like a general approach is not in the offing. How about a more
constrained approach, like the limited set of indicators provided by some
interfaces?

First of all, I don't think you're going to get much past a dozen or so
indicators before you run into trouble. And there are countless use-cases for
reactions where a limited set of indicators isn't going to cut it. And given
that very limited set is almost certainly representable in a fashion acceptable
to most cultures using existing emoji - why not only allow that limited set in
your application if that's a requirement? (And if some of those emoji are
actually missing, well, that's what codepoint additions are for.)

> It's the sort of effort that is appealing but extremely difficult, for

Dave, ever the optimist.

> serious effort to standardize a difficult construct.  So let's just use

Language codes are probably a better example - the fights over some of those
were epic. (And for all I know are still happening - I dropped out of that
discussion many years ago.) And even once we had them, getting people to use
them for pictogram selection just didn't happen.

> That's what the current specification does.

And IMO all it should do.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Feb 2021 14:37:08 -0500

Ned, so I'm clear here:
Are you supporting the Experimental protocol as specified?

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Feb 2021 11:46:51 -0800

> Are you supporting the Experimental protocol as specified?

If a co-author doesn't support a draft and it's status and especially if 
they haven't previously expressed that concern -- which he hasn't -- 
we've got bigger problems.

d/

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Feb 2021 14:11:22 -0800 (PST)

> Are you supporting the Experimental protocol as specified?

??? Of course I support it. My comments below were focused entirely
on the proposal to expand the scope of the project to include some kind
of mapping in an attempt to solve the "different pictographs mean different
things to different people" problem. Which is the kind of problem I enjoy
discussing, but actually trying to solve, not so much.

				Ned