Internationalized Domain Name explained


internationalized domain name (IDN) is an Internet domain name that (potentially) contains non-ASCII characters. Such domain names could contain letters with diacritics, as required by many European languages, or characters from non-Latin scripts such as Arabic or Chinese. However, the standard for domain names does not allow such characters, and much work has gone into finding a way around this, either by changing the standard, or by agreeing on a way to convert internationalized domain names into standard ASCII domain names while preserving the stability of the domain name system.

IDN has, by the standards of the Internet, a long history; it was originally proposed in 1996 (by M. Duerst) and implemented in 1998 (by T.W.Tan et al). After much debate and many competing proposals, a system called Internationalizing Domain Names in Applications (IDNA) was adopted as the chosen standard, and is currently, as of 2005, in the process of being rolled out.

In IDNA, the term internationalized domain name means specifically any domain name consisting only of labels to which the IDNA ToASCII algorithm can be successfully applied. (For the meaning of 'label' and 'ToASCII', see the section ToASCII and ToUnicode below.)

Internationalizing domain names in applications


Internationalizing Domain Names in Applications (IDNA) is a mechanism defined in 2003 for handling internationalized domain names containing non-ASCII characters.Such domain names could not be handled by the existing DNS and name resolver infrastructure. Rather than redesigning the existing DNS infrastructure, it was decided that non-ASCII domain names should be converted to a suitable ASCII-based form by web browsers and other user applications; IDNA specifies how this conversion is to be done.

IDNA was designed for maximum backward compatibility with the existing DNS system, which was designed for use with names using only a subset of the ASCII character set.

An IDNA-enabled application is able to convert between the restricted-ASCII and non-ASCII representations of a domain, using the ASCII form in cases where it is needed (such as for DNS lookup), but being able to present the more readable non-ASCII form to users. Applications that do not support IDNA will not be able to handle domain names with non-ASCII characters, but will still be able to access such domains if given the (usually rather cryptic) ASCII equivalent.

ICANN issued guidelines for the use of IDNA in June 2003,and it was already possible to register .jp domains using this system in July 2003. Several other top-level domain registries started accepting registrations in March 2004.

Mozilla 1.4, Netscape 7.1, Opera 7.11 and Safari are among the first applications to support IDNA. A browser plugin is available for Internet Explorer 6 to provide IDN support. Internet Explorer 7.0 and Windows Vista's URL APIs provide native support for IDN.

ToASCII and ToUnicode


The conversions between ASCII and non-ASCII forms of a domain name are accomplished by algorithms called ToASCII and ToUnicode. These algorithms are not applied to the domain name as a whole, but rather to individual labels. For example, if the domain name is www.example.com, then the labels are www, example and com, and ToASCII or ToUnicode would be applied to each of these three separately.

The details of these two algorithms are complex, and are specified in the RFC linked at the end of this article. The following gives an overview of their behaviour.

ToASCII leaves unchanged any ASCII label, but will fail if the label is unsuitable for DNS.If given a label containing at least one non-ASCII character, ToASCII will apply the Nameprep algorithm (which converts the label to lowercase and performs other normalization) and will then translate the result to ASCII using Punycode before prepending the 4-character string "xn--". This 4-character string is called the ACE prefix, where ACE means ASCII Compatible Encoding, and is used to distinguish Punycode-encoded labels from ordinary ASCII labels.Note that the ToASCII algorithm can fail in a number of ways; for example, the final string could exceed the 63-character limit for the DNS. A label on which ToASCII fails cannot be used in an internationalized domain name.

ToUnicode reverses the action of ToASCII, stripping off the ACE prefix and applying the Punycode decode algorithm. It does not reverse the Nameprep processing, since that is merely a normalization and is by nature irreversible.Unlike ToASCII, ToUnicode always succeeds, because it simply returns the original string if decoding would fail. In particular, this means that ToUnicode has no effect on a string that does not begin with the ACE prefix.

Example of IDNA encoding


As an example of how IDNA works, suppose the domain to be encoded is B


<-- Previous | Home Glossary | Next -->

Latest tweets mentioning Internationalized Domain Name


Latest blogs mentioning Internationalized Domain Name

readyspace.com.my Icon - Jul 30, 2019 - Internationalized Domain Name (IDN) Conversion Tools - CentOS Web Panel is deployed in Cloud Server Linux. Contact us to find out our latest offers! The post Internationalized Domain Name (IDN) Conversion Tools appeared first on ReadySpace Malaysia.
readyspace.com Icon - Jul 30, 2019 - Internationalized Domain Name (IDN) Conversion Tools – Control WebPanel Wiki - When working with a domain name containing international (non-ASCII) characters, you need to convert the domain name into “punycode” before adding it to the CWP,DNS or Web server. You can use this IDN Conversion Tools to convert your domain from ...

Latest news about Internationalized Domain Name

Internationalized Domain Name Program Adds Two Languages - Jun, 2008 - MARINA DEL REY, Calif.: Thai and Urdu are the newest languages available on the Internet Corporation for Assigned Names and Numbers wikipages set up for the global testing of Internationalized Domain Names (IDNs). ...
Internationalized Domain Names - Nov, 2000 - Workshop at ICANN Annual Meeting (13 November) For several months, a working ...
Internationalized Domain Names Working Group Requests Additional Information - Jun, 2001 - Marina del Rey, California, USA (21 June 2001) At the ICANN Stockholm meeting, the Internationalized Domain Names Internal ...