AT-LARGE ADVISORY COMMITTEE
STATEMENT FOR THE ICANN BOARD ON INTERNATIONALISED DOMAIN NAMES
Introductory Note by the Staff
This document is a statement from the At-Large Advisory Committee delivered to the Board of Directors of ICANN in its role as an Advisory Committee. It was approved by the ALAC by unanimous vote on 29 th October 2007.
Note on Translations
The original version of this document is the English text, which is available at http://www.atlarge.icann.org/en/correspondence/. The process of gaining agreement on the contents of the original text was conducted in English. Where a difference of interpretation exists or is perceived to exist between a non-English edition of this document and the original text, the original shall prevail.
[End of Introduction]
At-Large Advisory Committee Statement for the ICANN Board on Internationalised Domain Names
At ICANN San Juan Meeting in July 2007, the Board requested that that the ICANN community including the GNSO, ccNSO, GAC, and ALAC provide the Board with responses to the published list of issues and questions that need to be addressed in order to move forward with IDN ccTLDs associated with the ISO 3166-1 two-letter codes in a manner that ensures the continued security and stability of the Internet. The Board requested status reports regarding progress by the conclusion of the ICANN meeting in Los Angeles in October 2007.
ALAC is hereby respectfully presenting to the Board the status report, which synchronizes the comprehensive discussions and comments from the user community (please refer to ALAC IDN Working Group ). ALAC appreciates and cherishes all the contributions and reiterates the commitment to work collaboratively with other constituencies, including the GNSO, ccNSO and GAC, to explore both an interim and an overall approach to IDN ccTLDs associated with the ISO 3166-1 two-letter codes.
Q.1: Which 'territories' are eligible for an IDN ccTLD?
Despite its problems, the ISO-3166 two-letter code list is the least controversial definition of cc available. So we believe that this list should serve for the moment until consensus on another definition is reached. This does not mean that ALL those listed need to implement IDNs.
Q.2: Should an IDN ccTLD string be "meaningful"?
The word 'meaningful' should be interpreted to mean describing the territory, economy or country specified by the two-letter code. In this narrow sense the answer should be yes. We are not referring to acquired secondary, often commercial, meanings attached to certain ccTLDs not describing the intended territory.
Q.3: How many IDN ccTLDs per script per territory?
One should aim for just one IDN string per per script per territory at the first stage in order to get the project moving. There may be cases where different languages within a given territory use the same script and have different representations for the territory name in that script. In such cases, if there is demonstrated demand for more than one IDN, one possibility is to 'bundle' the various representations as one IDN ccTLD. This would involve having more than one representation in the root but should solve the local problem.
Q.4: How many scripts per territory?
The number should eventually be decided by the local Internet Community through sufficient, transparent and multi-stakeholder consultation mechanism. IDNs are designed to serve the people who use the specific scripts other than ASCII. Without prejudice to the ICANN IDN Guidelines on technical constraint, non-ASCII script users should have the freedom to decide whether to reflect thier native scripts in the DNS. However, realization of this final and idealistic solution will be a long process involving complicated technology and policy development. Given that non-ASCII users have been waiting too long for IDN deployment, it is suggested to adopt a fast-track experimental solution in the short term. Under this short-term solution, the Internet community in each ccTLD territory may choose only one IDN script for deployment. The one script chosen should be out of genuine consensus of the local community, carefully defined in terms of variants or homographs.
Q.5: Number of characters in the string?
This question is correlated to Q.2. Although ccTLDs in ASCII are expressed in two-letter codes listed in ISO 3166, the number of charaters in IDN ccTLDs cannot and should not be pre-defined. A ccTLD will be meaningless if it cannot reflect the link with a certain territory. However, many ccTLDs, once expressed in the non-script scripts, cannot reflect the territory links in two-letter format. Forced abbreviations could cause confusion or even distortion. Therefore, the number of characters in the IDN string should be decided by the local Internet community and technically subject to the IDN guidelines.
Q.6: Are there any 'rights' attached to a given script?
IDNs are not only online identifiers but non-English speaking people's culture expression on the Internet. In IDN implementation, social responsibility should outweigh commercial interests. In the long run, any selection of IDN scripts or operation should be subject to the language community's self-determination. Some language community has already been well-organized, which defeats the suspicion that local community cannot be defined. However, for the purpose of the fast-track experimental deployment, some fast-track consultation mechanism may need to be created, such as object or appeal system. If the question means whether any priority right should be given any language group where the script set is shared by several languages, no rights or priorities should be given to any one language group using the script. Where possible, variants of a script should be treated as separate scripts to avoid this problem, but then IDN implementation would require measures to combat homographs and phishing. CCTLDs--even IDN ccTLDs--should maintain the linkage with specific territories and may well restrict registrations outside the territories. Thus, it should be the language community within the territory of a ccTLD that are consulted for the IDN ccTLD matching to that ccTLD. Given the unique territorial nature of CCTLDs, even in share-script circumstance, IDNs for ccTLDs should not be a big problem among the language communities that share some scripts in different ccTLD territories because their IDN ccTLDs must be in different stings anyway. What's important that one ccTLD should not be entitled to interfere the selection of IDN ccTLD in another territory that use the same scripts or share some scripts.
Q.7: Should a list of IDN ccTLD strings be mandated?
A universal mandating should not be implemented at the initial stage. Users have the right to use IDNs rather than a duty to do so. Neither the automatically converting ISO 3166 into an IDN list solution is far from being realistic: this would impose some ccTLDs that have no demand for IDN use to implement them, which is obviously contradictory to the purpose of IDNs. Also, compiling a mandatory list would slow down the IDN development process. The crucial question at this stage is how the local community consensus can be reached in case IDN implementation is necessary. One solution to that is the proposal by APTLD, which states that it is important to allow each interested existing ccTLD to propose ONE string and provide six months for Internet community at Large including the 'affected' Communities and Governments to voice possible objections and/or comments. If no serious reservations are aired then the string may go into the root. However, even though a list of IDN ccTLD can be complied through the one-string-one-ccTLD approach it cannot be a final solution, and if made mandatory, it will cause serious rivalry between different script users in one ccTLD territory. Issues related to that include: What makes one script may be chosen over others in a multiple-script ccTLD territory? Is this reflected in the local cultural or social policy/strategy? How those minority script users can protest against this and will they protest?
Q.8: Who picks a string for a territory in the absence of a mandated list?
As stated in the Q7, each existing ccTLD should be allowed to propose one string and to provide six months for the Internet Community at Large to express their views/concerns/comments. It is mandatory to include the local community in the consultation process in deciding the string. Public review/objections regarding the proposed ccTLDs strings should be opened and transparent.
Q.9: What coordination should exist between the different actors?
There is no doubt that coordination of the main issues related to IDN ccTLD strings is needed. One of the most important aspects in this coordination process would be a proper balance between the general rules vs. level of autonomy at the "territory" level. At the initial stage, there can be implemented a bottom-up vs. informal coordination model, which based on the Lessons learned vs. Good models would further develop into more global/formal coordination model if needed.
Q.10: Who can apply to have the IDN ccTLD delegated or to be the delegate for that ccTLD and,who decides on the delegation?
CcTLD Manager ( Sponsoring Organization ) should have the right to apply for a delegation of IDN ccTLD, while ICANN should ensure that the local internet community has been consulted and that a local multi-stakeholder agreement have been reached on the IDN ccTLD Delegation and the public policies issue related to IDN ccTLD.
Q.11: Should there be an agreement between ICANN and the IDN ccTLD operator on the operation of the IDN ccTLD string?
This Question looks simple but represent a very complex and sensitive issue, IDN ccTLD operators should agree to a set of rules and operational guidelines to be followed in order to insure stability and interoperability of the DNS.
Q.12: Is the operation and management of an IDN ccTLD different to that of an existing ccTLD? Such that there be specific global technical requirements related to running the IDN ccTLD?
Due to the Language and cultural sensitivity, in both Technical and administrative aspects the operation of an IDN ccTLD might be slightly different from the management of existing ccTLD, in order ensure consistency and stability the preference should be that the existing ccTLD operator could be the new IDN ccTLD operator unless the local internet community have objections on the current ccTLD operator and requested a delegation of IDN ccTLD to a new sponsoring organization.
The statement may be read in full in the attached PDF [137K].