Internet Draft                                             Dan Oscarsson
draft-ietf-idn-udns-00.txt                                 Telia ProSoft
Updates: RFC 2181, 1035, 1034, 2535                        9 July 2000
Expires: 9 January 2001

   Using the Universal Character Set in the Domain Name System (UDNS)

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

     The list of Internet-Draft Shadow Directories can be accessed at


   Since the Domain Name System (DNS) [RFC1035] was created there have
   been a desire to use other characters than ASCII in domain names.
   Lately this desire have grown very strong and several groups have
   started to experiment with non-ASCII names.

   By using the Universal Character Set (UCS) [ISO10646] this document
   updates the Domain Name System so that non-ASCII domain names can be
   used while still being compatible with the current (RFC 1035) DNS.

1. Introduction

   While the need for non-ASCII domain names have existed since the
   creation of the DNS, the need have increased very much during the
   last few years. Currently there are at least two implementations
   using UTF-8 in use, and others using other methods.

Dan Oscarsson           Expires: 9 January 2001                 [Page 1]

Internet Draft               Universal DNS                   9 July 2000

   To avoid several different implementations of non-ASCII names in DNS
   that do not work together, and to avoid breaking the current ASCII
   only DNS, there is an immediate need to standardise how DNS shall
   handle non-ASCII names.

   The basic handling of character data in DNS have several properties
   that need to be preserved:
    - The DNS itself places only one restriction on the particular
      labels that can be used to identify resource records. That one
      restriction relates to the length of the label and the full name.
      The length of any one label is limited to between 1 and 63 octets.
      A full domain name is limited to 255 octets (including the
      separators).  [RFC2181]
    - Any binary string whatever can be used as the label of any
      resource record. Similarly, any binary string can serve as the
      value of any record that includes a domain name as some or all of
      its value (SOA, NS, MX, PTR, CNAME, and any others that may be
      added).  Implementations of the DNS protocols must not place any
      restrictions on the labels that can be used. In particular, DNS
      servers must not refuse to serve a zone because it contains labels
      that might not be acceptable to some DNS client programs.
    - Names must be compared with case-insensitivity.  [RFC1035]
    - The original case should be preserved when possible as data is
      entered into the system. This also implies that responses should
      preserve case when possible. [RFC1035] Some of the reasons for
      this are:
        + Domain names are used for many purposes.
        + One is domain names where company names or trademarks could be
          used.  Very commonly companies and trademarks are using a
          combination of upper and lower case to enhance the image of
          the name.  Many of them would prefer that when you, for
          example, lookup the domain name for an IP address, the correct
          case is returned.
        + An other is the e-mail address defined in the SOA record.
          While many systems now does a case-insensitive comparison on
          the user name part of the e-mail address, there may still be
          those that don't.  And also here, e-mail addresses can be made
          more readable by mixing upper and lower case.
        + If you look up a host name form an IP address you may want to
          use the host name to compare with other data. Many services
          under Unix does this, and many of the are not case-
          insensitive. So they need the correct case returned.
        + There may be other uses of domain names that requires them to
          be unchanged.
    - The characters in the ASCII character set should still be encoded
      as ASCII.

Dan Oscarsson           Expires: 9 January 2001                 [Page 2]

Internet Draft               Universal DNS                   9 July 2000

   This document specifies the update needed of the DNS protocol, user
   interface issues and the effect of other protocols. It is intended to
   full fill the requirements of internationalised domain names which
   currently worked on by the IDN working group [IDNREQ].

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

    IDN: Internationalised Domain Name, here used to mean a domain name
      containing non-ASCII characters.

    ACE: ASCII Compatible Encoding. Used to encode IDNs in a way
      compatible with the ASCII host name syntax.

1.2 Previous versions of this document

   The first version of this document was available as draft-oscarsson-

