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/.<every other country> 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 .<country> 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 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.

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.

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.

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.

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.

It’s just probably me, but I really don’t understand WHY this has to be inserted into the Root Zone (.) ?

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.

Btw: “dig @a.root-servers.net xn—hgbk6aj7f53bba. any” fortunately doesn’t work, so how “live” is this?

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.

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 www.test.icann.org where they can quickly see all the kind of possibilities for testing.

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:

The two paragraphs above almost contradict each other; if people don’t type in DNS names, there’s probably no need to internationalize it.

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:

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.

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.

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.

I must be mistaking the title of the article then which clearly reads “ICANN Tests IDN TLD (Live!)”, note the “Live!” ;)

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.

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.

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.

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.

Can you explain me how exactly testing:
xn-punycode.
is different from testing:
xn-punycode.idn-test.cn.

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.