Internet Draft                                 D. Crocker
     draft-crocker-idn-idna-00.txt Brandenburg InternetWorking
     Expires in six months                       23 June  2002




               Internationalizing Domain Names
                   in Applications (IDNA)



     Status of this Memo

     This document is an Internet-Draft and is in full
     conformance with all provisions of Section 10 of
     RFC2026.

     Internet-Drafts are working documents of the Internet
     Engineering Task Force (IETF), its areas, and its
     working groups. Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum
     of six months and may be updated, replaced, or obsoleted
     by other documents at any time. It is inappropriate to
     use Internet-Drafts as reference material or to cite
     them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be
     accessed at http://www.ietf.org/shadow.html.


     Abstract

     Internationalized Domain Names (IDN) use Unicode for
     domain name, rather than using a subset of ASCII.  This
     increased name space, as well the requirement to
     maintain compatibility with the existing domain name
     service means that IDNs must be encoded in a form that
     can be supported without changes to any portion of the
     DNS that does not participate in the upgrade to IDN.
     This specification defines a mechanism called IDNA for
     handling them in a standard fashion and specifies an
     IDNA profile for domain names used as host references.
     IDNA allows non-ASCII characters to be represented using
     the same octets used in so-called host names today. This
     representation allows IDNs to be introduced with minimal
     changes to the existing DNS infrastructure. IDNA is only
     meant for processing domain names, not free text.



0.   Document Change Notes --

     This is a revision to draft-ietf-idn-idna-09.txt.  It is
     being distributed independently to facilitate
     discussion.

     The goal is to gain consensus about revisions to the IDN
     working group document, specifically for the following
     changes:

        a.   Split the document into two, one for defining
           Internationalized Domain Names (IDN) and the other for
           defining an encoding method of IDNs, namely IDNA using ACE.

        b. Distinguish general IDNA from its specific use for host
           names (IDNA-Host), by factoring the two into separate
           specification sections.  Use for host names is specified more
           precisely, in terms of a specific syntax BNF rule from the
           relevant existing DNS specification, so that IDNA-Host will
           apply precisely to all DNS record fields and protocol units
           conforming to that BNF.

        c. Distinguish Domain Name character set enhancement (IDN)
           from the encoding approach for 'non-native' representations
           (IDNA).

        d. Further clarification of distinction between IDNA world
           and non-IDNA world.

        e. Remove historical commentary.  At the least, it needs to
           be outside of the sections with normative text, or otherwise
           distinguish as being non-normative.

        f. Except for specification of the ACE-based mechanism,
           move  software, API and other host-specific discussion into a
           non-normative appendix, so that the specification is
           restricted to protocol-only details. f.  Distinguish user
           presentation from protocol and storage encoding.

        g. Change the anthropomorphic, ambiguous use of 'aware' and
           'unaware' to refer to the nature of encoding as IDN-native
           and IDN-ACE.

     Notations:

     Text, such as citations, that needs to be provided is
     indicated by <<???>>.  Personal comments are indicated
     by << // xqqy // /Dave >>

     The changes are extensive, so that providing change
     marks would be more distracting than helpful.  Still,
     most of the changes are slight language modifications
     and some moving of text around.  Most of the original
     text is still present.



1.   Introduction

     Expansion of the DNS namespace to permit Unicode, rather
     than a subset of ASCII, requires special handling of the
     binary data, within an ASCII DNS environment.  This
     document proceeds from <id: draft-idn-idn-00.txt> and
     defines:

          1)   A mechanism called IDNA for handling them in a
               standard fashion within the current, ASCII-based
               DNS, using an ASCII-compatible encoding (ACE) of
               the IDN string

          2)   An IDNA profile, called IDNA-Host for domain
               names used as references host references, such
               as for URLs and email addresses.

     IDNA allows applications to use ASCII name labels that
     begin with a special prefix, to represent non-ASCII name
     labels. Protocols that transport domain names need not
     support this mapping; therefore IDNA does not require
     changes to any protocol infrastructure. Equally, IDNA is
     transparent to DNS servers and resolvers that do not yet
     participate in the IDNA enhancement; the ASCII name
     service provided by the existing DNS is sufficient for
     handling IDNA ACE strings.

     Therefore, the IDNA service also does not require any
     applications to conform to IDNA, except applications
     that elect to use IDNA in order to support IDN, while
     maintaining interoperability with the existing, ASCII-
     based DNS infrastructure. Adding IDNA support to an
     existing application entails changes to the application
     only -- or to a "shim" layer below the application and
     above the existing transport and DNS protocol layers.



