ALAC Statement on the Draft Proposal for the Study of Issues Related to the Delegation of IDN Variant TLDs - Draft


Public Comment Announcement: Draft Proposal for the Study of Issues Related to the Delegation of IDN Variant TLDs (ends 6 April 11)


The ALAC welcomes the proposed studies on IDN Variant TLDs.  With the introduction of IDN ccTLDs, users at large At-Large end users increasingly expect IDN gTLDs to be available.  IDN Variant TLDs is a critical aspect for IDN TLDs.  Without delegation of preferred IDN Variants, the IDN TLD process is incomplete.

The proposed approach of separating the study into separate case studies should be an appropriate direction.  This is nNot only because the linguistic, cultural and geo-political challenges may be different between the identified cases, but also because the maturity and experience in policy and operations in handling IDN Variants may be different.  As such, it is encouraging to anticipate the potential that beyond the issues report, proceeding forward, it is possible to envision that consistent delegation of IDN Variant TLDs could be implemented for those cases with mature policy and operational experience as soon as possible, and in time for the first round of the new gTLD process.

Regarding the identified case studies, it may be useful to consider related aspects with the identified cases as well.  For example, the consideration of Greek and Latin along with Cyrillic, the consideration of the different scripts and languages in the Arabic and Indic cases, and the consideration of Japanese Kanji and Korean Hanja along with Chinese.

Furthermore, the example of “ö” vs “oe” may better be described as a phonetic workaround than IDN Variants.  It could be understood in the context of the discussion, to explain some of the current confusion regarding IDN Variants, however, it should be made clearer as such.  Furthermore, it may be useful to therefore highlight the importance of separating the case studies.

The working definition for an IDN Variant TLD in the proposal is a good starting point: “variant characters occur where a single conceptual character can be identified with two or more different Unicode Code Points with graphic representations that may or may not be visually similar. IDN variant TLDs contain one or more characters that have such variants.”

To better round out the definition, 2 two aspects should be considered: 1. That it could be possible that a string (of two or more) characters can be identified as a “base string” with IDN Variant strings containing one or more characters, and vice versa; 2. That an IDN Variant is a different domain name in the DNS[At-Large Policy Development Early Engagement: Locking of a Domain Name subject to UDRP Proceedings Workspace - May 2013|#_ftn1] (according to the DNS standards), but considered to be conceptually integral with the Primary IDN.

A suggested update to the working definition may be:

IDN Variant Labels contain one or more characters that have IDN Character Variants.  IDN Character Variants occur where a single conceptual character (or string of characters) can be identified with two or more different Unicode Code Points (or string of Unicode Code Points) with graphic representations that may or may not be visually similar. IDN Variant domains are considered distinct entries to the DNS by protocol standards, but are considered integral with the corresponding Primary IDN by policy.

Finally, the composition of the case study teams would be crucial to the success of the studies.  Whereas a reasonable size for the teams is important to ensure workable efficiency and effectiveness, an inclusive approach, especially for observers would also be essential for the completeness and support of the work.

 


[At-Large Policy Development Early Engagement: Locking of a Domain Name subject to UDRP Proceedings Workspace - May 2013] This is to distinguish the situation where capital letters and small letters, e.g. “A (U+0041)” and “a (U+0061)” occupy different Unicode Code Points but do not require variant considerations by policy because it is already considered identical within the DNS standards.