Quicksearch
Calendar
|
January '09 |
|
||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
The problem with IDNs
Monday, October 13. 2008
Last week, ICANN announced that it had added two new languages to its IDN testbed. Bengali and Khmer have thus become scripts number 16 and 17 to be supported as part of ICANN's global IDN experiment.
ICANN is testing IDN TLDs, i.e. a complete domain name written in a non-ASCII format. The Greek IDN test link (http://παράδειγμα.δοκιμή) serves as a good example: not only is the domain name (the left part after the dot) written in Greek, but so is the extension (the right part before the dot).
I see some irony in ICANN pushing its IDN testbed while at the same time, ccTLD managers are finding it harder and harder to decide what to do with IDNs. In July, the Belgium registry DnsBE announced that, having consulted the community, it had decided not to go ahead with an IDN implementation at this time.
And last week, at an AFNIC meeting, I learned that IDNs were not included in the French registry's action plan for 2009. That means no IDNs for .FR before 2010 at the earliest.
Admittedly, several European registries, including the Germans, the Swiss and the Austrians, have already launched IDNs. But I can't help thinking that IDNs are creating as many problems as they are solving, and that is why registries are having trouble implementing them. We can only hope that ICANN's current experimentation will lead to a simpler, more intuitive IDN system. That would increase the chances for widespread IDN adoption.
Unfortunately, there's some doubt cast on that as well. I was at a Eurolinc meeting last week (an organisation that promotes multilingualism on the Internet) and IDNs were discussed by technical people who know a lot more about them than I do. The consensus seemed to be that the current IDNA protocol, upon which ICANN's testbed is based and which relies on a form of coding called punycode to translate IDNs into ASCII-compatible data, is problematic. One suggestion I heard: dump punycode and use only UTF8 coding. A practical solution? I don't know to be honest, but it's nice to see people working an alternative ideas to make IDNs happen.
> organisation that promotes multilingualism
> on the Internet) and IDNs were discussed
> by technical people who know a lot more
> about them than I do.
I won't comment on your evaluation of Eurolinc but I can assure you that noone at the IETF (the standard organization which standardizes IDNA) is seriously considering dropping Punycode.
See the charter of the current IDN working group (a very questionable group but this specific point was never challenged) :
http://www.ietf.org/html.charters/idnabis-charter.html
That's for the reasons explained here (in french):
http://www.bortzmeyer.org/pourquoi-idn-et-pas-un-dns-unicode.html
What is on the horizon is idn.idn, with unicode on both sides of the dot. That is what has been testing, and from all reports that is moving forward with some languages slated to "fast track" in 2009.
Verisign and other registries (JPRS most recently) have issued draft reports on plans for DNAME or other alising of .com, .net, .jp, .cn, etc to mirror those gTLD and ccTLDs in the various scripts and languages where applicable.
Interesting reading is ICANN budget for 2009 a public document that lays out the groundwork and support for the rollout of IDNs and the applicable budgets to support the initiatives.
