China supports its IDNccTLD for a long through stubs. Actually they are in the root zone, but not in the ICANN root file. The problem is that IDNA was documented in 2003 in continuation of i-DNs existing IDNs and related to Unicode version 3-2. While Unicode had reached version 5. There was a need to make IDNA independent from Unicode version, to correct some imperfections, etc. This has been stabilized for the Internet by the recently published IDNA2008 version.

It only describes the way the Internet DNS wants to receive IDNs to restore them at the proper destination. This is neat and clean on the Internet side. The problem is that ICANN has not understood yet that the work is not completed: nothing has been specified for the user side, just a list of still not approved suggestions.

The reason why is that IDNA2008 unleashes the Internet capacity to support multiplicity, what is named the “presentation” layer and this way makes common the use of classes. This is an enormous change for users (ICANN only takes care of class “IN” domain names). At the same time, since there is no more “stringprep” there is a lot more flexibility for character mapping (preventing look alike characters to be confused, on a cultural basis). Yet, that mapping is just “up in the air”. There is no documentation, not configuration file and format, etc. in order to introduce some globally understood/used procedure.

As a result you can have several IDNA enabled applications on your PC that may resolve differently the _same_ IDN. IETF has no solution yet for that. Because this is on the user side, not on the network side. But this is not in the scope of anyone, because no one is in charge of something universal to the user.

So, the solution is for the Internet Users themselves to specify their own architecture. This is not complex. This works very simply, there is not a single line of code to change: just to load and run named on your computer and use your own copy of the root to make your computer non recursive and to get build a copy of Bind that supports punycode.

Problem is that when you have that on board your PC you are not tied to ICANN something anymore. You can decide to support any TLD which has a name server. Choosing among millions of TLDs of your liking if people started supporting them for free. In addition you can do that in other classes than “IN” and this means no pollution, no interference with ICANN. You can even run your own “.com” in an other of the 65.000 classes.

This is chaos. Actually, this is the unique virtual root and exactly what ICANN has asked to experiment in its ICP-3 document, but never did. This is why Fast Track with only a few selected IDNccTLDs is technically meaningless and an incitation to all the others to start their own MYCANN class.

ICANN played sorcerer apprentice. They followed the IETF work. But did not grasp the implication. The implication is that most of the DNS may become chaos except in the Google Class run be a unique centralised Google Public DNS. Just remember that the Chair of the IDNA2008 IETF WG is the boss of the the Google Public DNS and that they have the Google IETF internationalization specialist as an ICANN BoD Member.

This is obvioulsy something that China, Russia, India probably Europe cannot accept easily. The day they understand (or actually the day they want to use it) they will object and build their own DNS version (everyone can do that and share its config files). Bye Bye ICANN. What is astonishing is that ICANN does not even care …

I for one appreciate and respect your efforts.

To your specific comments:

1. China: yes this has worked well at the _second_level_ with a plugin and/or re-direct inside China. That is however not the same as inserting IDN TLds in the rootzone. One thing is the technical feasibility, another is the policy aspects. (not re the above, the policy aspects are dealth with in the ICANN community. For gTLDs this is via the GNSO and for ccTLDs this is via the ccNSO. Othen various advisory committes provide input as well).

2. Email: you are right, getting emails out in IDNs would be great. The protocol is under development in the IETF. A LOT of people are spending their free time making this happen and again, the IETF is open for participation for anyone interested and able to do so. Once the protocol is completed I am sure it will be implemented by various email software providers – some already have. This however does not lie inside the mandate of ICANN and any application developers decides if they want to implement that fucntionality or not.

3. gtlds vs cctlds: they follow two different processes. One thing that was agreed upon between the various groups in the ICANN community was that if either of the two processes was ready before the other, then none should be slowed down. There is nothign else to it than that….

4. # in Fast Track: yes, the remaining are in evaulation. This means that we are still processing them and/or that the requestors are working on aspects of their request. The total is 17 (including the four that passed String Evaulation).

It almost sounds to your comments like anybody should be allowed to get any string they want in the root zone, with no processes or check/rules etc in place. Well, that is not how things work and if they did we would not have the Internet we have today.

At least I know that I (just like many others on ICANN staff) are putting in a lot of extra hours (and no we do not get paid overtime) to make things work well and as quickly as possible. What do you do? Posting negative comments on the blog, you are off course welcome to do so, but it does not seem very productive to me….

“Since Fast Track is supposed to be a technical feasibility test….”

This is incorrect. There are a number of requirement other than those in the technical evaulation step. For example, government support, community support for the string, resemblance of the countryname etc. Please see the Implementation Plan at: http://www.icann.org/en/topics/idn/fast-track/

Tina

Make no mistake. I am happy for the future of IDN. Icann only seems to be a road block.

China has used their IDN .中国 for years and it has resolved within China for that time. They only want it to go global. Who is standing in the way?

Actually, IDN haven’t worked well. There are many things that still aren’t working for IDN. E-mail being the biggest and largest set back for full adoption. Not to mention you are not treating IDN cctlds and IDN gtlds the same.

You have held back IDN gtlds while given a green light on cctlds. Thus saying all IDN are not equal.

Four days into the fast track program, by your own account, you had 10 requests in 4 languages. Yet you’ve only allowed 2 languages and 4 requests through to the final step. How is that possible? It’s been 3 weeks since you’ve announced this. Where are the others? Fast-Track? Really?

Yes, you are very clearly standing in the way. So no, the failing is only on you.