Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

RESOLUTION OF THE AT-LARGE COMMUNITY

ON THE IMPLEMENTATION OF INTERNATIONALISED DOMAIN NAMES (IDNS) FOR THE BENEFIT OF INDIVIDUAL INTERNET USERS WORLDWIDE

Internationlized domian names (IDNs) are to bridge the last digital kilometer that distances non-Latin script users from conveniently and effectively using the Internet. Despite all the challenges and difficulties on IDN implementation, IDNs are crucial to the fulfillment of the ICANN’s strategic goals of improving multilingualism, internationalization and multi-stakeholder participation.

ALAC has been continuingly and actively participating in the IDN activities of the President’s Advisory Committee on IDNs and the policy-making in the GNSO and ccNSO. As the user interface of ICANN, ALAC is committed to bring the users’ voices to ICANN and facilitate the relevant research and policy-making of ICANN. Through ALAC’s continuous efforts, nearly 100 user organizations rooted in more than 40 language communities on all five continents have been joined the ICANN community and four Regional User Organizations have been established or are going to take off.

resolved that:

We particularly emphasize that:

  • Representatives from at-large community, particularly from the Regional At-Large Organizations, be able to join all the ICANN IDN policy-making processes with full membership and voting right;
  • Local/regional pre-existing developments regarding IDN gTLDs be taken into account when considering introduction of new IDN domains;
  • Support from local language community be a key element to be considered for evaulation of IDN TLD applications;
  • ICANN IDN policy-making and implementation processes be substantively accelerated and no delay be tolerated.

Annex

Since any policy and implementation of the IDNs have significant impact on the interests of the individual users at large, ALAC are of belief that that user community be effectively, sufficiently and timely consulted and represented in any IDN decision-making process.

Deployment of IDN raises new technical problems and policy concerns. We strongly suggest the following principles be followed in policy-making and technical application process:

1. Local language communities should play a central role.

Local/regional pre-existing developments regarding IDN gTLDs should be taken into account when considering introduction of new IDN domains. The opinions of those bottom-up, multi-stakeholder initiatives on IDNs developed in a language community should, particularly, be respected as far as the IDNs in that language/script are concerned. ICANN should refer to the relevant language communities with respect to whether applications of IDN strings are in compliance with relevant variant tables.

IDN Policy should be designed to allow for local choice that meets the needs and wishes of the language community concerned. Capacity of effectively serving local language communities should be prioritized in selection of IDN operators. Preferential treatment should be given to the applications for particular communities in need of IDN gTLDs, for example through lower entry barriers, while safeguarding adequate levels of service to the relevant communities.

The past experiences with comparative evaluations in the ICANN environment, particularly those relating to sponsored top-level domains where measures of “community” support needed to be obtained, may be considered in IDN implementation.

2. Any anti-competition effect should be prevented.

Free market competition is in the interests of IDN users and thus should be encouraged and protected. To this end, no priority right for new strings on the top-level should derive from existing gTLD strings as such; no priority rights for new domain names shall derive from the possession of existing domain name strings as such. The technical approaches that may have anti-competition impact, such as use of DNAME records, shall not be deployed.

Non-Latin script users have been waiting too long, and no further delay should be tolerated with respect to application of IDN, particularly on the top-level. Neither non-IDN gTLDs nor IDN gTLDs should be delayed due to the other.

We support the plan of the IDN test and stress that the expeditious and consistent implementation of IDNs at both gTLDs and ccTLDs is equally important. A rapid process for implementation of both is needed.

3. Consumer protection should be prioritized.

There should be measures to limit user confusion due to variants (i.e. substitutable characters/symbols within a script/language). An IDN gTLD string with variants shall be treated in analogy with current practice for IDN SLD labels, i.e. strings that only differ from an IDN gTLD string by variants are not available for registration by others.

When selecting IDN strings, the issue of confusing similarity should be limited to visual or typographical confusing similarity.

4. Balance of interests should be kept.

Protection of intellectual property rights of existing domain name holders or gTLD operators should not be at the cost of market competition and consumer protection. Intellectual property concerns may be addressed by the operators’ sunrise period or ICANN UDRP mechanism, but should not constitute further restriction in IDN policy choice.