Skip to main content

Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    idnabis mailing list <>, 
    idnabis chair <>
Subject: Document Action: 'Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale' to Informational RFC

The IESG has approved the following document:

- 'Internationalized Domain Names for Applications (IDNA): Background, 
   Explanation, and Rationale '
   <draft-ietf-idnabis-rationale-17.txt> as an Informational RFC

This document is the product of the Internationalized Domain Names in Applications, Revised Working Group. 

The IESG contact persons are Lisa Dusseault and Alexey Melnikov.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary
The Internationalized Domain Names for Applications (IDNA) revisions are
intended to reduce significantly IDNA dependency on specific versions of
the Unicode character coding system. The Working Group produced the
following documents representing a revision to the earlier “IDNA2003”
proposed standard [only RFC 3490 is specifically affected]:
Definitions: draft-ietf-idnabis-defs-11.txt
Protocol: draft-ietf-idnabis-protocol-16.txt
Bi-Di: draft-ietf-idnabis-bidi-06a.txt
Tables: draft-ietf-idnabis-tables-07.txt
Rationale: draft-ietf-idnabis-rationale-13.txt
Mappings: draft-ietf-idnabis-mappings-04.txt

Of these, Definitions, Protocol, Bi-Di and Tables are normative;
Rationale is informative and mappings is optional (Informational).

Working Group Summary
The initial impetus for the revisiting of the IDNA2003 proposed standards
emerged in written form in RFC4690. An informal technical team worked to
develop a framework for consideration that was later discussed, edited,
and ratified to create the IDNABIS working group in 2008. Readers will
note that this is nearly 2010 but the new specifications bear the label
IDNA2008 because the work was started in that year. The documents
resulting from the IDNABIS Working Group effort have been extensively
discussed over a two year period by the WG and by interested parties
especially language experts in the Chinese, Japanese and Hangul spaces,
speakers of Hebrew, Indic languages as well as a working group of expert
Arabic speakers. The WG has had the participation of several Unicode
consortium representatives. There was controversy during the development
of these documents but a rough consensus has formed around the

There was an impasse relating to mapping of Unicode characters into other
Unicode characters prior to the generation of a punycode equivalent string
to produce an A-label [please see the Definitions document]. This was
resolved by introducing the non-normative “mappings” document observing
ways in which this aspect of dealing with internationalized domain names
might be approached. The principal rationale for re-visiting the IDNA2003
recommendations arose from field experience and a recommendation from the
IAB [RFC4690]. A major objective was to re-specify the standard in such a
way as to make it independent of changes to the Unicode code set
(something that evolves more or less continuously). The method for
achieving this is to use the Unicode properties feature (per
code-point/character) to determine whether the code point should be
allowed, disallowed or used only under certain conditions in domain name
labels. There remains the problem of deployment in a world of web servers,
browsers and other applications using domain names that may have already
implemented the IDNA2003 recommendations.

Implementation tactics for dealing with the old and new specifications
may vary. Perfect backward compatibility with IDNA2003 was not possible
(without simply replicating it, negating the rationale for the
redefinition effort of IDNA2008). This is particularly true of the special
characters “esszet” or “sharp-S” used in German and the “final sigma” used
in Greek. These were mapped into other valid Unicode characters under
IDNA2003 but allowed in IDNA2008 because the Unicode code points for these
were introduced in the interim between IDNA2003 and IDNA2008
standardization efforts. Registries have several implementation choices
including bundled registration of previously mapped and newly allowed
characters or rejection of conflicting new registrations. The treatment of
languages that are expressed in Right-to-Left form (see “Bi-Di” document)
has been revised relative to IDNA2003 and it is believed that the revision
is clearer and more precise in its form and limitations on the use of
numeric characters, for example.

Document Quality

There are test implementations of the rules proposed by IDNA2008 but no
released operational software. Such implementations have awaited the
achievement of rough consensus on the controversial parts of the new
proposals. Inputs from special expert bodies such as a Korean expert
language group, an informal Arabic speakers group, and a number of
individual commentators from the Unicode community, among others, have
contributed to the documents as they now exist. Multiple implementations
of the Tables rules have confirmed the stability of the definitions under
distinct implementations.

RFC Editor Note