RFC 3743 (rfc3743) - Page 3 of 33

Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean

RFC 3743                 JET Guidelines for IDN               April 2004


1.  Introduction

   Domain names form the fundamental naming architecture of the
   Internet.  Countless Internet protocols and applications rely on
   them, not just for stability and continuity, but also to avoid
   ambiguity.  They were designed to be identifiers without any language
   context.  However, as domain names have become visible to end users
   through Web URLs and e-mail addresses, the strings in domain-name
   labels are being increasingly interpreted as names, words, or
   phrases.  It is likely that users will do the same with languages of
   differing character sets, such as Chinese, Japanese and Korean (CJK),
   in which many words or concepts are represented using short sequences
   of characters.

   The introduction of what are called Internationalized Domain Names
   (IDN) amplifies both the difficulty of putting names into identifiers
   and the confusion that exists between scripts and languages.
   Character symbols that appear (or actually are) identical, or that
   have similar or identical semantics but that are assigned the
   different code points, further increase the potential for confusion.
   DNS internationalization also affects a number of Internet protocols
   and applications and creates additional layers of complexity in terms
   of technical administration and services.  Given the added
   complications of using a much broader range of characters than the
   original small ASCII subset, precautions are necessary in the
   deployment of IDNs in order to minimize confusion and fraud.

   The IETF IDN Working Group [IDN-WG] addressed the problem of handling
   the encoding and decoding of Unicode strings into and out of Domain
   Name System (DNS) labels with the goal that its solution would not
   put the operational DNS at any risk.  Its work resulted in one
   primary protocol and three supporting ones, respectively:

      1. Internationalizing Host Names in Applications [IDNA]
      2. Preparation of Internationalized Strings [STRINGPREP]
      3. A Stringprep Profile for Internationalized Domain Names
         [NAMEPREP]
      4. Punycode [PUNYCODE]

   IDNA, which calls on the others, normalizes and transforms strings
   that are intended to be used as IDNs.  In combination, the four
   provide the minimum functions required for internationalization, such
   as performing case mappings, eliminating character differences that
   would cause severe problems, and specifying matching (equality).
   They also convert between the resulting Unicode code points and an
   ASCII-based form that is more suitable for storing in actual DNS
   labels.  In this way, the IDNA transformations improve a user's
   chances of getting to the correct IDN.



Konishi, et al.              Informational