Internationalized domain names (IDNs) have been available to Internet users for many years, but this year the first fully non-Latin IDN domains have become enabled by ICANN and country-code top-level domain registries. The recent success of the launch of Russia’s .?? (.rf) ccTLD shows that there is an enormous demand for domain names in Internet users’ native languages.

While speaking and writing in one’s own language is of course universal, actually enabling that language in the DNS is an extremely complex problem. Because the ubiquitous, legacy, portions of the DNS can only accept and resolve ASCII labels, non-Latin scripts such as Chinese, Cyrillic and Greek need to be encoded into ASCII by applications before they can be used on the Internet to visit websites or exchange emails.

For years, everyone has used an IETF standard called IDNA to map Unicode (which can be used to represent essentially all characters in all languages) into the 37 ASCII characters (Letters, Digits, Hyphen) allowable in DNS. But as Unicode evolved, the old IDNA protocol did not evolve with it. So the IETF is currently developing what it calls IDNABIS, or IDNA2008, to de-couple IDNs from any specific version of Unicode while maintaining an unambiguous one-to-one relationship between IDNs as they appear in applications and as they appear in the DNS. Companies that decide to apply to ICANN to operate new TLDs in IDN languages will have to use the new specification and registries that have implemented the earlier version of IDNA will also have to upgrade to the 2008 version.

Because it is such as complex subject, and because ICANN plans to release new, revised technical guidelines for registries managing IDNs, ICANN hosted an informational session at its December 2010 meeting in Cartagena, Colombia, in which registries including Afilias shared their experiences with launching, managing and transitioning IDNs.

Some languages and scripts, such as Arabic, have multiple ways of expressing the same string of characters that typically represent a word. Therefore, speakers discussed issues with “bundling” domain registrations where two strings would have the same meaning to a native human speaker but are represented differently in Unicode. To give an English example, because the DNS is designed to be authoritative and unambiguous, it is akin to the question of whether color.com and colour.com should resolve to the same address.

At the ICANN session, Marina Nikerova of the .?? registry explained that the new Russian ccTLD did not experience any of these code point problems, as Cyrillic has only one script to work with, but said that usability remains a concern. The .?? domain has achieved broad browser support, she said, but search engines such as Google still frequently return ASCII domains first when users search for Cyrillic. She referenced an example of the word “????????”, which means “news” and is the name of a major Russian newspaper.

While the browser problem may be substantially solved for .??, one problem it and other IDN registries continue to experience is that the current e-mail protocol does not allow for the use of non-ASCII characters as the e-mail address listed as the sender or recipient. IDN email is currently subject to a parallel IETF initiative called EAI, for E-mail Address Internationalization, which expects to publish its final specifications next year. Nikerova said that solving the e-mail problem, which includes enabling IDN characters in the username before the @ symbol, will likely lead to a “next wave” of registrations in the new Russian TLD.

The above indicates an e-mail sent to the IDN equivalent of [email protected] (the IDN for .RU) from the Arabic equivalent of [email protected] (the IDN for .JO) © Afilias

The fact that lack of e-mail support could inhibit the adoption of IDNs is a problem Afilias has addressed with a newly developed IDN E-Mail software. Afilias’ VP of product development Michael Young told the ICANN session that the software is a “soup-to-nuts” solution for handling IDN e-mail on desktop and mobile devices, as well as providing the server-side support for IDNs in, for example, Web-based email.