ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

This document represents a proposal by the At-Large Advisory Committee for global policies to be introduced in regard to internationalized domain names.

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 economical 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. In particular, uncautious policies might create relevant security risks and thus stifle the adoption of IDNs. 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 coordinating body in the domain names space. As such, it cannot subtract itself to the responsibilities this role entails.

We would thus like to suggest some principles that we submit to the attention of ICANN and of the Internet stakeholder community:

1. The possibility of a coordinated adoption (as "best practices") of common standardized allowance and 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 that would derive to the users by having to cope with strings that are equivalent or allowed in some TLDs, but not equivalent or not allowed in others. Also, the availability of global best practices would prevent the adoption of imprecise or plainly wrong variant tables by gTLDs and by ccTLDs 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 it.

This principle does not just come 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. While the implementation of this principle might be difficult and thus be abandoned in certain cases, the existing experiments — for example with Arabic or Chinese/Japanese/Korean scripts — prove that there are strong incentives and opportunities for affected communities from different countries and environments to come together successfully. ICANN should act as convenor and facilitator for the affected communities 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. Equivalences and other technical and policy measures should be oriented to user perception: the misuse of strings which would likely look equivalent, confusing or deceptive to the average user of the Internet must be prevented to the extent possible.

Homophones, homographs, deceptive similarities between different scripts are a fact of life and cannot be easily avoided. At the same time, there are some technical options to reduce possibilities for malevolent use, phishing attacks, or simply confusion. Such technical options should be aimed to the effect that strings would have on final users, and not to other considerations; for example, two strings could be considered equivalent when they are very likely not to be distinguished the one from the other when written or read. We would like to stress that not addressing the problem, allowing for uncautious registrations of potentially problematic domain names, 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 the one with the other.

4. The introduction of IDNs should not cause a significant increase of the total cost that registrants have to pay in average to protect their registrations from abuse of similarly confusing strings.

While it is normal for many registrants to pay a few other times the registration fee to prevent others from getting strings that could potentially be confused with their domain name of choice, the introduction of IDNs might easily make the number of such deceptive strings very high. Moreover, IDNs introduce a brand new category: strings that are not just deceptively similar, but are actually indistinguishable from the registered one. Care should be taken so that reasonable options — for example through the use of bundling, or through specific dispute resolution mechanisms — are offered to registrants to prevent these cases; it would not be acceptable to de-facto force users to pay two, four, or even ten or twenty times the registration fee to protect their name from other people's registration of equivalent strings.

5. Care should be taken to protect registrants that have been using ASCII-based graphical approximations of non-ASCII strings that might suddenly become available in their correct form.

This issue affects registrants from countries that use "quasi-ASCII" scripts, such as most European countries and the Francophone community, where it has been common usage to substitute accented letters with the corresponding non-accented ones when converting words into domain names. Once IDNs are introduced, 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 will 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 done 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).

6. The problem of equitable access to gTLD IDNs by all language communities should be addressed.

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, if gTLDs are to support non-ASCII domain names, then 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 .

7. 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 matter, the more we will be having problems 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 or refunded.

8. 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 be able 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. Actually, the "IDN.Roman" experiments appear to be more like a source of confusion than an acceptable solution; "IDN.IDN" domain names should be deployed as soon as possible. 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 IDN) should promote a cooperative effort with other entities in this field (e.g. IETF, W3C...) to ensure that this final goal can be promptly and effectively reached and to understand at which level (infrastructure, application...) 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.

To support our proposals with practical ideas, we would like to suggest some technical and policy options that could be explored in future discussions as possible solutions to implement the principles we outlined above:

a. Making, to the extent possible and as seen useful by the different communities, all groups of characters which would be perceived as equivalent by final users technically equivalent in variant tables.

While in some cases (for example, European languages) the high quantity of cross-script intertwinings could make this impossible, for other languages it looks feasible to make alternate representations of the same character formally equivalent.

b. Using registration bundles to ensure that no two variants of the same string 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. Bundling could be one possible solution to prevent this from happening.

c. Ensuring that registration bundles can be obtained for a price which is not directly proportional to the number of variants included in the bundle.

As the number of possible permutations of equivalent characters in a string might easily grow up to 2 to the n-th power, the corresponding registration fee should not be equal to 2ⁿ times the single registration fee.

d. Launching a "sunrise period" to allow registrants of graphical ASCII approximations of IDNs priority access to the correct version; or, foreseeing a specific dispute-resolution process to address disputes between an early ASCII-approximate registrant and a late IDN registrant.

This would allow registrants from European countries to migrate smoothly from the ASCII approximation (e.g. liberte.com) to the correct IDN string (e.g. liberté.com) without giving way to disputes or cybersquatting cases.

e. Launching a prompt and speedy process for the introduction into the root zone file of IDN semantical equivalents to the existing TLDs.

We believe that the prompt introduction of "IDN.IDN" domain names is crucial for further Internet development. As technical issues are solved, we believe that the addition to the root of semantical equivalents in other scripts of existing TLDs — and in particular, of country names for ccTLDs — does not need to undergo the extensive review process required for new TLDs (both ASCII and IDN), but should become a clerical task of IANA.

f. Evaluating the opportunity of deploying IDNs into gTLDs.

There are pros and cons to the idea of having IDNs into gTLDs; as unsponsored gTLDs naturally address all possible language communities, the number of scripts and languages to be supported would be high, and thus opportunities for confusion and misuse. At the same time, gTLDs such as dot com represent a core resource for global e-commerce, which should not be used to give advantage to English-speaking communities.

g. Adding appropriate provisions in terms of universal linguistic access to the obligations of gTLD registries foreseen by their contracts with ICANN.

We believe that if IDNs are to be introduced in gTLDs, then equitable access should be offered to users of all reasonably common scripts. It would be unacceptable if, due to purely commercial considerations, only a few major scripts were to be supported in gTLDs. While the specific provisions, and whether they should be binding or just recommended, might differ according to the relevance, size and scope of the specific gTLD, the issue should be carefully addressed.

Finally, we would like to note our concern with the fact that, up to this moment, the process adopted for IDN policy discussion has been offering insufficient possibilities for participation by non-English speakers. On this very matter it is extremely important to provide access to discussions to other language communities; efforts should be undertaken to provide working documents in a reasonable number of major languages and in ensuring that adequate time is given to non-English speakers to understand the texts and the issues and provide their point of view.