draft-ietf-idn-lace-01.txt

bind-3.2.

Internet Draft                                            Mark Davis
draft-ietf-idn-lace-01.txt                                       IBM
January 5, 2001                                         Paul Hoffman
Expires July 5, 2001                                      IMC & VPNC

        LACE: Length-based ASCII Compatible Encoding for IDN

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

This document describes a transformation method for representing
non-ASCII characters in host name parts in a fashion that is completely
compatible with the current DNS. It is a potential candidate for an
ASCII-Compatible Encoding (ACE) for internationalized host names, as
described in the comparison document from the IETF IDN Working Group.
This method is based on the observation that many internationalized host
name parts will have a few substrings from a small number of rows of the
ISO 10646 repertoire. Run-length encoding for these types of
host names will be fairly compact, and is fairly easy to describe. 


1. Introduction

There is a strong world-wide desire to use characters other than plain
ASCII in host names. Host names have become the equivalent of business
or product names for many services on the Internet, so there is a need
to make them usable by people whose native scripts are not representable
by ASCII. The requirements for internationalizing host names are
described in the IDN WG's requirements document, [IDNReq].

The IDN WG's comparison document [IDNComp] describes three potential
main architectures for IDN: arch-1 (just send binary), arch-2 (send
binary or ACE), and arch-3 (just send ACE). LACE is an ACE, called
Length-based ACE or LACE, that can be used with protocols that match arch-2
or arch-3. LACE specifies an ACE format as specified in ace-1 in
[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in
[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the
beginning of the name part).

In formal terms, LACE describes a character encoding scheme of the
ISO/IEC 10646 [ISO10646] coded character set (whose assignment of
characters is synchronized with Unicode [Unicode3]) and the rules for
using that scheme in the DNS. As such, it could also be called a
"charset" as defined in [IDNReq]. It can also be viewed as a specialized
UTF (transformation format), designed to work within the restrictions of
the DNS.

The LACE protocol has the following features:

- There is exactly one way to convert internationalized host parts to
and from LACE parts. Host name part uniqueness is preserved.

- Host parts that have no international characters are not changed.

- Names using LACE can include more internationalized characters than
with other ACE protocols that have been suggested to date. LACE-encoded
names are variable length, depending on the number of transitions
between rows in the ISO 10646 repertoire that appear in the name part.
Name parts that cannot be compressed using run-length encoding can have
up to 17 characters, and names that can be compressed can have up to 35
characters. Further, a name that has just a few row transitions
typically can have over 30 characters.

It is important to note that the following sections contain many
normative statements with "MUST" and "MUST NOT". Any implementation that
does not follow these statements exactly is likely to cause damage to
the Internet by creating non-unique representations of host names.

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 for code points and names
from the Unicode Standard [Unicode3] and ISO 10646. For example, the
letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER
A".

LACE converts strings with internationalized characters into
strings of US-ASCII that are acceptable as host name parts in current
DNS host naming usage. The former are called "pre-converted" and the
latter are called "post-converted".

1.2 IDN summary

Using the terminology in [IDNComp], LACE specifies an ACE format as
specified in ace-1. Further, it specifies an identifying mechanism for
ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning
of the name part).

LACE has the following length characteristics.

- LACE-encoded names are variable length, depending on the number of
transitions between rows that appear in the name part.

- Name parts that cannot be compressed using run-length encoding can
have up to 17 characters.

- Names that can be compressed can have up to 35 characters.

-A name that has just a few row transitions typically can have over 30
characters.


2. Host Part Transformation

According to [STD13], host parts must be case-insensitive, start and
end with a letter or digit, and contain only letters, digits, and the
hyphen character ("-"). This, of course, excludes any internationalized
characters, as well as many other characters in the ASCII character
repertoire. Further, domain name parts must be 63 octets or shorter in
length.

2.1 Name tagging

All post-converted name parts that contain internationalized characters
begin with the string "lq--". (Of course, because host name parts are
case-insensitive, this might also be represented as "Lq--" or "lQ--" or
"LQ--".) The string "lq--" was chosen because it is extremely unlikely
to exist in host parts before this specification was produced. As a
historical note, in late October 2000, none of the second-level host
name parts in any of the .com, .edu, .net, and .org top-level domains
began with "lq--"; there are many tens of thousands of other strings of
three characters followed by a hyphen that have this property and could
be used instead. The string "lq--" will change to other strings with the
same properties in future versions of this draft.

