Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
RFC 5895

Document Type RFC - Informational (September 2010; No errata)
Authors Paul Hoffman  , Pete Resnick 
Last updated 2018-03-30
Replaces draft-ietf-idnabis-mappings
Stream Independent Submission
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream ISE state (None)
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5895 (Informational)
Action Holders
Telechat date
Responsible AD Peter Saint-Andre
Send notices to
Independent Submission                                        P. Resnick
Request for Comments: 5895                         Qualcomm Incorporated
Category: Informational                                       P. Hoffman
ISSN: 2070-1721                                           VPN Consortium
                                                          September 2010

                         Mapping Characters for
       Internationalized Domain Names in Applications (IDNA) 2008


   In the original version of the Internationalized Domain Names in
   Applications (IDNA) protocol, any Unicode code points taken from user
   input were mapped into a set of Unicode code points that "made
   sense", and then encoded and passed to the domain name system (DNS).
   The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893)
   presumes that the input to the protocol comes from a set of
   "permitted" code points, which it then encodes and passes to the DNS,
   but does not specify what to do with the result of user input.  This
   document describes the actions that can be taken by an implementation
   between receiving user input and passing permitted code points to the
   new IDNA protocol.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Resnick & Hoffman             Informational                     [Page 1]
RFC 5895                      IDNA Mapping                September 2010

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

1.  Introduction

   This document describes the operations that can be applied to user
   input in order to get it into a form that is acceptable by the
   Internationalized Domain Names in Applications (IDNA) protocol
   [IDNA2008protocol].  It includes a general implementation procedure
   for mapping.

   It should be noted that this document does not specify the behavior
   of a protocol that appears "on the wire".  It describes an operation
   that is to be applied to user input in order to prepare that user
   input for use in an "on the network" protocol.  As unusual as this
   may be for a document concerning Internet protocols, it is necessary
   to describe this operation for implementors who may have designed
   around the original IDNA protocol (herein referred to as IDNA2003),
   which conflates this user-input operation into the protocol.

   It is very important to note that there are many potential valid
   mappings of characters from user input.  The mapping described in
   this document is the basis for other mappings, and is not likely to
   be useful without modification.  Any useful mapping will have
   features designed to reduce the surprise for users and is likely to
   be slightly (or sometimes radically) different depending on the
   locale of the user, the type of input being used (such as typing,
   copy-and-paste, voice, and so on), the type of application used, etc.
   Although most common mappings will probably produce similar results
   for the same input, there will be subtle differences between

1.1.  The Dividing Line between User Interface and Protocol

   The user interface to applications is much more complicated than most
   network implementers think.  When we say "the user enters an
   internationalized domain name in the application", we are talking
   about a very complex process that encompasses everything from the
   user formulating the name and deciding which symbols to use to

Resnick & Hoffman             Informational                     [Page 2]
RFC 5895                      IDNA Mapping                September 2010

   express that name, to the user entering the symbols into the computer
   using some input method (be it a keyboard, a stylus, or even a voice
   recognition program), to the computer interpreting that input (be it
   keyboard scan codes, a graphical representation, or digitized sounds)
   into some representation of those symbols, through finally
Show full document text