Internationalizing Domain Names in Applications (IDNA)
RFC 3490

 
Document Type RFC - Proposed Standard (March 2003; Errata)
Obsoleted by RFC 5891, RFC 5890
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state WG Document
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3490 (Proposed Standard)
Telechat date
Responsible AD Erik Nordmark
IESG note Updated drafts are available. Need to be reviewed to see
if the IESG comments have been addressed.
Send notices to <jseng@pobox.org.sg>, <Marc.Blanchet@viagenie.qc.ca>
Network Working Group                                       P. Faltstrom
Request for Comments: 3490                                         Cisco
Category: Standards Track                                     P. Hoffman
                                                              IMC & VPNC
                                                             A. Costello
                                                             UC Berkeley
                                                              March 2003

         Internationalizing Domain Names in Applications (IDNA)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   Until now, there has been no standard method for domain names to use
   characters outside the ASCII repertoire.  This document defines
   internationalized domain names (IDNs) and a mechanism called
   Internationalizing Domain Names in Applications (IDNA) for handling
   them in a standard fashion.  IDNs use characters drawn from a large
   repertoire (Unicode), but IDNA allows the non-ASCII characters to be
   represented using only the ASCII characters already allowed in so-
   called host names today.  This backward-compatible representation is
   required in existing protocols like DNS, so that IDNs can be
   introduced with no changes to the existing infrastructure.  IDNA is
   only meant for processing domain names, not free text.

Table of Contents

   1. Introduction..................................................  2
      1.1 Problem Statement.........................................  3
      1.2 Limitations of IDNA.......................................  3
      1.3 Brief overview for application developers.................  4
   2. Terminology...................................................  5
   3. Requirements and applicability................................  7
      3.1 Requirements..............................................  7
      3.2 Applicability.............................................  8
         3.2.1. DNS resource records................................  8

Faltstrom, et al.           Standards Track                     [Page 1]
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
Show full document text