Note that a zone administrator might still choose to use "lq--" at the
beginning of a host name part even if that part does not contain
internationalized characters. Zone administrators SHOULD NOT create host
part names that begin with "lq--" unless those names are post-converted
names. Creating host part names that begin with "lq--" but that are not
post-converted names may cause two distinct problems. Some display
systems, after converting the post-converted name part back to an
internationalized name part, might display the name parts in a
possibly-confusing fashion to users. More seriously, some resolvers,
after converting the post-converted name part back to an
internationalized name part, might reject the host name if it contains
illegal characters.

2.2 Converting an internationalized name to an ACE name part

To convert a string of internationalized characters into an ACE name
part, the following steps MUST be preformed in the exact order of the
subsections given here.

If a name part consists exclusively of characters that conform to the
host name requirements in [STD13], the name MUST NOT be converted to
LACE. That is, a name part that can be represented without LACE MUST NOT
be encoded using LACE. This absolute requirement prevents there from
being two different encodings for a single DNS host name.

If any checking for prohibited name parts (such as ones that are
prohibited characters, case-folding, or canonicalization) is to be done,
it MUST be done before doing the conversion to an ACE name part.

Characters outside the first plane of characters (those with codepoints
above U+FFFF) MUST be represented using surrogates, as described in
RFC 2781 [RFC2781].

The input name string consists of characters from the ISO 10646
character set in big-endian UTF-16 encoding. This is the pre-converted
string.

2.2.1 Check the input string for disallowed names

If the input string consists only of characters that conform to the host
name requirements in [STD13], the conversion MUST stop with an error.

2.2.2 Compress the pre-converted string

The entire pre-converted string MUST be compressed using the compression
algorithm specified in section 2.4. The result of this step is the
compressed string.

2.2.3 Check the length of the compressed string

The compressed string MUST be 36 octets or shorter. If the compressed
string is 37 octets or longer, the conversion MUST stop with an error.

2.2.4 Encode the compressed string with Base32

The compressed string MUST be converted using the Base32 encoding
described in section 2.5. The result of this step is the encoded string.

2.2.5 Prepend "lq--" to the encoded string and finish

Prepend the characters "lq--" to the encoded string. This is the host
name part that can be used in DNS resolution.

2.3 Converting a host name part to an internationalized name

The input string for conversion is a valid host name part. Note that if
any checking for prohibited name parts (such as prohibited characters,
case-folding, or canonicalization is to be done, it MUST be done after
doing the conversion from an ACE name part.

If a decoded name part consists exclusively of characters that conform
to the host name requirements in [STD13], the conversion from LACE MUST
fail. Because a name part that can be represented without LACE MUST NOT
be encoded using LACE, the decoding process MUST check for name parts
that consists exclusively of characters that conform to the host name
requirements in [STD13] and, if such a name part is found, MUST
beconsidered an error (and possibly a security violation).

2.3.1 Strip the "lq--"

The input string MUST begin with the characters "lq--". If it does not,
the conversion MUST stop with an error. Otherwise, remove the characters
"lq--" from the input string. The result of this step is the stripped
string.

2.3.2 Decode the stripped string with Base32

The entire stripped string MUST be checked to see if it is valid Base32
output. The entire stripped string MUST be changed to all lower-case
letters and digits. If any resulting characters are not in Table 1, the
conversion MUST stop with an error; the input string is the
post-converted string. Otherwise, the entire resulting string MUST be
converted to a binary format using the Base32 decoding described in
section 2.5. The result of this step is the decoded string.

2.3.3 Decompress the decoded string

The entire decoded string MUST be converted to ISO 10646 characters
using the decompression algorithm described in section 2.4. The result
of this is the internationalized string.

2.3.4 Check the internationalized string for disallowed names

If the internationalized string consists only of characters that conform
to the host name requirements in [STD13], the conversion MUST stop with
an error.

2.4 Compression algorithm

The basic method for compression is to reduce a substring that consists
of characters all from a single row of the ISO 10646 repertoire to a
count octet followed by the row header followed by the lower octets of
the characters. If this ends up being longer than the input, the string
is not compressed, but instead has a unique one-octet header attached.

Although the uncompressed mode limits the number of characters in a LACE
name part to 17, this is still generally enough for all names in almost
scripts. Also, this limit is close to the limits set by other encoding
proposals.

Note that the compression and decompression rules MUST be followed
exactly. This requirement prevents a single host name part from having
two encodings. Thus, for any input to the algorithm, there is only one
possible output. An implementation cannot chose to use one-octet mode or
two-octet mode using anything other than the logic given in this