[I18ndir] Study Group on Use of Emoji as Second Level Domain

[Martin J. Dürst <[e-mail]>]

Dear I18N Directorate members,

I don't want to interrupt Harald's important work on our review, and 
would like the topic of this mail to be treated as a separate topic, 
with less priority.

Because ICANN meets next week (starting already tomorrow my time, i.e. 
already this Friday for some of you) in Kobe, Japan, I at one point was 
considering attending. I had to abandon that plan because of other 
committments, but as a result of looking at the schedule carefully, I 
found the following:

https://64.schedule.icann.org/meetings/962146
ccNSO: Study Group on Use of Emoji as Second Level Domain

I'm wondering whether anybody (maybe Patrik?) will be attending. I may 
be able to dial in with Adobe Connect, but probably not for the whole 
1.5 hours.

Any hints on which direction to contribute would be appreciated. I can 
imagine any of the following (and more):

- Don't worry, they'll never get anywhere anyway
- Tell them in clear words that they aren't allowed to do that
- Don't bother to tell them, they won't listen and care only about money
- Ask whether they are serious, and what protocol changes they may need
- Tell them about the 'minor' technical points they may not be aware of
- Don't bother with dialing in, the session will be available as a video

As for a summary of the technical situation as far as I know it:

While IDNA 2003 allowed some symbol characters that are now considered 
emoji, IDNA 2008 doesn't allow such characters. I haven't had time to 
check UTR 46 or browsers and other applications. I'm not sure what the 
group plans to discuss.

The LDH principle would exclude emoji the same way it would exclude 
$%#@& and friends. I'm sure I (as well as others) have in the past made 
arguments against Unicode symbols based on the difficulty of entering 
them; in many environments, in particular smart phones, that's no longer 
the case.

Emoji also would present a proofing ground for context-related 
registration restrictions and techniques such as linking and blocking. 
As an example, many things that appear to the user as a single emoji are 
encoded as a sequence of several code points, but not all such sequences 
produce reasonable results. One of the experiences of the Unicode 
Consortium over the last few years is that certain technologies (from 
things such as surrogate pairs upwards) get adopted much more quickly 
when they are needed for emoji than when they are needed for some 
minority language or script.

Similarity is also in the eye of the beholder. As an example, I'd guess 
most people wouldn't have big difficulties to distinguish two emoji 
where one has a "light skin tone" modifier and the other has a "dark 
skin tone" modifier (see 
https://www.unicode.org/reports/tr51/#Diversity). But distinguishing 
between "medium-light skin tone" and "medium skin tone", in particular 
when only seeing one of the pair, will be very difficult. Also, to keep 
all the different variations of smileys apart is a very tough job (at 
least for me, YMMV).

Regards,   Martin.