ICANN At-Large Advisory Committee Statement on the Introduction of IDNs
ICANN At Large Advisory Committee Statement on the Introduction of Internationalized Domain Names This document represents a proposal by ICANN’s At-Large Advisory Committee (ALAC) for global policies to be introduced regarding internationalized domain names (IDNs). It does not, however, represent the unanimous views of the ALAC members. The ALAC will continue to discuss the principles enumerated below, and will provide additional comments and statements on IDNs. __________________________________________________________ First of all, we would like to express our appreciation for the hard work conducted by many parties to promote the development and the deployment of IDNs in various top level domains. However, we stress that IDNs are not only a technical or business matter, but rather a fundamental element of the respect for cultural diversity and of the internationalization of the Internet. As such, cultural and political considerations should not be given lower priority than economic or technical ones – as apparently it has been until today. We think that the prompt introduction of full and non-discriminating support for all scripts and languages in domain names, as well as in other elements of the Internet that are directly used by the final consumers, is one of the most pressing issues that need to be addressed by the global Internet community. However, since the Internet will be a resource that will likely be used for decades, if not for centuries, any mistake made in this phase could compromise its future in the long term. This is why we think that special care must be taken in ensuring an orderly and wise deployment of IDN registrations. We also note that ICANN is the only global policy-making authority in the domain name space. As such, it cannot ignore its responsibilities in defining global policies, and in encompassing and enforcing such policies in the contractual obligations of the registries and registrars. The following is a list of proposed principles that we submit for the consideration of ICANN and the Internet stakeholder community: 1. The possibility of a coordinated adoption (as “best practices”) of common standardized variant tables for each script should be studied and, if possible, embraced. Even if the feasibility of this idea still needs some general discussion and study, the availability and widespread adoption of common tables could be of great use. It would prevent the confusion users would experience by having to cope with strings that are equivalent in some TLDs, but not equivalent in others. Also, the availability of global best practices would prevent the adoption of imprecise or plainly wrong variant tables by gTLDs and by countries where the availability of linguistic experts in a given script might be limited or non-existent. 2. It is the right and duty of the Internet communities who use a certain script to develop and adopt the “best practice” character and variant tables that pertain to that script. This principle in not only offered as plain common sense, but it is also necessary to respect the cultural diversities and the natural principle of sovereignty of the peoples of the world. ICANN should act as convenor and facilitator for the affected community to self-organize and come to agreement on the tables, but should also ensure that these best practices are implemented by those TLD registries that have contractual agreements with ICANN. 3. “Equivalence” should be defined in terms of usage: strings which would likely look equivalent to the average user must be made technically equivalent and bundled to the extent possible. The definition of equivalence must be developed based on the effect it would have on final users, not for other considerations; thus, two strings should be considered equivalent when they are very likely not to be distinguished one from the other when written or read. Also, not defining any equivalences is an unacceptable policy, because it would prevent the adoption of any anti-cybersquatting and anti-confusion measures, since there would not be any simple and standard way to define which strings could be confused one with the other. 4. All equivalent variants of a given domain name should be either sold and registered in bundle, or reserved to the first registrant of any of them, so that no two variants of the same name can be assigned to different registrants. Domain names that look equivalent should not be used by different registrants or for different services - otherwise a whole new category of cybersquatting and phishing cases will emerge. The opportunity of bundling registrations of equivalent domain names should be carefully considered. 5. Registrants should not be asked to pay more for a bundle than what they would pay for a single domain name, especially if they are not going to actually use all variants. It is not acceptable to force users to pay two, four, or even ten or twenty times the registration fee – as the number of variants for a string may easily become very high – to protect their name from other people's registration of equivalent strings. (As an alternate possibility, as pointed out in principle 4, you could consider the option of reserving – but not registering – all variants when a given string of the bundle is registered, and asking the registrant to re-pay the fee only in case he/she actually wants to make a variant active.) 6. Existing registrants of romanized versions of strings should be given priority in the registration of all equivalent variants in non-ASCII tables. It would lead to the foremost confusion if the owner of, say,“ liberte.com” would have to watch someone else register “liberté.com,” since after IDNs become common no French-speaking user would ever type that domain name without the accent. In that case, the existing “liberte.com” registration would become practically worthless, or even considered as a squatter to the new “liberté.com” registration. Also, this would not be respectful of any investment of time and money that individuals and companies might have made to promote their Internet presence. However, this principle should only involve equivalence as defined in principle 3 – that is, graphical equivalence. It should not involve homophonies or semantic equivalences – i.e. the owner of liberte.com should not get priority rights on domain names meaning “freedom” in other languages and scripts (nor on the same string under other TLDs). 7. Global registries should be required to support all scripts. If support for a given script would be left to pure market considerations, it is likely that minority scripts (seen on a global scale, i.e. also scripts which are maybe used by entire countries but that do not represent at this time a significant percentage of the global Internet users) would never be implemented in gTLDs. We think that all peoples of the world should be enabled to register domain names in their own script under global TLDs, and especially under gTLDs that hold a majority share of the gTLD market, such as .com . 8. The status of existing registrations, and the opportunity of proceeding with registrations before final rules are developed, should be assessed as soon as possible. The more we proceed with the introduction of IDNs in an uncoordinated and unregulated manner, the more problems we will have in fixing the damage that will have been done. We think that ICANN and the affected communities should undertake a special effort to develop and approve a global IDN policy in the shortest possible amount of time. In the meantime, there is the risk that the existing registrations will conflict with the final policy, and will be a source of confusion or complaints. While not much can be done about existing registrations, it would be good to consider immediately whether the adoption of interim rules to restrict additional registrations that might later cause problems is appropriate. This applies especially to gTLDs, which affect all the languages and scripts (ccTLDs are, in practice, a more limited source of potential conflicts, and ccTLD policies on IDNs are already being discussed at the national level). In any case, if any existing registration ever would be deemed totally incompatible with the final policies and thus denied renewal, the registrant should be adequately compensated/receive a refund. 9. A plan for the complete internationalization of the domain name system, including top level domains and protocol string names, should be devised, in cooperation with the other appropriate entities. It is not particularly useful to make the second level domain name international, if the user will still be required to type in the Latin script to complete URIs (i.e. to enter the top level domain part of the host name or the protocol part (e.g. http) of the URI). All parts of the Internet identifiers which are to be used by final consumers should eventually be made available in any script and language. Thus, given that not all these issues pertain to the DNS, ICANN (through its new President's Advisory Committee on IDNs) should promote a cooperative effort with other entities in this field (e.g. IETF, W3C, etc.) to ensure that this final goal can be promptly and effectively reached and to understand at which level (infrastructure, application, etc.) each of these issues should be addressed. Also, all rules, policies and contracts under the responsibility of ICANN – the UDRP, for example – should be assessed to determine whether they would need revisions to take into account the future mass deployment of IDNs. ICANN Interim At-Large Advisory Committee committee@xxxxxxxxxxxxxx |