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

From: Martin J. Dürst <[email-masked]>
Date: Fri, 8 Mar 2019 10:15:53 +0000

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.

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 08 Mar 2019 14:16:31 +0100

On 8 Mar 2019, at 11:15, Martin J. Dürst wrote:

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

Yes, I am participating.

What should be known is that this initiative by ccNSO is triggered by some work by many, including SSAC that issued a report on security issues with emojis (or non-conformant to IDNA2008). ICANN Board took up the baton and said in some words "one should be conformant to IDNA2008" but at the same time identified some issues in some gTLDs and some ccTLDs, and asked gNSO and ccNSO to look in to the issues, and liaise with SSAC.

The gTLD work more or less concluded that all contracted parties do have conformance with IDNA2008 in the contract (although I personally comment that there might be some issues with domain names registered before that contract was signed).

In ccNSO it is more complicated as there is no contractual agreements. Just coordination.

There is a draft document from the ccNSO working group that is to be discussed, and that describes the situation.

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

Unclear to me. I will be there on site.

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

Thanks, Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 08 Mar 2019 22:22:22 +0900

Btw, the Observations in the current version of the report is:

Observations:
● Potential for confusability with emoji is significant but is currently contained given the small number of registries which accept the registration of domain names which include emoji.
● Some in the emoji domain name industry have proposed Whitelisting as a potential solution to address confusability
● In addition to the confusability issues, SSAC has pointed out there is no agreed to way of pronouncing emoji or otherwise representing them in a way that they can be managed by (for example) various aids people with disabilities uses.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Mar 2019 09:45:04 -0500

A few small observations to supplement Patrik's two messages,
partially because the first point below interacts with what
draft-faltstrom-unicode11 should say...

(1) Unless ICANN decides to depart from IDNA2008, allowing emoji
in domain names would require a substantive change to RFC 5892
and probably 5891.  Perhaps one should not extrapolate, but,
given our inability to engage on even relatively minor
clarifications, I'd a little skeptical about the IETF being able
to do that.  From a technical standpoint, such a change would
either require allowing all So code points or would require
continuing to disallow that general category but then allowing
emoji by exception.  Such an exception, whether by block or by
enumerating code points, would almost certainly lead to a
requirement for normative updates to 5892 with every version of
Unicode and more pressure to do them quickly, not just
statements that nothing of significance has changed.

(2) In addition to the issues mentioned by Patrik about
representations of individual characters, emoji combining
sequences are defined by Unicode, but are defined without
normalization or rendering rules that would facilitate
unambiguous comparison, either of strings by computers or by
people looking at displays.   To the extent to which we consider
non-decomposing code points a problem to be concerned about,
even if all we do is to put those code points on a "troublesome"
list, emoji strings would pose a far more challenging set of
issues.  The combining problem could be eliminated by
prohibiting emoji-containing labels of more than one code point,
but not only would that contradict the long-standing principle
of avoiding single-character labels (because of the original
reason for that principle), but, despite what I gather is
current practice, I can't imagine those who are anxious to sell
domain names with emoji in them would allow such a restriction
for very long.

(3) I've looked briefly at UTR#46 for Unicode 12
(https://www.unicode.org/reports/tr46/ and
https://unicode.org/Public/idna/12.0.0/IdnaMappingTable.txt and
it still allows emoji (or at least a considerable number of them
-- I haven't spotted any exceptions).  Because (except for
earlier emoticons) they are prohibited by IDNA2003 as well as
IDNA2008, there should be no further pretense that it is about
"transition".  Instead, it is a third, orthogonal, standard.  It
also causes a nasty problem (and ambiguity in that spec) for ZWJ
and JZNJ, the former of which has a special interpretation for
emoji that I'll leave as an exercise.

Madness.  I hope those who are at the ICANN meeting,
particularly Harald (as IETF liaison) and Patrik will be
explaining that to relevant parties.

    john

--On Friday, March 8, 2019 10:15 +0000 "Martin J. Dürst"
<[email-masked]> wrote:

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

---

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 08 Mar 2019 09:59:16 -0500

> earlier emoticons) they are prohibited by IDNA2003

