The Technical Test Program has not yet been released for public commentary. A new timeline will be announced shortly under news and noteworthy at www.icann.org
The single interoperable Internet is based on a shared namespace originating in a single root. This ensures that all users of the global Internet have a platform on which they can communicate with each other. The geographic extent of the Internet is constantly expanding, with a corresponding increase in its use by the diverse linguistic groups of the world. Content reflecting this linguistic diversity has long been available online. There is a need to continue supporting multilingual access to the Internet. This is a necessary step in realizing the full potential of the Internet for serving as a global communications platform.
One challenge in implementing multilingualism on the Internet is the preparation of content in the numerous languages, alphabets, scripts, and character sets that must be accommodated. There is also a need to deal with these same factors in the development of keyword, search, and directory systems. Finally, this all needs to be reflected in the Domain Name System ("DNS") which underlies all resource identification, even if specific concern with domain names is only a fraction of the total multilingualism issue.
ICANN takes all issues related to internationalization very seriously. In relation to its mission, the implementation of internationalized domain names ("IDNs") is of utmost importance. An IDN is a domain name that contains characters from non-Latin scripts, or includes the use of accents and diacritical marks with Latin characters.
ICANN has already established guidelines for the introduction of IDN on the second level of the DNS [for example, the ICANN portion of www.icann.org]. In addition, the Internet community and ICANN have collaboratively appointed a group of leading experts to a President's Advisory Committee on IDNs.
This committee is preparing a proposal for a technical test of internationalized top level domain labels. Representatives from all regions of the world are taking part in the discussion of the technical test and have agreed that the stability and security of the DNS which supports the Internet as we know it today will have the highest priority. It is for this reason that due diligence is being applied and that technical testing is to take place.
The technical test will include two approaches to the insertion of IDN records into the root zone of the DNS. These are:
- DNAME records - as defined in RFC 2672 DNAME provides an alias designation for an entire domain by mapping a new domain into another that already exists. For an existing TLD, this corresponds to the use of a punycode* string to provide an internationalized alias designation for that TLD using a DNAME record in the root zone.
- NS-records - permit the insertion an internationalized label in the root zone without the duplication of a pre-existing sub domain structure.
The test procedure will ensure that enabling multiple languages at the top level will not adversely affect users. It will also establish the technical methods that are available for such deployment and will enable ICANN's policy development bodies to move forward with their ongoing work with regard to policy decisions essential to a production environment in which users will be able to access the Internet using their local languages.
Any such policy decisions must be based on the results of transparent and verifiable tests of suitable technical bases for the deployment of IDN TLDs in a production environment. The available solutions need to be both technically stable and not compromise the stability and security of the DNS. Therefore, the result of the technical test is considered to be absolutely essential input to policy development processes. ICANN's Generic Names Supporting Organization (GNSO) initiated a policy development process during the ICANN meeting in Vancouver in December 2005. This will include participation from the ccNSO and the Governmental Advisory Committee (GAC). The appointed working group is currently awaiting input from the technical test before the full range of relevant policy issues can be formulated and action toward decisions about them can begin.
The timeline for the technical test is outlined below. Its development will be focused on topics such as the selection criteria for applicants, lifetime of the test, review and evaluation, label definition, and many more important issues.
As outlined below the project description will be released for public review before it is put before the ICANN Board for approval and, if entailing any amendments to the Root Zone, the US Department of Commerce for authorization. During the development of the project key stakeholders will be consulted. As this is a technical test such stakeholder participation will be particularly focused on the members of ICANN's Security and Stability Advisory Committee (SSAC) and the Root Server Advisory Committee (RSAC).
* Punycode is a bootstring encoding that will convert the local characters in a domain name into the limited character set that is supported by the DNS. The encoding is applied to each component of a domain name and a prefix 'xn--' is added to the translated Punycode string. For example, the first component of the domain name rødgrødmedfløde.dk becomes 'xn--rdgrdmedflde-vjbdg' in Punycode, and therefore the domain is represented as xn--rdgrdmedflde-vjbdg.dk
Project Development Timeline
9 March 2006: The President's Advisory Committee met to discuss a draft timeline and project for the technical test of internationalized labels. The Committee agreed to recommend that ICANN post the timeline as outlined here.
19-23 March 2006: An initial presentation introduction will be made to the SSAC and RSAC in order to ask for their expertise, assistance, and support in the continued development of the project for testing internationalized labels.
April 2006: The project description for the technical test of internationalized labels will reach a state where the Committee will release it for public review and commentary.
April - May 2006: One-month public comment period. Announcements will in particular be made to all existing supporting organizations, IDN working groups, technical community and other known interested parties.
May 2006: All received comments will be gathered and the project will be amended as necessary after which the Committee will vote on a recommendation to ICANN to submit the project for ICANN Board approval, and consequent US DoC authorization.
Also, an analysis for the reasoning concerning why the received comments were accepted or rejected will be provided.
June 2006: The President's Advisory Committee will submit the final project to the ICANN staff and Board with recommendation to implement the project as quickly as possible.
June 2006: ICANN staff will seek ICANN Board and if necessary DoC approval for implementing the project. This is anticipated to be reached no later than the ICANN meeting in Marrakesh, 26-30 June 2006.
July 2006: Following such approval the request for applications for participation in the technical test will be announced. The evaluation team will be formed, and the IANA process for inserting and removing the experimental labels will be initiated and the test environment will be open.
The DNS and domain names [www.example.org] were not originally developed to accommodate languages that use non-Latin scripts, or require diacritical addition to Latin characters. As the Internet continues to grow, many new users are interested in being able to write domain names using their local languages and scripts. Various technical experts have suggested that to accommodate such a need directly in the DNS, the infrastructure of the Internet would need to be dramatically changed.
The Internet Engineering Task Force reviewed potential options for changing the standards of the Internet's architecture and the result became the IDNA standard that was developed in 2003 (RFC 3490 by Patrick Fältström, Paul Hoffman and Adam M. Costello).
In parallel with the development of the IDNA standard, ICANN developed guidelines for the introduction of IDNs. At the time of announcement of version 1.0 of the guidelines, the registries for the .cn, .jp, and .tw country codes, as well as for the .info and .org generic top-level domains, committed to adhere to the Guidelines. Further, as authorized by the ICANN Board in March 2003, additional registries that decided to seek to deploy IDNs under their agreements with ICANN would be authorized to do so, on the basis of the IDN Guidelines. Since then, the following gTLD registries have been authorized to implement IDNs by following the IDN guidelines, .info, .museum, .biz, .org, .name, .com, .net.
Correspondence between the registries and ICANN can be found online at
The IDN Guidelines contain an agreement that, as the deployment of IDNs proceeds, ICANN and the participating IDN registries will work together to review these Guidelines at regular intervals to make any necessary adjustments based on the deployment experience. During 2005, discussions concerning the issue of IDN spoofing increased dramatically. These discussions resulted in a focus by the IDN registries and ICANN on revisions to the IDN Guidelines in order to prevent certain types of spoofing and phishing attacks. This topic was highlighted at the IDN Workshop in held in connection with the ICANN meeting in Luxembourg, June 2005, after which version 2.0 of the IDN Guidelines was developed.
Of particular importance in version 2.0 was the association of each label in a registered internationalized domain name with a single script (with certain exceptions for languages with established orthographies and conventions requiring commingled use of multiple scripts). These added requirements were introduced to limit the potential for phishing attacks and the resulting confusion for users.
The introduction the IDNA standard and the implementation of IDNs at the second level, with the following revision of the associated guidelines only addressed a few of the issues concerning internationalization of the Internet. Additional concerns include:
- internationalized domain name dispute resolution mechanisms
- expansion of the content and display of information contained in the Whois databases browser and other application development deployment
- implementation of IDN in the top level of the DNS (a topic that has received a great deal of recent attention)
At several ICANN meetings, the focus has been on such issues concerning the continued deployment of IDNs. At the recent ICANN meeting in Vancouver, particular focus was placed on IDN TLDs. It was agreed that a technical test should be conducted to determine the suitability of two types of DNS resource records for the stable and secure deployment of IDN TLDs in the DNS. This technical test would include public participation when testing DNAME and NS records as described above.
The principles and framework for this project will ensure that the test takes place in a safe context and that the labels placed in the root zone for the purpose of the test are purely temporary, with no value subsequent to the test and to be removed from the zone immediately upon its conclusion. The project plan also ensures that the scope and size of the testing will remain manageable so that rapid growth of the test environment does not jeopardize the operation of project controls.
The anticipation is to be able to launch the actual technical test later this year. After their evaluation, the results will be provided to ICANN policy development bodies. Throughout the course of the test, its evaluation, and the subsequent development of policies, it must be notes that there are significant areas related to the internationalization of the Internet, such as development of content in local languages that do not fall under ICANN's mandate.
For more details on announcement, and material concerning IDNs, please visit http://www.icann.org/topics/idn/