2. The DNS Protocol

   The DNS protocol is used when communicating between DNS servers and
   other DNS servers or DNS clients. User interface issues like the
   format of zone files or how to enter or display domain names are not
   part of the protocol.

   The update of the protocol defined here can be used immediately as it
   is fully compatible with the DNS of today.

   As at this stage not all requirements are completed and many ideas
   for handling IDNs are being discussed, this version of the draft
   includes several alternatives to some of the aspects of the DNS
   internationalisation, with comments to help in the discussions.
   Using an alternative may result in not being able to use IDNs
   immediately as it may require all DNS servers taking part in a query
   to be updated first.

   The goal of this update in the DNS protocol is to add IDN handling
   with as little disruption as possible to software unaware of domain
   names with non-ASCII characters in them. To be able to do this it is
   necessary for the DNS servers to be able to identify if it is talking
   to software knowing about IDNs or not. And if the software does not
   understand IDNs, the DNS server must use an ASCII Compatible Encoding
   (ACE) of IDNs in the communication to avoid disruption the software.

Dan Oscarsson           Expires: 9 January 2001                 [Page 3]

Internet Draft               Universal DNS                   9 July 2000

   ACE will be further discussed later.

2.1 Internationalisation aware software (IDN aware)

   Internationalisation aware DNS software (IDN aware) is software that
   handles the rules for handling international text as defined here.
   Only IDN aware software will get all requirements fulfilled.

   For a DNS server to know if it is talking to IDN aware software, DNS
   awareness must be signalled in some way that is compatible with the
   current non-IDN aware software (following [RFC1035]).

2.1.1 The IN bit

   Referring to section 4.1.1 in [RFC1035] and section 6.1 in [RFC2535]
   the the DNS query/response format header is updated by allocation the
   last un-allocated bit in the header. This bit is defined to be zero
   in old servers and resolvers. For description of all field see the
   sections in the above RFCs.

                                           1  1  1  1  1  1
             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
            |                      ID                       |
            |QR|   Opcode  |AA|TC|RD|RA|IN|AD|CD|   RCODE   |
            |                    QDCOUNT                    |
            |                    ANCOUNT                    |
            |                    NSCOUNT                    |
            |                    ARCOUNT                    |

   IDN aware software identifies itself in a query or a response by
   setting the IN bit in the DNS query/response format header.  As this
   bit is defined to be zero in old servers and resolvers they identify
   themselves as non-IDN aware.

   IDN aware software MUST set the IN bit in both queries and responses.
   Currently there is no need for a client to know that the DNS server
   knows about IDNs, but by always setting the IN bit in responses will
   allow clients to use this information if need arises in the future.

2.1.2 Alternatives

Dan Oscarsson           Expires: 9 January 2001                 [Page 4]

Internet Draft               Universal DNS                   9 July 2000

   While the IN bit used above is the cleanest way, it is also the last
   free bit available in the DNS header since DNSSEC reserved the other
   two free ones. To avoid using the last free bit here are some
   alternative ways.

   Note: These alternatives are here to help show why the above IN bit
   is the best choice and to help discussions about how to do it. Using the RA, AA or TC bit

   Use one of the bits that only have a meaning in a response as defined
   by RFC 1035: the RA, AA or TC bit. One of these bits could be defined
   to be a IN bit in queries and the old meaning in responses. Non-IDN
   DNS servers following RFC 1035 can be expected to ignore these bits
   in queries.
   Some of the drawbacks are:
    - Some old software may not zero the value of the bits in queries
      and will therefore look as if they are IDN aware.
    - The bit cannot be used in a response to inform the client that the
      server is IDN aware.
    - Not recommended by [IANADNS]. Using the RCODE bits

   Use the bits of the RCODE value. It is defined by RFC 1035 to be used
   in responses. One of these bits could be defined to be a IN bit in
   queries or a value for all bits could be used, and the old meaning in
   responses. Non-IDN DNS servers following RFC 1035 can be expected to
   ignore these bits in queries.
   Some of the drawbacks are:
    - Their value are not defined in queries by RFC 1035. Most software
      could be expected to send them as zero as most zero the entire
      header before setting the values needed for the query. Instead of
      using just a bit one could use all bits. Using a value of all ones
      (all bits set to 1) would probably be a good flag even if old
      software fills it with random bits.
    - The bits cannot be used in a response to inform the client that
      the server is IDN aware. Using the upper 8 bits of QTYPE

   The QTYPE is 16 bits but currently are codes above 255 not used.  It
   would therefore be possible to use one of the upper 8 bits as an IN
   bit.  Some of the drawbacks are:
    - Using an upper bit results in a a new value for the QTYPE.
      Software following RFC 1035 will see this as an unknown QTYPE and
      return an error response, forcing a new query using the QTYPE
      without the bit set. This will result in a overhead because of the

