Summary

  • ICANN’s 5 October release adds Javanese and Unified Canadian Aboriginal Syllabics reference rules and updates seven related rules; cross-script variants make the release a connected change set rather than two isolated additions.
  • The second-level rules guide registry IDN-table design and review. Their coverage counts do not establish top-level delegation, universal application support or real-world adoption.

Analysis

A language list can look like a catalogue. ICANN’s 5 October publication is better read as a dependency map.

The release adds Second-Level Reference Label Generation Rules (LGRs) for Javanese and Unified Canadian Aboriginal Syllabics (UCAS), then updates seven other LGRs: Arabic script, Arabic language, Inuktitut language, Japanese language, Japanese script, Latin script and the Latin Full Variant Set. ICANN says its reference set now covers 30 scripts and 32 languages. Those totals measure the published reference material, not the number of languages that work across every registrar, browser, email system or application.

The update notes show why counting additions misses the operational issue. The new UCAS reference rule is accompanied by additional cross-script variants in the Inuktitut language rules. A Latin character added to support Algonquian languages in Canada is accompanied by changes to cross-script variants in the Latin Full Variant Set. Japanese language and script rules are aligned with Root Zone LGR version 6. The Arabic-script changes support Pegon writing in Indonesia. Each entry has a relationship to other rules that a registry or review process may need to consider.

That matters because these rules are inputs to a decision surface. ICANN describes Second-Level Reference LGRs as resources that gTLD registry operators can use when designing Internationalized Domain Name (IDN) tables; ICANN also uses them to review tables submitted by registries for security and stability. The table determines which labels a particular zone may accept under its policy and how variants are handled. A change to one reference file can therefore affect a registry’s analysis beyond the script named in the release headline.

This is not a claim that registries have already adopted the October versions or that every affected table must change in the same way. It is a version-control question: which reference set did an operator use, what changed in the new set, and which supported labels or variant relationships should be retested? A registry that tracks only the two newly added scripts could miss a related update elsewhere in its IDN table or review workflow.

The boundary between levels is also important. Second-Level Reference LGRs concern IDN tables used under generic top-level domains. The 2026 New gTLD Applicant Guidebook uses Root Zone LGR version 6 for top-level strings and their variants. The two rule systems interact through alignment and shared technical dependencies, but they answer different questions. A second-level reference rule does not itself approve a new top-level domain, delegate a label, or create a registrant’s entitlement to use one.

ICANN’s public-comment outcome records 33 relevant comments: 32 supported the proposed new and updated reference rules, while one focused on a Javanese typo and clarification. That is useful evidence about the submissions ICANN received. It is not a vote by all registries, all users of the scripts, or every language community. The same distinction matters when the publication is described as community-developed: relevant experts and groups were consulted, but the comment tally has a limited constituency and purpose.

The release also should not be mistaken for Universal Acceptance. Machine-readable label rules can help a registry assess whether a label fits its table and how related variants should be treated. They cannot make a web form accept an address, cause an email service to deliver to it, or ensure that software stores and displays it correctly. ICANN’s own announcement leaves room for future scripts and languages as relevant community input becomes available. Published coverage is a foundation for technical review, not a reader-facing adoption metric.

For registry operators, the practical response is to treat a reference update as a change set. Compare the version in use with the new files; map each changed rule to the registry’s own IDN table; test affected labels and variant relationships; and coordinate the resulting policy and implementation dates with registry service providers. The cross-script links deserve particular attention because users and registries encounter labels, not isolated code-point lists.

The significant question is not simply how many scripts ICANN has added. It is whether the rule set remains internally coherent as coverage expands. The October release demonstrates that an addition can travel: one script’s inclusion may require another language’s variants to be reconsidered, while a character addition can alter a full cross-script variant set. That is why the catalogue is also a maintenance surface.