273 lines
11 KiB
Plaintext
273 lines
11 KiB
Plaintext
Internet Draft Paul Hoffman
|
|
draft-ietf-idn-idna-00.txt IMC & VPNC
|
|
September 12, 2000 Patrik Faltstrom
|
|
Expires in six months Cisco
|
|
|
|
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.
|
|
|
|
1.1 Design philosophy
|
|
|
|
To date, the 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.
|
|
|
|
Updating all (or even a significant percentage) of the DNS servers in
|
|
the world will be difficult, to say the least. Because of this, we have
|
|
designed a protocol that requires no updating of any name servers. IDNA
|
|
still requires the updating of applications, but once a
|
|
user has updated these, she or he could immediately start using
|
|
internationalized host names. The cost of implementing IDN would thus be
|
|
much lower, and the speed of implementation will 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].
|
|
|
|
1.3 IDN summary
|
|
|
|
Using the terminology in [IDNCOMP], this protocol specifies an IDN
|
|
architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE),
|
|
and the method for distinguishing ACE name parts from current name parts
|
|
is ace-2.1.1 (add hopefully-unique legal tag). Because there is no
|
|
changes needed to the DNS, the transition strategy is trans-1 (always do
|
|
current plus new architecture).
|
|
|
|
|
|
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 | | End system
|
|
| +-------------+
|
|
| ^
|
|
| | API call and return: nameprepped RACE
|
|
| v
|
|
| +----------+
|
|
| | Resolver |
|
|
| +----------+ |
|
|
+----------------^--------------------------------+
|
|
| DNS query and response: nameprepped RACE
|
|
v
|
|
+-------------+
|
|
| DNS servers |
|
|
+-------------+
|
|
|
|
|
|
2.1.1 Users and 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 RACE [RACE] ASCII-compatible encoding.
|
|
Applications MAY allow RACE input and output, but are not encouraged to
|
|
do so except as an interface for advanced users, possibly for debugging.
|
|
RACE 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 RACE encodings in the user interface is described
|
|
in section 3. Since RACE can be rendered either as the encoded ASCII
|
|
glyphs or the proper decoded character glyphs, the rendering engine for
|
|
an application SHOULD have an option for the user to select the
|
|
preferred display; if it does, rendering the RACE SHOULD NOT be the
|
|
default.
|
|
|
|
2.1.2 Applications and resolvers
|
|
|
|
Applications communicate with resolver libraries through a programming
|
|
interface (API). Typically, the IETF does not standardize APIs, although
|
|
it has 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 RACE, the application MUST prepare
|
|
each name part as specified in [NAMEPREP]. The application MUST use RACE
|
|
ASCII-compatible encoding for the name parts that are sent to the
|
|
resolver, and will always get name parts encoded in RACE from the
|
|
resolver.
|
|
|
|
IDNA-aware applications MUST be able to work with both
|
|
non-internationalized host name parts (those that conform to RFC 1035
|
|
[STD13]) and internationalized host name parts. An IDNA-aware
|
|
application that is resolving a non-internationalized host name parts
|
|
MUST NOT do any preparation or conversion to RACE on any
|
|
non-internationalized name part.
|
|
|
|
2.1.3 Resolvers and DNS servers
|
|
|
|
An operating system might have a set of libraries for converting host
|
|
names to nameprepped RACE. The input to such a library might be in one
|
|
or more charsets that are used in applications (UTF-8 and UTF-16 are
|
|
likely candidates for almost any operating system, and script-specific
|
|
charsets are likely for localized operating systems). The output would
|
|
be either the unchanged name part (if the input already conforms to [STD
|
|
13]), or the nameprepped, RACE-encoded name part. Such a library would
|
|
help keep applications smaller.
|
|
|
|
DNS servers MUST use the RACE format for internationalized host name
|
|
parts.
|
|
|
|
If a signalling system which makes negotiation possible between old and
|
|
new DNS clients and servers is standardized in the future, the encoding
|
|
of the query in the DNS protocol itself can be changed from RACE to
|
|
something else, such as UTF-8. The question whether or not this should
|
|
be used is, however, a separate problem and is not discussed in this
|
|
memo.
|
|
|
|
2.1.4 Avoiding exposing users to the raw ACE encoding
|
|
|
|
All applications that might show the user a host name that was received
|
|
from a gethostbyaddr or other such lookup SHOULD update as soon as
|
|
possible in order to prevent users from seeing the ACE. However, this is
|
|
not considered a big problem because so few applications show this type
|
|
of resolution to users.
|
|
|
|
|
|
3. Name Server Considerations
|
|
|
|
It is imperative that there be only one encoding for a particular host
|
|
name. RACE is an encoding for host name parts that use characters
|
|
outside those allowed for host names [STD 13]. Thus, a primary master
|
|
name server MUST NOT contain an RACE-encoded name that decodes to a host
|
|
name that is allowed in [STD 13].
|
|
|
|
Name servers MUST NOT have any records with host names that contain
|
|
internationalized name parts unless those name parts have be prepared
|
|
according to [NAMEPREP]. If names that are not legal in [NAMEPREP] are
|
|
passed to an application, it will result in an error being passed to the
|
|
application with no error being reported to the name server. Further, no
|
|
application will ever ask for a name that is not legal in [NAMEPREP]
|
|
because requests always go through [NAMEPREP] before getting to the DNS.
|
|
|
|
The host name data in zone files (as specified by section 5 of RFC 1035)
|
|
MUST be both nameprepped and RACE encoded.
|
|
|
|
|
|
4. Root Server Considerations
|
|
|
|
Because there are no changes to the DNS protocols, adopting this
|
|
protocol has no effect on the root servers.
|
|
|
|
|
|
5. Security Considerations
|
|
|
|
Much of the security of the Internet relies on the DNS. Thus, any change
|
|
to the characteristics of the DNS can change the security of much of the
|
|
Internet.
|
|
|
|
Host names are used by users to connect to Internet servers. The
|
|
security of the Internet would be compromised if a user entering a
|
|
single internationalized name could be connected to different servers
|
|
based on different interpretations of the internationalized host name.
|
|
|
|
Because this document normatively refers to [NAMEPREP], it includes the
|
|
security considerations from that document as well.
|
|
|
|
|
|
6. References
|
|
|
|
[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
|
|
Proposals", draft-ietf-idn-compare.
|
|
|
|
[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
|
|
Internationalized Host Names", draft-ietf-idn-nameprep.
|
|
|
|
[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
|
|
draft-ietf-idn-race.
|
|
|
|
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
|
|
Requirement Levels", March 1997, RFC 2119.
|
|
|
|
[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
|
|
10646", January 1998, RFC 2279.
|
|
|
|
[STD13] Paul Mockapetris, "Domain names - implementation and
|
|
specification", November 1987, STD 13 (RFC 1035).
|
|
|
|
|
|
A. Authors' Addresses
|
|
|
|
Paul Hoffman
|
|
Internet Mail Consortium and VPN Consortium
|
|
127 Segre Place
|
|
Santa Cruz, CA 95060 USA
|
|
phoffman@imc.org
|
|
|
|
Patrik Faltstrom
|
|
Cisco Systems
|
|
170 West Tasman Drive SJ-13/2
|
|
San Jose, CA 95134 USA
|
|
paf@cisco.com
|