2.   Terminology

     The key words "MUST", "SHALL", "REQUIRED", "SHOULD",
     "RECOMMENDED", and "MAY" in this document are to be
     interpreted as described in RFC 2119 [RFC2119].

     ACE

          means ASCII Compatible Encoding.

     ACE label

          refers to an internationalized label that can be
          represented using only ASCII characters but is
          equivalent to a label containing non-ASCII
          characters. More rigorously, an ACE label is
          defined to be any label that the ToUnicode
          operation would alter. For every internationalized
          label that cannot be directly represented in ASCII,
          there is an equivalent ACE label. An ACE label
          always begins with the ACE prefix defined in
          section 5. The conversion of labels to and from the
          ACE form is specified in section 4.

     ACE prefix

          is defined to be a string of ASCII characters that
          appears at the beginning of every ACE label. It is
          specified in section 5.

     Equivalence of labels

          is defined in IDNA in terms of the ToASCII
          operation, which constructs an ASCII form for a
          given label.  Labels are defined to be equivalent
          if and only if their ASCII forms produced by
          ToASCII match using a case-insensitive ASCII
          comparison. Traditional ASCII labels already have a
          notion of equivalence: upper case and lower case
          are considered equivalent.  The IDNA notion of
          equivalence is an extension of the old notion.
          Equivalent labels in IDNA are treated as alternate
          forms of the same label, just as "foo" and "Foo"
          are treated as alternate forms of the same label.

     Internationalized domain name for applications (IDNA)

          refers to a domain name subject to the technical
          enhancements for supporting IDN in the case of
          general domain names.  Procedurally, this is a
          domain name that can be mapped from IDN-native to
          IDN-ACE with the ToASCII operation (see section 4)
          applied to each label without failing.

     IDN-ACE

          is a domain name slot that is not an IDN-native
          domain name slot. Obviously, this includes any
          domain name slot whose specification predates IDNA.



3.   IDN for Applications (IDNA)

     In order to permit IDN functionality without requiring
     changes to existing DNS infrastructure servers and
     resolvers, IDNA uses ASCII Compatible Encoding (ACE).
     IDNA-ACE represents IDN labels within the current, ASCII-
     based DNS protocol and storage infrastructure.  That is,
     Domain names that use Unicode values in their labels are
     encoded to occupy a reserved portion of the existing,
     ASCII-based domain name space.

     Components of an IDNA-enhanced DNS are:

     Resolver-ASCII-1--|
                       |
                       |--Server-A--|
                       |            |--Server-A-ASCII-admin
     Resolver-ACE-2 ---|
                       |
                       |--Server-B--|
                                    |--Server-B-ACE-admin

     The components labeled with ASCII do not support IDN.
     The components labeled with ACE support IDN through
     IDNA's ACE conventions.

     The protocol between any resolver and any server is
     unmodified.

     The software and procedures for administering Server-A
     are unmodified.  Server-A therefore maintains only slots
     with original, ASCII values.  It maintains no IDN slots.

     Server-B is unmodified.  However Server-B-ACE-admin is
     modified to support creation and modification of IDN
     slots, based on IDNA's ACE conventions.  Hence, Server-B
     can hold IDN labels.

     Resolver-ASCII-1 is unmodified and supports only ASCII
     domain names.  It therefore can process an IDN string
     only in its ACE form.

     Resolver-ACE-2 is modified to support the IDN through
     IDNA's ACE conventions.  Hence it can convert ACE
     strings to their "native" Unicode, for display according
     to local host Unicode mechanisms.  The modification to
     Resolver-ACE-2 may be changes to the resolver, itself,
     or may be effected through an independent modules that
     is called as a surrogate for the Resolver and that, in
     turn calls an unmodified Resolver-ASCII module.



4.   IDNA for Host Domain Names (IDNA-Host)

     ASCII Domain names used within URLs and email addresses
     are subject to restrictions specified in [STD3] for host
     names.  Internationalized host domain names (IDN-Host)
     enhances the permitted range of host addresses by
     continuing the ASCII-related restrictions, but
     permitting use of Unicode values.

     IDNA mechanisms support IDN-Host as IDNA-Host.  IDNA-
     Host is IDNA with [STD3] host naming restrictions
     applied to ASCII and Unicode domain names.



