draft-ietf-idn-idna-10.txt   draft-ietf-idn-idna-11.txt 
Internet Draft Patrik Faltstrom Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-10.txt Cisco draft-ietf-idn-idna-11.txt Cisco
June 24, 2002 Paul Hoffman Auguest 29, 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 host names today. be represented using only the ASCII characters already allowed in
This representation allows IDNs to be introduced with no changes to so-called host names today. This backward-compatible representation is
the existing DNS infrastructure. IDNA is only meant for processing required in existing protocols like DNS, so that IDNs can be introduced
domain names, not free text. with no changes to the existing infrastructure. 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
depend on changes to any infrastructure. In particular, IDNA does not depend on changes to any infrastructure. In particular, IDNA does not
depend on 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 for IDNA. sufficient for IDNA.
skipping to change at line 135 skipping to change at line 136
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. This document explicitly refers to "domain name" is used in general. This document explicitly cites [STD3]
[STD3] to make it clear where this syntactic restrictions apply. whenever referring to the host name syntax restrictions defined therein.
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.) IDNA extends the set of considered a label in this specification.) IDNA extends the set of
usable characters in labels that are text. For the rest of this usable characters in labels that are text. For the rest of this
document, the term "label" is shorthand for "text label", and "every document, the term "label" is shorthand for "text label", and "every
label" means "every text label". label" means "every text label".
skipping to change at line 207 skipping to change at line 208
domain name slot explicitly designated for carrying an internationalized domain name slot explicitly designated for carrying an internationalized
domain name as defined in this document. The designation may be static domain name as defined in this document. The designation may be static
(for example, in the specification of the protocol or interface) or (for example, in the specification of the protocol or interface) or
dynamic (for example, as a result of negotiation in an interactive dynamic (for example, as a result of negotiation in an interactive
session). session).
An "IDN-unaware domain name slot" is defined in this document to be any An "IDN-unaware domain name slot" is defined in this document to be any
domain name slot that is not an IDN-aware domain name slot. Obviously, domain name slot that is not an IDN-aware domain name slot. Obviously,
this includes any domain name slot whose specification predates IDNA. this includes any domain name slot whose specification predates IDNA.
3. Requirements 3. Requirements and applicability
3.1 Requirements
IDNA conformance means adherence to the following four requirements: IDNA conformance means adherence to the following four requirements:
1) Whenever dots are used as label separators, the following characters 1) Whenever dots are used as label separators, the following characters
MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full 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), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full
stop). stop).
2) Whenever a domain name is put into an IDN-unaware domain name slot 2) Whenever a domain name is put into an IDN-unaware domain name slot
(see section 2), it MUST contain only ASCII characters. (see section 2), it MUST contain only ASCII characters.
skipping to change at line 238 skipping to change at line 241
label. When requirements 2 and 3 both apply, requirement 2 takes label. When requirements 2 and 3 both apply, requirement 2 takes
precedence. precedence.
4) Whenever two labels are compared, they MUST be considered to match if 4) Whenever two labels are compared, they MUST be considered to match if
and only if they are equivalent, that is, their ASCII forms (obtained by and only if they are equivalent, that is, their ASCII forms (obtained by
applying ToASCII) match using a case-insensitive ASCII comparison. applying ToASCII) match using a case-insensitive ASCII comparison.
Whenever two names are compared, they MUST be considered to match if and Whenever two names are compared, they MUST be considered to match if and
only if their corresponding labels match, regardless of whether the only if their corresponding labels match, regardless of whether the
names use the same forms of label separators. names use the same forms of label separators.
3.2 Applicability
IDNA is applicable to all domain names in all domain name slots except
where it is explicitly excluded.
This implies that IDNA is applicable to many protocols that predate
IDNA. Note that IDNs occupying domain name slots in those protocols
MUST be in ASCII form (see section 3.1, requirement 2).
3.2.1. DNS resource records
IDNA does not apply to domain names in the NAME and RDATA fields of DNS
resource records whose CLASS is not IN. This exclusion applies to every
non-IN class, present and future, except where future standards override
this exclusion by explicitly inviting the use of IDNA.
There are currently no other exclusions on the applicability of IDNA to
DNS resource records; it depends entirely on the CLASS, and not on the
TYPE. This will remain true, even as new types are defined, unless
there is a compelling reason for a new type to complicate matters by
imposing type-specific rules.
3.2.2. Non-domain-name data types stored in domain names
Although IDNA enables the representation of non-ASCII characters in
domain names, that does not imply that IDNA enables the representation
of non-ASCII characters in other data types that are stored in domain
names. For example, an email address local part is sometimes stored in
a domain label (hostmaster@example.com would be represented as
hostmaster.example.com in the RDATA field of an SOA record). IDNA does
not update the existing email standards, which allow only ASCII
characters in local parts. Therefore, unless the email standards are
revised to invite the use of IDNA for local parts, a domain label that
holds the local part of an email address SHOULD NOT begin with the ACE
prefix, and even if it does, it is to be interpreted literally as a
local part that happens to begin with the ACE prefix.
4. Conversion operations 4. Conversion operations
An application converts a domain name put into an IDN-unaware slot or An application converts a domain name put into an IDN-unaware slot or
displayed to a user. This section specifies the steps to perform in the displayed to a user. This section specifies the steps to perform in the
conversion, and the ToASCII and ToUnicode operations. conversion, and the ToASCII and ToUnicode operations.
The input to ToASCII or ToUnicode is a single label that is a sequence The input to ToASCII or ToUnicode is a single label that is a sequence
of Unicode code points (remember that all ASCII code points are also of Unicode code points (remember that all ASCII code points are also
Unicode code points). If a domain name is represented using a character Unicode code points). If a domain name is represented using a character
set other than Unicode or US-ASCII, it will first need to be transcoded set other than Unicode or US-ASCII, it will first need to be transcoded
to Unicode. to Unicode.
Starting from a whole domain name, the steps that an application takes Starting from a whole domain name, the steps that an application takes
to do the conversions are: to do the conversions are:
1) Decide whether the domain name is a "stored string" or a "query 1) Decide whether the domain name is a "stored string" or a "query
string" as described in [STRINGPREP]. If this conversion follows the string" as described in [STRINGPREP]. If this conversion follows the
"queries" rule from [STRINGPREP], set the flag called "AllowUnassigned". "queries" rule from [STRINGPREP], set the flag called "AllowUnassigned".
2) Split the domain name into individual labels as described in section 2) Split the domain name into individual labels as described in section
3. The labels do not include the separator. 3.1. The labels do not include the separator.
3) Decide whether or not to enforce the restrictions on ASCII characters 3) For each label, decide whether or not to enforce the restrictions on
in host names [STD3]. If the restrictions are to be enforced, set the ASCII characters in host names [STD3]. If the restrictions are to be
flag called "UseSTD3ASCIIRules". enforced, set the flag called "UseSTD3ASCIIRules" for that label.
4) Process each label with either the ToASCII or the ToUnicode 4) Process each label with either the ToASCII or the ToUnicode
operation. Use the ToASCII operation if you are about to put operation. Use the ToASCII operation if you are about to put
the name into an IDN-unaware slot. Use the ToUnicode operation if you the name into an IDN-unaware slot. Use the ToUnicode operation if you
are displaying the name to a user. are displaying the name to a user.
5) If ToASCII was applied in step 4 and dots are used as label 5) If ToASCII was applied in step 4 and dots are used as label
separators, change all the label separators to U+002E (full stop). separators, change all the label separators to U+002E (full stop).
The following two subsections define the ToASCII and ToUnicode The following two subsections define the ToASCII and ToUnicode
skipping to change at line 594 skipping to change at line 634
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
Because the specification of the DNS database content in [STD13] Existing DNS servers do not know the IDNA rules for handling non-ASCII
predates IDNA, DNS database content (such as common zone files) are forms of IDNs, and therefore need to be shielded from them. All
IDN-unaware, and hence requirement 2 of section 3 of this document existing channels through which names can enter a DNS server database
applies to them. Internationalized domain names MUST be converted to (for example, master files [STD13] and DNS update messages [RFC2136])
their equivalent ASCII forms before being entered into DNS database are IDN-unaware because they predate IDNA, and therefore requirement 2
content. of section 3.1 of this document provides the needed shielding, by ensuring
that internationalized domain names entering DNS server databases
through such channels have already been converted to their equivalent
ASCII forms.
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. Because of the design of the ToASCII and ToUnicode domain name. Because of the design of the ToASCII and ToUnicode
operations, there are no ACE labels that decode to ASCII labels, and operations, there are no ACE labels that decode to ASCII labels, and
therefore name servers cannot contain multiple ASCII encodings of the therefore name servers cannot contain multiple ASCII encodings of the
same domain name. same domain name.
[RFC2181] explicitly allows domain labels to contain octets beyond the [RFC2181] explicitly allows domain labels to contain octets beyond the
ASCII range (0..7F), and this document does not change that. Note, ASCII range (0..7F), and this document does not change that. Note,
however, that there is no defined interpretation of octets 80..FF as however, that there is no defined interpretation of octets 80..FF as
characters. If labels containing these octets are returned to characters. If labels containing these octets are returned to
applications, unpredictable behavior could result. The ASCII form applications, unpredictable behavior could result. The ASCII form
defined by ToASCII is the only standard representation for defined by ToASCII is the only standard representation for
internationalized labels in the current DNS protocol. internationalized labels in the current DNS protocol.
8. Root Server Considerations 8. Root server considerations
IDNs are likely to be somewhat longer than current domain names, so the IDNs are likely to be somewhat longer than current domain names, so the
bandwidth needed by the root servers is likely to 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
skipping to change at line 671 skipping to change at line 714
[UNICODE] The Unicode Consortium. The Unicode Standard, Version 3.2.0 is [UNICODE] The Unicode Consortium. The Unicode Standard, Version 3.2.0 is
defined by The Unicode Standard, Version 3.0 (Reading, MA, defined by The Unicode Standard, Version 3.0 (Reading, MA,
Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode 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/) Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/)
and by the Unicode Standard Annex #28: Unicode 3.2 and by the Unicode Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/). (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.
skipping to change at line 723 skipping to change at line 766
application needs to include the normalization tables itself. Using application needs to include the normalization tables itself. Using
normalization tables other than the one referenced from this normalization tables other than the one referenced from this
specification could have security and operational implications. specification could have security and operational implications.
To help prevent confusion between characters that are visually similar, To help prevent confusion between characters that are visually similar,
it is suggested that implementations provide visual indications where a it is suggested that implementations provide visual indications where a
domain name contains multiple scripts. Such mechanisms can also be used domain name contains multiple scripts. Such mechanisms can also be used
to show when a name contains a mixture of simplified and traditional to show when a name contains a mixture of simplified and traditional
Chinese characters, or to distinguish zero and one from O and l. 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 A. Changes from -10 to -11
[[ To be removed when published as an RFC ]] [[ To be removed when published as an RFC ]]
In the first paragraph of section 1, change "require" to "depend on" Made capitalization of section titles consistent.
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: In the abstract, changed from:
Throughout this document the term "label" is shorthand for "text IDNs use characters drawn from a large repertoire (Unicode), but IDNA
label", and "every label" means "every text label". allows the non-ASCII characters to be represented using the same
octets used in so-called host names today. This representation allows
IDNs to be introduced with no changes to the existing DNS
infrastructure.
to: to:
IDNA extends the set of usable characters in labels that are text. IDNs use characters drawn from a large repertoire (Unicode), but IDNA
For the rest of this document, the term "label" is shorthand for allows the non-ASCII characters to be represented using only the
"text label", and "every label" means "every text label". ASCII characters already allowed in so-called host names today. This
backward-compatible representation is required in existing protocols
In section 2, change "When referring explicitly to the syntax like DNS, so that IDNs can be introduced with no changes to the
restrictions for host names in [STD3], the term "host name syntax" is existing infrastructure.
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 In secton 2, changed from:
soon as possible in order" to "will need to be updated". This document explicitly refers to [STD3] to make it clear where
this syntactic restrictions apply.
to:
This document explicitly cites [STD3] whenever referring to the
host name syntax restrictions defined therein.
Remove section 6.5, and renumber sections 6.6 and 6.7 down. In section 3, added section 3.2 on applicability of IDNA. Also changed
the heading numbering for this section, and changed references to the
old numbering to reflect the new numbering.
In section 6.6, remove the sentence "In other words, the output of In section 4, changed from:
ToASCII is the canonical name." 3) Decide whether or not to enforce the restrictions on ASCII
characters in host names [STD3]. If the restrictions are to be
enforced, set the flag called "UseSTD3ASCIIRules".
to:
3) For each label, decide whether or not to enforce the restrictions
on ASCII characters in host names [STD3]. If the restrictions are to
be enforced, set the flag called "UseSTD3ASCIIRules" for that label.
Replace section 7 with the following to alleviate fears about In section 7, changed the first paragraph from:
required changes to the DNS.
Because the specification of the DNS database content in [STD13] Because the specification of the DNS database content in [STD13]
predates IDNA, DNS database content (such as common zone files) are predates IDNA, DNS database content (such as common zone files) are
IDN-unaware, and hence requirement 2 of section 3 of this document IDN-unaware, and hence requirement 2 of section 3 of this document
applies to them. Internationalized domain names MUST be converted to applies to them. Internationalized domain names MUST be converted to
their equivalent ASCII forms before being entered into DNS database their equivalent ASCII forms before being entered into DNS database
content. content.
to:
It is imperative that there be only one ASCII encoding for a Existing DNS servers do not know the IDNA rules for handling
particular domain name. Because of the design of the ToASCII and non-ASCII forms of IDNs, and therefore need to be shielded from them.
ToUnicode operations, there are no ACE labels that decode to ASCII All existing channels through which names can enter a DNS server
labels, and therefore name servers cannot contain multiple ASCII database (for example, master files [STD13] and DNS update messages
encodings of the same domain name. [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
requirement 2 of section 3 of this document provides the needed
[RFC2181] explicitly allows domain labels to contain octets beyond shielding, by ensuring that internationalized domain names entering
the ASCII range (0..7F), and this document does not change that. DNS server databases through such channels have already been
Note, however, that there is no defined interpretation of octets converted to their equivalent ASCII forms.
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. 21 change blocks. 
69 lines changed or deleted 98 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/