Comments on the Thaana Script Root Zone Label Generation Rules Proposal:

The proposal for a Root Zone Label Generation Rules (RZ-LGR) for the Thaana script is a crucial step towards enabling a truly multilingual internet1 .... The involvement of a dedicated Thaana Generation Panel (GP) with diverse expertise3 and the conduct of public consultation sessions in the Maldives4 reflect a commendable effort towards community-based development, a principle often emphasized in internet governance processes1 ....

However, several aspects of the proposal warrant further scrutiny and analysis.

Repertoire Listing: The proposal states that the RZ-LGR includes neither decimal digits nor the HYPHEN-MINUS5 . This aligns with the conservative nature of Root Zone LGRs. However, the justification for the inclusion and exclusion of specific Thaana code points within the recommended repertoire4 could benefit from more detailed explanation within this document itself, rather than relying solely on external references5 ....

Question: While referencing the Maximal Starting Repertoire (MSR)5 ... and the Unicode Standard5 is important, could the proposal elaborate further on the specific criteria used by the Thaana GP to validate and select Thaana code points for inclusion in this specific RZ-LGR? This would enhance the transparency of the decision-making process.

◦

Analysis:

▪ Pro (Excluding Digits and Hyphen): This conservative approach minimizes potential confusion and security risks at the root level, consistent with the purpose of RZ-LGRs.

▪ Con (Limited Explanation): The lack of detailed rationale within the proposal for individual code point decisions makes it harder for the broader community to assess the GP's reasoning and potentially identify oversights.

Variants: The proposal defines one set of in-script variants and states that no cross-script variants have been identified due to the structure of the Thaana script5 . The rationale provided – that the requirement of a vowel after each consonant in Thaana removes similarity with Arabic labels – is a significant point. However, the proposal could benefit from a more in-depth analysis of potential visual or phonetic similarities with other scripts that might pose security risks, even if structurally different.

◦

Question: Has the Thaana GP considered potential confusability with code points in other scripts that might share visual similarities with Thaana glyphs, even if the underlying script structures differ significantly? What methodology was used to definitively rule out the need for any cross-script variant considerations for security purposes at the root level?

◦

Analysis:

▪ Pro (No Cross-Script Variants): If genuinely no security risks are posed by cross-script similarity, this simplifies the LGR and avoids unnecessary restrictions. The structural difference with Arabic provides a strong initial argument.

▪ Con (Potential Oversight): Relying solely on structural differences might overlook subtle visual similarities that could be exploited for malicious purposes (e.g., homograph attacks). A more explicit security analysis considering a broader range of scripts used in the vicinity or with historical connections could strengthen the justification.

Rules: The proposal mentions two rules: "V only follows a C" and "C must be followed by a V"8 . These rules are fundamental to the Thaana script. However, the proposal could provide a more formal specification of these rules, perhaps in line with the format used in the normative XML specification9 . Additionally, it would be beneficial to understand how these rules are enforced within the RZ-LGR framework and potential implications for valid Thaana TLD labels.

◦

Question: Could the proposal provide a more formal and detailed specification of the proposed rules for Thaana root zone labels, including how these rules will be technically implemented and enforced within the RZ-LGR system? Are there any edge cases or exceptions within the Thaana script that these rules might need to accommodate?

◦

Analysis:

▪ Pro (Enforcing Script Structure): Adhering to the inherent rules of the Thaana script ensures that only valid Thaana labels are permitted at the root level.

▪ Con (Lack of Formal Specification): The current description of the rules is high-level. A more formal specification would reduce ambiguity and facilitate technical implementation and community understanding.

Handling of Specific Sequences: The discussion regarding the sequence <0x078B, 0x0783> (Dh-R) as a potential IDN ccTLD for "Maldives" and the GP's decision not to allow it in this version due to the predictability principle and lack of formal confirmation8 highlights a tension between practical considerations and LGR principles. While adhering to the predictability principle is vital for the stability of the root zone, ICANN and the GP should have a clear pathway for considering and incorporating formally selected IDN ccTLDs in future updates to the RZ-LGR.

◦

Question: What is the formal process and timeline for a sequence like <0x078B, 0x0783> (once formally confirmed as an IDN ccTLD by the community and relevant authorities) to be considered for inclusion or special handling within the Thaana RZ-LGR in future versions?

◦

Analysis:

▪ Pro (Adherence to Predictability): This prevents ad-hoc inclusion of specific labels and maintains the integrity of the LGR.

▪ Con (Potential Delay for Legitimate ccTLDs): If the process for updating the RZ-LGR to include confirmed IDN ccTLDs is lengthy, it could hinder the deployment of country-code TLDs in local scripts.

Benchmarking:

Organizations similar to ICANN in managing technical standards, such as the Internet Engineering Task Force (IETF)10 and the World Wide Web Consortium (W3C), typically emphasize:

Transparency and Detailed Rationale: Technical specifications and standards are usually accompanied by extensive documentation explaining the reasoning behind design choices, inclusion/exclusion criteria, and potential trade-offs. This enhances community understanding and facilitates informed review.

Formal Specifications: Rules and requirements are often specified in a formal language or with a high degree of technical precision to minimize ambiguity and ensure consistent implementation.

Security Considerations: Security implications are a paramount concern, especially for foundational internet infrastructure like the DNS root. Proposals undergo thorough security reviews, often involving dedicated expert groups.

While the Thaana RZ-LGR proposal reflects community involvement and considers the structure of the script, it could be strengthened by adopting a more detailed and formally specified approach in line with the best practices of established standards organizations.

This submission offers qualified support for the Proposal for Thaana Script Root Zone Label Generation Rules. While the community-based development and consideration of the Thaana script's structure are positive aspects, the proposal lacks sufficient detail in explaining the rationale behind repertoire decisions, the comprehensive analysis of potential cross-script security concerns, and a formal specification of the proposed rules. To improve the proposal, the Thaana GP should include more detailed justifications for code point inclusion/exclusion, provide a more explicit analysis of cross-script visual similarities from a security perspective, and present a formal specification of the rules governing valid Thaana root zone labels. Furthermore, ICANN should outline a clear and timely process for incorporating formally approved IDN ccTLDs into relevant RZ-LGRs in future updates. These enhancements will increase the transparency, robustness, and overall quality of the Thaana RZ-LGR.