The primary focus of this article is to illustrate that the Applicant Guidebook is not supplying sufficient protection mechanisms, and creates too high financial barrier for those who are interested in applying for multiple Top-Level Domains (TLDs) that are translations/transliterations of each other and/or of an existing generic Top-Level Domains (tt-gTLDs).

The proposed solution will replace the financial entry barrier with other limitations that I think are more adequate in order to encourage the availability of Internationalized Domain Name (IDN) gTLDs, and at the same time require that they are implemented and managed initially in a conservative and safe manner. This opens the opportunity to lessen restrictions in the future if it is safe to do so. We have many times in the past learned the lesson that restrictions cannot be imposed later on without difficulty and downsides to all parties involved.

Current Situation:

Per the current version of Draft Applicant Guidebook (DAG) anybody can apply for tt-gTLDs. Existing operators can object to applications for various reasons, such as “string confusion”. Each tt-gTLD must be applied for separately, to a cost of 185.000$ each, and with no relation between them.

Proposed Solution:

1. Applicants should be allowed to apply for multiple tt-gTLDs within the same application.

2. tt-gTLDs must always have the same registry operator. In other words, tt-gTLDs must be managed in one joint agreement with ICANN, and anything that affects one tt-gTLD must affect the others within the same agreement.

3. tt-gTLDs must be run in a coordinated manner. This should be generally consistent across gTLDs, but could vary slightly depending on the nature of the tt-gTLDs. This is where I am getting into trouble with the DNS technical capabilities as none exists for such coordination/“the same”/or anything like that. But as I argue below there is a user expectation for this behavior and while we cannot meet it technically we should attempt to get close.

To do so we could carefully analyze some of the following: the CNNIC management of IDN ccTLDs; the TWNIC management of IDN ccTLDs; the proposed VeriSign approach where registration rights are provided existing registrants that have registered [IDN].com; possibility of requiring that the language or script (and associated IDN table) of the top-level must match domains registered at second level. The latter does not mean third and lower levels will follow the same rule. But do we really want to start IDN gTLDs off by inviting possible phishing attacks with [russian].[german], or [spanish].[greek]?

While we do not see phishing attacks in IDNs at the moment, these security risks are still applicable especially considering that we do not have very restrictive IDN Guidelines (or other rules) to require cross-language/script IDN tables when multiple scripts/languages are operated under the same TLD.

4. The base application fee should be 185.000$, and each additional tt-gTLD (within the same application) should only incur an additional cost equivalent to the cost associated with the DNS Stability Panel Evaluation (in the Fast Track Process this was estimated 6.000$ per string but will likely be higher in gTLD Program as it is more extensive). Additional costs may still appear in extended evaluations and so forth.

5. An initial limit should be imposed on a maximum number of tt-gTLDs per applicant. Each of the tt-gTLDs should further be restricted initially to be one per language or script only.

6. Accommodation of minority languages should be encouraged through a specially developed program at ICANN supporting education, marketing, and information sharing with developing countries or regions. The topics should include both IDNs general functionality, usability, implementation, but also general DNS information—all adapted specifically to the need of each location.

7. tt-gTLD registry operators should be required to supply data and information related to their experience of managing the tt-gTLDs in accordance with rules set in 3). They should further participate in review and analysis of such implementations and openly provide their information to the public and to ICANN to improve the ongoing policy development and TLD Program enhancements.

Rationale and Arguments:

The overall argument must be that of avoiding confusion and ensuring consistency for users, which is in accordance with ICANN’s primary mission (to ensure the security and stability of the DNS and, in particular, the Internet’s root server system).

All current public tt-gTLD applicants have stated that their tt-gTLDs will be run in some sort of coordinated manner which means that they need a related or the same agreement with ICANN. This coordination would be destroyed if one tt-gTLD would be re-delegated and the rest would stay with the initial registry operator. Further, the general Internet user does not understand the functionality of IDNs. Most think that IDNs that are translations of for example an ASCII string, are ‘the same’, and think that the mapping between them magically happens somewhere so that it does not matter which one is typed into for example a browser address bar.

