Chinese:
With one billion people around the world using Chinese as their primary language, it means that one out of every five people on the planet can have benefit from the introduction of the newly approved Chinese extensions:

• .中国 and .中國 – CNNIC – the China Internet Network Information Center http://www.cnnic.cn

• .香港 – HKIRC – Hong Kong Internet Registration Corporation Limited http://www.hkirc.hk

• .台灣 and .台湾- TWNIC – Taiwan Network Information Center http://www.twnic.tw

This is also the first time that variants are allowed at top-level domains or extensions for the Internet. For CNNIC and TWNIC they each have two variants approved for delegation. Both organizations have over a decade in variant operational experience, and have published implementation plans that describe how the variants are to be managed. We hope to get some good experience in these launches that can be used generally for TLD variant management and help us make this available for others as well.

At lot of people are of course asking the obvious question: when will we be able to make registrations and what are the registration rules? They should be available shortly, but please go to the respective organization for the IDN ccTLD management for more details about registration rules, launches and timelines.

At the ICANN meeting in Brussels, where the ICANN Board approval took place on 25 June 2010, it was followed by a CDNC event. Everybody celebrated the newly approved Chinese IDN ccTLDs, with music and food – pictures to come.

Singapore and Syria:
This month’s IDN ccTLD string evaluation completions included Singapore and Syria, with:

Syrian Arab Republic: سورية (Arabic)
Singapore: 新加坡 and சிங்கப்பூர் (Chinese and Tamil)

This means that the two organizations now can submit their requests to have these strings delegated as new top-level domains for use in the Internet.

IDN ccTLD Fast Track Status:
All in all we have now received 31 requests for IDN ccTLDs from countries and territories. Together they represent 19 languages. Details can be found at: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

The corresponding countries are:
United Arab Emirates, Saudi Arabia, Russian Federation, and Egypt.

This essentially means that we have started seeing domain names where the top-level/extension is either: امارات. السعودية. .рф مصر.

Congratulations to the teams behind:

• United Arab Emirates: امارات.
• Saudi Arabia: السعودية.
• Russian Federation: .рф
• Egypt: مصر.

The simultaneous delegation of the three Arabic based IDN ccTLDs was completed last week, and the delegation of the Russian IDN ccTLD was completed this week in conjunction with the Russian Internet Governance Forum: http://russia2010.intgov.net/eng/program.php

This is an history milestone and an achievement reached due to years of hard work by so many people across the world, including: technical developments with the core group in the IETF’s IDNA protocol working group; development of the policies and procedures; application development to ensure IDNs work across browser and other software; and so forth.

ICANN would like to thank everyone involved in making IDN TLDs a reality, and we look forward to seeing how IDN TLDs are embraced by users globally, and to the introduction of the next group of IDN ccTLDs. The full list will continue to be updated and can be found here: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

Some of the milestones leading to the last week’s great IDN result:

12 May 2010: Delegation of the Russian Federation IDN ccTLD

5 May 2010: Simultaneous delegation of the three first IDN ccTLDs for United Arabic Emirates, Saudi Arabia, Egypt.

22 April 2010: ICANN Board approval of the first four country delegations, for Saudi Arabia, United Arabic Emirates, Russian Federation, and Egypt.

21 January 2010: ICANN announces the first four IDN ccTLD requests as having completed step 2 (of 3) in the Fast Track Process, thereby the requested IDN ccTLDs have been approved.

16 November 2009: ICANN launches the IDN ccTLD Fast Track Process thereby opening up for countries and territories to submit requests for IDN ccTLDs.

30 October 2009: ICANN Board approves the Final Implementation Plan for the IDN ccTLD Fast Track Process, and announces the launch.

Oct 2008: First draft implementation plan for IDN ccTLD Process

Feb 2008: First report from the IDNC WG leading to IDN ccTLD Fast Track Process

Jun 2003: IDNA protocol, IDN Guidelines, initiation of browser implementation

An area of the ICANN website is dedicated to IDN resources, and includes links to all the milestones and news announcements: http://www.icann.org/en/topics/idn/

ICANN is actively taking part in conferences and events, with a focus on applications and usability of new technology on the Internet. This is to spread information about IDNs and how they work in order to obtain a more streamlined user experience across applications.

