draft-ietf-idn-idna-09.txt   draft-ietf-idn-idna-10.txt 
Internet Draft Patrik Faltstrom Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-09.txt Cisco draft-ietf-idn-idna-10.txt Cisco
May 24, 2002 Paul Hoffman June 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 38 skipping to change at line 38
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 host names today. be represented using the same octets used in so-called host names today.
This representation allows IDNs to be introduced with minimal changes to This representation allows IDNs to be introduced with no changes to
the existing DNS infrastructure. IDNA is only meant for processing the existing DNS infrastructure. IDNA is only meant for processing
domain names, not free text. 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 depend on changes to any infrastructure. In particular, IDNA does not
require any changes to DNS servers, resolvers, or protocol elements, depend on 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 for IDNA.
This document does not require any applications to conform to IDNA, but This document does not require any applications to conform to IDNA, but
applications can elect to use IDNA in order to support IDN while applications can elect to use IDNA in order to support IDN while
maintaining interoperability with existing infrastructure. Adding IDNA maintaining interoperability with existing infrastructure. If an
support to an existing application entails changes to the application application wants to use non-ASCII characters in domain names, IDNA is
only, and leaves room for flexibility in the user interface. the only currently-defined option. Adding IDNA support to an existing
application entails changes to the application 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. Proposals that were not chosen by the IDN components have been updated. Proposals that were not chosen by the IDN
Working Group would require that user applications, resolvers, and DNS Working Group would depend on user applications, resolvers, and DNS
servers be updated in order for a user to use an internationalized servers being updated in order for a user to use an internationalized
domain name. Rather than require widespread updating of all components, domain name. Rather than rely on widespread updating of all components,
IDNA requires only user applications to be updated; no changes are IDNA depends on updates to user applications only; no changes are needed
needed to the DNS protocol or any DNS servers or the resolvers on user's to the DNS protocol or any DNS servers or the resolvers on user's
computers. computers.
1.1 Brief overview for application developers 1.1 Brief overview for application developers
Applications can use IDNA to support internationalized domain names Applications can use IDNA to support internationalized domain names
anywhere that ASCII domain names are already supported, including DNS anywhere that ASCII domain names are already supported, including DNS
master files and resolver interfaces. (Applications can also define master files and resolver interfaces. (Applications can also define
protocols and interfaces that support IDNs directly using non-ASCII protocols and interfaces that support IDNs directly using non-ASCII
representations. IDNA does not prescribe any particular representation representations. IDNA does not prescribe any particular representation
for new protocols, but it still defines which names are valid and how for new protocols, but it still defines which names are valid and how
skipping to change at line 133 skipping to change at line 135
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 [STD13] talks about "domain names" and "host names", but many people use
the terms interchangeably. Further, because [STD13] was not terribly the terms interchangeably. Further, because [STD13] was not terribly
clear, many people who are sure they know the exact definitions of each clear, many people who are sure they know the exact definitions of each
of these terms disagree on the definitions. In this document the term of these terms disagree on the definitions. In this document the term
"domain name" is used in general. When referring explicitly to the "domain name" is used in general. This document explicitly refers to
syntax restrictions for host names in [STD3], the term "host name [STD3] to make it clear where this syntactic restrictions apply.
syntax" is used.
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". (The zero-length composed of three labels: "www", "example", and "com". (The zero-length
root label described in [STD13], which can be explicit as in root label described in [STD13], which can be explicit as in
"www.example.com." or implicit as in "www.example.com", is not "www.example.com." or implicit as in "www.example.com", is not
considered a label in this specification.) Throughout this document the considered a label in this specification.) IDNA extends the set of
term "label" is shorthand for "text label", and "every label" means usable characters in labels that are text. For the rest of this
"every text label". In IDNA, not all text strings can be labels. document, the term "label" is shorthand for "text label", and "every
label" means "every text label".
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. This document does not attempt to define an "internationalized failing. This document does not attempt to define an "internationalized
host name". It is expected that some name-handling bodies, such as large host name". It is expected that some name-handling bodies, such as large
zone administrators and groups of affiliated zone administrators, will zone administrators and groups of affiliated zone administrators, will
want to limit the characters allowed in IDNs further than what is want to limit the characters allowed in IDNs further than what is
specified in this document, such as to prohibit additional characters specified in this document, such as to prohibit additional characters
that they feel are unneeded or harmful in registered domain names. that they feel are unneeded or harmful in registered domain names.
skipping to change at line 280 skipping to change at line 282
The following two subsections define the ToASCII and ToUnicode The following two subsections define the ToASCII and ToUnicode
operations that are used in step 4. operations that are used in step 4.
4.1 ToASCII 4.1 ToASCII
The ToASCII operation takes a sequence of Unicode code points that make The ToASCII operation takes a sequence of Unicode code points that make
up one label and transforms it into a sequence of code points in the up one label and transforms it into a sequence of code points in the
ASCII range (0..7F). If ToASCII succeeds, the original sequence and the ASCII range (0..7F). If ToASCII succeeds, the original sequence and the
resulting sequence are equivalent labels. resulting sequence are equivalent labels.
It is important to note that the ToASCII operation can fail. If the It is important to note that the ToASCII operation can fail. ToASCII
ToASCII operation fails on any label in a domain name, that domain name fails if any step of it fails. If any step of the ToASCII operation
MUST NOT be used as an internationalized domain name. The application fails on any label in a domain name, that domain name MUST NOT be used
needs to have some method of dealing with this failure. as an internationalized domain name. The application needs to have some
method of dealing with this failure.
The inputs to ToASCII are a sequence of code points, the AllowUnassigned The inputs to ToASCII are a sequence of code points, the AllowUnassigned
flag, and the UseSTD3ASCIIRules flag. The output of ToASCII is either a flag, and the UseSTD3ASCIIRules flag. The output of ToASCII is either a
sequence of ASCII code points or a failure condition. 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 could fail). Applying the ToASCII range to begin with (although it could fail). Applying the ToASCII
operation multiple times has exactly the same effect as applying it just operation multiple times has exactly the same effect as applying it just
once. once.
skipping to change at line 429 skipping to change at line 432
| +----------+ | encodings | | +----------+ | encodings |
| ^ | | | ^ | |
+-----------------|----------|----------------------+ +-----------------|----------|----------------------+
DNS protocol: | | DNS protocol: | |
ACE | | ACE | |
v v v v
+-------------+ +---------------------+ +-------------+ +---------------------+
| DNS servers | | Application servers | | DNS servers | | Application servers |
+-------------+ +---------------------+ +-------------+ +---------------------+
The box labeled "Application" is where the application splits a host The box labeled "Application" is where the application splits a domain
name into labels, sets the appropriate flags, and performs the ToASCII name into labels, sets the appropriate flags, and performs the ToASCII
and ToUnicode operations. This is described in section 4. and ToUnicode operations. This is described in section 4.
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 desired by the application developer, and can display domain names in
any charset. That is, the IDNA protocol does not affect the interface any charset. That is, the IDNA protocol does not affect the interface
between users and applications. between users and applications.
skipping to change at line 493 skipping to change at line 496
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. ACE labels cannot be represented directly in ASCII use the ACE form. ACE labels
always include the ACE prefix. always include the ACE prefix.
An operating system might have a set of libraries for performing the
ToASCII operation. 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).
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] and [STD3]) non-internationalized labels (those that conform to [STD13] and [STD3])
and internationalized labels. 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. Thus the ToASCII and ToUnicode libraries in the operating system. Thus the ToASCII and ToUnicode
operations might be performed inside these new versions of the resolver operations might be performed inside these new versions of the resolver
libraries. libraries.
Domain names stored in zones follow the rules for "stored strings" from Domain names passed to resolvers or put into the question
[STRINGPREP]. Domain names passed to resolvers or put into the question
section of DNS requests follow the rules for "queries" from section of DNS requests follow the rules for "queries" from
[STRINGPREP]. [STRINGPREP].
6.3 DNS servers 6.3 DNS servers
An operating system might have a set of libraries for performing the Domain names stored in zones follow the rules for "stored strings" from
ToASCII operation. The input to such a library might be in one or more [STRINGPREP].
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).
For internationalized labels that cannot be represented directly in For internationalized labels that cannot be represented directly in
ASCII, DNS servers MUST use the ACE form produced by the ToASCII ASCII, DNS servers MUST use the ACE form produced by the ToASCII
operation. All IDNs served by DNS servers MUST contain only ASCII operation. All IDNs served by DNS servers MUST contain only ASCII
characters. characters.
If a signaling system which makes negotiation possible between old and If a signaling system which makes negotiation possible between old and
new DNS clients and servers is standardized in the future, the encoding new DNS clients and servers is standardized in the future, the encoding
of the query in the DNS protocol itself can be changed from ACE to of the query in the DNS protocol itself can be changed from ACE to
something else, such as UTF-8. The question whether or not this should 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 be used is, however, a separate problem and is not discussed in this
memo. memo.
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 Any application 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 will need to be updated if it is 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 (which always includes the ACE prefix) show the name in ACE format (which always includes the ACE prefix)
instead of displaying the name with the replacement character (U+FFFD). instead of displaying the name with the replacement character (U+FFFD).
This is to make it easier for the user to transfer the name correctly to This is to make it easier for the user to transfer the name correctly to
other programs. Programs that by default show the ACE form when they other programs. Programs that by default show the ACE form when they
cannot show all the characters in a name label SHOULD also have a cannot show all the characters in a name label SHOULD also have a
mechanism to show the name that is produced by the ToUnicode operation mechanism to show the name that is produced by the ToUnicode operation
with as many characters as possible and replacement characters in the with as many characters as possible and replacement characters in the
positions where characters cannot be 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 DNSSEC authentication of IDN domain names
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
document, or may be covered in a different document.
For developers interested in displaying domain names that have
bidirectional text, the Unicode standard has an extensive discussion of
how to deal with reorder glyphs for display when dealing with
bidirectional text such as Arabic or Hebrew. See [UAX9] for more
information. In particular, all Unicode text is stored in logical order.
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
means for a requester of domain information to authenticate the source means for a requester of domain information to authenticate the source
of the data. This ensures that it can be traced back to a trusted of the data. This ensures that it can be traced back to a trusted
source, either directly, or via a chain of trust linking the source of source, either directly, or via a chain of trust linking the source of
the information to the top of the DNS hierarchy. the information to the top of the DNS hierarchy.
IDNA specifies that all internationalized domain names served by DNS IDNA specifies that all internationalized domain names served by DNS
servers that cannot be represented directly in ASCII must use the ACE servers that cannot be represented directly in ASCII must use the ACE
form produced by the ToASCII operation. This operation must be performed form produced by the ToASCII operation. This operation must be performed
prior to a zone being signed by the private key for that zone. Because prior to a zone being signed by the private key for that zone. Because
of this ordering, it is important to recognize that DNSSEC authenticates of this ordering, it is important to recognize that DNSSEC authenticates
the ASCII domain name, not the Unicode form or the mapping between the the ASCII domain name, not the Unicode form or the mapping between the
Unicode form and the ASCII form. In other words, the output of ToASCII Unicode form and the ASCII form. In the presence of DNSSEC, this is the
is the canonical name. In the presence of DNSSEC, this is the name that name that MUST be signed in the zone and MUST be validated against.
MUST be signed in the zone and MUST be validated against.
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 6.6 Limitations of IDNA
The IDNA protocol does not solve all linguistic issues with users The IDNA protocol does not solve all linguistic issues with users
inputting names in different scripts. Many important language-based and inputting names in different scripts. Many important language-based and
script-based mappings are not covered in IDNA and must be handled 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 outside the protocol. For example, names that are entered in a mix of
traditional and simplified Chinese characters will not be mapped to a traditional and simplified Chinese characters will not be mapped to a
single canonical name. Another example is Scandinavian names that are single canonical name. Another example is Scandinavian names that are
entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be
mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE). 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 Because the specification of the DNS database content in [STD13]
section 5 of RFC 1035) MUST be processed with ToASCII before it is predates IDNA, DNS database content (such as common zone files) are
entered in the zone files. IDN-unaware, and hence requirement 2 of section 3 of this document
applies to them. Internationalized domain names MUST be converted to
their equivalent ASCII forms before being entered into DNS database
content.
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. Thus, a primary master name server MUST NOT contain an domain name. Because of the design of the ToASCII and ToUnicode
ACE-encoded label that decodes to an ASCII label. The ToASCII operation operations, there are no ACE labels that decode to ASCII labels, and
assures that no such names are ever output from the operation. therefore name servers cannot contain multiple ASCII encodings of the
same domain name.
Name servers MUST NOT serve records with domain names that contain [RFC2181] explicitly allows domain labels to contain octets beyond the
non-ASCII characters; such names MUST be converted to ACE form by the ASCII range (0..7F), and this document does not change that. Note,
ToASCII operation in order to be served. If names that are not processed however, that there is no defined interpretation of octets 80..FF as
by ToASCII are passed to an application, it will result in unpredictable characters. If labels containing these octets are returned to
behavior. Note that [STRINGPREP] describes how to handle versioning of applications, unpredictable behavior could result. The ASCII form
unallocated codepoints. defined by ToASCII is the only standard representation for
internationalized labels in the current DNS protocol.
8. Root Server Considerations 8. Root Server Considerations
IDNs are likely to be somewhat longer than current host names, so the IDNs are likely to be somewhat longer than current domain names, so the
bandwidth needed by the root servers should go up by a small amount. bandwidth needed by the root servers is likely to go up by a small amount.
Also, queries and responses for IDNs will probably be somewhat longer Also, queries and responses for IDNs will probably be somewhat longer
than typical queries today, so more queries and responses may be forced than typical queries today, so more queries and responses may be forced
to go to TCP instead of UDP. to go to TCP instead of UDP.
9. References 9. References
9.1 Normative references 9.1 Normative references
[PUNYCODE] Adam Costello, "Punycode: An encoding of Unicode for use with [PUNYCODE] Adam Costello, "Punycode: An encoding of Unicode for use with
IDNA", draft-ietf-idn-punycode. IDNA", draft-ietf-idn-punycode.
skipping to change at line 659 skipping to change at line 655
work in progress work in progress
9.2 Informative references 9.2 Informative references
[DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC [DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[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.
[RFC2181] Robert Elz and Randy Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm, [UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm,
<http://www.unicode.org/unicode/reports/tr9/>. <http://www.unicode.org/unicode/reports/tr9/>.
[UNICODE] The Unicode Standard, Version 3.1.0: The Unicode Consortium. [UNICODE] The Unicode Consortium. The Unicode Standard, Version 3.2.0 is
The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley defined by The Unicode Standard, Version 3.0 (Reading, MA,
Developers Press, 2000. ISBN 0-201-61633-5, as amended by: Unicode Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode
Standard Annex #27: Unicode 3.1, Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/)
<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>. and by the Unicode Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/).
[USASCII] Vint Cerf, "ASCII format for Network Interchange", October [USASCII] Vint Cerf, "ASCII format for Network Interchange", October
1969, RFC 20. 1969, RFC 20.
10. Security Considerations 10. Security Considerations
Security on the Internet partly relies on the DNS. Thus, any change to 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 the characteristics of the DNS can change the security of much of the
Internet. 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 identify and connect to Internet
security of the Internet would be compromised if a user entering a servers. The security of the Internet is compromised if a user entering
single internationalized name could be connected to different servers a single internationalized name is connected to different servers based
based on different interpretations of the internationalized domain name. on different interpretations of the internationalized domain name.
Because this document normatively refers to [NAMEPREP], it includes the When systems use local character sets other than ASCII and Unicode, this
security considerations from that document as well. specification leaves the the problem of transcoding between the local
character set and Unicode up to the application. If different
applications (or different versions of one application) implement
different transcoding rules, they could interpret the same name
differently and contact different servers. This problem is not solved by
security protocols like TLS that do not take local character sets into
account.
Because this document normatively refers to [NAMEPREP], [PUNYCODE], and
[STRINGPREP], it includes the security considerations from those
documents as well.
If or when this specification is updated to use a more recent Unicode
normalization table, the new normalization table will need to be
compared with the old to spot backwards incompatible changes. If there
are such changes, they will need to be handled somehow, or there will be
security as well as operational implications. Methods to handle the
conflicts could include keeping the old normalization, or taking care of
the conflicting characters by operational means, or some other method.
Implementations MUST NOT use more recent normalization tables than the
one referenced from this document, even though more recent tables may be
provided by operating systems. If an application is unsure of which
version of the normalization tables are in the operating system, the
application needs to include the normalization tables itself. Using
normalization tables other than the one referenced from this
specification could have security and operational implications.
To help prevent confusion between characters that are visually similar,
it is suggested that implementations provide visual indications where a
domain name contains multiple scripts. Such mechanisms can also be used
to show when a name contains a mixture of simplified and traditional
Chinese characters, or to distinguish zero and one from O and l.
11. Authors' Addresses 11. 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
Santa Cruz, CA 95060 USA Santa Cruz, CA 95060 USA
phoffman@imc.org phoffman@imc.org
Adam M. Costello Adam M. Costello
University of California, Berkeley University of California, Berkeley
idna-spec.amc @ nicemice.net idna-spec.amc @ nicemice.net
A. Changes from -09 to -10
[[ To be removed when published as an RFC ]]
In the first paragraph of section 1, change "require" to "depend on"
in two places. Also, add "for IDNA" to the end of the paragraph.
In the second paragraph of section 1, add the following after the
first sentence: "If an application wants to use non-ASCII characters in
domain names, IDNA is the only currently-defined option.".
In the second sentence of the third paragraph of section 1, change
"require that" to "depend on". Change the third sentence from "Rather
than require widespread updating of all components, IDNA requires only
user applications to be updated; ..." to "Rather than rely on widespread
updating of all components, IDNA depends on updates to user applications
only; ...".
In section 2, change:
Throughout this document the term "label" is shorthand for "text
label", and "every label" means "every text label".
to:
IDNA extends the set of usable characters in labels that are text.
For the rest of this document, the term "label" is shorthand for
"text label", and "every label" means "every text label".
In section 2, change "When referring explicitly to the syntax
restrictions for host names in [STD3], the term "host name syntax" is
used." to "This document explicitly refers to [STD3] to make it clear
where this syntactic restrictions apply."
In section 4.1, add "ToASCII fails if any step of it fails." after the
first sentence of the second paragraph. Change the sentence that starts
"If the ToASCII operation fails..." to "If any step of the ToASCII
operation fails...".
Change "host name" to "domain name" in section 6 and section 8.
Move the sentence "Domain names stored in zones follow the rules for
"stored strings" from [STRINGPREP]." from the end of section 6.2 to the
beginning of section 6.3.
Move the first paragraph of section 6.3 to just after the second
paragraph in section 6.2, where it is more appropriate.
In the first sentence of section 6.4, change "SHOULD be updated as
soon as possible in order" to "will need to be updated".
Remove section 6.5, and renumber sections 6.6 and 6.7 down.
In section 6.6, remove the sentence "In other words, the output of
ToASCII is the canonical name."
Replace section 7 with the following to alleviate fears about
required changes to the DNS.
Because the specification of the DNS database content in [STD13]
predates IDNA, DNS database content (such as common zone files) are
IDN-unaware, and hence requirement 2 of section 3 of this document
applies to them. Internationalized domain names MUST be converted to
their equivalent ASCII forms before being entered into DNS database
content.
It is imperative that there be only one ASCII encoding for a
particular domain name. Because of the design of the ToASCII and
ToUnicode operations, there are no ACE labels that decode to ASCII
labels, and therefore name servers cannot contain multiple ASCII
encodings of the same domain name.
[RFC2181] explicitly allows domain labels to contain octets beyond
the ASCII range (0..7F), and this document does not change that.
Note, however, that there is no defined interpretation of octets
80..FF as characters. If labels containing these octets are returned
to applications, unpredictable behavior could result. The ASCII form
defined by ToASCII is the only standard representation for
internationalized labels in the current DNS protocol.
Add to section 9.2:
[RFC2181] Robert Elz and Randy Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
In section 9.2, change the reference to:
[UNICODE] The Unicode Consortium. The Unicode Standard, Version 3.2.0
is defined by The Unicode Standard, Version 3.0 (Reading, MA,
Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode
Standard Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/) and by the Unicode Standard
Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).
Change the third paragraph of section 10 to the following two
paragraphs:
Domain names are used by users to identify and connect to Internet
servers. The security of the Internet is compromised if a user
entering a single internationalized name is connected to different
servers based on different interpretations of the internationalized
domain name.
When systems use local character sets other than ASCII and Unicode,
this specification leaves the the problem of transcoding between the
local character set and Unicode up to the application. If different
applications (or different versions of one application) implement
different transcoding rules, they could interpret the same name
differently and contact different servers. This problem is not solved
by security protocols like TLS that do not take local character sets
into account.
Add the following three paragraphs to the end of section 10:
If or when this specification is updated to use a more recent Unicode
normalization table, the new normalization table will need to be
compared with the old to spot backwards incompatible changes. If
there are such changes, they will need to be handled somehow, or
there will be security as well as operational implications. Methods
to handle the conflicts could include keeping the old normalization,
or taking care of the conflicting characters by operational means, or
some other method.
Implementations MUST NOT use more recent normalization tables than
the one referenced from this document, even though more recent tables
may be provided by operating systems. If an application is unsure of
which version of the normalization tables are in the operating
system, the application needs to include the normalization tables
itself. Using normalization tables other than the one referenced
from this specification could have security and operational
implications.
To help prevent confusion between characters that are visually
similar, it is suggested that implementations provide visual
indications where a domain name contains multiple scripts. Such
mechanisms can also be used to show when a name contains a mixture of
simplified and traditional Chinese characters, or to distinguish zero
and one from O and l.
 End of changes. 27 change blocks. 
77 lines changed or deleted 109 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/