draft-ietf-idn-idna-03.txt

bind-3.2.

Internet Draft                                     Patrik Faltstrom
draft-ietf-idn-idna-03.txt                                    Cisco
July 20, 2001                                          Paul Hoffman
Expires in six months                                    IMC & VPNC

             Internationalizing Host 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

The current DNS infrastructure does not provide a way to use
internationalized host names (IDN). This document describes a mechanism
that requires no changes to any DNS server or resolver that will allow
internationalized host names to be used by end users with changes only
to applications. It allows flexibility for user input and display, and
assures that host names that have non-ASCII characters are not sent to
DNS servers or resolvers.


1. Introduction

In the discussion of IDN solutions, a great deal of discussion has
focused on transition issues and how IDN will work in a world where not
all of the components have been updated. Earlier proposed solutions
require that user applications, resolvers, and DNS servers to be updated
in order for a user to use an internationalized host name. Instead of
this requirement for widespread updating of all components, the current
proposal is that only user applications be updated; no changes are
needed to the DNS protocol or any DNS servers or the resolvers on user's
computers.

This document is being discussed on the [e-mail]
mailing list. To subscribe, send a message to
[e-mail] with the single word "subscribe" in
the body of the message.

1.1 Design philosophy

Many proposals for IDN protocols have required that DNS servers be
updated to handle internationalized host names. Because of this, the
person who wanted to use an internationalized host name had to be sure
that their request went to a DNS server that was updated for IDN.
Further, that server could only send queries to other servers that had
been updated for IDN because the queries contain new protocol elements
to differentiate IDN name parts from current host parts. In addition,
these proposals require that resolvers must be updated to use the new
protocols, and in most cases the applications would need to be updated
as well.

These proposals would require that the application protocols that use
host names as protocol elements to change. This is due to the
assumptions and requirements made in those protocols about the
characters that have always been used for host names, and the encoding
of those characters. Other proposals for IDN protocols do not require
changes to DNS servers but still require changes to most application
protocols to handle the new names.

Updating all (or even a significant percentage) of the existing servers
in the world will be difficult, to say the least. Updating applications,
application gateways, and clients to handle changes to the application
protocols is also daunting. Because of this, we have designed a protocol
that requires no updating of any name servers. IDNA still requires the
updating of applications, but only for input and display of names, not
for changes to the protocols. Once a user has updated these, she or he
could immediately start using internationalized host names. The cost of
implementing IDN may thus be much lower, and the speed of implementation
could be much higher.

1.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].


2. Structural Overview

In IDNA, users' applications are updated to perform the processing
needed to input internationalized host names from users, display
internationalized host names that are returned from the DNS to users,
and process the inputs and outputs from the DNS.

2.1 Interfaces between DNS components in IDNA

The interfaces in IDNA can be represented pictorially as:

                   +------+
                   | User |
                   +------+
                      ^
                      |Input and display: local interface methods
                      |(pen, keyboard, glowing phosphorus, ...)
    +-----------------|------------------------------+
    |                 v                              |
    |         +--------------------------+           |
    |         |       Application        |           |
    |         +--------------------------+           |
    |                  ^       ^                     |
    | Call to resolver:|       |Application-specific |
    |   nameprepped ACE|       |protocol:            |
    |                  v       |predefined by the    | End system
    |         +----------+     |protocol or defaults |
    |         | Resolver |     |to nameprepped ACE   |
    |         +----------+     |                     |
    |               ^          |                     |
    +---------------|----------|---------------------+
       DNS protocol:|          |
     nameprepped ACE|          |
                    v          v
         +-------------+    +---------------------+
         | DNS servers |    | Application servers |
         +-------------+    +---------------------+

This document uses the generic term "ACE" for an ASCII-compatible
encoding. After the IDN Working Group has chosen a specific ACE, this
document will be updated to refer to just that single ACE. Until that
time, an implementor creating experimental software must choose an ACE
to use, such as RACE or LACE or DUDE.

2.1.1 Entry and display in applications

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

An IDNA-aware application can accept and display internationalized host
names in two formats: the internationalized character set(s) supported
by the application, and in an ACE. Applications MAY allow ACE input and
output, 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.
The optional use, especially during a transition period, of ACE
encodings in the user interface is described in section 3. Because name
parts encoded with ACE 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.

Host 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 the 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.

In protocols and document formats that define how to handle
specification or negotiation of charsets, IDN host name parts can be
encoded in any charset allowed by the protocol or document format. If a
protocol or document format only allows one charset, IDN host name parts
must be given in that charset. In any place where a protocol or document
format allows transmition of the characters in IDN host name parts, IDN
host name parts SHOULD be transmitted using whatever character encoding
and escape mechanism that the protocol or document format uses at that
place.

All protocols that have host names as protocol elements already have the
capacity for handling host names in the ASCII charset. Thus, IDN host
name parts can be specified in those protocols in the ACE charset, which
is a superset of the ASCII charset that uses the same set of octets.

2.1.2 Applications and resolvers

Applications communicate with resolver libraries through a programming
interface (API). Typically, the IETF does not standardize APIs, although
there are non-standard APIs specified for IPv6. This protocol does not
specify a specific API, but instead specifies only the input and output
formats of the host names to the resolver library.

Before converting the name parts into ACE, the application MUST prepare
each name part as specified in [NAMEPREP]. The application MUST use ACE