draft-ietf-idn-idna-06.txt   draft-ietf-idn-idna-07.txt 
Internet Draft Patrik Faltstrom Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-06.txt Cisco draft-ietf-idn-idna-07.txt Cisco
January 7, 2002 Paul Hoffman February 24, 2002 Paul Hoffman
Expires in six months IMC & VPNC Expires in six months IMC & VPNC
Adam M. Costello Adam M. Costello
UC Berkeley UC Berkeley
Internationalizing Domain Names in Applications (IDNA) Internationalizing Domain Names in Applications (IDNA)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
skipping to change at line 37 skipping to change at line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Until now, there has been no standard method for domain names to use Until now, there has been no standard method for domain names to use
characters outside the ASCII repertoire. This document defines characters outside the ASCII repertoire. This document defines
internationalized domain names (IDNs) and a mechanism called IDNA for internationalized domain names (IDNs) and a mechanism called IDNA for
handling them in a standard fashion. IDNs use characters drawn from a handling them in a standard fashion. IDNs use characters drawn from a
large repertoire (Unicode), but IDNA allows the non-ASCII characters to large repertoire (Unicode), but IDNA allows the non-ASCII characters to
be represented using the same octets used in so-called hostnames today. be represented using the same octets used in so-called host names
today. IDNA is only meant for processing domain names, not free
text.
1. Introduction 1. Introduction
IDNA works by allowing applications to use certain ASCII name labels IDNA works by allowing applications to use certain ASCII name labels
(beginning with a special prefix) to represent non-ASCII name labels. (beginning with a special prefix) to represent non-ASCII name labels.
Lower-layer protocols need not be aware of this; therefore IDNA does not Lower-layer protocols need not be aware of this; therefore IDNA does not
require changes to any infrastructure. In particular, IDNA does not require changes to any infrastructure. In particular, IDNA does not
require any changes to DNS servers, resolvers, or protocol elements, require any changes to DNS servers, resolvers, or protocol elements,
because the ASCII name service provided by the existing DNS is entirely because the ASCII name service provided by the existing DNS is entirely
sufficient. sufficient.
skipping to change at line 59 skipping to change at line 61
This document does not require any applications to conform to IDNA, This document does not require any applications to conform to IDNA,
but applications can elect to use IDNA in order to support IDN while but applications can elect to use IDNA in order to support IDN while
maintaining interoperability with existing infrastructure. Adding IDNA maintaining interoperability with existing infrastructure. Adding IDNA
support to an existing application entails changes to the application support to an existing application entails changes to the application
only, and leaves room for flexibility in the user interface. only, and leaves room for flexibility in the user interface.
A great deal of the discussion of IDN solutions has focused on A great deal of the discussion of IDN solutions has focused on
transition issues and how IDN will work in a world where not all of the transition issues and how IDN will work in a world where not all of the
components have been updated. Other proposals would require that user components have been updated. Other proposals would require that user
applications, resolvers, and DNS servers be updated in order for a user applications, resolvers, and DNS servers be updated in order for a user
to use an internationalized host name. Rather than require widespread to use an internationalized domain name. Rather than require widespread
updating of all components, IDNA requires only user applications to be updating of all components, IDNA requires only user applications to be
updated; no changes are needed to the DNS protocol or any DNS servers or updated; no changes are needed to the DNS protocol or any DNS servers or
the resolvers on user's computers. the resolvers on user's computers.
This document is being discussed on the ietf-idna@mail.apps.ietf.org 1.1 Interaction of protocol parts
mailing list. To subscribe, send a message to
ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in IDNA requires that implementations process input strings with Nameprep
the body of the message. [NAMEPREP], which is a profile of Stringprep [STRINGPREP], and then with
Punycode [PUNYCODE]. Implementations of IDNA MUST fully implement
Nameprep and Punycode; neither Nameprep nor Punycode are optional.
2 Terminology 2 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119 "MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
A code point is an integral value associated with a character in a coded A code point is an integral value associated with a character in a coded
character set. character set.
skipping to change at line 94 skipping to change at line 98
ASCII means US-ASCII, a coded character set containing 128 characters ASCII means US-ASCII, a coded character set containing 128 characters
associated with code points in the range 0..7F. Unicode is an extension 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 of ASCII: it includes all the ASCII characters and associates them with
the same code points. the same code points.
The term "LDH code points" is defined in this document to mean the code The term "LDH code points" is defined in this document to mean the code
points associated with ASCII letters, digits, and the hyphen-minus; that points 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 is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an abbreviation for
"letters, digits, hyphen". "letters, digits, hyphen".
[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.
A label is an individual part of a domain name. Labels are usually shown A 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 separated by dots; for example, the domain name "www.example.com" is
composed of three labels: "www", "example", and "com". In IDNA, not all composed of three labels: "www", "example", and "com". (The zero-length
text strings can be labels. (The zero-length root label that is implied root label that is implied in domain names, as described in [STD13], is
in domain names, as described in [STD13], is not considered a label in not considered a label in this specification.) Throughout this document
this specification.) the term "label" is shorthand for "text label", and "every label" means
"every text label". In IDNA, not all text strings can be labels.
An "internationalized domain name" (IDN) is a domain name for which the An "internationalized domain name" (IDN) is a domain name for which the
ToASCII operation (see section 4) can be applied to each label without ToASCII operation (see section 4) can be applied to each label without
failing. failing. This document does not attempt to define an "internationalized
host name". It is expected that protocols and name-handling bodies will
want to limit the characters allowed in IDNs further than what is
specified in this document, such as to prohibit additional characters
that they feel are unneeded or harmful in registered domain names.
An internationalized label contains characters from the Unicode An "internationalized label" is a label composed of characters from the
character set. To allow such a label to be handled by existing Unicode character set; note, however, that not every string of Unicode
applications, an "ACE label" is defined to be a label that contains only characters can be an internationalized label. To allow internationalized
ASCII characters but represents an equivalent label containing non-ASCII labels to be handled by existing applications, IDNA uses an "ACE label"
characters. For every internationalized label that cannot be directly (ACE stands for ASCII Compatible Encoding), which can be represented
represented in ASCII, there is an equivalent ACE label. The conversion using only ASCII characters but is equivalent to a label containing
of labels to and from the ACE form is specified in section 4. non-ASCII characters. More rigorously, an ACE label is defined to be any
label that the ToUnicode operation would alter (see section 4.2). For
every internationalized label that cannot be directly represented in
ASCII, there is an equivalent ACE label. The conversion of labels to and
from the ACE form is specified in section 4.
The "ACE prefix" is defined in this document to be a string of ASCII The "ACE prefix" is defined in this document to be a string of ASCII
characters that appears at the beginning of every ACE label. It is characters that appears at the beginning of every ACE label. It is
specified in section 5. specified in section 5.
A "domain name slot" is defined in this document to be a protocol element A "domain name slot" is defined in this document to be a protocol element
or a function argument or a return value (and so on) explicitly or a function argument or a return value (and so on) explicitly
designated for carrying a domain name. Examples of domain name slots designated for carrying a domain name. Examples of domain name slots
include: the QNAME field of a DNS query; the name argument of the include: the QNAME field of a DNS query; the name argument of the
gethostbyname() library function; the part of an email address following gethostbyname() library function; the part of an email address following
skipping to change at line 142 skipping to change at line 160
protocol or interface) or dynamic (for example, as a result of protocol or interface) or dynamic (for example, as a result of
negotiation in an interactive session). negotiation in an interactive session).
A "generic domain name slot" is defined in this document to be any A "generic domain name slot" is defined in this document to be any
domain name slot that is not an internationalized domain name slot. domain name slot that is not an internationalized domain name slot.
Obviously, this includes any domain name slot whose specification Obviously, this includes any domain name slot whose specification
predates IDNA. predates IDNA.
3. Requirements 3. Requirements
IDNA conformance means adherence of the following three rules: IDNA conformance means adherence of the following three requirements:
1) Whenever a domain name is put into a generic domain name slot, every 1) Whenever a domain name is put into a generic domain name slot (see
label MUST contain only ASCII characters. Given an internationalized section 2), every label MUST contain only ASCII characters. Given an
domain name (IDN), an equivalent domain name satisfying this requirement internationalized domain name (IDN), an equivalent domain name
can be obtained by applying the ToASCII operation (see section 4) satisfying this requirement can be obtained by applying the ToASCII
to each label. operation (see section 4) to each label.
2) ACE labels SHOULD be hidden from users whenever possible. Therefore, 2) ACE labels obtained from domain name slots SHOULD be hidden from
before a domain name is displayed to a user or is output into a context users except when the use of the non-ASCII form would cause problems or
likely to be viewed by users, the ToUnicode operation (see section 4) when the ACE form is explicitly requested. Given an internationalized
SHOULD be applied to each label. When requirements 1 and 2 both apply, domain name, an equivalent domain name containing no ACE labels can be
requirement 1 takes precedence. obtained by applying the ToUnicode operation (see section 4) to each
label. When requirements 1 and 2 both apply, requirement 1 takes
precedence.
3) Whenever two labels are compared, they MUST be considered to 3) Whenever two labels are compared, they MUST be considered to
match if and only if their ASCII forms (obtained by applying ToASCII) match if and only if their ASCII forms (obtained by applying ToASCII)
match using a case-insensitive ASCII comparison. match using a case-insensitive ASCII comparison.
4. Conversion operations 4. Conversion operations
This section specifies the ToASCII and ToUnicode operations. Each one This section specifies the ToASCII and ToUnicode operations. Each one
operates on a sequence of Unicode code points (but remember that all operates on a sequence of Unicode code points (but remember that all
ASCII code points are also Unicode code points). When domain names are ASCII code points are also Unicode code points). When domain names are
represented using character sets other than Unicode and ASCII, they will represented using character sets other than Unicode and ASCII, they will
need to first be transcoded to Unicode before these operations can be need to first be transcoded to Unicode before these operations can be
applied, and might need to be transcoded back afterwards. applied, and might need to be transcoded back afterwards.
4.1 ToASCII 4.1 ToASCII
The ToASCII operation takes a sequence of Unicode code points and The ToASCII operation takes a sequence of Unicode code points and
transforms it into a sequence of code points in the ASCII range (0..7F). transforms it into a sequence of code points in the ASCII range (0..7F).
The original sequence and the resulting sequence are equivalent labels The original sequence and the resulting sequence are equivalent labels.
(if the original is an internationalized label that cannot be directly (If the original is an internationalized label that cannot be directly
represented in ASCII, the result will be the equivalent ACE label). represented in ASCII, the result will be the equivalent ACE label.)
ToASCII fails if any step of it fails. Failure means that the original ToASCII fails if any step of it fails. If any step fails, the original
sequence cannot be used as a label in an IDN. sequence MUST NOT be used as a label in an IDN.
The inputs to ToASCII are a sequence of code points; a flag indicating
whether to prohibit unassigned code points (see [STRINGPREP]); and a
flag indicating whether to apply the host name syntax rules. The output
of ToASCII is either a sequence of ASCII code points or a failure
condition.
ToASCII never alters a sequence of code points that are all in the ASCII ToASCII never alters a sequence of code points that are all in the ASCII
range to begin with (although it may fail). range to begin with (although it could fail).
ToASCII consists of the following steps: ToASCII consists of the following steps:
1. If all code points in the sequence are in the ASCII range (0..7F) 1. If all code points in the sequence are in the ASCII range (0..7F)
then skip to step 3. then skip to step 3.
2. Perform the steps specified in [NAMEPREP]. 2. Perform the steps specified in [NAMEPREP] and fail if there is
an error.
3. Host-specific restrictions: If the label is part of a host name 3. If the label is part of a host name (or is subject to the host
(or is subject to host name syntax rules) then perform these name syntax rules) then perform these checks:
checks:
* Verify the absence of non-LDH ASCII code points; that is, the (a) Verify the absence of non-LDH ASCII code points; that is,
absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
* Verify the absence of leading and trailing hyphen-minus; that (b) Verify the absence of leading and trailing hyphen-minus;
is, the absence of U+002D at the beginning and end of the that is, the absence of U+002D at the beginning and end of
sequence. the sequence.
4. If all code points in the sequence are in the ASCII range (0..7F), 4. If all code points in the sequence are in the ASCII range (0..7F),
then skip to step 8. then skip to step 8.
5. Verify that the sequence does NOT begin with the ACE prefix. 5. Verify that the sequence does NOT begin with the ACE prefix.
6. Encode the sequence using the encoding algorithm in [PUNYCODE]. 6. Encode the sequence using the encoding algorithm in [PUNYCODE].
7. Prepend the ACE prefix. 7. Prepend the ACE prefix.
skipping to change at line 224 skipping to change at line 250
The ToUnicode operation takes a sequence of Unicode code points and The ToUnicode operation takes a sequence of Unicode code points and
returns a sequence of Unicode code points. If the input sequence is a returns a sequence of Unicode code points. If the input sequence is a
label in ACE form, then the result is an equivalent internationalized label in ACE form, then the result is an equivalent internationalized
label that is not in ACE form, otherwise the original sequence is label that is not in ACE form, otherwise the original sequence is
returned unaltered. returned unaltered.
ToUnicode never fails. If any step fails, then the original input ToUnicode never fails. If any step fails, then the original input
sequence is returned immediately in that step. sequence is returned immediately in that step.
The inputs to ToUnicode are a sequence of code points; a flag indicating
whether to prohibit unassigned code points (see [STRINGPREP]); and a
flag indicating whether to apply the host name syntax rules. The output
of ToUnicode is always a sequence of Unicode code points.
1. If all code points in the sequence are in the ASCII range (0..7F) 1. If all code points in the sequence are in the ASCII range (0..7F)
then skip to step 3. then skip to step 3.
2. Perform the steps specified in [NAMEPREP]. (If step 3 2. Perform the steps specified in [NAMEPREP] and fail if there is an
of ToASCII is also performed here, it will not affect the error. (If step 3 of ToASCII is also performed here, it will not
overall behavior of ToUnicode, but it is not necessary.) affect the overall behavior of ToUnicode, but it is not
necessary.)
3. Verify that the sequence begins with the ACE prefix, and save a 3. Verify that the sequence begins with the ACE prefix, and save a
copy of the sequence. copy of the sequence.
4. Remove the ACE prefix. 4. Remove the ACE prefix.
5. Decode the sequence using decoding algorithm in [PUNYCODE]. Save 5. Decode the sequence using decoding algorithm in [PUNYCODE]. Save
a copy of the result of this step. a copy of the result of this step.
6. Apply ToASCII. 6. Apply ToASCII.
7. Verify that the sequence matches the saved copy from step 3, using 7. Verify that the sequence matches the saved copy from step 3, using
a case-insensitive ASCII comparison. a case-insensitive ASCII comparison.
8. Return the saved copy from step 5. 8. Return the saved copy from step 5.
5. ACE prefix 5. ACE prefix
The ACE prefix, used in the conversion operations (section 4), will be [[ Note to the IESG and Internet Draft readers: The two uses of the
specified in a future revision of this document. It will be two string "IESG--" below are to be changed at time of publication to a
alphanumeric ASCII characters followed by two hyphen-minuses. The prefix which fulfills the requirements in the first paragraph. ]]
ToASCII and ToUnicode operations MUST recognize the ACE prefix in a
case-insensitive manner.
For example, the eventual ACE prefix might be the string "jk--". In this The ACE prefix, used in the conversion operations (section 4), is two
case, an ACE label might be "jk--r3c2a-qc902xs", where "r3c2a-qc902xs" alphanumeric ASCII characters followed by two hyphen-minuses. It cannot
is the part of the ACE label that is generated by the encoding steps in be any of the prefixes already used in earlier documents, which includes
[PUNYCODE]. the following: "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--"
and "zq--". The ToASCII and ToUnicode operations MUST recognize the ACE
prefix in a case-insensitive manner.
The ACE prefix for IDNA is "IESG--".
This means that an ACE label might be "IESG--de-jg4avhby1noc0d", where
"de-jg4avhby1noc0d" is the part of the ACE label that is generated by
the encoding steps in [PUNYCODE].
6. Implications for typical applications using DNS 6. Implications for typical applications using DNS
In IDNA, applications perform the processing needed to input In IDNA, applications perform the processing needed to input
internationalized domain names from users, display internationalized internationalized domain names from users, display internationalized
domain names to users, and process the inputs and outputs from DNS and domain names to users, and process the inputs and outputs from DNS and
other protocols that carry domain names. other protocols that carry domain names.
The components and interfaces between them can be represented The components and interfaces between them can be represented
pictorially as: pictorially as:
skipping to change at line 307 skipping to change at line 345
| DNS servers | | Application servers | | DNS servers | | Application servers |
+-------------+ +---------------------+ +-------------+ +---------------------+
6.1 Entry and display in applications 6.1 Entry and display in applications
Applications can accept domain names using any character set or sets Applications can accept domain names using any character set or sets
desired by the application developer, and can display domain names in any desired by the application developer, and can display domain names in any
charset. That is, the IDNA protocol does not affect the interface charset. That is, the IDNA protocol does not affect the interface
between users and applications. between users and applications.
An IDNA-aware application can accept and display internationalized domain An IDNA-aware application can accept and display internationalized
names in two formats: the internationalized character set(s) supported domain names in two formats: the internationalized character set(s)
by the application, and as an ACE label. Applications MAY allow input supported by the application, and as an ACE label. ACE labels that are
and display of ACE labels, but are not encouraged to do so except as an displayed or input MUST always include the ACE prefix. Applications MAY
interface for special purposes, possibly for debugging. ACE encoding is allow input and display of ACE labels, but are not encouraged to do so
opaque and ugly, and should thus only be exposed to users who absolutely except as an interface for special purposes, possibly for debugging. ACE
need it. The optional use, especially during a transition period, of ACE encoding is opaque and ugly, and should thus only be exposed to users
encodings in the user interface is described in section 6.4. Because who absolutely need it. The optional use, especially during a transition
name labels encoded as ACE name labels can be rendered either as the period, of ACE encodings in the user interface is described in section
encoded ASCII characters or the proper decoded characters, the 6.4. Because name labels encoded as ACE name labels can be rendered
application MAY have an option for the user to select the preferred 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 method of display; if it does, rendering the ACE SHOULD NOT be the
default. default.
Domain names are often stored and transported in many places. For example, Domain 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 they are part of documents such as mail messages and web pages. They are
transported in many parts of many protocols, such as both the transported in many parts of many protocols, such as both the
control commands and the RFC 2822 body parts of SMTP, and the headers control commands and the RFC 2822 body parts of SMTP, and the headers
and the body content in HTTP. It is important to remember that domain and the body content in HTTP. It is important to remember that domain
names appear both in domain name slots and in the content that is passed names appear both in domain name slots and in the content that is passed
over protocols. over protocols.
skipping to change at line 356 skipping to change at line 395
Applications normally use functions in the operating system when they Applications normally use functions in the operating system when they
resolve DNS queries. Those functions in the operating system are often resolve DNS queries. Those functions in the operating system are often
called "the resolver library", and the applications communicate with the called "the resolver library", and the applications communicate with the
resolver libraries through a programming interface (API). resolver libraries through a programming interface (API).
Because these resolver libraries today expect only domain names in Because these resolver libraries today expect only domain names in
ASCII, applications MUST prepare labels that are passed to the resolver ASCII, applications MUST prepare labels that are passed to the resolver
library using the ToASCII operation. Labels received from the resolver library using the ToASCII operation. Labels received from the resolver
library contain only ASCII characters; internationalized labels that library contain only ASCII characters; internationalized labels that
cannot be represented directly in ASCII use the ACE form. cannot be represented directly in ASCII use the ACE form. ACE labels
always include the ACE prefix.
IDNA-aware applications MUST be able to work with both IDNA-aware applications MUST be able to work with both
non-internationalized labels (those that conform to [STD13] non-internationalized labels (those that conform to [STD13]
and [STD3]) and internationalized labels. and [STD3]) and internationalized labels.
It is expected that new versions of the resolver libraries in the future It is expected that new versions of the resolver libraries in the future
will be able to accept domain names in other formats than ASCII, and will be able to accept domain names in other formats than ASCII, and
application developers might one day pass not only domain names in application developers might one day pass not only domain names in
Unicode, but also in local script to a new API for the resolver Unicode, but also in local script to a new API for the resolver
libraries in the operating system. libraries in the operating system.
skipping to change at line 398 skipping to change at line 438
6.4 Avoiding exposing users to the raw ACE encoding 6.4 Avoiding exposing users to the raw ACE encoding
All applications that might show the user a domain name obtained from a All applications that might show the user a domain name obtained from a
domain name slot, such as from gethostbyaddr or part of a mail header, domain name slot, such as from gethostbyaddr or part of a mail header,
SHOULD be updated as soon as possible in order to prevent users from SHOULD be updated as soon as possible in order to prevent users from
seeing the ACE. seeing the ACE.
If an application decodes an ACE name using ToUnicode but cannot show If an application decodes an ACE name using ToUnicode but cannot show
all of the characters in the decoded name, such as if the name contains all of the characters in the decoded name, such as if the name contains
characters that the output system cannot display, the application SHOULD characters that the output system cannot display, the application SHOULD
show the name in ACE format instead of displaying the name with the show the name in ACE format (which always includes the ACE prefix)
replacement character (U+FFFD). This is to make it easier for the user instead of displaying the name with the replacement character (U+FFFD).
to transfer the name correctly to other programs. Programs that by This is to make it easier for the user to transfer the name correctly to
default show the ACE form when they cannot show all the characters in a other programs. Programs that by default show the ACE form when they
name label SHOULD also have a mechanism to show the name that is cannot show all the characters in a name label SHOULD also have a
produced by the ToUnicode operation with as many characters as possible mechanism to show the name that is produced by the ToUnicode operation
and replacement characters in the positions where characters cannot be with as many characters as possible and replacement characters in the
displayed. positions where characters cannot be displayed.
The ToUnicode operation does not alter labels that are not valid ACE The ToUnicode operation does not alter labels that are not valid ACE
labels, even if they begin with the ACE prefix. After ToUnicode has been labels, even if they begin with the ACE prefix. After ToUnicode has been
applied, if a label still begins with the ACE prefix, then it is not a applied, if a label still begins with the ACE prefix, then it is not a
valid ACE label, and is not equivalent to any of the intermediate valid ACE label, and is not equivalent to any of the intermediate
Unicode strings constructed by ToUnicode. Unicode strings constructed by ToUnicode.
6.5 Bidirectional text in domain names 6.5 Bidirectional text in domain names
The display of domain names that contain bidirectional text is not covered The display of domain names that contain bidirectional text is not covered
in this document. It may be covered in a future version of this in this document. It may be covered in a future version of this
document, or may be covered in a different document. document, or may be covered in a different document.
For developers interested in displaying host names that have For developers interested in displaying domain names that have
bidirectional text, the Unicode standard has an extensive discussion of bidirectional text, the Unicode standard has an extensive discussion of
how to deal with reorder glyphs for display when dealing with how to deal with reorder glyphs for display when dealing with
bidirectional text such as Arabic or Hebrew. See [UAX9] for more bidirectional text such as Arabic or Hebrew. See [UAX9] for more
information. In particular, all Unicode text is stored in logical order. information. In particular, all Unicode text is stored in logical order.
6.6 DNSSEC authentication of IDN domain names 6.6 DNSSEC authentication of IDN domain names
DNS Security [DNSSEC] is a method for supplying cryptographic DNS Security [DNSSEC] is a method for supplying cryptographic
verification information along with DNS messages. Public Key verification information along with DNS messages. Public Key
Cryptography is used in conjunction with digital signatures to provide a Cryptography is used in conjunction with digital signatures to provide a
skipping to change at line 452 skipping to change at line 492
is the canonical name. In the presence of DNSSEC, this is the name that is the canonical name. In the presence of DNSSEC, this is the name that
MUST be signed in the zone and MUST be validated against. It also SHOULD MUST be signed in the zone and MUST be validated against. It also SHOULD
be used for other name comparisons, such as when a browser wants to be used for other name comparisons, such as when a browser wants to
indicate that a URL has been previously visited. indicate that a URL has been previously visited.
One consequence of this for sites deploying IDNA in the presence of One consequence of this for sites deploying IDNA in the presence of
DNSSEC is that any special purpose proxies or forwarders used to DNSSEC is that any special purpose proxies or forwarders used to
transform user input into IDNs must be earlier in the resolution flow transform user input into IDNs must be earlier in the resolution flow
than DNSSEC authenticating nameservers for DNSSEC to work. than DNSSEC authenticating nameservers for DNSSEC to work.
6.7 Limitations of IDNA
The IDNA protocol does not solve all linguistic issues with users
inputting names in different scripts. Many important language-based and
script-based mappings are not covered in IDNA and must be handled
outside the protocol. For example, names that are entered in a mix of
traditional and simplified Chinese characters will not be mapped to a
single canonical name. Another example is Scandinavian names that are
entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be
mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE).
7. Name Server Considerations 7. Name Server Considerations
Internationalized domain name data in zone files (as specified by section Internationalized domain name data in zone files (as specified by section
5 of RFC 1035) MUST be processed with ToASCII before it is entered in 5 of RFC 1035) MUST be processed with ToASCII before it is entered in
the zone files. the zone files.
It is imperative that there be only one ASCII encoding for a particular It is imperative that there be only one ASCII encoding for a particular
domain name. ACE is an encoding for domain name labels that use non-ASCII domain name. ACE is an encoding for domain name labels that use non-ASCII
characters. Thus, a primary master name server MUST NOT contain an characters. Thus, a primary master name server MUST NOT contain an
ACE-encoded label that decodes to an ASCII label. The ToASCII operation ACE-encoded label that decodes to an ASCII label. The ToASCII operation
assures that no such names are ever output from the operation. assures that no such names are ever output from the operation.
Name servers MUST NOT serve records with domain names that contain Name servers MUST NOT serve records with domain names that contain
non-ASCII characters; such names MUST be converted to ACE form by the non-ASCII characters; such names MUST be converted to ACE form by the
ToASCII operation in order to be served. If names that are not processed ToASCII operation in order to be served. If names that are not processed
by ToASCII are passed to an application, it will result in unpredictable by ToASCII are passed to an application, it will result in unpredictable
behavior. Note that [NAMEPREP] describes how to handle versioning of behavior. Note that [STRINGPREP] describes how to handle versioning of
unallocated codepoints. unallocated codepoints.
8. Root Server Considerations 8. Root Server Considerations
Because there are no changes to the DNS protocols, adopting this IDNs are likely to be somewhat longer than current host names, so the
protocol has no effect on the DNS root servers. bandwidth needed by the root servers should go up by a small amount.
Also, queries and responses for IDNs will probably be somewhat longer
than typical queries today, so more queries and responses may be forced
to go to TCP instead of UDP.
9. Security Considerations 9. Security Considerations
Much of the security of the Internet relies on the DNS. Thus, any change Security on the Internet partly relies on the DNS. Thus, any
to the characteristics of the DNS can change the security of much of the change to the characteristics of the DNS can change the security of much
Internet. of the Internet.
This memo describes an algorithm which encodes characters that are not This memo describes an algorithm which encodes characters that are not
valid according to STD3 and STD13 into octet values that are valid. No valid according to STD3 and STD13 into octet values that are valid. No
security issues such as string length increases or new allowed values security issues such as string length increases or new allowed values
are introduced by the encoding process or the use of these encoded are introduced by the encoding process or the use of these encoded
values, apart from those introduced by the ACE encoding itself. values, apart from those introduced by the ACE encoding itself.
Domain names are used by users to connect to Internet servers. The Domain names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers single internationalized name could be connected to different servers
skipping to change at line 504 skipping to change at line 558
security considerations from that document as well. security considerations from that document as well.
A. References A. References
[PUNYCODE] Adam Costello, "Punycode", draft-ietf-idn-punycode. [PUNYCODE] Adam Costello, "Punycode", draft-ietf-idn-punycode.
[DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC [DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of [NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep. Internationalized Domain Names", draft-ietf-idn-nameprep.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119. Requirement Levels", March 1997, RFC 2119.
[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication [STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
and Support" (RFC 1123), STD 3, October 1989. and Support" (RFC 1123), STD 3, October 1989.
[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC [STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
1034) and "Domain names - implementation and specification" (RFC 1035, 1034) and "Domain names - implementation and specification" (RFC 1035),
STD 13, November 1987. STD 13, November 1987.
[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm. [STRINGPREP] Paul Hoffman and Marc Blanchet, "Preparation of
http://www.unicode.org/unicode/reports/tr9/ Internationalized Strings ("stringprep")", draft-hoffman-stringprep,
work in progress
.
[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. [UNICODE] The Unicode Standard, Version 3.1.0: The Unicode Consortium.
The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley
Developers Press, 2000. ISBN 0-201-61633-5, as amended by: Unicode Developers Press, 2000. ISBN 0-201-61633-5, as amended by: Unicode
Standard Annex #27: Unicode 3.1 Standard Annex #27: Unicode 3.1,
<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>. <http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.
B. Design philosophy B. Authors' Addresses
Many proposals for IDN protocols have required that DNS servers be
updated to handle internationalized domain names. Because of this, a
person who wanted to use an internationalized domain name would have to be
sure that their request went to a DNS server that had been updated for
IDN. Further, that server could send queries only to other servers that
had been updated for IDN, because the queries contain new protocol
elements to differentiate IDN labels from current labels. In
addition, these proposals require that resolvers be updated to use the
new protocols, and in most cases the applications would need to be
updated as well.
These proposals would require changes to the application protocols that
use host names as protocol elements, because of 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 users have updated the applications,
they can 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.
C. Authors' Addresses
Patrik Faltstrom Patrik Faltstrom
Cisco Systems Cisco Systems
Arstaangsvagen 31 J Arstaangsvagen 31 J
S-117 43 Stockholm Sweden S-117 43 Stockholm Sweden
paf@cisco.com paf@cisco.com
Paul Hoffman Paul Hoffman
Internet Mail Consortium and VPN Consortium Internet Mail Consortium and VPN Consortium
127 Segre Place 127 Segre Place
 End of changes. 35 change blocks. 
123 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/