Update: This article is also published on CircleID.
Last month, John Klensin wrote an article published 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 sound 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 … 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.