We will continue to make more information, such as the examples below, available for users and everyone interested in IDNs. We very much appreciate any feedback you might have, pointers to what type of information you think might be lacking, and suggestions for online forums, seminars, or other type of events where information about IDNs would be good to include.

This first post is focused on how IDNs work and where registrations can be made.

What are IDNs?

The acronym “IDNs” stand for Internationalized Domain Names. IDNs are domain names that include characters used in the local representation of languages that contain one or more characters other than the twenty-six letters of the basic Latin alphabet “a,b,…z”, “0,1,…9” or “-“. An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese.

Example: ñandú.cl

Since the Domain Name System is not capable of communicating with these characters, a system is made so that the domain name stored is actually:

xn--and-6ma2c.cl

This “xn--and-6ma2c.cl” is referred to as the A-label for the IDN and does not make a lot of sense for users and was never intended for users to see – however, in some instances you will see this – see below for more explanations and examples.

Why are IDNs introduced?

Historically domain names could only consist of characters from “a,b,c…,z”; “0,1,2,…,9” and “-“.

The geographic expansion of the Internet and the corresponding increase of use by various linguistic groups or communities resulted in the need for domain names also to consist of characters from all scripts used in the world today. Content written in various languages has been around for a long time.

The fact is that for example websites where the content is all in Hindi should also have a web-address in Hindi. Web content in various languages has been around for a long time. The matching addresses are now here.

IDNs are about your choice

Let’s be clear: IDNs will provide opportunities for more people to have easier access to the Internet. Some people are concerned about IDNs dividing the Internet because they are not able to read or type some of these languages.

But it’s all about user choice. The choice of effectively being able to select which script or language a domain name should be based on. In this way you can brand yourself better and in that way target the market you want more effectively. Printed material can have web references in the same script as the material is written in. And keep in mind that a website can for example have more than one address….which now can be a choice between different scripts and languages.

Another aspect of this that is important to realize it that by introducing IDNs in the Internet/single root today means that we hopefully have avoided a fragmentation with various “internets” based on different scripts. That would be a situation where communication between these “internets” would be difficult if not impossible. Introducing IDNs in the Internet today effectively ensures the global interoperability of the Internet.

How can I make registrations of IDNs?

ICANN is not in the business of offering the domain names registrations. The registrations can be made through registrars or their resellers, and for some ccTLDs directly via the TLD registry manager. As such, for information about how to register domain names in the new IDN ccTLDs should be sough via the IDN ccTLD managers.

All current TLD managers and operators are listed at http://www.iana.org/domains/root/db/

This will be updated shortly to include the three IDN ccTLDs that were made available yesterday http://icann.org/en/announcements/announcement-05may10-en.htm

Until then you can find the main points of contacts at: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

IDN registrations under some of the existing (ASCII) TLDs (e.g. .com, .org, .gr, .cn, etc) have been available since as early as 2001. The registry managers or your preferred choice of domain name registrar or reseller will be able to assist you with more information about these IDN registrations under existing ASCII TLDs. Domain names under the gTLDs (generic top-level domains such as .com) can be registered through ICANN accredited registrars or their resellers. A list of all ICANN accredited registrars is available here: http://www.icann.org/en/registrars/accredited-list.html

Note that some IDN ccTLD managers have decided to take pre-registrations before their requests for IDN ccTLDs have been completed. ICANN is not endorsing this as it is not possible to guarantee a certain TLD for availability until it has passed through all steps in the processes successfully.

How do IDNs work?

IDNs have been around for years at the second level (the “icann” portion in the address http://www.icann.org ) and as a result, browsers and other application software started updating their systems years ago. Today the newest versions of all major browsers can handle IDNs. They have implemented IDNs slightly differently, which will give slightly different user experience, but those that are IDN capable will get you to the right and same site. So what’s the difference?

Well due to the different ways that IDNs are implemented, different options are made available by the different browsers. Some examples as follows:

In all of these examples, you will get to the actual site. What does not always display as entered is the address in the address-bar. The examples explain how users can overcome this fact.

Internet Explorer:

The screenshots below is from IE v8 accessing: http://παράδειγμα.δοκιμή (this is the Greek version of the ICANN wiki and the address means “example.test” in English).

You will note two things:
1) The address in the address bar is displayed as:

