Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
At ICANN San Juan, I found out from Tina Dam, ICANN’s IDN Program Director, that she was putting together a live IDN TLD test bed plan which includes translations of the string .test into eleven written languages (Arabic, Chinese-simplified, Chinese-traditional, Greek, Hindi, Japanese, Korean, Persian, Russian, Tamil and Yiddish) and ten scripts (Arabic, Cyrillic, Devanagari, Greek, Han, Hangul, Hebrew, Hiragana, Katakana, Tamil).
I was very excited to hear that and wanted to blog about it but there was much to catch up at work so I let it slide.
Two days ago, an update from ICANN on this project:
ICANN today finalized the IDN .test Evaluation Plan and continued taking steps toward insertion of IDN strings in the root zone. Recent changes to the plan are based on comments received on the IDN public forum and also from consultations with ICANN Technical Advisory Committees. This last version was approved by the ICANN Board at their 14 August 2007 meeting. The resolution directs ICANN Staff to implement the IDN .test Evaluation Plan, and report back to the ICANN Board following the conclusion of the evaluation.
Specifically, the Board approved the delegation of eleven evaluative top-level domains representing the term ‘test’ translated into: Arabic, Persian, Chinese (simplified and traditional), Russian, Hindi, Greek, Korean, Yiddish, Japanese and Tamil. Following this ICANN Board approval, the delegation request will now go through standard IANA procedures for insertion of top-level domains into the root zone. The technical evaluations of IDN TLDs and their usability in various applications will proceed following their delegation.
This is a major milestone in the IDN Program Plan and signals a significant step forward towards Internationalization of the DNS. It is currently anticipated that delegation of these TLDs and the evaluations, as described in the plan, will commence in September 2007.
I would like to applaud ICANN (specifically Tina) on bringing the project this far. This is a major undertaking, and an important one too, for the following reasons:
I’m sure there are skeptics and ICANN-haters out there who will dismiss this for time-wasting activity, etc. The truth is, no one has actually tested IDN TLD’s on Internet-wide scale before. And no, country-wide deployments will not suffice because the diversity of software environments and cultures simply isn’t there.
And if you’re a proponent of the just-do-it school of thought, this should be seen as a move in the right direction. If no major problem was found during the live test, it will shut the mouths of those who are doubtful.
We should take advantage of this test to file bugs for your favourite software vendors and get them to support IDNs! When was the last time IANA inserted a test TLD to the root? Tell them that if IANA agreed to putting these test strings in the root, this is not a default ignorable fringe technology alright.
So, help spread the word and test the Internationalized Internet!
??????
Sponsored byCSC
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byRadix
A World-Renowned Source for Internet Developments. Serving Since 2002.
It’s just probably me, but I really don’t understand WHY this has to be inserted into the Root Zone (.) ?
Delegations for .cn/.th/.
has already been made for a long long time, and it seems that this will just be a precursor for ICANN to start creating .company (but then written in chinese) into the root.
The big question I have there is what that really accomplishes. I know one thing it accomplishes: more money going to the registries.
For the rest IDN is a just big scam using xn—punycode to generate more money, especially if ICANN at one point will be inserting, specially for certain scripts, “.com” alike TLD’s into the root. DNS is a hierarchy, that is a structure like a tree, not a flattened out bush kind of setup.
I do, partially, agree that IDN is a good thing, people should be able to writetheir DNS names in their own script, but, let the chinese nicely do that under .cn.
The part where I don’t agree is the mere fact that DNS is not for people (except maybe network admins) to type in anymore, DNS is for computers to resolve the given hostnames into IP addresses, people should be using different services for resolving ‘where to go’. Google/Yahoo/MSN/searchthingy should be the ones in use.
.biz/.info/.museum/etc etc should have never existed. .net should have retained it’s original meaning: for network infrastructure, same for .org/.com where these are global organizations and companies, while local things, eg the bakery around the corner, can readily use their local .
variant.
Btw: “dig @a.root-servers.net xn—hgbk6aj7f53bba. any” fortunately doesn’t work, so how “live” is this?
And if this really was for ‘ruling out problems in implementations’, why not simply set up xn-punycode.test.icann.org and point vendors to a http://www.test.icann.org where they can quickly see all the kind of possibilities for testing.
Jeroen, it sounds like you have various issues with new TLDs — not just IDNs. I’m going to just pick IDN parts to reply to.
The two paragraphs above almost contradict each other; if people don’t type in DNS names, there’s probably no need to internationalize it.
Not surprisingly, many do share your view that DNS names are just identifiers that should not carry cultural or linguistic significance. John Klensin’s DNS-Search proposal was a move in that direction.
Unfortunately, domain names “leak” in so many places from browser URL bar to billboards and name cards. Market forces (or human nature) have long decided that domain names need to be meaningful, and it can only be meaningful when localized to the language of the user. For many users who do not speak Latin-based languages, the numpad on an English keyboard is all they can identify with.
You can keep that opinion. I happen to think that money should only be a bi-product (and not much at that) of the process that uses IDN to empower users.
So that people don’t have to live with ASCII labels that don’t make sense for them, and in right-to-left languages that mixing of directionality creates more confusion than utility.
It’s not live yet. According to ICANN, the delegation will happen some time in September, so we’d expect to hear about it some time this month.
Testing a TLD by appending a suffix will not give you any conclusive results. The only other way to test this properly is to set up fake root servers and have other devices configured to use those fake root servers. Those tests had been done before but IMHO they do not provide sufficient coverage.
William Tan said:
Simple question: are people going to type punycode, yes or no?
If no, then why does it have to be in the root?
as you wrote yourself:
I can agree fully with this, but still DNS will carry PUNYCODE, not the scriptthat the user types. As such the root doesn’t have to carry this in the root either.
The tool that converts the scriptto punycode can easily append .idn to it, or .cn for chinese scriptetc, thus avoiding having a 100/200/300 new TLD’s in the root zone for every different language on this planet.
Or do you want to hear:
“I just came up with a variation of Klingon and I also need my own TLD!!!!”
You are trying to solve user interface problems in the wrong way. Of course extra TLD’s is extra ching ching.
I must be mistaking the title of the article then which clearly reads “ICANN Tests IDN TLD (Live!)”, note the “Live!” ;)
With “Testing a TLD”, you mean a “DNS label”, there is nothing special about TLD’s at all. It is just a text string separated by dots. It all works the same, every level of hierarchy (hey that famous great word hierarchy again!) has glue from the domain it is a subdomain of. TLD’s are just subdomains of the roots, normal domains are just subdomains of TLD’s etc.
Can you explain me how exactly testing:
xn-punycode.
is different from testing:
xn-punycode.idn-test.cn.
Except that dig +trace will show you one redirection less?
And of course that most likely companies will be more happy to PAY for 2nd level domains instead of a 3rd level domain one….
Your dictionary word for today: Hierarchy
Look it up, it is a very good word that describes how DNS looks like.
Also, by putting it in the roots, how are people actually going to tests this if they don’t know about it at all?
Oh indeed exactly the same way as the subdomains ;)
I’m not sure how putting A-labels into the 2nd level or lower make it any more hierarchical. Granted it keeps the root from being too cluttered, but you can’t avoid any of the administrative overhead associated with inserting labels into the root.
I completely agree with you that there is no theoretical difference between a label at the root and the label at any other level. However, I think the point is to test the fringe cases and non-compliant software/devices that incorrectly places restrictions on the TLD.
Firstly, there is no provision in IDNA (rfc3490) for appending suffixes after punycode encoding. So, what you are proposing wouldn’t work for most IDN-enabled software today. Other than IE7, no other IDN software that I know of today allows you to self-configure a suffix. There used to be .mltbd.com for Verisign’s IDN test bed, and certain other plugins may use their own suffixes but these are all non-standard. If you have an issue with how IDNA was specified, you should bring it up in IETF.
Secondly, as if adding the special rule about “hyphen-minus characters in the third and fourth position of a label” wasn’t bad enough of a hack, you want a standardized suffix that software would recognize and strip before displaying to the user?
I may have misunderstood your argument, but from what I’ve read it seems your major gripe is having new labels in the root zone. I note your point though I disagree.