5.   ACE

     ASCII Compatible Encoding (ACE) maps between Unicode
     "native" strings and an ASCII-readable representation of
     the Unicode.

     ACE domain labels comprise an ACE prefix string,
     followed by the ACE version of the Unicode.


5.1. ACE prefix

     [[ Note to the IESG and Internet Draft readers: The two
     uses of the string "IESG--" below are to be changed at
     time of publication to a prefix which fulfills the
     requirements in the first paragraph. IANA will assign
     this value. ]]

     The ACE prefix, used in the conversion operations
     (section 4), is two alphanumeric ASCII characters
     followed by two hyphen-minuses. It cannot

     be any of the prefixes already used in earlier
     documents, which includes the following: "bl--", "bq--",
     "dq--", "lq--", "mq--", "ra--", "wq--" and "zq--". The
     ToASCII and ToUnicode operations MUST recognize the ACE
     prefix in a case-insensitive manner.

     The ACE prefix for IDNA is "IESG--".

     This means that an ACE label might be "IESG--de-
     jg4avhby1noc0d", where "de-jg4avhby1noc0d" is the part
     of the ACE label that is generated by the encoding steps
     in [PUNYCODE].

     While all ACE labels begin with the ACE prefix, not all
     labels beginning with the ACE prefix are necessarily ACE
     labels.  Non-ACE labels that begin with the ACE prefix
     will confuse users and SHOULD NOT be allowed in DNS
     zones.



5.2. ACE Enforcement

     Whenever a domain name is put into an IDN-ACE domain
     name slot, it MUST contain only ASCII characters.

     Given an internationalized domain name (IDN), an
     equivalent domain name satisfying this requirement can
     be obtained by applying the ToASCII operation (see
     section 4) to each label and, if dots are used as label
     separators, changing all the label separators to U+002E.


5.3. ACE Display

     ACE labels obtained from domain name slots SHOULD be
     hidden from users except when the use of the non-ASCII
     form would cause problems or when the ACE form is
     explicitly requested.  Given an internationalized domain
     name, an equivalent domain name containing no ACE labels
     can be obtained by applying the ToUnicode operation (see
     section 4) to each label.  When requirements 2 and 3
     both apply, requirement 2 takes precedence.


