Internet Draft D. Crocker
draft-crocker-idn-idn-00.txt Brandenburg InternetWorking
Expires in six months 23 June 2002
Internationalized Domain Names (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
Globalization of the Internet requires that domain names
be able use characters outside the ASCII repertoire.
This document specifies internationalized domain names
(IDNs) and defines initial domain name constructs in
which IDNs can be used. IDNs use characters drawn from
a large repertoire (Unicode).
0. Document Change Notes --
This is a revision to draft-ietf-idn-idna-09.txt. It is
being distributed independently to facilitate
discussion.
The goal is to gain consensus about revisions to the IDN
working group document, specifically for the following
changes:
a. Split the document into two, one for defining
Internationalized Domain Names (IDN) and the other for
defining an encoding method of IDNs, namely IDNA using ACE.
b. Distinguish general IDN from its specific use for host
names (IDN-Host). Use for host names is specified more
precisely, in terms of a specific syntax BNF rule from the
relevant existing DNS specification, so that IDN-Host will
apply precisely to all DNS record fields and protocol units
conforming to that BNF.
1. Introduction
Until now, there has been no standard method for domain
names to use characters outside the ASCII repertoire.
This document defines enhancements to the definition of
domain names, to support internationalized domain names
(IDN). The details for doing protocol encoding of IDNs
are specified separately.
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].
"ASCII"
means US-ASCII [USASCII], a coded character set
containing 128 characters associated with code
points in the range 0..7F. Unicode is an extension
of ASCII: it includes all the ASCII characters and
associates them with the same code points.
Code point
refers to an integral value associated with a
character in a coded character set.
Domain name
is used as a general term for strings conforming to
[STD13]. [STD13] talks about "domain names" and
"host names", but many people use the terms
interchangeably. Further, because [STD13] was not
terribly clear, many people who are sure they know
the exact definitions of each of these terms
disagree on the definitions. This document uses the
terms separately.
Domain name slot
refers to a protocol element or a function argument
or a return value (and so on) explicitly designated
for carrying a domain name. Examples of domain name
slots include: the QNAME field of a DNS query; the
name argument of the gethostbyname() library
function; the part of an email address following
the at-sign (@) in the From: field of an email
message header; and the host portion of the URI in
the src attribute of an HTML <IMG> tag. General
text that just happens to contain a domain name is
not a domain name slot; for example, a domain name
appearing in the plain text body of an email
message is not occupying a domain name slot.
Host name
is a domain name conforming to STD13, with the
naming character set limited to LDH.
Internationalized host name (IDN-Host)
is an IDN conforming to the STD13, except that it
also supports non-ASCII characters from Unicode.
Internationalized domain name" (IDN)
is a domain name that has characters drawn from the
restricted set of Unicode defined in <<???>>
Internationalized label
is a label composed of characters from the Unicode
character set; note, however, that not every string
of Unicode characters can be an internationalized
label.
IDN-native
is a domain name slot specified to hold an
internationalized domain name. The designation may
be static (for example, in the specification of the
protocol or interface) or dynamic (for example, as
a result of negotiation in an interactive session).
Label
is an individual part of a domain name. Labels are
usually shown separated by dots; for example, the
domain name "www.example.com" is composed of three
labels: "www", "example", and "com". (The zero-
length root label described in [STD13], which can
be explicit as in "www.example.com." or implicit as
in "www.example.com", is not considered a label in
this specification.) Throughout this document the
term "label" is shorthand for "text label", and
"every label" means "every text label". In IDNA,
not all text strings can be labels.
LDH code points
is defined to mean the codepoints associated with
ASCII letters, digits, and the hyphen-minus; that
is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
abbreviation for "letters, digits, hyphen".
Unicode
is a coded character set [UNICODE] containing tens
of thousands of characters. A single Unicode code
point is denoted by "U+" followed by four to six
hexadecimal digits, while a range of Unicode code
points is denoted by two hexadecimal numbers
separated by "..", with no prefixes.
3. International Domain Names (IDN)
3.1. Data representation
This specification enhances the set of values for valid
domain name labels from the restricted ASCII specified
in [STD3], to include [Unicode].
Mechanisms for encoding Unicode values in Domain Names
is specified separately. Hence this specification
provides no detail for IDNs in "native" binary form (IDN-
Native) or for "encoded" Unicode-based IDNs.
3.2. Dot as label separator
For systems supporting IDN, wherever dot is permitted as
a label separator, the following characters MUST be
recognized as dots: U+002E (full stop), U+3002
(ideographic full stop), U+FF0E (fullwidth full stop),
U+FF61 (halfwidth ideographic full stop).
<< // Are there also multiple Unicode characters
permitted for at-sign? What about for slash ("/")?
If not, then why is the domain name lexical
analyzer now required to look for 4 characters
rather than only one?
This appears to be a case of putting into the
protocol something that is, in fact, entirely a
user-interface issue. That some user interfaces
will choose to map U+3002 to ASCII dot does not
mean that it needs to be in the protocol. // /Dave
>>
4. References
4.1. Normative references
[STD3] Bob Braden, "Requirements for Internet Hosts --
Communication Layers" (RFC 1122) and "Requirements for
Internet Hosts -- Application and Support" (RFC 1123),
STD 3, October 1989.
[STD13] Paul Mockapetris, "Domain names - concepts and
facilities" (RFC 1034) and "Domain names -
implementation and specification" (RFC 1035), STD 13,
November 1987.
4.2. Informative references
[DNSSEC] Don Eastlake, "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2119] Scott Bradner, "Key words for use in RFCs to
Indicate Requirement Levels", March 1997, RFC 2119.
[UAX9] Unicode Standard Annex #9, The Bidirectional
Algorithm,
<http://www.unicode.org/unicode/reports/tr9/>.
[UNICODE] The Unicode Standard, Version 3.1.0: The
Unicode Consortium. The Unicode Standard, Version 3.0.
Reading, MA, Addison-Wesley Developers Press, 2000. ISBN
0-201-61633-5, as amended by: Unicode Standard Annex
#27: Unicode 3.1,
<http://www.unicode.org/unicode/reports/tr27/tr27-
4.html>.
[USASCII] Vint Cerf, "ASCII format for Network
Interchange", October 1969, RFC 20.
5. Security Considerations
Security on the Internet partly relies on the DNS. Thus,
any change to the characteristics of the DNS can change
the security of much of the Internet.
This memo describes an algorithm that encodes characters
that are not valid according to STD3 and STD13 into
octet values that are valid. No security issues such as
string length increases or new allowed values are
introduced by the encoding process or the use of these
encoded values, apart from those introduced by the ACE
encoding itself.
Domain 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 domain name.
6. Authors' Addresses
Patrik Faltstrom
Cisco Systems
Arstaangsvagen 31 J
S-117 43 Stockholm Sweden
paf@cisco.com
Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
phoffman@imc.org
Adam M. Costello
University of California, Berkeley
idna-spec.amc @ nicemice.net