One of the main IDN questions asked by end-users in the last few months, and that have been discussed during the ICANN Paris meeting in the recent week is as follows:
“If I have registered <domainname>.tld, then how will you ensure that I am also the registrant of <domainname>.<idn-tld>, for all languages.”
The question shows that there is an expectation that:
(i) there is a way to translate the .tld into other languages. Having done that with .test I can assure you it is quite a challenge to find a word that is an adequate translation for all users in a community. Often there is more than one way to express the word “test” in various languages. Some existing TLDs might be easier to translate than others, but common for them is that they could be represented several ways within one language.
(ii) that the registry operator for the .tld will apply to become the operator for such new TLD(s), and that if they do so and are successful in their application, that they will implement .tld with an aliasing functionality where registrants under .tld automatically becomes registrants of the same domain names under .idn-tld
On the gTLD side of things:
a. the GNSO policy for introduction of new gTLDs states that there is not precedence for becoming an operator of an IDN TLD. In other words, just because you are operating a TLD today it does not mean that you automatically become the operator for any translated version of that TLD (being IDN or ASCII, but mostly discussed in relation to IDNs).
b. in the process for introduction of new gTLDs there are various objection procedures available. While they are not implemented completely yet you might imagine that the .tld registry operator might object to someone else applying for the IDN version the .tld.
c. The policy does not provide a global direction to registration policy regulations, such as for example whether or not new TLDs should be aliased to an existing TLD.
On the ccTLD side, the situation is similar:
a. the IDNC WG final report does not talk about this specific topic.
b. based on community discussions during the last few months, it could be anticipated some IDN ccTLD will be operated as aliased versions of the existing ccTLDs, and others will not. The decision is usually referred to a difference in opinion on whether there should be IP protection or more competition and choice.
On the technical side of things:
a. aliasing have often been connected to the concept of DNAME. DNAME have been initially tested, and indications are that it will not be useful to provide the aliasing functionality. ICANN is looking into the opportunity for having more tests done on this topic.
b. without a standard way of implementing aliasing the concern is that aliasing will be implemented in many different ways leaving users confused and a need to further education than currently is needed, which could be avoided.
In Summary: There is no guarantee to the registrants, it depends on whether existing registry operators will apply for the IDN version of the their TLDs; that the application is granted; and that they will implement aliasing as their registration policy, which we currently do not have a technical standard for, and which the policies are not providing global direction upon.