Skip to main content

Main IDN User Question

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.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."