http://xn--hxajbheg2az3al.xn--jxalpdlp/%CE%91%CF%81%CF%87%CE%B9%CE%BA%CE…

2) There is a small pop-up stating that the address cannot be displayed with your current language settings.

If you click on the pop-up and select the change language settings you will get the following options, where you can add languages to your settings:

Adding, in this example, Greek to your language settings will effectively display the address as in the following screenshot, where the address is displayed in Greek:

It is noticeable that the path in the web address contains “%CE%91%CF%81%CF%87…”. The path should effectively also be internationalized.

Mozilla Firefox

The screenshot below is from Firefox v 3.5.5 accessing: http://उदाहरण.परीक्षा (this is the Hindi version of the ICANN wiki and the address means “example.test” in English).

It is noticed that the address (and the path) in the address-bar is displayed correctly in the Devanagari script: http://उदाहरण.परीक्षा/मुख्य_पृष्ठ

The implementation of IDNs in Firefox is based on a white-list of those TLDs/extensions that Firefox considers ‘safe’. All the “.test” TLDs has been added to this white-list. If you are accessing a site and the address is displayed in the http://xn--p1b6ci4b4b3a.xn--11b5bs3a9aj6g format then this is because that particular TLD or extension is not in the Firefox white-list.

If you trust these addresses and wish them to display in the address-bar as the local characters then you can make changes to the white list manually. A detailed explanation on how to do this is available here: http://idn.icann.org/Firefox_Information

The screenshot below gives you an indication of what to look for, but please be careful when making changes so that you do not damage the functionality of the browser.

Opera Browser

The screenshots below is from Opera 10.53 accessing: http://בײַשפּיל.טעסט (this is the Yiddish version of the ICANN wiki and the address means “example.test” in English).

The Opera browser supports the “example.test” names either directly, or after updating as described in a separate article on the Opera Browser: http://idn.icann.org/Opera_Information

As is noticed in the above, the address in the Hebrew script displayed as http://xn--fdbk5d8ap9b8a8d.xn--deba0ad/הויפּט_זײַט – in order have it displayed as: http://בײַשפּיל.טעסט updates need to be made.

Another example where Opera is supporting the IDNs directly is displayed below, which is the Chinese version of “example.test” – i.e. http://例子.测试/首页

Are you using a different browser than those examples provided here?

Please try things out either live under any of the IDNs that are available, or in the IDN wiki at http://idn.icann.org and let us know how this works for you. The IDN wiki also contains a lot of additional information related to fonts etc. Please feel free to add and share your IDN expertise and experiences on the wiki.

The next IDN topic blog post will be on IDN & Security. Meanwhile, please make sure to let us know any topics you would like to see covered.

Internationalization of the internet means that the internet is equally accessible from all languages and scripts

More information about IDNs can be found at: http://www.icann.org/en/topics/idn/

IDN ccTLDs in the DNS root zone:

Egypt: مصر (Egypt)
Saudi Arabia: السعودية (AlSaudiah)
United Arab Emirates: امارات (Emarat)

- in addition Russian Federation: рф (rf) is approved by the ICANN Board for delegation, and related activities are scheduled for the Russian Internet Governance Forum http://russia2010.intgov.net/eng/program.php (next week)

A big congratulation to all four countries from the ICANN Team on reaching these goals! We are very much looking forward to seeing how the market will adopt and use these IDN ccTLDs.

Also a big THANK YOU goes out to all of those in the communty that have worked on this for years. That is, those on the ground at the various registries and governments that have worked actively locally; the IDNA protocol authors for outstanding technical volunteer work for years; the policy makers for getting the processes ready; application developers for making sure that IDNs functions in all new versions of the main browsers – and so forth.

IDN ccTLDs ready for TLD Delegation:

The last step in the Fast Track Process is the delegation step. Once requests successfully meet string the evaluation criteria they are eligible to apply for delegation. This is following the same ICANN IANA process as is used for ASCII based ccTLDs.

A total of nine (9) countries/territories are current at this stage. A full list of them, the IDN ccTLDs, and contact details are available here: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

The languages include: Chinese, Arabic, Sinhalese, Tamil, and Thai.

IDN ccTLDs under evaluation

In addition to everything listed above, ICANN is currently processing requests from eight (8) countries/territories. As soon as these have completed the String Evaluation” criteria they will be added to the list at: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

IDN ccTLD Fast Track Process looking forward

As is clear from all the positive IDN news, the fast Track Process is working really well for many countries. Part of making sure that it works effectively for all users is a review of the process. This is scheduled annually, which would be 16 November 2010. Staff is currently reviewing whether a review should take place sooner.

Also, as stated in the Fast Track Process, variant TLDs cannot be introduced until a method for this is made available. Please see a previous blog post for details on work that still needs to be done on this subject: http://blog.icann.org/2010/04/update-about-synchronized-idn-cctlds/

We hope to come with a more detailed plan on this soon.

IDN usability

Finally, we continue to receive a lot of questions concerning usability. The IDNs works well. We are working on a blog post with usability examples and explanations, and will publish this shortly.

Meanwhile, if you have experience with the new IDN ccTLDs please send them to us either as comments to this blog post, or directly to me at tina.dam@icann.org

The ICANN Board also took actions that are expected to expedite Chinese characters in top-level domains as part of the IDN ccTLD Fast Track. This will be the first set of variant IDN ccTLDs to be introduced – under special circumstances. More work is underway on the subject of variants, including policy-procedural analysis and technical definitions and plans for testing.

In addition, last week, a new IDN ccTLD request was announced as having passed the String Evaluation stage – for the country of Jordan. This means that Jordan now may enter the String Delegation step, which is the last step in the Fast Track Process. As such Jordan joins 13 other countries/territories having succesfully passed String Evaulation. The full list can be seen here: http://www.icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

The total number of received requests in the Fast Track Process is: 21
The total number of languages represented is: 11

To read more about the IDN ccTLD Fast Track, go here: http://www.icann.org/en/topics/idn/fast-track

If you only see boxes in the above IDN ccTLDs, then you may need to download the necessary font: http://idn.icann.org/Fonts – or perhaps you are experiencing a problem with IDNs that is not rendered correctly when viewed in various applications. Either way we’d love to hear about it

As you may know, one of the ICANN Board resolutions from the recent ICANN meeting in Nairobi directed staff to develop an extension to the Fast Track Process: a mechanism to introduce Synchronized IDN ccTLDs. A Proposed Implementation Plan was subsequently published for public comments.

The Proposed Implementation Plan can be found here: http://icann.org/en/announcements/announcement-22mar10-en.htm

Since Synchronized IDN ccTLDs in the Fast Track context is a new concept, naturally this has raised some concerns and confusion. The best place to record comments and questions is in the public forum: http://icann.org/en/public-comment/#synch Still, we thought it would be helpful to point to some resources, and answer questions we have seen in mail lists and elsewhere.

If you haven’t read it yet, we encourage you to read the recently published Q&A. The Q&A addresses concerns raised by the technical community due to the usage of certain terminology in the Board resolution and the Proposed Implementation Plan. In particular the Q&A explains that “synchronized” relates solely to policy and procedural requirements. The Q&A further clarifies that there is no (DNS) technical mechanism by which domains under Synchronized IDN ccTLDs will be made to resolve identically (same address/value etc) at the DNS protocol level. As a result, from a purely technical/DNS protocol perspective, two synchronized IDN ccTLDs are simply two separate delegations from the root zone.

If you have further questions, we encourage you to attend one or both of two upcoming webinars. These webinars will be recorded and the recordings will be published at the public comment forum for review by all interested parties. The webinars are scheduled for 14 April at 01:00 and 14:00 UTC. Registration and access information can be found at: http://icann.org/en/announcements/announcement-2-08apr10-en.htm or directly at the e-learning site at: http://icann.org/en/learning/

In addition it is important to note that the plan for synchronized IDN ccTLDs is not a general statement from ICANN about how all variant TLD introductions can or should be made. Quite the contrary, the requirements in the Proposed Implementation Plan for Synchronized IDN ccTLDs assures that it is limited. As one example of these limitations it is required that Synchronized IDN ccTLDs request first must complete the String Evaluation step in the Fast Track Process. Again, the Synchronized IDN ccTLD Process is an extension of the Fast Track Process and all Fast Track rules apply.

