Re: [DNSOP] Status of IDNA

[Andrew Sullivan <[e-mail]>]

On Thu, Apr 13, 2017 at 02:39:36AM +0000, Viktor Dukhovni wrote:
> 
> Well, IIRC they sensibly converged on a case-folded normal form
> that ensures that https://Духовный.org maps to the same underlying
> wire-form domain as https://духовный.org, i.e. both result in
> queries for xn--b1adqpd3ao5c.org.  AFAIK, those would generally be
> different domains under IDNA2008.

They would be different domains because the first of them is
DISALLOWED.  But everyone knew, when making IDNA2008, that removing
the case mapping from the protocol meant that clients needed to do it
before starting.  That's what https://tools.ietf.org/html/rfc5895 was
all about (a document that could have moved faster if some
participants had collaborated more enthusiastically instead of, well,
going away and making their own protocol).

One of the problems we had with IDNA2003 was that the protocol did the
caseFold operation.  The difficulty there was that there was no way to
pay attention to locale or other information that might tell you the
right thing to do, because caseFold is not nearly as simple as ASCII
always pretended it was.  IDNA2008's answer was to kick this problem
out of the protocol and into user agents, which were supposed to do
this in a sensible way.  If UTS#46 had restricted itself to that kind
of job, it could well have been an enormous contribution to the
practical use of IDNs.  Unfortunately, it didn't do just that.

> While is true that UTS#46 maps <U+1F4A9>.org to xn--ls8h.org, (see

In the way I'm using the term, that's not mapping, that's re-encoding.
The idea of "mapping" is to substitute in some more or less
predictable way some set of Unicode code points for some other set of
Unicode code points.  Then you can run the resulting final string
through the IDNA2008 algorithm.  

The problem with treaing U+1F4A9 as an acceptable character for an
identifier is not in itself -- maybe it is fine on its own -- but that
it is part of a class of characters that do not have normalizations
and are not letters or digits.  The IETF took seriously the advice
from UTC that we should use the stable categories that UTC had
invented, and derive our properties from those.  We did so, and no
emojis are in the categories that we used for the derivation.  It is
therefore more than a little frustrating to see the same UTC now
recommending that such characters be used in identifiers on the
network.  Such use is particularly bad with emojis because they have
no normalization either, and they interact in some ways with ZWNJ.
They provide a completely new playground for attackers to use in
phishing and so on, and we already have _enough_ trouble with that
without inventing new ways to cause ourselves grief.

Anyway, I doubt very much that DNSOP is the list where this ought to
be discussed (idna-update is still an open list, as is the IAB's
i18n-discuss list even though the program is closed, and precis is
still an active WG last I checked).  But any sentence about
internationalization that involves the concept "just do _x_" is, I
think, already too naïve.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]