Dan Oscarsson           Expires: 9 January 2001                 [Page 5]

Internet Draft               Universal DNS                   9 July 2000

      extra query/response that have to be done for all non-IDN aware
      servers and will make IDN queries slower and increase the DNS
      traffic. It will go away when all DNS servers is IDN aware, but
      that is many years in the future. Using EDNS

   Using EDNS [RFC2671] additional information could be sent in the
   additional section of a query or response. The IN bit could then be
   sent in an OPT RR record. An example of doing it this way can be
   found in [IDNE].  Some of the drawbacks are:
    - As most software today do not implement EDNS and return an error
      response, forcing a new query to be sent without EDNS.  This will
      result in a overhead because of the extra query/response that have
      to be done for all non-IDN aware servers and will make IDN queries
      slower and increase the DNS traffic. It will go away when all DNS
      servers is EDNS aware, but that is many years in the future.
    - Even a query for an ASCII only domain name will have the query
      overhead described above. The OPT RR will have to be sent here
      also, otherwise the server cannot know if the client can handle
      IDNs in the response.

2.2 Character data

   Character data need to be able to represent as much as possible of
   the characters in the world as well as being compatible with ASCII.
   It must also be well defined so that it can easily be handled and
   should be compact as only 63 octets is available without an extension
   of the protocol.

2.2.1 Native format of character data in the DNS protocol

   Character data used in the DNS protocol MUST, unless it is sent as an
   ACE to non-IDN aware software, use:
    - Use ISO 10646 (UCS) [ISO10646] as coded character set.
    - Be normalised using form C as defined in Unicode technical report
      #15 [UTR15]. See also [CHNORM].
    - Encoded using the UTF-8 [RFC2279] character encoding scheme.

   In responses to non-IDN aware software, IDNs MUST be encoded using

   As all data is required to be normalised before sent using the DNS
   protocol, a DNS server do not need to normalise any data coming in
   through a request. But it MUST normalise data loaded from a zone

Dan Oscarsson           Expires: 9 January 2001                 [Page 6]

Internet Draft               Universal DNS                   9 July 2000 Alternative native formats

   Here are some alternative possibilities to the native format defined
   above and comments of why they were not selected, to help in
   discussions. See [IDNCOMP] for more examples. Using other normalisation formats

   The Unicode normalisation form C does not remove any information in
   the character data while making it as compact as possible and have a
   well defined order of combining characters.

   One could use form KC or some other normalisation format that removes
   all forms that are not significant when testing for domain name
   equivalence, but that would remove a lot of information that is
   important in printing or displaying them. It would be like replacing
   all upper case letters in ASCII names with the lower case version.

   As normalisation form C is both compact and does not destroy any
   information it is also well suited to be the standard format to be
   used in all protocols using UCS. It is the one recommended by W3C.

   Software can be reused if all protocols use the same normalisation
   form. Using other encoding schemes than UTF-8

   While using another coded character set than UCS is possible,
   allowing only one simplifies software very much and reduces the
   possibility of incompatibilities. But using UTF-8 is not that compact
   for several languages. For some a single row of UCS is enough and for
   some 16-bit values is best.  The native format could easily include a
   tag byte first defining subset/encoding of UCS allowing ISO 8859-1,
   UTF-8, UCS-2 or UTF-16 to be used. This would allow more compact
   format and therefore more characters into the 63 byte limit of a
   label, for some names.  It would not make software much more complex
   as the coded character set is still the same. But unless the length
   limits are unacceptable or cannot be overridden is an easy way,
   having just one scheme is easiest. Handling length limits

   The current DNS protocol limits a label to 63 octets. As IDNs take
   more than one octet for some characters, an IDN cannot have 63
   characters in a label like an ASCII name can. For example a name
   using Hangul would have a maximum of 21 characters when encoded using
   UTF-8. There is currently no requirement on minimum length that is
   required in IDNs, but even if the need does not appear immediately it