Given these designed-in requirements/limitations, the volume of Synchronized IDN ccTLDs will not really increase the total volume of new TLDs already contemplated within the Fast Track Process. Also, confusingly similar IDN ccTLDs will not be allowed for delegation regardless of whether they are considered synchronized or not (this type of variant TLDs needs additional work, see below). And, there are no current activities ongoing towards a notion of “Synchronized IDN gTLDs”.

As mentioned, more work is required to create a general mechanism by which all variant IDN TLDs (not just the very limited set of Synchronized IDN ccTLDs) can be introduced. The term variant has been used loosely; other related terminology used is aliasing, sameness, and so forth. A clarification of the terminology and what is meant by it is needed before the ongoing work can be initiated. A more general solution depends on (at least!):

• Definition of what exactly it is that is being sought by a “variant solution”. What is the desired behavior of variants in all cases?

• Definition of the different types of variants – which may inform the answers to 1).

• Review and test of DNAME as a technical solution, and its adequacy to achieve variant TLD management.

• Review/test of BNAME as a technical solution, and its adequacy to achieve variant TLD management. It is noted that the BNAME proposal is rather new and currently exist as an Internet Draft in the IETF.

• Review/test of variant management via procedures and registration policies. This based on the experience with the Synchronized IDN ccTLDs.

Along with the technical community, ICANN wants to contribute to finding the answers to these questions, and is launching a project to address them. Part of this work will be looking to use the community experience on this subject. In particular ICANN is seeking advice from the technical community, such as for example the work currently ongoing in the IETF/DNSEXT on the subject of sameness and variants in context of the DNS.

Meanwhile we look forward to your comments in the public forum, and your participation in the upcoming webinars!

The overall rules seem clear:

1) If you apply for an IDN ccTLD that is confusingly similar with an existing ccTLD, gTLD, or reserved name, then your request will be declined.

2) If you request an IDN ccTLD that is confusingly similar to a “validated” IDN ccTLD, then your request will be declined.

3) If you request an IDN ccTLD that is confusingly similar to another IDN ccTLD under evaluation, and yet not “validated”, then both request will be placed on hold until a solution is found.

4) If you request an IDN ccTLD that is confusingly similar to an applied-for gTLD string that has reached Board approval, and hence considered an existing TLD, then your request will be declined.

5) If you request an IDN ccTLD that is confusingly similar to an applied-for gTLD string, then both parties will be informed.

Validation, for the purpose of the Fast Track Process means that it has been established that the string is a meaningful representation of the corresponding country/territory name, and that it has successfully passed the DNS Stability Panel evaluation.

However, it is the notion of confusingly similar and exactly how it is established that two or more strings are so confusingly similar that they cannot co-exist in the DNS, that reasonably is raising questions.

As the Final Implementation Plan states, any such determination is on a case-by-case basis. However, it is probably useful to provide some insight into how the panel makes such a determination.

While the determination is done by the DNS Stability Panel, Fast Track participants should know that ICANN staff will provide them with concerns about confusability (if such is found) during the initial review of a Fast Track request. The requester then has the opportunity to either (i) change the string they requested, (ii) withdraw the request and resubmit at a later stage, or (iii) continue with the request as originally submitted.

Type styles, fonts, etc.

Issue: A sufficiently creative choice of type styles or the exploitation of information about scripts that a given user may be unable to display can result in one character (or a sequence of characters) in one script being visually confusable with one or more characters (or character sequence(s)) in another script.

The issue becomes even more serious for closely related scripts (for example, Greek/Latin/Cyrillic).

While we are aware of the issues, some level of risk must be accepted. These kinds of issues cannot be completely guarded against, especially as type styles and fonts (just like languages and scripts) evolve and change over time.

Instead, determining confusability is focused on issues that may arise from the basic geometry of characters that is preserved, to a greater or lesser degree, across a variety of fonts, styles, and formatting.

Two-character strings

Issue: Two-character strings that consist of Unicode code points in scripts such as the Latin, Greek, and Cyrillic script blocks are intrinsically confusable with currently defined or potential future country code TLD (ccTLD) strings based on the ISO 3166-1 alpha-2 codes.

This is particularly true when variations in font and presentation interface are considered. And it is not limited to the pairs of “visually confusable characters” identified in Unicode Technical Report #39. Those characters are based on Unicode Reference Fonts that are deliberately designed to reduce the potential for visual confusion.