5.4. ACE Conversion operations

     An application converts a domain name put into an IDN-
     ACE slot or displayed to a user. This section specifies
     the steps to perform in the conversion, and the ToASCII
     and ToUnicode operations.

     The input to ToASCII or ToUnicode is a single label that
     is a sequence of Unicode code points (remember that all
     ASCII code points are also Unicode code points). If a
     domain name is represented using a character set other
     than Unicode or US-ASCII, it will first need to be
     transcoded to Unicode.

     Starting from a whole domain name, the steps that an
     application takes to do the conversions are:

     1)   Decide whether the domain name is a "stored string" or a
          "query string" as described in [STRINGPREP]. If this
          conversion follows the "queries" rule from [STRINGPREP], set
          the flag called "AllowUnassigned".


     2)   Split the domain name into individual labels as
          described in section 3. The labels do not include the
          separator.

     3)   Decide whether or not to enforce the restrictions on
          ASCII characters in host names [STD3]. If the restrictions
          are to be enforced, set the flag called "UseSTD3ASCIIRules".

     4)   Process each label with either the ToASCII or the
          ToUnicode operation. Use the ToASCII operation if you are
          about to put the name into an IDN-ACE slot. Use the ToUnicode
          operation if you are displaying the name to a user.

     If ToASCII was applied in step 4 and dots are used as
     label separators, change all the label separators to
     U+002E (full stop).

     The following two subsections define the ToASCII and
     ToUnicode operations that are used in step 4.


     5.4.1.    ToASCII

     The ToASCII operation takes a sequence of Unicode code
     points that make up one label and transforms it into a
     sequence of code points in the ASCII range (0..7F). If
     ToASCII succeeds, the original sequence and the
     resulting sequence are equivalent labels.

     It is important to note that the ToASCII operation can
     fail. If the ToASCII operation fails on any label in a
     domain name, that domain name MUST NOT be used as an
     internationalized domain name. The application needs to
     have some method of dealing with this failure.

     The inputs to ToASCII are a sequence of code points, the
     AllowUnassigned flag and the UseSTD3ASCIIRules flag. The
     output of ToASCII is either a sequence of ASCII code
     points or a failure condition.

     ToASCII never alters a sequence of code points that are
     all in the ASCII range to begin with (although it could
     fail). Applying the ToASCII operation multiple times has
     exactly the same effect as applying it just once.

     ToASCII consists of the following steps:

     1.  If all code points in the sequence are in the ASCII
         range (0..7F) then skip to step 3.

     2.  Perform the steps specified in [NAMEPREP] and fail if
         there is an error. The AllowUnassigned flag is used in
         [NAMEPREP].

     3.  If the UseSTD3ASCIIRules flag is set, then perform these
         checks:

          (a)  Verify the absence of non-LDH ASCII code points; that
               is, the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.

          (b)  Verify the absence of leading and trailing hyphen-minus;
               that is, the absence of U+002D at the beginning and end of
               the sequence.

     4.  If all code points in the sequence are in the ASCII
         range    (0..7F), then skip to step 8.

     5.  Verify that the sequence does NOT begin with the ACE
         prefix.

     6.  Encode the sequence using the encoding algorithm in
         [PUNYCODE]and fail if there is an error.

     7.  Prepend the ACE prefix.

     8.  Verify that the number of code points is in the range 1
         to 63 inclusive.


     5.4.2.    ToUnicode

     The ToUnicode operation takes a sequence of Unicode code
     points that make up one label and returns a sequence of
     Unicode code points. If the input sequence is a label in
     ACE form, then the result is an equivalent
     internationalized label that is not in ACE form,
     otherwise the original sequence is returned unaltered.

     ToUnicode never fails. If any step fails, then the
     original input sequence is returned immediately in that
     step.

     The inputs to ToUnicode are a sequence of code points,
     the AllowUnassigned flag and the UseSTD3ASCIIRules flag.
     The output of ToUnicode is always a sequence of Unicode
     code points.

     1.   If all code points in the sequence are in the ASCII
          range (0..7F) then skip to step 3.

     2.   Perform the steps specified in [NAMEPREP] and fail if
          there is an error. (If step 3 of ToASCII is also performed
          here, it will not affect the overall behavior of ToUnicode,
          but it is not necessary.) The AllowUnassigned flag is used in
          [NAMEPREP].

     3.   Verify that the sequence begins with the ACE prefix, and
          save a copy of the sequence.

     4.   Remove the ACE prefix.

     5.   Decode the sequence using the decoding algorithm in
          [PUNYCODE] and fail if there is an error. Save a copy of the
          result of this step.

6.   Apply ToASCII.

7.   Verify that the result of step 6 matches the saved copy
from step 3, using a case-insensitive ASCII comparison.

8.   Return the saved copy from step 5.


5.5. ACE Comparison

     Whenever two labels are compared, they MUST be
     considered to match if and only if they are equivalent,
     that is, their ASCII forms (obtained by applying
     ToASCII) match using a case-insensitive ASCII
     comparison.

     Whenever two names are compared, they MUST be considered
     to match if and only if their corresponding labels
     match, regardless of whether the names use the same
     forms of label separators.



6.   Implications for Components in DNS