Dan Oscarsson           Expires: 9 January 2001                 [Page 7]

Internet Draft               Universal DNS                   9 July 2000

   will come.

   The limits imposed by RFC 1035 is 63 octets per label and 255 octets
   for the full name. The 255 limit is not a protocol limit but one to
   simplify implementations.

   When longer limits are allowed for IDNs, we still need to set a limit
   to simplify implementations. By following the limits defined in RFC
   1035 the limits for IDNs (and ASCII only names) is defined as:

   A label is limited to a maximum of 63 character code points in UCS
   normalised using Unicode form C.  The full name is limited to a
   maximum of 255 character code points normalised as for a label.

   Longer labels in DNS are supported as follows: EDNS long label

   An extended label type is defined that allows as a minimum 255 octets
   per label. It can be defined as in [IDNE].

   Even though a label now can have 255 octets, an ASCII only name by
   still only have 63 characters in it.

   All IDN aware software MUST implement the ENDS long label.

   As EDNS is not understood by older software, a query with an EDNS
   long label will fail and can only be returned in a response to an IDN
   aware client. It is recommended that only IDNs that fits into the 63
   octets in the standard label are used until enough DNS software have
   been upgraded to avoid a lot of overhead in queries. Alternative: encoded long label

   As an alternative to EDNS, it is possible to split a long label into
   several parts and encode it into several labels. It could be done
   like this: <UTF-8 code part1><DEL>.<DEL><UTF-8 code part 2>.com.
   Where the <DEL> octet indicates that part1 and part2 shall be joined
   together. This can be done inside the client (resolver) software and
   in the DNS server so that application software and the user will not
   be aware of it happening.

   While this solution can work through non-IDN aware software it is
   less clean than the EDNS solution. And there are always the
   possibility that some software assumes that part1 is a host name.

2.2.2 ASCII Compatible Encoding

Dan Oscarsson           Expires: 9 January 2001                 [Page 8]

Internet Draft               Universal DNS                   9 July 2000

   When responding to non-IDN aware software (for example most current
   DNS software and current SMTP implementations) there is a need for a
   transition mechanism to support them.

   As a lot of software and protocols assume only the ASCII letters,
   digits and hyphen in each label, the transition mechanism should use
   an ASCII Compatible Encoding (ACE) to encode the IDNs.

   This ACE can then be used by DNS and other protocols when
   communicating with non-IDN aware software.

   The selected ACE will be defined in a separate document, but some of
   the basic ways to do it, is as follows:
    - Tag labels that are ACE names with a prefix or suffix.

      This would give names like: or
      where the XXXXX is the ACE name and the leading "ra--" or trailing
      "-" is the tag.

      Using this technique some labels may be using ACE and some not.

      One difficulty here is to have a tag that will never occur in a
      normal domain name.

      Labels longer than 63 octets could be split like this: where during decoding the parts
      XXXXX and YYYY will be joined to form one label. This technique
      can probably mess up some programs that assume that a dot
      separates each label.
    - Use a special TLD.

      Here names would look like: XXXXX.YYYY.ACE where XXXXX.YYYY is the
      encoded name.

      Here we do not have the problem of selecting a tag that is unique
      as the TLD will be unique.
    - Using label aliases (not really an ACE).

      One could use a user defined or automatically generated aliases to
      labels that are returned to non-IDN aware software. This way
      labels could be made meaningful.

      One problem with this is to convert from the IDN to the ACE, you
      need access the DNS to lookup the alias. This may be difficult for
      some protocols that have no access to the DNS at the moment the
      conversion must be done.