not sure that IDNA2003 prohibited them specifically because at that 
time, we were using Unicode 3.2 as the base and emojis did not exist. 
And all « Unassigned » code points were giving some direction 
(store/query) but was underspecified essentially.

> as well as
> "transition".  Instead, it is a third, orthogonal, standard.

The Unicode IDNA mapping table such as 
https://unicode.org/Public/idna/12.0.0/IdnaMappingTable.txt but all 
versions down to 6.X  (see 
https://unicode.org/Public/idna/6.0.0/IdnaMappingTable.txt) actually 
make emojis « valid » for the purpose of TR46. So this is not so 
much news.

Marc.

> It
> -- 
> I18ndir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i18ndir

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Mar 2019 12:07:50 -0500

Marc,

I was trying to be brief in the hope of having time to look
carefully at Harald's note today but, to clarify...

--On Friday, March 8, 2019 09:59 -0500 Marc Blanchet
<[email-masked]> wrote:

>> https://unicode.org/Public/idna/12.0.0/IdnaMappingTable.txt
>> and it still allows emoji (or at least a considerable number
>> of them -- I haven't spotted any exceptions).  Because
>> (except for earlier emoticons) they are prohibited by IDNA2003
> 
> not sure that IDNA2003 prohibited them specifically because at
> that time, we were using Unicode 3.2 as the base and emojis
> did not exist. And all « Unassigned » code points were
> giving some direction (store/query) but was underspecified
> essentially.

One can certainly call it "underspecified", but it seems to me
that the following are/were perfectly clear in IDNA2008, at
least for strings accepted by registries for delegation and
storage in the DNS, which is, AFAIK, the only issue before
ICANN.   By definition, such as string is a "stored string" (see
Section 4(1) of RFC 3490 and Section 7.2 of RFC 3454
(Stringprep).  The latter includes the statement "(stored
strings MUST NOT contain unassigned code points,...", which, to
me, is about as close to "prohibited" as the IETF gets.
Obviously that might be different if StringPrep (and possibly
NamePrep) had been updated after Unicode 3.2, but they weren't,
so any claim for validity under IDNA2003 takes us into the vary
strange territory of local interpretations and extrapolations of
what the IDNA2003 tables might have been with speculative
updates.  That, in turn, leads us down the path to many
alternative IDNA alleged standards (not just IDNA2003, UTR#46,
and IDNA2008, but many, many, versions and interpretations of
what an IDNA2003bis might look like) -- a subject about which
Patrik, SSAC, and others have written at length (independent of
my concerns and, if you like, ranting on the subject).

> https://unicode.org/Public/idna/12.0.0/IdnaMappingTable.txt
> but all versions down to 6.X  (see
> https://unicode.org/Public/idna/6.0.0/IdnaMappingTable.txt)
> actually make emojis « valid » for the purpose of TR46. So
> this is not so much news.

Yes.  I didn't mean to imply that it was new.  I have been
hoping that, with each recent version of UTR#46 and its tables
and additional evidence about their unsuitability for
identifiers (including, fwiw, their exclusion by UAX#31 [1])
that the decision to treat emoji as valid in UTR#46 would be
reversed or at least supplemented there by a strong cautionary
note.  While I gather that the stability rules would prefer an
actual change from "valid" to "disallowed" without some very
fancy footwork, nothing I know of would prevent such a warning.
Those changes haven't happened.   I suppose I might have
inserted "still" in my comment but, the more UTR#46 is pushed as
an alternate or supplemental standard relative to IDNA2008, the
more I think we (and ICANN, etc.) need to be aware of the
divergence.

best, 
   john

[1] Yes, I'm aware of the claim that different (and less
restrictive) rules are appropriate for IDns relative to UAX#31
"identifiers" because the latter are about programming language
identifiers, but I just don't buy it.  It would probably be
reasonable if one believes that DNS names are not identifiers
(or intended for use as identifiers) but are, instead, value or
vanity tokens to be bought and sold without concern about
identifier usability.   If one considers DNS names as
identifiers for use by end users, many of whom may have little
knowledge of what is going on, then there is a strong case that
rules for what is allowed in those identifiers should be more
restrictive, not less, than rules for identifiers to be used by
programmers-specialists in programming languages.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 09 Mar 2019 09:30:48 +0900

On 8 Mar 2019, at 23:45, John C Klensin wrote:

> A few small observations to supplement Patrik's two messages, partially because the first point below interacts with what
> (1) Unless ICANN decides to depart from IDNA2008, allowing emoji in domain names would require a substantive change to RFC 5892 and probably 5891.  Perhaps one should not extrapolate, but, given our inability to engage on even relatively minor
> clarifications, I'd a little skeptical about the IETF being able to do that.  From a technical standpoint, such a change would either require allowing all So code points or would require
> continuing to disallow that general category but then allowing emoji by exception.  Such an exception, whether by block or by enumerating code points, would almost certainly lead to a
> requirement for normative updates to 5892 with every version of Unicode and more pressure to do them quickly, not just

FWIW, I do not see ICANN moving away from IDNA2008, the contrary. The board decision was firm, and now I can find it (not being on 30' feet).

<https://www.icann.org/resources/board-material/resolutions-2017-11-02-en#1.e>

Resolved (2017.11.02.09), the Board hereby directs that conformance to IDNA2008 and its successor will continue to be a necessary condition to determine valid IDN TLD labels.

Resolved (2017.11.02.10), the Board requests that the Country Code Names Supporting Organization (ccNSO) and the Generic Names Supporting Organization (GNSO) engage with the SSAC to more fully understand the risks and consequences of using a domain name that includes emoji in any of its labels, and inform their respective communities about these risks.

Resolved (2017.11.02.11), the Board requests that the ccNSO and GNSO integrate conformance with IDNA2008 and its successor into their relevant policies so as to safeguard security, stability, resiliency and interoperability of domain names.

Resolved (2017.11.02.12), the Board directs the ICANN CEO, or his designee(s), to engage with gTLD and ccTLD communities on the findings and recommendations in SAC095.

> unambiguous comparison, either of strings by computers or by people looking at displays.   To the extent to which we consider non-decomposing code points a problem to be concerned about, even if all we do is to put those code points on a "troublesome"
> list, emoji strings would pose a far more challenging set of issues.  The combining problem could be eliminated by
> prohibiting emoji-containing labels of more than one code point, but not only would that contradict the long-standing principle of avoiding single-character labels (because of the original reason for that principle), but, despite what I gather is
> current practice, I can't imagine those who are anxious to sell domain names with emoji in them would allow such a restriction for very long.

Agree.

> https://unicode.org/Public/idna/12.0.0/IdnaMappingTable.txt and it still allows emoji (or at least a considerable number of them -- I haven't spotted any exceptions).  Because (except for
> earlier emoticons) they are prohibited by IDNA2003 as well as IDNA2008, there should be no further pretense that it is about "transition".  Instead, it is a third, orthogonal, standard.  It also causes a nasty problem (and ambiguity in that spec) for ZWJ and JZNJ, the former of which has a special interpretation for emoji that I'll leave as an exercise.
>

Thanks. And yes, we need all help we can to ensure the very very few that do allow emoji in some way to really be outliers. SSAC have been working hard to get the above board resolutions through in 2017, including as you can see that it not only talks about emoji, but also alignment with "IDNA2008 and its successor" which cements ICANN should not start to play the game of standards, but reference what IETF is doing.

Yes, that puts the hot potato back to here (i.e. IETF)...

   Patrik

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 9 Mar 2019 03:28:35 +0100

The report to the board here at ICANN is that the study group is trying
to gather information on what the 18 ccTLDs that allow emoji
registration are doing to contain the damage from them, and that ICANN
is still solidly supporting restriction of 2nd level domains to the
IDNA2008 repertoire - but has no power to make policy for ccTLDs, the
strongest it can do is recommendations.

-- 
Surveillance is pervasive. Go Dark.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 18 Mar 2019 10:10:01 +0000

Hello Patrik, others,

I would like to thank you and others very much for answers to my mail on 
this subject. I was very glad to see that the subject is in best hands 
when I got the answers. I want to apologize again for interrupting our 
main work.

Regards,   Martin.