[council] Very interesting - CircleID: Examining the Proposed Internationalization of TLDs -

["sophiabekele" <sophiabekele@xxxxxxxxx>]

Dear All,

I am sending this article for your interest.

I do not know James, and had no idea he had the same views as I have been 
expressing these past couple of weeks until I saw the article.  

Regards,
Sophia


"Examining the Proposed Internationalization of TLDs"
By: James Seng, Nov 30, 2004
http://www.circleid.com/posts/examining_the_proposed_internationalization_o
f_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.