Dan Oscarsson           Expires: 9 January 2001                 [Page 9]

Internet Draft               Universal DNS                   9 July 2000

2.3 Domain name matching

   One of the most difficult areas of making DNS universal is what names
   are equivalent to an other. For ASCII this was easily solved by
   case-insensitivity. It is also easily solved for many other Latin
   based alphabets. But when you look at the whole world you get a
   mixture of rules, some conflicting, including case-insensitivity,
   half width/full width, final/non-final forms and much more.

   This type of matching will be called "equivalence matching" here

2.3.1 Equivalence matching rules

   To compare two domain names, both names must first be mapped to a
   format where all equivalent characters are mapped to one character so
   that the names then can be binary compared.

   This mapping is done from the native UCS normalised form C format as
    1) Fold case to lower case.
    2) Do additional simplification.
    3) Normalise to Unicode form C again.

   For the UCS character code range 0-255 (ASCII and ISO 8859-1) the
   case folding MUST be done by following the one to one mapping as
   defined in the Unicode 3.0 Character Database [UDATA].  Case folding
   and simplification for the rest of UCS will be defined in a separate

2.3.2 Matching of domain names in DNS servers

   To be able to handle correct domain name matching in lookups, the
   following MUST be followed by DNS servers:
    - Do matching on authorative data using the full name equivalence
      matching needed for the characters used in the data.
    - On non-authorative data, either do binary matching or case-
      insensitive matching on ASCII letters and binary matching on all
    - Implement the equivalence matching rules as defined above. Local
      variations are not allowed.

   The effect of the above is:
    - only servers handling authorative data must implement equivalence
      matching of names. And they need only implement the subset needed
      for the subset of characters of UCS they support in its
      authorative zones.

Dan Oscarsson           Expires: 9 January 2001                [Page 10]

Internet Draft               Universal DNS                   9 July 2000

    - it normally gives fast lookup because data is usually sent like:
      resolver <-> server <-> authorative server.
      While full equivalence matching can be complex and CPU consuming,
      the server in the middle will do caching with only simple and fast
      binary matching. So the impact of complex matching rules should
      not slow down DNS very much.

2.4 Inter operability between IDN aware DNS software and non-IDN aware

   While the current non-IDN aware DNS software MUST allow UTF-8 encoded
   domain names (if they follow RFC1035, 2181) a lot of software using
   DNS may not (for example SMTP). To not break all the old software
   only expecting or allowing ASCII in domain names, the following rules
   MUST be followed by an IDN aware DNS server:
    - A query with the IN bit set is assumed to be from IDN aware
    - A query with domain names having valid non-ASCII UTF-8 characters
      is assumed to be from IDN aware software even if the IN bit is not
      set. (this is because the query can have been sent from an IDN
      aware resolver through a non-IDN aware server).
    - Always encode using ACE the UTF-8 names into ASCII before sending
      it when responding to non-IDN aware software.
    - Never have ACE names in the response when responding to IDN aware
    - Always check for ACE names in requests.
    - Not do zone transfers to non-IDN aware software, if the zone
      contains non-ASCII.
    - Return the server failed error if a label cannot be encoded into
      ACE and fit in the 63 octets allowed.

   An IDN aware DNS resolver MUST:
    - Decode any ACE names before sending them using the DNS protocol.
    - Decode any ACE names received in a response.

   The result of this is:
    - Old software gets an ASCII only domain name using only the old set
      of allowed characters.
    - Both IDN aware DNS servers and resolver software must handle up
      coding of domain names.
    - Domain names used from old software will work in other protocols
      only allowing ASCII names.
    - We may get old software that is never fixed as it still works.
    - We do not get rid of this user unfriendly, encode everything in
      ASCII handling that many non-ASCII users complain about.

   Note: As a non-IDN aware DNS server only understands matching using
   ASCII case-insensitivity, it may cache IDN responses as different