Therefore, a very conservative standard is being used to assess applied-for strings that consist of two Greek, Cyrillic, or Latin characters, including a default presumption of confusability to which exceptions may be made in specific cases.

How are strings ranked?

The Fast Track Process recognizes the following rankings for requested two-character IDN ccTLD strings. The higher the rank the more likely the applied-for string as a whole presents a significant risk of user confusion.

[6] Both characters are visually identical to an ISO 646 Basic Version (ISO 646-BV*) character. [International Organization for Standardization, "Information Technology – ISO 7-bit coded character set for information interchange," ISO Standard 646, 1991.]

[5] One character is visually identical to, and one character is visually confusable with, an ISO 646-BV character.

[4] Both characters are visually confusable with, but neither character is visually identical to, an ISO 646-BV character.

[3] One character is visually distinct from, and one character is visually identical to, an ISO 646-BV character.

[2] One character is visually distinct from, and one character is visually confusable with, an ISO 646-BV character.

[1] Both characters are visually distinct from an ISO 646-BV character.

Some disagreement may arise in assessing whether a string is confusingly similar with existing ccTLDs, gTLDs, or applied-for strings. Thus, these rankings are for guidance only, and the DNS Stability Panel makes its assessment based on the rankings and on the expertise of the panelists. In difficult situations, the panel may conduct extended evaluations that also can include drawing on additional linguistic expertise.

The likelihood of user confusion presented by a given two-character IDN ccTLD string does not depend strictly on the individual confusability of each character, if considered separately. The assessment of “visually distinct” and “visually confusable” takes into account both the individual features of each character and their combined effect.

In general, a two-character IDN string at rank [4] or higher presents a significant risk of user confusion.

In general, a two-character IDN string at rank [3] or lower does not present a significant risk of user confusion.

What about confusable strings already in the DNS root zone?

Some have argued that we already have TLDs in the DNS root zone that could be considered confusingly similar, so there is no need to prevent future confusingly similar strings from being entered in the root zone as well. There is only one answer to such statement: Just because there are issues today does not mean that we should make it worse for the future!

Finally, thank you to the DNS Stability Panel for all their work in this area and for generating the rankings based on their professional experience and prelaunch training!

None of this information replaces or changes the information available and defined in the Final Implementation Plan for the IDN ccTLD Fast Track Process. It is merely an elaboration of that published information.

First, note that community support for a string is different and specifies different requirements than community support for the IDN ccTLD sponsoring organization.

• Support for the string is required in the String Evaluation step of the Fast Track Process.
• Support for the sponsoring organization is required later, during the String Delegation step of the Fast Track Process.
This separation in process means:

1. Evaluation of the desired string is completely separate and distinct from evaluation of the appropriate sponsoring organization for an IDN ccTLD.

2. The sponsoring organization does not need to be identified until the String Delegation step begins.

3. Only rarely would the same documentation be appropriate to demonstrate support for both a string and its sponsoring organization, as two different types of support are being required and evaluated.

• While the letters requesting string selection and support involve a requester stating preferences for a string, the letters involved in the delegation process are used to corroborate a selection process and a community consensus-building process for the proposed operator.

The community string support requirement specifically ensures that the Internet community takes part in the decision for a string.

This requirement is part of the Linguistic Process Validation in the Final Implementation Plan, as stated here:

That the received documentation of community support for the string(s) is satisfactory.
• This should be demonstrated in a similar manner as required for delegation requests, see Module 5, Appendix 2 for guiding information.

The nature of community support can, and is expected to, vary from country to country and between territories. Differences in cultures mean different ways of consulting Internet users, and hence different ways of gathering the necessary supporting material. Signed form letters are not considered adequate for participants to express their support.

Despite the difference in the approach taken, the selection of a string to represent a country or territory must be in the interests of the Internet user community of the country or territory. Thus, there should be dialogue in the country or territory about what string(s) should be selected to best support the local Internet community.

The following are examples of questions a requester may be asked. They enable staff to successfully complete the Linguistic Process validation.

In particular we are looking for information such as:

1. What kind of dialogue, outreach, survey or other types of events has taken place to select the string requested?

2. How was consensus reached on the requested string during such activities?

3. What alternative strings were considered and why were they rejected?

4. Was any opposition to the requested string received? If yes, which?

In evaluating these information elements, staff will put weight on a process that:

• Allows for people that do not have the same view to participate;

• Is open and consultative; and

• Allows differing points of view to be expressed.

In addition, it is helpful for a requester to provide a chronology or narrative of the process (not just the final decision), and at least a general description of who had access to, or was involved in, the event(s) at which the decision was reached.

• ICANN denying some countries/territories access to the Fast Track Process
• ICANN approving IDN ccTLDs
• The notion of pre-registrations in new TLDs

This blog post is intended to set the record straight on these matters.

Is ICANN denying access to the Fast Track Process?
Let me be very clear: The Fast Track Process for submitting requests for IDN ccTLD strings is available to all eligible countries and territories. Statements like ICANN has refused IDN ccTLDs to some countries are incorrect. ICANN encourages eligible countries and territories to participate in the process and submit their IDN ccTLD requests.

This is an exciting new opportunity for Internet users around the world, and we would like to see as many users being served by these new initiatives as possible and as are deemed useful.

ICANN also has a support function in place at idncctldrequest@icann.org for interested parties.

So far, ICANN has received 17 requests encompassing 10 languages. These numbers will be updated from time to time at http://icann.org/en/topics/idn/fast-track/.

To comply with the confidentiality requirements of the process, ICANN cannot disclose any additional information. We cannot state whether a particular request has been received, or how far along the process a request is. We understand that the public has a great deal of interest in potential future IDN ccTLDs, and therefore some requesting entities have elected to publicly disclose information about their requests.

However, the only time ICANN can make information available about a request is after it successfully passes the String Evaluation step.

What strings are ‘approved’ and what does it mean?
Four IDN ccTLD strings were recently announced as successfully completing the String Evaluation step of the Fast Track Process. These requests are associated with Egypt, the Russian Federation, Saudi Arabia, and the United Arab Emirates. The full announcement is here: http://icann.org/en/announcements/announcement-21jan10-en.htm.

However, passing the String Evaluation step is not the same as saying that ICANN approved these TLDs. These four entities must go through the final step in the Fast Track Process – String Delegation. The String Delegation step must be initiated by the respective country or territory, and that can only be done with requests that have successfully met the String Evaluation criteria. String Delegation follows the same ICANN IANA process that is used for ASCII-based ccTLDs, and thus String Delegation requests are submitted to IANA root zone management.

Only after String Delegation takes place will these TLDs be in the DNS root zone, and only then can resolutions requests against them be performed. In other words, this is when domains can be registered and used.

Has ICANN authorized pre-registration of TLD domain names?
ICANN has not authorized pre-registration of domain names in any potential future TLDs.

The reason is simple: There is no way to be sure that a certain string will become a TLD and hence available for domain name registration until all steps in the associated evaluation and delegation processes are successfully completed.

ICANN has previously posted warnings concerning speculative pre-registrations, and those warnings are still informative. You can review them at http://www.icann.org/en/announcements/icann-pr29sep00.htm

These are associated with: Egypt, the Russian Federation, United Arab Emirates, and Saudi Arabia.

See the full announcement here: http://icann.org/en/announcements/announcement-21jan10-en.htm

So what does that mean?

It means that these may now initiate the String Delegation process, which is the last step before the strings are actually in the DNS root zone and hence available for use.

The remaining 12 requests are still being processed and at ICANN we are very much looking forward to completing more requests as well as receiving additional new requests

Overall, the Fast Track Process has three main steps:

1) Preparation (by the requester in the country / territory). Community consensus is built for which IDN ccTLD to apply for, how it is run, and which organization will be running it, along with preparing and gathering all the required supporting documentation.

2) String Evaluation: incoming requests to ICANN in accordance with the criteria described above: the technical and linguistic requirements for the IDN ccTLD string(s). Applications are received through an online system available together with additional material supporting the process at http://www.icann.org/en/topics/idn/fast-track/

3) String Delegation: requests successfully meeting string evaluation criteria are eligible to apply for delegation following the same ICANN IANA process as is used for ASCII based ccTLDs. String delegation requests are submitted to IANA root zone management.