6.1. Implications for typical applications using DNS

     In IDNA, applications perform the processing needed to
     input internationalized domain names from users, display
     internationalized domain names to users and process the
     inputs and outputs from DNS and other protocols that
     carry domain names.

     The components and interfaces between them can be
     represented pictorially as:
                      +------+
                      | User |
                      +------+
                           | Input and display:
                           | local interface methods
                           | (pen, keyboard, video, ...)
       +-------------------|-------------------------------+
       |                   v                               |
       |          +-----------------------------+          |
       |          |      Application            |          |
       |          |   (ToASCII and ToUnicode    |          |
       |          |    operations may be        |          |
       |          |    called here)             |          |
       |          +-----------------------------+          |
       |                   ^       ^                       |End
       |                            |                      |sys
       | Call to resolver: |        | Application-specific |
       |              ACE  |        | protocol:            |
       |                   v        | ACE unless the       |
       |           +----------+     | protocol is updated  |
       |           | Resolver |     | to handle other      |
       |           +----------+     | encodings            |
       |                 ^          |                      |
       +-----------------|----------|----------------------+
           DNS protocol: |          |
                     ACE |          |
                         v          v
              +-------------+    +---------------------+
              | DNS servers |    | Application servers |
              +-------------+    +---------------------+

     The box labeled "Application" is where the application
     splits a host name into labels, sets the appropriate
     flags, and performs the ToASCII and ToUnicode
     operations. This is described in section 4.


     6.1.1.    Entry and display in applications

     Applications can accept domain names using any character
     set or sets desired by the application developer, and
     can display domain names in any character set. That is,
     the IDNA protocol does not affect the interface between
     users and applications.

     An IDNA-native application can accept and display
     internationalized domain names in two formats: the
     internationalized character set(s) supported by the
     application, and as an ACE label. ACE labels that are
     displayed or input MUST always include the ACE prefix.
     Applications MAY allow input and display of ACE labels,
     but are not encouraged to do so except as an interface
     for special purposes, possibly for debugging.

          ACE encoding is opaque and ugly, and should thus
          only be exposed to users who absolutely need it.

     Because name labels encoded as ACE name labels can be
     rendered either as the encoded ASCII characters or the
     proper decoded characters, the application MAY have an
     option for the user to select the preferred method of
     display; if it does, rendering the ACE SHOULD NOT be the
     default.

     Domain names are often stored and transported in many
     places. For example, they are part of documents such as
     mail messages and web pages. They are transported in
     many parts of many protocols, such as both the control
     commands and the RFC 2822 body parts of SMTP, and the
     headers and the body content in HTTP. It is important to
     remember that domain names appear both in domain name
     slots and in the content that is passed over protocols.

     In protocols and document formats that define how to
     handle specification or negotiation of charsets, labels
     can be encoded in any charset allowed by the protocol or
     document format. If a protocol or document format only
     allows one charset, the labels MUST be given in that
     charset.

     In any place where a protocol or document format allows
     transmission of the characters in internationalized
     labels, internationalized labels SHOULD be transmitted
     using whatever character encoding and escape mechanism
     the protocol or document format uses at that place.

     All protocols that use domain name slots already have
     the capacity for handling domain names in the ASCII
     charset. Thus, ACE labels (internationalized labels that
     have been processed with the ToASCII operation) can
     inherently be handled by those protocols.


     6.1.2.    Applications and resolver libraries

     Applications normally use functions in the operating
     system when they resolve DNS queries. Those functions in
     the operating system are often called "the resolver
     library", and the applications communicate with the
     resolver libraries through a programming interface
     (API).

     Because these resolver libraries today expect only
     domain names in ASCII, applications MUST prepare labels
     that are passed to the resolver library using the
     ToASCII operation. Labels received from the resolver
     library contain only ASCII characters; internationalized
     labels that cannot be represented directly in ASCII use
     the ACE form. ACE labels always include the ACE prefix.

     IDNA-native applications MUST be able to work with both
     non-internationalized labels (those that conform to
     [STD13] and [STD3]) and internationalized labels.

     It is expected that new versions of the resolver
     libraries in the future will be able to accept domain
     names in other formats than ASCII, and application
     developers might one day pass not only domain names in
     Unicode, but also in local script to a new API for the
     resolver libraries in the operating system. Thus the
     ToASCII and ToUnicode operations might be performed
     inside these new versions of the resolver libraries.

     Domain names stored in zones follow the rules for
     "stored strings" from [STRINGPREP]. Domain names passed
     to resolvers or put into the question section of DNS
     requests follow the rules for "queries" from
     [STRINGPREP].


     6.1.3.    DNS servers

     An operating system might have a set of libraries for
     performing the ToASCII operation. The input to such a
     library might be in one or more charsets that are used
     in applications (UTF-8 and UTF-16 are likely candidates
     for almost any operating system, and script-specific
     charsets are likely for localized operating systems).

     For internationalized labels that cannot be represented
     directly in ASCII, DNS servers MUST use the ACE form
     produced by the ToASCII operation. All IDNs served by
     DNS servers MUST contain only ASCII characters.

     If a signaling system that makes negotiation possible
     between old and new DNS clients and servers is
     standardized in the future, the encoding of the query in
     the DNS protocol itself can be changed from ACE to
     something else, such as UTF-8. The question whether or
     not this should be used is, however, a separate problem
     and is not discussed in this memo.


     6.1.4.    Avoiding exposing users to the raw ACE encoding

     All applications that might show the user a domain name
     obtained from a domain name slot, such as from
     gethostbyaddr or part of a mail header, SHOULD be
     updated as soon as possible in order to prevent users
     from seeing the ACE.

     If an application decodes an ACE name using ToUnicode
     but cannot show all of the characters in the decoded
     name, such as if the name contains characters that the
     output system cannot display, the application SHOULD
     show the name in ACE format (which always includes the
     ACE prefix) instead of displaying the name with the
     replacement character (U+FFFD). This is to make it
     easier for the user to transfer the name correctly to
     other programs. Programs that by default show the ACE
     form when they cannot show all the characters in a name
     label SHOULD also have a mechanism to show the name that
     is produced by the ToUnicode operation with as many
     characters as possible and replacement characters in the
     positions where characters cannot be displayed.

     The ToUnicode operation does not alter labels that are
     not valid ACE labels, even if they begin with the ACE
     prefix. After ToUnicode has been

     applied, if a label still begins with the ACE prefix,
     then it is not a valid ACE label, and is not equivalent
     to any of the intermediate Unicode strings constructed
     by ToUnicode.


     6.1.5.    Bidirectional text in domain names

     The display of domain names that contain bidirectional
     text is not covered in this document. It may be covered
     in a future version of this document, or may be covered
     in a different document.

     For developers interested in displaying domain names
     that have bidirectional text, the Unicode standard has
     an extensive discussion of how to deal with reorder
     glyphs for display when dealing with bidirectional text
     such as Arabic or Hebrew. See [UAX9] for more
     information. In particular, all Unicode text is stored
     in logical order.


     6.1.6.    DNSSEC authentication of IDN domain names

     DNS Security [DNSSEC] is a method for supplying
     cryptographic verification information along with DNS
     messages. Public Key Cryptography is used in conjunction
     with digital signatures to provide a means for a
     requester of domain information to authenticate the
     source of the data. This ensures that it can be traced
     back to a trusted source, either directly, or via a
     chain of trust linking the source of the information to
     the top of the DNS hierarchy.

     IDNA specifies that all internationalized domain names
     served by DNS servers that cannot be represented
     directly in ASCII must use the ACE form produced by the
     ToASCII operation. This operation must be performed
     prior to a zone being signed by the private key for that
     zone. Because of this ordering, it is important to
     recognize that DNSSEC authenticates the ASCII domain
     name, not the Unicode form or the mapping between the
     Unicode form and the ASCII form. In other words, the
     output of ToASCII is the canonical name. In the presence
     of DNSSEC, this is the name that MUST be signed in the
     zone and MUST be validated against.

     One consequence of this for sites deploying IDNA in the
     presence of DNSSEC is that any special purpose proxies
     or forwarders used to transform user input into IDNs
     must be earlier in the resolution flow than DNSSEC
     authenticating nameservers for DNSSEC to work.



     6.1.7.    Limitations of IDNA

     The IDNA protocol does not solve all linguistic issues
     with users inputting names in different scripts. Many
     important language-based and script-based mappings are
     not covered in IDNA and must be handled outside the
     protocol. For example, names that are entered in a mix
     of traditional and simplified Chinese characters will
     not be mapped to a single canonical name. Another
     example is Scandinavian names that are entered with
     U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be
     mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE).


