It must be over a year since I last looked at the IANA IDN tables and they have grown massively in that time ➜ iana.org/domains/idn-tables 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. The Registries have a contractual obligation to ICANN to publish the tables. That is a task managed by IANA. 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. On Mon, Feb 26, 2018 at 11:48 AM, Asmus Freytag <asmusf@ix.netcom.com> wrote:
On 2/26/2018 7:51 AM, Andrew Sullivan wrote:
On Mon, Feb 26, 2018 at 01:47:56PM +0300, Maxim Alzoba wrote:
As I understand all IDN tables, which passed 2012 application round are to be allowed to use despite any changes in LGR (it was the part of the discussion when LGRs were established).
Correct. But some people are updating in line with LGR tools already -- particularly when their communities are sensitive to the issues of general-purpose domains and need conflicting uses of the same script. This applies (for instance) to Han, certainly Latin and Arabic, and probably Cyrillic (and maybe even Latin, Cyrillic, and Greek, though I know of nobody who's been that careful yet).
The previous "variants" approach derived from the JET work made the distinction between "blocked" and "allocatable" less plain than it is now, and the inter-writing-system effects of characters is also now plainer and so easier to represent. The JET approach worked quite well for CJK when used in relative isolation, but has limitations when applied more generally, which is why the new approach was worked out.
One interesting development for Chinese is a clever bit of tweaking of the algorithm that defines the set of "allocatable" variants.
The original JET approach was intended to lead to at most three possible labels: one all-simplified, one all-traditional label plus one mixed label (as applied for).
Because some code points have more than one simplified or more than one traditional variant, a simple-minded scheme would allow a combinatorial explosion of allocatable labels in some cases.
The new algorithm is able to limit the number of allocatable labels in these cases to four; fewer in the general case.
This would be a big win, as keeping the number of allocatable variants small has benefits, especially as the number of allocatable FQDN is the permutation of all allocatable labels on each level.
Embedding the reduction into the algorithm has the advantage of making the set of allocatable labels predictable (by evaluating the label against the LGR). The LGR would fully conform to RFC 7940.
The number of blocked variants is still defined by the permutation of all variants that aren't allocatable. For some labels, the numbers can be formidable, but fortunately, there is no need to enumerate them, even for collision testing.
However, even the largest set of blocked variant pales compared to the immense size of the namespace (20,000 code points) to the power of (maximal number of code points in a U-label).
I believe the Chinese Generation Panel is planning a presentation of the scheme at ICANN61.
A./