�

Internationalized Domain Names

The Internet, despite its current high development state and its popularity, has not overcome the barrier related to the use of diacritics and some foreign languages in general in domain names. That state have made many of the users to make up and use sometimes unconventional or awkward names derived from their mother tongue. There has been a research going on for two years in order to overcome that barrier. The devised solution is called Internationalized Domain Names (IDN). A IDN is a domain that may contain any letters, digits (a hyphen may be used as well) that come from of the repertoire of the Unicode (the UTF8 coding, www.unicode.org).

Among many IDN implementation internet drafts the following were chosen by The Internet Engineering Task Force (IETF, www.ietf.org):

• Internationalizing Domain Names In Applications (IDNA). (RFC3490) . it is a document defining IND and a mechanism called IDNA responsible for its implementation.
• Nameprep: A Srtingprep Profile for Internationalized Domain Names (IDN). (RFC4391) . the document is a profile of the .Stringprep. which describes rules of forming of IDN domain labels.
• Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications. (RFC 3492) . it is a document describing the Punycode coding algorithm which is an of instance Bootstring one. The algorithm allows to re-encode Unicode strings into ASCII ones composed of letters, digits and hyphens only. The mapping is unambiguous, i.e. for each given Unicode string there is one and only one corresponding ASCII coded string.

The idea behind the IDN and its supporting mechanism (the IDNA protocol) is based on distinction between the Unicode type domain and ASCII coded one.

The ASCII coded form of IDN domain is derived after performing the Punycode algorithm based translation on the Unicode domain name. The derived ASCII coded domain name is then stored as DNS resources i.e. in databases and name servers. configuration files, as usual.

The way of using the IDN type domains is no different then the traditional way of coping with domains. Principles of working with IDNA may be easily explained by the example involving an internet browser. We need to be provided with the newest version of an internet browser capable of coping with IDN or install the IDN plug-in to our current browser. Then, all that is left for us to do is to open a page of our interest , e.g. www.¼d¼b³o.dns.pl. The entered domain name with diacritics represented by Unicode string within our operating system is then recoded to corresponding ASCII representation. The application sends such representation to a resolver in order to obtain the IP address of the WWW server identified by that domain name. As it can be seen, the user does not even need to be aware of the Unicode to ASCII translation as it is being performed within the web browser.

The IDNA protocol implementation does not introduce any change to the DNS.s infrastructure. It means that there is no need to alter any of the existing Internet.s protocols in order to get the IDN working. The IDNA protocol interferes only in the top level layer of the OSI model, therefore the IDN introduction requires only upgrades of software which interacts with domains, such as web browsers, e-mail and ftp clients, html editors etc. Popularity of IDNA depends mainly on spreading of that kind of software.

On the 14th of 2003 The Internet Assigned Numbers Authority (IANA, www.iana.org) chose the .xn. pefix for the ACE form of IDN domains. Then, on the 7th of 2003 RFC Editor (www.rfc-editor.org) announced mentioned projects as RFC documents. Currently they have standards track status (see RFC 2026). The new standard is about to be issued.

2003.04.30