Now one might argue that trying to accommodate such expectations is (i) not possible technically; and (ii) too late because SLD translations already exists and is registered to different registrants. However, I think we should get as close to reaching that user expectation as possible. Simply because there already exist some level of confusion does not mean we should increase it, especially not with the top-level introduction.

Since protection mechanisms are planned by registry operators for future IDN gTLDs, let’s make them Best Practices For All as opposed to making it a decision made individually for each registry operator and thereby having a high risk for very different and thereby confusing mechanisms to be put in place.

If the initial requirements for management of the tt-gTLDs turns out to be too restrictive and preventing innovation then we can lessen them after some experience.

Comparison to Variant gTLDs:

At the moment variant TLDs cannot be applied for because they require some additional analysis, possible policy development, and implementation work to be done before it is decided if they can safely be delegated in the DNS.

From an end-user perspective what is the major difference between .gTLD-translated and .gTLD-variant?

The answer is: Not very different.

The average Internet user will expect them to be ‘the same’, at least to certain extent.

For example:

.koeln (basic ASCII option?)

.køln (translation of .köln but variant to .koeln?)

.köln (variant to the two above?)

.cologne (translation of all above?)

So while at least two of the top two three are variants and are awaiting more analysis to determine whether they can be allocated, the latter could be operated by a different registry. I think this is doing all Internet users a disfavor and will create an enormous confusion. Not only do users need to get used to a lot of new TLDs, they also will be implemented in different and confusing ways with no logical coordination or future protections.

Variants and translations create same problems although at differing scale: visual confusing variants, distinct variants, translations, transliterations, and mixes thereof. And no matter what general definition we try to find for variants, it will not match that of the user expectation. Is .köln and .cologne confusing and would an objection hold?

The DNS cannot manage TLDs as ‘the same’ and we need to be careful about setting such expectations and require training and marketing to be performed to explain this aspect. Contrary though, the user expectation is there, and instead of basing the result on the expectation that ‘someone’ will object if there is a problem, let’s put at least some basic rules in place, just like has been done for the couple of “variant IDN ccTLDs”. In this way we will also get much more experience to help ICANN’s project for figuring out what to do with the (remaining) “variant” TLDs (both ccTLDs and gTLDs).

“This is too difficult and objective to manage for ICANN”:

Domains names were not intended to be language expressions and because of this many domain names or labels do not have a natural translation, and many have multiple translations options. When we talk about ‘same as’ we are moving into difficult territory - who is going to make such determination of what is the same as? Will the decision be objective?

The truth is that this process simply cannot be implemented without some level of objective decision-making. I don’t see why ICANN should not make these decisions. ICANN has a certain mandate and staff is capable and hired to do so, so let them make the decisions.

Also, how hard is it to determine what is a translation and what is not? Take a look at the expected new gTLDs. They are for example listed here.

I would claim that a couple of individuals who did an amazing job in the IDN .test project (to determine translations by conducting outreach, questions to native speakers of certain languages, and visits to the library to research dictionaries) could also do so for the list of new gTLDs to validate the tt-gTLDs. In the rare case of disagreements such should be dealt with as corner cases and would hence take a bit longer than other applications.

Volume Restriction:

In order to avoid an insanely huge volume of tt-gTLDs in each application (you could imagine that for a low fee each applicant simply would translate or transliterate in as many languages as they could think possible) and since this is untouched territory (and as such obviously need some experience), I think it would be entirely appropriate for ICANN or the ICANN Board to set a maximum limit of such tt-gTLDs within an application to some reasonable number. Perhaps in the range of 10ish in the initial round, and one string per language or script only.

This is similar to the limit set in the IDN ccTLD Fast Track Process (one per country/territory per script or language…). While that volume restriction did not fit the need of all applicants this far in Fast Track, it did fit the need of the vast majority of the applicants. Is it perfect? No, probably not, but it would allow for more IDN gTLDs implemented in a careful manner, with a restriction set by the authority, as opposed to some financial barrier that only make it harder for certain regions to participate, and most likely would minimize the overall number of IDN gTLDs associated with a gTLD.

If IDN gTLDs is what we want, then let’s make them attractive and safe for the users to facilitate.

All opinions in this post are personal.