6.2. Name Server Considerations

     Internationalized domain name data in zone files (as
     specified by section 5 of RFC 1035) MUST be processed
     with ToASCII before it is entered in the zone files.

     It is imperative that there be only one ASCII encoding
     for a particular domain name. Thus, a primary master
     name server MUST NOT contain an ACE-encoded label that
     decodes to an ASCII label. The ToASCII operation assures
     that no such names are ever output from the operation.

     Name servers MUST NOT serve records with domain names
     that contain non-ASCII characters; such names MUST be
     converted to ACE form by the

     ToASCII operation in order to be served. If names that
     are not processed by ToASCII are passed to an
     application, it will result in unpredictable behavior.
     Note that [STRINGPREP] describes how to handle
     versioning of unallocated codepoints.


6.3. Root Server Considerations

     IDNA strings are likely to be somewhat longer than
     current host names, so the bandwidth needed by the root
     servers should go up by a small amount. In addition,
     queries and responses using IDNA strings will probably
     be somewhat longer than typical queries today, so more
     queries and responses may be forced to go to TCP instead
     of UDP.



7.   References


7.1. Normative references

     [PUNYCODE] Adam Costello, "Punycode: An encoding of
     Unicode for use with IDNA", draft-ietf-idn-punycode.

     [NAMEPREP] Paul Hoffman and Marc Blanchet, "Nameprep: A
     Stringprep Profile for Internationalized Domain Names",
     draft-ietf-idn-nameprep.

     [STD3] Bob Braden, "Requirements for Internet Hosts --
     Communication Layers" (RFC 1122) and "Requirements for
     Internet Hosts -- Application and Support" (RFC 1123),
     STD 3, October 1989.

     [STD13] Paul Mockapetris, "Domain names - concepts and
     facilities" (RFC 1034) and "Domain names -
     implementation and specification" (RFC 1035), STD 13,
     November 1987.

     [STRINGPREP] Paul Hoffman and Marc Blanchet,
     "Preparation of Internationalized Strings
     ("stringprep")", draft-hoffman-stringprep, work in
     progress


