draft-ietf-idn-idne-02.txt

bind-3.2.

Internet Draft                                   Marc Blanchet
draft-ietf-idn-idne-02.txt                            Viagenie
March 19, 2001                                   Paul  Hoffman
Expires in six months                               IMC & VPNC

            Internationalized domain names using EDNS (IDNE)

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

The current DNS infrastructure does not provide a way to use
internationalized domain names (IDN). This document describes an
extension mechanism based on EDNS which enables the use of IDN without
causing harm to the current DNS. IDNE enables IDN host names with a as
many characters as current ASCII-only host names. It fully supports
UTF-8 and conforms to the IDN requirements.


1. Introduction

Various proposals for IDN have tried to integrate IDN into the current
limited ASCII DNS. However, the compatibility issues make too many
constraints on the architecture. Many of these proposals require
modifications to the applications or to the DNS protocol or to the
servers. This proposal take a different approach: it uses the
standardized extension mechanism for DNS (EDNS) and uses UTF-8 as the
mandatory charset. It causes no harm to the current DNS because it uses
the EDNS extension mechanism. The major drawback of this proposal is
that all protocols, applications and DNS servers will have to be
upgraded to support this proposal.

1.1 Terminology

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

Hexadecimal values are shown preceded with an "0x". For example,
"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
shown preceded with an "0b". For example, a nine-bit value might be
shown as "0b101101111".

Examples in this document use the notation from the Unicode Standard
[UNICODE3] as well as the ISO 10646 [ISO10646] names. For example, the
letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER
A". In the lists of prohibited characters, the "U+" is left off to make
the lists easier to read.

1.2 IDN summary

Using the terminology in [IDNCOMP],  this protocol specifies an IDN
architecture of arch-2 (send binary or ACE). The binary format is
bin-1.1 (UTF-8), and the method for distinguishing binary from current
names is bin-2.4 (mark binary with EDNS0). The transition period is not
specified.


2. Functional Description

DNS query and responses containing IDNE labels have the following
properties:

- The string in the label MUST be pre-processed as described in
[NAMEPREP] before the query or response is prepared.

- The characters in the label MUST be encoded using UTF-8 [RFC2279].

- The entire label MUST be encoded EDNS [RFC2671].

- The version of the IDN protocol MUST be identified.


3. Encoding

An IDNE label uses the EDNS extended label type prefix (0b01), as
described in [RFC2671]. (A normal label type always begin with 0b00). A
new extended label type for IDNE is used to identify an IDNE label. This
document uses 0b000010 as the extended label type; however, the label
type will be assigned by IANA and it may not be 0b000010.

          0                   1                   2
bits  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2     . . .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
         |0 1|    ELT    |     Size      |        IDN label ...        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+


ELT: The six-bit extended label type to be assigned by the IANA for an
IDN label. In this document, the value 0b000010 is used, although that
might be changed by IANA.

Size: Size (in octets) of the IDN label following. This MUST NOT
be zero.

IDN label: Label, encoded in UTF-8 [RFC2279]. Note that this label might
contain all ASCII characters, and thus can be used for host name labels
that are legal in [STD13].

IDNE labels can be mixed with STD13 labels in a domain name.

The compression scheme in section 4.1.4 of [STD13] is supported as is.
Pointers can refer to either IDN labels or non-IDN labels.

3.1 Examples

3.1.1 Basic example

The following example shows the label me.com where the "e" in "me" is
replaced by a <LATIN CAPITAL LETTER E WITH ACUTE>, which is U+00C9. The
decomposition and downcasing specified in [NAMEPREP] changes the second
character to <LATIN SMALL LETTER E WITH ACUTE>, U+00E9. This string is
then transformed using UTF-8 [RFC2279] to 0x6DC3A9.

Ignoring the other fields of the message, the domain name portion of the
datagram could look like:

          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       20 | 0  1  0  0  0  0  1  0| 0  0  0  0  0  0  1  1|
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       22 |         0x6D (m)      |       0xC3 (e'(1))    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       24 |         0xA9 (e'(2))  |       3               |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       26 |         0x63 (c)      |       0x6F (o)        |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       28 |         0x6D (m)      |       0x00            |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Octet 20 means EDNS extended label type (0b01) using the IDN label
        type (0b000010)
Octet 21 means size of label is 3 octets following
Octet 22-24 are the "m*" label encoded in UTF-8
Octet 25-28 are "com" encoded as a STD13 label
Octet 29 is the root domain

3.1.2 Example with compression

Using the previous labels, one datagram might contain "www.m*.com" and
"m*.com" (where the "*" is <LATIN CAPITAL LETTER E WITH ACUTE>).

Ignoring the other fields of the message, the domain name portions of
the datagram could look like:

          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       20 | 0  1  0  0  0  0  1  0| 0  0  0  0  0  0  1  1|
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       22 |         0x6D (m)      |       0xC3 (e'(1))    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       24 |         0xA9 (e'(2))  |       3               |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       26 |         0x63 (c)      |       0x6F (o)        |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       28 |         0x6D (m)      |       0x00            |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      .    .    .
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       40 |           3           |       0x77 (w)        |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       42 |       0x77 (w)        |       0x77 (w)        |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       44 | 1  1|                20                       |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The domain name "m*.com" is shown at offset 20. The domain name
"www.m*.com" is shown at offset 40; this definition uses a pointer to
concatenate a label for www to the previously defined "m*.com".


4. Label Size

In IDNE, the maximum length of a label is 255 octets, and the maximum
size for a domain name is 1023 octets. The reason for using these values
is so that IDNE labels can have the same number of characters as the
ASCII-based labels in [STD13]. Because character encoding in UTF-8 is
variable length, the maximum octet length for characters expected in the
foreseeable future (that is, 4 octets for a single character) was used.
Note that this extension allows some IDNE labels to be longer than 63
characters and some IDNE names to be longer than 255 octets.

Software creating DNS queries or responses using IDNE MUST verify that,
after IDN preparation and transformation to UTF8, that no labels are
longer than 255 octets and that no names are longer than 1023 octets. If
there is a user interface associated with the process creating the query
or response, that interface SHOULD give the user an error message.

Software MUST NOT transmit DNS queries or responses which contain labels
that are longer than 255 octets or names that are longer than 1023
octets. Servers MUST NOT accept DNS queries or responses which contain
labels that are longer than 255 octets or names that are longer than
1023 octets, and MUST send the NOTIMPL RCODE error message if such
queries or responses are received.


5. UDP Packet Size