Dan Oscarsson           Expires: 9 January 2001                [Page 11]

Internet Draft               Universal DNS                   9 July 2000

   even though the are IDN equivalent. This will result in more data
   cached but not give invalid responses.


   DNSSEC [RFC2535] is complex and not yet fully studied. Especially the
   canonical DNS name order and signing of RRsets.

   The canonical DNS name order sorts names with letters as lower case.
   In IDN this means to fold to lower case, normalise and simplify as is
   done in lookups.  This would mean that only a DNS server knowing the
   full equivalence rules could do the sorting. It would be better if
   this was not needed.

   Signing of RRsets is done on the canonical RR form. RFC 2535 is
   somewhat unclear if domain names inside the RDATA should be lower
   cased. If not, so that original format of RDATA is preserved, signing
   should be no problem in IDN aware DNS software.

   The full handling of DNSSEC and IDN data may have to be described in
   a separate document.

3. Characters allowed in domain names

   The DNS protocol do not place any restriction on characters used in a
   domain name. However applications that make use of DNS data may have
   restrictions imposed on what particular values are acceptable in
   their environment. If the client has such restrictions, it is solely
   responsible for validating the data from the DNS to ensure that it
   conforms before it makes any use of that data. [RFC2181]

   For example domains, hosts and e-mail addresses are represented in
   DNS and may have different rules.

   As the whole idea of making DNS universal is to get domain names with
   non-ASCII, the original recommendation in DNS [RFC1035] for
   host/domain names needs to be updated. But, the DNS may not itself
   place any restriction on the characters allowed in a domain name.
   Domain names are used for more than hosts and e-mail domains.

   It is recommended that domains, hosts and e-mail addresses all are
   extended to allow all letters, digits and some separators of UCS.

   This have to be defined in an other document. A beginning to this is
   available in [NAMEPREP].

Dan Oscarsson           Expires: 9 January 2001                [Page 12]

Internet Draft               Universal DNS                   9 July 2000

4. User interface issues

   Locally on a system or in a user interface a different character set
   than the one defined to be used in the DNS protocol may be used.
   Therefore software must map between the local character set and the
   character set of the protocol, so that human beings can understand

   This means that a zone file that is edited in a text editor by a
   person before being loaded into a DNS server must be allowed to be in
   the local character set. Software may not assume that the user can
   edit text encoded in UTF-8. A zone file transmitted between DNS
   software that is not handled by a human, can be transmitted using any

   When character data is presented to a human or entered by a human,
   software must, as good as possible, present it using local character
   set and allow it to be entered using the local character set.  It is
   the responsibility of the software to convert between the local
   character set and the one used in the protocol, not the human.

   The down coding defined above allows all names to be entered and
   displayed for all users, as long as at least the ASCII characters are

4.1 Applications using DNS software

   If an application does a call to DNS, it must present the data to the
   users in the local character set used by the user, down coding if
   necessary. Software used to access DNS should give the application
   programmer both the possibility of doing queries and getting
   responses using local character set, and using UTF-8.

   APIs like getipnodebyname should be updated with a IDN flag that
   results in the name being returned using the current locale, instead
   of native UTF-8 or ASCII format.

5. Effect on other protocols

   As now a domain name may include non-ASCII many other protocols that
   include domain names need to be updated. For example SMTP, HTTP and
   URIs. The ACE format can be used when interfacing with ASCII only
   software or protocols.  Protocols like SMTP could be extended using
   ESMTP and a UTF8 option that defines that all headers are in UTF-8.

   It is recommended that protocols updated to handle i18n do this by
   encoding character data in the same standard format as defined for
   DNS in this document (UCS normalised form C). The use of encoding it

Dan Oscarsson           Expires: 9 January 2001                [Page 13]

Internet Draft               Universal DNS                   9 July 2000

   in ASCII or by tagged character sets should be avoided.

   DNS do not only have domain names in them, for example e-mail
   addresses are also included. So an e-mail address would be expected
   to be changed to include non-ASCII both before and after the @-sign.

   Software need to be updated to follow the user interface
   recommendations given above, so that a human will see the characters
   in their local character set, if possible.

5.1 An example: SMTP

   When using SMTP it may be extended to allow UTF-8 in headers and
   addresses.  It will then have to, when transferring an e-mail to a
   SMTP system that have not been extended, encoded e-mail addresses and
   IDNs into an ACE.

   In this case an e-mail address could look like:
   where ra--XXXXX is the ACE of the given name and ra--YYYYY is the ACE
   of one part of the domain name.

6. Security Considerations

   As always with data, if software does not check for data that can be
   a problem, security may be affected. As more characters than ASCII is
   allowed, software only expecting ASCII and with no checks may now get
   security problems.

7. References

   [RFC1034]  P. Mockapetris, "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  P. Mockapetris, "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, November 1987.

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

   [RFC2181]  R. Elz and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2279]  F. Yergeau, "UTF-8, a transformation format of ISO 10646",
              RFC 2279, January 1998.

   [RFC2535]  D. Eastlake, "Domain Name System Security Extensions".
              RFC 2535, March 1999.

Dan Oscarsson           Expires: 9 January 2001                [Page 14]

Internet Draft               Universal DNS                   9 July 2000

   [RFC2671]  P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, August 1999.

   [ISO10646] ISO/IEC 10646-1:2000. International Standard --
              Information technology -- Universal Multiple-Octet Coded
              Character Set (UCS)

   [Unicode]  The Unicode Consortium, "The Unicode Standard -- Version
              3.0", ISBN 0-201-61633-5. Described at

   [UTR15]    M. Davis and M. Duerst, "Unicode Normalization Forms",
              Unicode Technical Report #15, Nov 1999,

   [UTR21]    M. Davis, "Case Mappings", Unicode Technical Report #21,
              Dec 1999,

   [UDATA]    The Unicode Character Database,
              The database is described in

   [IDNREQ]   James Seng, "Requirements of Internationalized Domain
   Names", draft-ietf-idn-requirement.

   [IANADNS]  Donald Eastlake, Eric Brunner, Bill Manning, "Domain Name
   System (DNS) IANA Considerations",draft-ietf-dnsext-iana-dns.

   [IDNE]     Marc Blanchet,Paul  Hoffman, "Internationalized domain
   names using EDNS (IDNE)", draft-ietf-idn-idne.

   [CHNORM]   M. Duerst, M. Davis, "Character Normalization in IETF
   Protocols", draft-duerst-i18n-norm.

   [IDNCOMP]  Paul Hoffman, "Comparison of Internationalized Domain Name
   Proposals", draft-ietf-idn-compare.

   [NAMEPREP] Paul Hoffman, "Comparison of Internationalized Domain Name
   Proposals", draft-ietf-idn-compare.

8. Acknowledgements

   Paul Hoffman giving many comments in our e-mail discussions.

   Ideas from drafts by Paul Hoffman, Stuart Kwan, James Gilroy and Kent

Dan Oscarsson           Expires: 9 January 2001                [Page 15]

Internet Draft               Universal DNS                   9 July 2000


   Magnus Gustavsson, Mark Davis, Kent Karlsson and Andrew Draper for
   comments on my draft.

   Discussions and comments by the members of the IDN working group.

Author's Address

   Dan Oscarsson
   Telia ProSoft AB
   Box 85
   201 20 Malmo


Dan Oscarsson           Expires: 9 January 2001                [Page 16]