Home / Blogs

Examining the Proposed Internationalization of TLDs

Last month, John Klensin wrote an article published here on CircleID regarding Internationalized Domain Names (IDN) Top Level Domains (TLD). Based on his Internet Draft, John suggests using language translation in the application for TLD. The advantage of this method is that all existing TLDs can now be represented in any number of languages without additional need for ICANN to create new TLD.

While this sounds like a clean solution to the IDN TLD problem, I don’t think it is viable for the following five reasons:

1. Similar idea has been proposed in the IETF IDN Working Group for IDN (See uname and vidn). While John proposal has some minor technical differences, the fact that these similar ideas has been considered and discarded by the IDN Working Group is worth noting1.

2. One of the differences of John proposal is that translations are only done only for TLDs. 2nd Level Domain (2LD) and others remains using IDNA (RFC 3490). From a technical design perspective, such exemption handling are not desirable; it isn’t “keep it short and simple” (KISS)2.

Bear in mind that IDNs are fundamental identifiers also used embedded into other technical protocols (e.g. URL, URI, Email Address, Jabber Address, SIP Address), such inconsistency would introduce additional complexity in other Internet protocols.

3. In the article, John said:

The country-code list changes only very slowly. ICANN plans for the generic name list to grow moderately, but not dramatically, in the foreseeable future. Maintaining a translation table in which around 300 names are kept together with convenient local forms is a fairly simple matter of programming.

While that is technical true, getting the translation table into the application is a big challenge itself as we witness how long it took IDNA to be adopted by browser. In fact, after nearly 2 years, Internet Explorer still lacks IDNA support although we know now it is in its roadmap.

draft-klensin-idn-tld also propose that “We suggest that c authors of applications programs may want to maintain a table that contain lists of TLDs and locally-desirable names for each one”

But it fails to mention how the table is going to be managed and later updated. Will every applications needs to be updated or download a new text file whenever ICANN adds a new TLD? Who will decide what’s the ‘locally desirable names”?

Dealing with such problem with a single text file (e.g. TLD.TXT) downloadable from IANA may seem viable in the short run. But in the long run, just like we can’t cope with HOST.TXT back in 1980s which resulted in the creation of DNS, a TLD.TXT will not scale and we will inevitably fall back to using some sort of directory look-up mechanism, or worst, reinventing DNS.

4. Translation is also a fairly instable with variation based on local and language. And names of countries are even trickier. For example Singapore, officially name is 新加坡 but it is often shorten to be 新国 or 星國.

Such inconsistency is not acceptable in a DNS protocol where uniqueness is critical. You just can?t ask your user to type in 新国 or星國, depending which application they using or which locale they using.

I am quite sure these problems exist for all languages, regardless for country names or generic names. Just for fun, try getting a group of your favorite linguists to translate .COM and .BIZ, and then step back, get lots of donuts and diet cokes and watch the show.

5. While this is the last reason I am going to give you, and I am sure there are more, it is the most important one too and perhaps the easiest to understand. If you can’t remember the above four technical reasons, then just remember this one:

How on earth is the Internet community going to explain to the rest of the world that a single company is going to control all .COM in their language?

IDN TLD is important and many groups are already asking for one. Some more important then others, like Arabic Domain Names is horrible to use when mixed with Latin TLD. However, ICANN cannot shy away from releasing IDN TLD by using such technical short-cut, by moving their burden to the applications developers.

If ICANN indeed is indeed the responsible for “generic and country code Top-Level Domain name system managed” (quote ICANN ), then do so, and make it count.

1 A detail discussion why so those proposals were rejected is an article on its own…some day perhaps.

2 IDNA is design to apply to all internationalized labels, regardless whether it is TLD, 2LD, 3LD etc, in accordance to the KISS principle.

By James Seng, Vice President

Filed Under


Jothan Frakes  –  Dec 2, 2004 3:17 PM

I compose this comment from the ICANN meetings in Capetown, South Africa while attending these meetings.

There have been such great strides made in the area of IDN standards and in the area of IDNA over the past many years.

There have also been many splitered technologies put in place to attempt to capitalize on .IDN TLDs.

There are two primary points that need to be addressed.

Standards have been designed, discussed, evolved, and drafted over a multi-year process, and those standards are still taking hold in their implimentation in any practical sense.

Until there is more adaptation of IDNA within applications to where native language becomes more pervasive in use, it might be wise to capture what has been learned and use that data to derive future steps in .IDN implimentations.

I opine that dilution and confusion can occur to create IDN versions of existing TLDs and delegate them to parties other than the encumbent operator, but caveat that opinion in that these registries MUST work to ensure some form of responsible variant technology be put in place.

The concern I voice in this opinion is these native language .IDN versions of say, for example .INFO being delegated to anyone other than the .INFO operator, could open the door to having the registration 产品.INFO (“product” in Simplified Chinese) being potentially diluted by the registration of 产品.信息.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

Domain Names

Sponsored byVerisign


Sponsored byDNIB.com

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign