Re: [Idna-update] [Ext] FWD: Expiration impending: <draft-klensin-idna-rfc5891bis-01.txt>

[John C Klensin <[e-mail]>]

--On Monday, March 5, 2018 16:23 -0500 Suzanne Woolf
<[e-mail]> wrote:

> Patrik,
> 
> That was before my time on the IAB, sorry.
> 
> But as it happens, I'm looking at an update to the IAB
> statement, so have been pondering this very question. Do you
> think that
> https://www.ietf.org/id/draft-klensin-idna-5892upd-unicode70-0
> 5.txt
> covers the options reasonably well? 

Suzanne,

Patrik may have a different answer, but, as the author of that
document, let me provide two opinions:

(1) No.  There is a newer version that covers more of the issues
and has a better discussion of options, but I have no intention
of posting it before there is a plan about how the document will
be processed.   I believe I told the IAB that while Andrew was
still Chair and told the late and lamented IAB I18N Program that
while Andrew was still chairing it.   I do have some ideas about
how it, and some other relevant documents might be processed,
but, until there is evidence that someone in "the leadership" is
interested, it has seemed to me that trying to write those
things down (or, e.g., flying to London to try to discuss the
issues and possibilities) would be a waste of time 

My amusement level is decreasing rapidly about the IAB's going
off and discussing issues like this internally without making
any attempt to involve members of the community who have actual
expertise and a history of doing most of the work.  In recent
months, I've been reminded by four well-known colleagues (two of
them former IAB Chairs) that the IAB got itself into a situation
in the early 1990s in which the community concluded that it had
gotten out of touch, thought its opinions were sufficient onto
themselves, and that wasn't interested in listening to experts
in the community who were not on the IAB.  Whether that
characterization was accurate or not and whatever one things of
the outcomes of the changes that followed, the results clearly
did not go well for the IAB or much of its then-membership.

(2) As much to Kim as to you... Although the IAB statement was
based on a limited understanding of only part of the problem,
the underlying problems, as described in the unposted
draft-klensin-idna-5892upd-unicode70-06.txt and, to a
considerable degree, in the expired but available
draft-klensin-idna-5892upd-unicode70-05.txt, are unchanged.
Given some of the behavior being exhibited by selected TLD
registries (I note from recent news that one of them is not only
selling names that are invalid under IDNA2008 (and that would
remain invalid if the tables were updated to Unicode 10.0
without changes being made to the Standard itself) but that
their record-keep systems are weak enough that they managed to
sell the same invalid strings multiple times and had to withdraw
the sales and that they are apparently also running a futures
market in such names using graphemes that are expected to be
assigned as code points in Unicode 11 and 12.  

There is another issue with Unicode 7 onward as far as domain
names are concerned.  Most, if not all, of the scripts that are
used for contemporary, widely-used, languages that are
well-represented on the Internet were coded long before now.  As
a result, most of the characters added in Unicode 7 and later
fall into one of three categories:

(i) Scripts that are less well-known in the Internet community
and which therefore carry even greater risk of "surprises"
(including but certainly not limited to, confusion with other
code points, issues with combining characters and what
normalization does or does not do, and special rendering issues)
if used in domain names.   Andrew's comment about this being
hard apply much more strongly to such scripts than to
better-known ones.

(ii) Letter- or digit-like characters added to existing scripts.
These potentially raise all of the issues listed above but, if
added to replace or supplement characters or character sequences
that are in use already, the may raise issues similar to the
relationship between Traditional and Simplified Chinese.

(iii) Characters (or, more precisely code points) that would not
qualify for use in domain name labels because of the properties
Unicode assigned to them.  That list includes emoji (because
they are symbols) but is definitely not limited to them.

Now, there are constituencies within ICANN would would like all
of those characters added and to start selling them.  But it
would be irresponsible (at best) on the IETF's part (or that of
ICANN) to encourage such things.

    john