7.2. Informative references

     [DNSSEC] Don Eastlake, "Domain Name System Security
     Extensions", RFC 2535, March 1999.

     [RFC2119] Scott Bradner, "Key words for use in RFCs to
     Indicate Requirement Levels", March 1997, RFC 2119.

     [UAX9] Unicode Standard Annex #9, The Bidirectional
     Algorithm,
     <http://www.unicode.org/unicode/reports/tr9/>.

     [UNICODE] The Unicode Standard, Version 3.1.0: The
     Unicode Consortium. The Unicode Standard, Version 3.0.
     Reading, MA, Addison-Wesley Developers Press, 2000. ISBN
     0-201-61633-5, as amended by: Unicode Standard Annex
     #27: Unicode 3.1,
     <http://www.unicode.org/unicode/reports/tr27/tr27-
     4.html>.

     [USASCII] Vint Cerf, "ASCII format for Network
     Interchange", October 1969, RFC 20.



8.   Security Considerations

     Security on the Internet partly relies on the DNS. Thus,
     any change to the characteristics of the DNS can change
     the security of much of the Internet.

     This memo describes an algorithm that encodes characters
     that are not valid according to STD3 and STD13 into
     octet values that are valid. No

     security issues such as string length increases or new
     allowed values are introduced by the encoding process or
     the use of these encoded values, apart from those
     introduced by the ACE encoding itself.

     Domain names are used by users to connect to Internet
     servers. The security of the Internet would be
     compromised if a user entering a single
     internationalized name could be connected to different
     servers based on different interpretations of the
     internationalized domain name.

     Because this document normatively refers to [NAMEPREP],
     it includes the security considerations from that
     document as well.



9.   Authors' Addresses

     Patrik Faltstrom
     Cisco Systems
     Arstaangsvagen 31 J
     S-117 43 Stockholm  Sweden
     paf@cisco.com

     Paul Hoffman
     Internet Mail Consortium and VPN Consortium
     127 Segre Place
     Santa Cruz, CA  95060  USA
     phoffman@imc.org

     Adam M. Costello
     University of California, Berkeley
     idna-spec.amc @ nicemice.net




   APPENDIX


A.1. Brief overview for application developers

     Applications can use IDNA to support internationalized
     domain names anywhere that ASCII domain names are
     already supported, including DNS master files and
     resolver interfaces. (Applications can also define
     protocols and interfaces that support IDNs directly
     using non-ASCII representations. IDNA does not prescribe
     any particular representation for new protocols, but it
     still defines which names are valid and how they are
     compared.)

     The IDNA protocol is contained completely within
     applications. It is not a client-server or peer-to-peer
     protocol: everything is done inside the application
     itself. When used with a DNS resolver library, IDNA is
     inserted as a "shim" between the application and the
     resolver library. When used for writing names into a DNS
     zone, IDNA is used just before the name is committed to
     the zone.

     There are two operations described in section 4 of this
     document:

     - The ToASCII operation is used before sending an IDN to
     something that expects ASCII names (such as a resolver)
     or writing an IDN into a place that expects ASCII names
     (such as a DNS master file).

     - The ToUnicode operation is used when displaying names
     to users, for example names obtained from a DNS zone.

     It is important to note that the ToASCII operation can
     fail. If it fails when processing a domain name, that
     domain name cannot be used as an internationalized
     domain name and the application has to have some method
     of dealing with this failure.

     IDNA requires that implementations process input strings
     with Nameprep [NAMEPREP], which is a profile of
     Stringprep [STRINGPREP], and then with Punycode
     [PUNYCODE]. Implementations of IDNA MUST fully implement
     Nameprep and Punycode; neither Nameprep nor Punycode are
     optional.