Home / Blogs

Making IDN gTLDs Attractive and Safe

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.

By Tina Dam, Co-Founder MYTLD

Filed Under


Moving in the right direction Ronald N. Andruff  –  Feb 28, 2011 5:05 PM

Your analysis is enlightening, Tina.  We have long argued that ICANN’s policy of forcing community-based applicants to choose which single language they will offer their multilingual communities (and which ones they not will be able to offer due to the exorbitant cost of $185K for each translation) is patently unfair and in direct opposition to ICANN’s stated goal of bringing forward IDNs as fast as possible.  With your long experience with IDNs, your recommended way forward makes a lot of sense and seems more than feasible.  The only points of contention I would raise is that this path should (1) be considered exclusively for community-based applicants only in order for them to best serve their communities; and (2) the strings themselves must be real words that one can find in any dictionary in the world (as opposed to constructed words such as .COM) to ensure that translations are exact.  Otherwise, I agree 100% with your recommendations.  Thanks for bringing them to the table! It would be welcome news if ICANN would finally hear the Community’s call—rather than being stuck in how big their litigation fund must be—and modify this element to meet community-based needs before the start of applications!

Kind regards,

Ron Andruff

Let's make it easy for groups that use multiple scripts too Andrew Mack  –  Feb 28, 2011 7:35 PM


There’s a lot to like in your proposal.  There’s a lot of common sense and a lot that fits what we members of the Joint Applicant Support Working Group have been discussing. 

As you know, our group is tasked with looking at how the community can support deserving applicants, especially applicants from emerging markets, so that they can participate in and benefit from the new gTLD process.  And, while I’m not sure I’d go as far as to accept the $185k application fee as a given – after all, it’s hardly a “level playing field” if you are applying from Senegal or Sri Lanka – I agree with what I see as your broader premises: that the goal is to get people where they want to go on the web, and to represent groups in the way they see themselves.

You mention the tt-gTLD as an example, and your approach seems sound.  In our Working Group we’ve also looked at the importance of working with communities, NGOs and others that have a multi-script identity, groups around the world who want to go about their day to day lives using more than one script.  Some of these are in larger languages, such as Bengali and English in India, Arabic and French in Tunisia or in smaller cases, such as the Cree community in North America that uses both Latin and Cree script. 

The key here is that to offer them the choice of only one script (or two scripts at the bargain price of $370k), well, this is an unacceptable choice for all but the wealthiest communities, NGOs and local companies.  It’s like asking which one leg would you like to stand on?

Clearly more work needs to be done on this to get the balance right.  That said, as you rightly note the “technical” cost of an additional tt-gTLD (or a “connected IDN” for that matter) is not an additional $185k.  In fact, dual-script applications wouldn’t need a subsidy at all assuming the applicant would pay the incremental cost of evaluating a second string.

If we want to accommodate minority languages as you say in your point 6, I think we need to stop discriminating against these dual script communities and see them as they are – one application representing two parts of a applicant’s self expression. 

I hope that the ICANN community will support our Working Group as we try to build the expertise and raise the funds that will be needed to provide support to needy groups.  I believe we can get to what Peter Dengate Thrush discussed today in Brussels – a process that is predictable and not subject to gaming.  Still, in our push for certainty, let’s not confuse users or penalize groups who, unlike most of here in the US, are capable of living and working in more than one script.

Andrew Mack

Very insightful post Tina.There has been plenty Constantine Roussos  –  Feb 28, 2011 11:32 PM

Very insightful post Tina.

There has been plenty of discussions about this important topic but the Applicant Guidebook has not yet tackled these issues. I have been pretty vocal about the transliterated gTLDs as well as synonyms. By not incorporating bundling pricing and a realistic approach to gTLDs and IDN gTLDs I believe users will lose out on IDN gTLDs that would launch if not for the financial burdens imposed by ICANN fees on adding transliterations. Also by not dealing directly with the synonym/transliteration problem (variance vs translations), confusion will be prevalent amongst users.

Many new applicants are ready to work with multilingual new TLDs but ICANN has not yet addressed the bundling/transliteration/synonym issue. I have made public comments at ICANN a few times and at Dot-Nxt about this overarching issue that has not been fully addressed. It is not a complicated problem to solve and I believe the Internet community has a lot to gain from it.

Where confusion might arise is in the cases where synonyms or transliterations eg .music vs .musique are run by 2 mutually-exclusive registries with different policies and objectives. Also by ICANN not addressing the bundling issue, new opportunities and innovation are missed. Is having a .music IDN gTLD in Arabic better than not having it altogether for Arabic speakers, because bundling pricing was not allowed? If ICANN does believe IDNs are significant, the necessary incentives need to be aligned to bring a host of benefits to a global internationalized audience.

Great job on getting the IDN ccTLD Fast Track program launched successfully by the way. ICANN needs more success stories like that. I am sure Kurt Pritz and the rest of the ICANN staff will work on solving the transliteration/synonym and bundling issues in a transparent manner. The community has expressed its opinion many times and I have not heard one person disagree that bundled pricing and a more practical approach to transliterations needs to be adopted. I am convinced that these issues will be addressed in the next final Applicant Guidebook.

Excellent analysis and I support it,

Constantine Roussos

Thanks and moving forward Tina Dam  –  Mar 1, 2011 10:40 PM

@ Ron, thanks for the support. I am not 100% sure I agree with your argument for community/dictionary words only - if people are confused they are confused, which means we have an obligation to start more conservatively for all. But I am ready to talk more and be convinced otherwise :-)

@ Andrew, thanks for the support and feedback. Yes I do know the work of JAS and I am sympathetic to how difficult it must be to get good rules in this area. I am curious as to what the JAS is doing moving forward after the last comment period?

@ Constantine, thanks for the support. It is interesting to think about after all this discussion on the subject why we (broadly the ICANN community) did not conduct an analysis of end-user potential for confusion. Or maybe we did and I missed it?

What we are trying to do is to introduce user choice, competition, innovation and so forth. What concerns me is that with possible hundreds of new TLDs in the market with no regulation on translated TLDs etc people get confused and the positive effect we were looking for does not happen.

I completely stand to be corrected if people think I am wrong. I am not trying to criticize anything, and my argument/opinion of confusion is based on personal experience. I am hesitant to propose an end-user survey or analysis because I don’t want things to be delayed but I truly believe in an initial more conservative approach that we then can open up for later. Maybe we could start by asking the Registry Stakeholder Group and potential applicants if they did some analysis in determining how to run translated TLDs and why they elected various “coordinated efforts”? I was not at .nxt but understand the subject was discussed there as well – anyone?


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global


Sponsored byDNIB.com

Brand Protection

Sponsored byCSC


Sponsored byVerisign

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign