draft-ietf-idn-udns-02.txt

bind-3.2.

Internet Draft                                             Dan Oscarsson
draft-ietf-idn-udns-02.txt                                 Telia ProSoft
Updates: RFC 2181, 1035, 1034, 2535                        24 February
2001 Expires: 24 August 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
     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

   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.

   This document defines how the Universal Character Set (UCS)
   [ISO10646] is to be used in DNS.

   It includes both a transition scheme for older software supporting
   non-ASCII handling in applications only, as well as how to use UCS in
   labels and having more than 63 octets in a label.


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



Dan Oscarsson           Expires: 24 August 2001                 [Page 1]

Internet Draft               Universal DNS              24 February 2001


   using UTF-8 in use, and others using other methods.

   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.

   While the DNS protocol allow any octet in character data, so far the
   octets are only defined for the ASCII code points. Octets outside the
   ASCII range have no defined interpretation. This document defines how
   all octets are to be used in character data allowing a standardised
   way to use non-ASCII in DNS.

   The specification here conforms to the IDN requirements [IDNREQ].

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   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 third version of this document included a way to return both
   ASCII and non-ASCII versions of a name. As this could not be
   guaranteed to work it has been removed.

   The second version of this document was available as draft-ietf-idn-
   udns-00.txt. It included a lot of possibilities as well as a flag bit
   that is now removed.

   The first version of this document was available as draft-oscarsson-
   i18ndns-00.txt.


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.




Dan Oscarsson           Expires: 24 August 2001                 [Page 2]

Internet Draft               Universal DNS              24 February 2001


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

   For a long time there will be software understanding UCS in DNS and
   software only understanding ASCII in DNS. It is therefore necessary
   to support a mixing of both types. For the following text software
   understanding UCS in DNS will be called UDNS aware.

   This specification supports the following scenarios:

    - UDNS unaware client, UDNS aware DNS server
    - UDNS aware client, UDNS unaware DNS server
    - UDNS aware client, UDNS unaware DNS server


2.1 Fundamentals

2.1.1 Standard Character Encoding (SCE)

   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.
   Character data is used in labels and in text fields in the RDATA part
   of a RR.

   The Standard Character Encoding of character data used in the DNS
   protocol MUST:
    - 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.

2.1.2 Binary Comparison Format (BCF)

   RFC 1035 states that the labels of a name are matched case-
   insensitively.  When using UCS this is no longer enough as there are
   other forms than case that need to match as equivalent. Form-
   insensitive matching of UCS includes:
    - Letters of different case are compared as the same character.
    - Code points of primary typographical variations of the same
      character are compared as the same character. An example is double
      width/normal width characters or presentation forms of a
      character.
    - Some characters are represented with multiple code points in UCS.
      All code points of one character must compare as the same.  For
      example the degree Kelvin sign is the same as the letter K.

   The original definition is now extended to be: labels must be
   compared using form-insensitivity.



Dan Oscarsson           Expires: 24 August 2001                 [Page 3]

Internet Draft               Universal DNS              24 February 2001


   To handle form-insensitivity it is here defined the Binary Comparison
   Format (BCF) to which strings can be mapped.  After strings is mapped
   to BCF they can be compared using binary string comparison.
   Implementors may implement the form-insensitive comparison without
   using BCF, as long as the results are the same.

   Mapping of a label to BCF is typically done by steps like: changing
   all upper case letters to lower case, mapping different forms to one
   form and changing different code points of one character into a
   single code point.

   For the UCS character code range 0-255 (ASCII and ISO 8859-1) the BCF
   MUST be done by mapping all upper case characters to lower case
   following the one to one mapping as defined in the Unicode 3.0
   Character Database [UDATA].

   The definition of the Binary Comparison Format (BCF) for the rest of
   UCS will be defined in a separate document. The nearest today is
   [NAMEPREP].

2.1.3 Backward Compatibility Encoding (BCE)

   To support older software expecting only ASCII and to support
   downgrading from 8-bit to 7-bit ASCII in other protocols (like SMTP)
   a Backward Compatibility Encoding (BCE) is available. It is a
   transition mechanism and will no longer be supported at some future
   time when it is so decided.

   The Backward Compatibility Encoding (BCE) of a label is defined as
   the BCF of the label encoded using an ASCII Compatible Encoding
   (ACE).

   The definition of the ACE to be used, is defined in a separate
   document.  Typical definitions that are suitable are [SACE] and
   [RACE].

2.1.4 Long names

   The current DNS protocol limits a label to 63 octets. As UTF-8 take
   more than one octet for some characters, an UTF-8 name 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.

   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.

   To support longer names a long label type is defined using [RFC2671]



Dan Oscarsson           Expires: 24 August 2001                 [Page 4]

Internet Draft               Universal DNS              24 February 2001


   as extended label 0b000011 (the label type will be assigned by IANA
   and may not be the number used here).

                                 1 1 1 1 1 1 1 1 1 1
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
            |0 1 0 0 0 0 1 1|  length       |  label data ...
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   length: length of label in octets
   label data: the label

   The long label MUST be handled by all software following this
   specification.  Also, they MUST support a UDP packet size of up to
   1280 bytes.

   The limits for labels are updated since RFC 1025 as follows:
   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.

   A long label MUST always use the Standard Character Encoding (SCE).

   As long labels are not understood by older software, a response MUST
   not include a long label unless the query did. At a later date, IETF
   may change this.


2.2 Rules for matching of domain names in UDNS aware 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 form-insensitive matching
      for the characters used in the data (for example a zone using only
      ASCII need only handle matching of ASCII characters).
    - On non-authorative data, either do binary matching or case-
      insensitive matching on ASCII letters and binary matching on all
      others.

   The effect of the above is:
    - only servers handling authorative data must implement form-
      insensitive matching of names. And they need only implement the
      subset needed for the subset of characters of UCS they support in
      their authorative zones.
    - it normally gives fast lookup because data is usually sent like:
      resolver <-> server <-> authorative server.
      While form-insensitive matching can be complex and CPU consuming,
      the server in the middle will do caching with only simple and fast



Dan Oscarsson           Expires: 24 August 2001                 [Page 5]

Internet Draft               Universal DNS              24 February 2001