Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: <draft-klensin-idna-rfc5891bis-01.txt>)

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

--On Saturday, March 10, 2018 09:06 -0400 Patrik Fältström
<[e-mail]> wrote:

> I think we should do some scenario planning here. Remember
> that we do not have a world where IDNA2008 based on Unicode
> 6.x is what people use. People use all different kind of mix
> between IDNA2008, IDNA2003 and Unicode versions. I have myself
> worked with the curl library (that uses libidn) and to be
> honest, I do not think people KNOW what they use. Or they
> know, and they know they violate the rules. For the contracted
> parties, they have the LGR coming down the road anyways, so...
> 
> And *if* we go down this path, is it "enough" to do in the LGR
> (i.e. ICANN) or should IETF do some adoption (and W3C?), or
> should IETF say "we can move forward in a more safe way AS WE
> KNOW ICANN DO LGR"...

As I said at far more length in another note, the LGR is (at
least by its charter/ Procedure) designed for, and applicable
only to, the root.  While those code points would probably be
safe to use in any zone, trying to apply them globally would be
unduly restrictive, would violate the "administratively
distributed hierarchy" principle, and, IMO, just wouldn't fly..
The latter would probably quickly reach the point that attempts
to apply the LGR to labels at the second level and beyond would
encourage non-compliance and daring ICANN to do anything about
it.     

As an example of the overly restrictive part, I assume that the
LGR rules, like the ccTLD Fast Track Procedures, would prohibit
the use of "ур" (U+0443 U+0440) or other permutations of those
characters) in to root on the grounds of either intrinsic
confusability or the potential conflict with the 3166-1 alpha-2
list.  However, if we accept the logic that justifies IDN TLDs,
that sequuence would be acceptable in a subtree of a domain
whose TLD label was in Cyrillic and that published and applied a
policy that its subdomains were entirely Cyrillic.

> Or...

I think the above puts us well into the "or..." range.

best,
   john