RFC 3490 (rfc3490) - Page 2 of 22

Internationalizing Domain Names in Applications (IDNA)

RFC 3490                          IDNA                        March 2003


         3.2.2. Non-domain-name data types stored in domain names...  9
   4. Conversion operations.........................................  9
      4.1 ToASCII................................................... 10
      4.2 ToUnicode................................................. 11
   5. ACE prefix.................................................... 12
   6. Implications for typical applications using DNS............... 13
      6.1 Entry and display in applications......................... 14
      6.2 Applications and resolver libraries....................... 15
      6.3 DNS servers............................................... 15
      6.4 Avoiding exposing users to the raw ACE encoding........... 16
      6.5  DNSSEC authentication of IDN domain names................ 16
   7. Name server considerations.................................... 17
   8. Root server considerations.................................... 17
   9. References.................................................... 18
      9.1 Normative References...................................... 18
      9.2 Informative References.................................... 18
   10. Security Considerations...................................... 19
   11. IANA Considerations.......................................... 20
   12. Authors' Addresses........................................... 21
   13. Full Copyright Statement..................................... 22

1. Introduction

   IDNA works by allowing applications to use certain ASCII name labels
   (beginning with a special prefix) to represent non-ASCII name labels.
   Lower-layer protocols need not be aware of this; therefore IDNA does
   not depend on changes to any infrastructure.  In particular, IDNA
   does not depend on any changes to DNS servers, resolvers, or protocol
   elements, because the ASCII name service provided by the existing DNS
   is entirely sufficient for IDNA.

   This document does not require any applications to conform to IDNA,
   but applications can elect to use IDNA in order to support IDN while
   maintaining interoperability with existing infrastructure.  If an
   application wants to use non-ASCII characters in domain names, IDNA
   is the only currently-defined option.  Adding IDNA support to an
   existing application entails changes to the application only, and
   leaves room for flexibility in the user interface.

   A great deal of the discussion of IDN solutions has focused on
   transition issues and how IDN will work in a world where not all of
   the components have been updated.  Proposals that were not chosen by
   the IDN Working Group would depend on user applications, resolvers,
   and DNS servers being updated in order for a user to use an
   internationalized domain name.  Rather than rely on widespread
   updating of all components, IDNA depends on updates to user
   applications only; no changes are needed to the DNS protocol or any
   DNS servers or the resolvers on user's computers.



Faltstrom, et al.           Standards Track