<div dir="ltr"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">It must be over a year since I last looked at the IANA IDN tables and they have grown massively in that time ➜ </span><a href="http://iana.org/domains/idn-tables" target="_blank" style="color:rgb(17,85,204);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">iana.org/domains/idn-tables</a></blockquote>Actually, all new TLD applicants were required to submit their language tables during the application window.  Part of the pre-delegation test is to test the registry function against the rulesets in the tables.<div>The Registries have a contractual obligation to ICANN to publish the tables. That is a task managed by IANA.<br>IANA has finally caught up with the publication of these tables, and that is why it appears to be a massive growth in a short period of time. As a member of the CSC (tasked with oversight of the IANA function), we are now monitoring the "speed" at which submitted tables get approved and then published on this site.<div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 26, 2018 at 11:48 AM, Asmus Freytag <span dir="ltr"><<a href="mailto:asmusf@ix.netcom.com" target="_blank">asmusf@ix.netcom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2/26/2018 7:51 AM, Andrew Sullivan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Feb 26, 2018 at 01:47:56PM +0300, Maxim Alzoba wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I understand all IDN tables, which passed 2012 application round<br>
are to be allowed to use despite any changes in LGR (it was the part of the<br>
discussion when LGRs were established).<br>
</blockquote>
Correct.  But some people are updating in line with LGR tools already<br>
-- particularly when their communities are sensitive to the issues of<br>
general-purpose domains and need conflicting uses of the same script.<br>
This applies (for instance) to Han, certainly Latin and Arabic, and<br>
probably Cyrillic (and maybe even Latin, Cyrillic, and Greek, though I<br>
know of nobody who's been that careful yet).<br>
<br>
The previous "variants" approach derived from the JET work made the<br>
distinction between "blocked" and "allocatable" less plain than it is<br>
now, and the inter-writing-system effects of characters is also now<br>
plainer and so easier to represent.  The JET approach worked quite<br>
well for CJK when used in relative isolation, but has limitations when<br>
applied more generally, which is why the new approach was worked out.<br>
</blockquote>
<br></span>
One interesting development for Chinese is a clever bit of tweaking of the algorithm<br>
that defines the set of "allocatable" variants.<br>
<br>
The original JET approach was intended to lead to at most three possible labels:<br>
one all-simplified, one all-traditional label plus one mixed label (as applied for).<br>
<br>
Because some code points have more than one simplified or more than one traditional<br>
variant, a simple-minded scheme would allow a combinatorial explosion of<br>
allocatable labels in some cases.<br>
<br>
The new algorithm is able to limit the number of allocatable labels in these cases<br>
to four; fewer in the general case.<br>
<br>
This would be a big win, as keeping the number of allocatable variants small<br>
has benefits, especially as the number of allocatable FQDN is the permutation<br>
of all allocatable labels on each level.<br>
<br>
Embedding the reduction into the algorithm has the advantage of making<br>
the set of allocatable labels predictable (by evaluating the label against the LGR).<br>
The LGR would fully conform to RFC 7940.<br>
<br>
The number of blocked variants is still defined by the permutation of all variants<br>
that aren't allocatable. For some labels, the numbers can be formidable, but<br>
fortunately, there is no need to enumerate them, even for collision testing.<br>
<br>
However, even the largest set of blocked variant pales compared to the<br>
immense size of the namespace (20,000 code points) to the power of<br>
(maximal number of code points in a U-label).<br>
<br>
I believe the Chinese Generation Panel is planning a presentation of the scheme<br>
at ICANN61.<span class="HOEnZb"><font color="#888888"><br>
<br>
A./<br>
<br>
</font></span></blockquote></div><br></div>