ICANN has added reference rules for forming second-level internationalized domain names in the Javanese and Unified Canadian Aboriginal Syllabics scripts, extending the technical framework registries can use to determine which labels and variants are valid.

The new and updated Label Generation Rules, published October 5, add the two scripts and revise seven existing reference LGRs covering Arabic, Inuktitut, Japanese and Latin scripts or languages. ICANN now publishes second-level reference LGRs covering 30 scripts and 32 languages.

The rules serve as reference points for gTLD registry IDN tables. Label Generation Rules define permitted characters, how they may be combined into domain labels, and which labels are treated as variants of one another. Registry operators can use ICANN’s reference LGRs when designing their own IDN tables, while ICANN uses them when reviewing tables submitted by gTLD registries.

The additions extend that framework to Javanese, a script used in Indonesia, and Unified Canadian Aboriginal Syllabics, or UCAS, which is used to write several Indigenous languages in Canada, including Inuktitut. The accompanying revisions also connect the new rules with existing tables where scripts or characters interact.

Several of the updates address those cross-script relationships. During the public-comment process, ICANN said the Inuktitut LGR was being revised to add cross-script variants associated with UCAS. The Latin reference LGR added a character supporting Algonquian languages in Canada, with corresponding cross-script variants added to the full-variant Latin rules. Japanese language and script rules were aligned with version 6 of the Root Zone LGR, while Arabic-script changes included two characters supporting Pegon, an Arabic-derived writing system used for languages in Indonesia.

ICANN received 33 relevant comments on the proposed additions and updates, with 32 supporting them. One submission sought a correction and clarification to the Javanese reference LGR, which ICANN said it incorporated before publication.

Publication does not itself mean every affected name becomes immediately registrable. Registry operators decide which supported IDN services and tables they offer, subject to their registry agreements and ICANN’s review processes. Registries seeking to add or modify an IDN service or update an approved IDN table may need to submit the relevant tables and explain whether existing registrations are affected.

The change nevertheless supplies registry operators with vetted reference material for scripts that previously lacked second-level reference LGRs. Its practical effect will depend on whether registries adopt or revise IDN tables to support the newly covered characters, labels and variant relationships.