[Ext] RE: emoji (was Re: I-D Action: draft-klensin-idna-rfc5891bis-00.txt)

[John C Klensin]

Shawn,

I don;t think either of us is likely to convince the other (or
anyone else) and much of what we are talking about isn't an IETF
problem unless someone has a plan about hiring Protocol Police,
so it is probably wise to start wrapping the conversation up.
Two comments below, just to try to understand where we differ.

--On Wednesday, 22 March, 2017 02:18 +0000 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

> I'm not suggestion "do nothing", however I do see much of the
> burden being on the registrar.  I don't think the client
> applications in particular should be overly critical.  If the
> registrar of .gr thinks something is useful that the registrar
> of .ru does not, then I don't think it's the browser's place
> to say that whatever.gr isn't a read domain.

Things may have changed when I wasn't looking, but my impression
is that Microsoft's long-standing strategy via-a-vis IDNA has
been to try to perform a language (or language and script) match
between the domain name and whatever languages the user has
configured into her system.  If that match fails, the user sees
A-labels.  Whether A-labels without addition information are
better or worse than an explanation of why a requested domain
name was unacceptable is an interesting human interface question
to which I don't have the answer.  But, if that policy
continues, real usability of emoji would require either
classifying them as a language and presumably allowing users to
configure their acceptability or making them part of every
"language".   In either case, unless you wanted to allow all
symbols in domain names, you'd need to maintain your own list of
what codes points, exactly, fit in the emoji category, with all
that implies about decision-making and maintenance.  Maybe not a
huge deal, but an issue nonetheless.

>> From the client perspective I think that if the DNS record
>> exists, then we should probably use it (with, of course,
>> whatever other checks we want to do to ensure that it's safe,
>> which, for us, are also things we do for all-ascii names and
>> often the user can override if they disagree with the browser
>> warning).

The other issue is that, while the Internet is, to a
considerable degree, built on assumptions of mutual
responsibility and cooperation, something that would encourage
"trust the registrars and registries", we know from experience
that there is a large population of registrars out there who
will register anything they can sell and, to all appearances,
who consider confusion and the risk of false positives to be
important parts of their business model.   In that situation,
applying those assumptions of reasonable behavior is
unreasonable and it is appropriate for the rest of us to try to
block at least the most obvious cases, even if we cannot
anticipate and try to block every case.  It is also appropriate,
and important precisely because of your (and others) observation
that some of these folks will just ignore us if we tell them
"no", that the community sort out some way to start holding
those registrars and registries accountable.   This is an ICANN
problem, not an IETF one, and it is intensely political, but,
while I don't see it as an appropriate topic for this list, need
to be addressed nonetheless.  Some of us are working on that,
and the draft that started this thread is part of that effort.

YMMD, but that is where I'm coming from.

  best,
   john