During the breakfast pre-panel discussion, a few of us were sitting around and discussing IDN Top Level Domains (TLDs). Normally, such debates goes no where but surprisingly, we actually got some agreement this time!
The first thing we note is that there is no perfect solution. Every proposals has some problems – it does not work with ccTLD; it breaks gTLD; it does not handle minority languages/scripts; it has collision with other languages; etc. So we should just try to find a solution which has the least amount of pain, so long it works, can scale and can be implemented reasonably.
Another thing to note is that gTLD, sTLD and ccTLD are very different from one another. It is unlikely we can find a solution that works for all type TLD. We should tackle them individually and differently.We agreed we should start with IDN ccTLD1 because we have no dispute who should be the operators of IDN ccTLD and we aren’t creating new SOA (Start-of-Authority). ccTLD operators are also close to their community hence in the best position to know what and how to provide IDNs to their users.
The idea of IDN ccTLD scared a lot of ICANN people – Imaging 240 ccTLD multiple by 2000+ languages, that’s 4m+ TLDs all in the root zone file. However, this is similar to saying we have 37 LDH (letters-digits-hypen) and 255 possible labels, and we could potentially nearly 38^255-1 TLDs! Wow.
The reality is that no ccTLD in the world is going to ask 2000 languages; Most will ask only one or at most, a handful like India. (See List of Official Languages).
Another often cited reason for not able to do IDN ccTLD is the lack of equivalent translated ISO 3166-1 alpha-2 code. While there are translation of ISO 3166-1 available, it is translated per-Member State, ie, there isn’t an definite authoritive list, and no translation for alpha-2 codes which is what we use in ccTLD.
And don’t wait for it – it aren’t going to happen in any reasonable amount of time. Instead, think of a open transparent process – set rules and requirements and layout procedure for obtaining IDN ccTLD. And the following are the rough idea of what we agreed upon:
1. Applicant must be existing ccTLD operator (with demostrated IDN capability).
2. IDN ccTLD proposed must be a “major” language2 in the region.
3. Applications to be published on ICANN website for X days for public comments and official objections.
4. Official objections must be valid and relevant to the application and can only be filed by other TLD operators.
5. In case of conflict, application will be put on hold while parties work out their differences.
The advantage of such procedure is that it allows non-controvisal IDN ccTLD to proceed. It allows those who want it, need it, most to get them and proceed while not held hostage by other special interest.
It is also unlikely we will create a lot of IDN ccTLD through this process initally. There are probabaly 20 ccTLD which IDN capability today, and of which, half of them (like .de, .fr etc) have no interest in IDN ccTLD. I would be surprise to see more then 10 IDN ccTLD created via this mechanism.
The disadvantage is this process does not deal with minority languages. That’s why we need to look at IDN sTLD as a process to fill this gap. Catalan proposed .cat, for example, would be a good start. And if ICANN wants to be even more prudent, by all means impose further restriction, such as imposing trial phase (for a period of time) and limit number of such IDN ccTLD to release initially.
[I made a presentation on this at the IDN policy panel @ ICANN]
1 This is not to suggest we don’t do IDN gTLD and IDN sTLD. We need to work on different rules for those.
2 “major” could be defined as official language or spoken by majority.
