draft-ietf-idn-requirements-04.txt   draft-ietf-idn-requirements-05.txt 
IETF IDN Working Group Editors Zita Wenzel, James Seng IETF IDN Working Group Editors Zita Wenzel, James Seng
Internet Draft draft-ietf-idn-requirements-04.txt Internet Draft draft-ietf-idn-requirements-05.txt
24 April 2001 Expires 24 October 2001
Requirements of Internationalized Domain Names Requirements of Internationalized Domain Names
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
skipping to change at line 27 skipping to change at line 29
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
"work in progress." "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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.
Intended Scope
The intended scope of this document is to explore requirements for the
internationalization of domain names on the Internet. It is not
intended to document user requirements. It is recommended that
solutions not necessarily be within the DNS itself, but could be a layer
interjected between the application and the DNS. Proposals SHOULD
fulfill most, if not all, of the requirements. This document MAY be
updated based on clinical trials.
Abstract Abstract
This document describes the requirement for encoding international This document describes the requirement for encoding international
characters into DNS names and records. This document is guidance for characters into DNS names and records. This document is guidance for
developing protocols for internationalized domain names. developing protocols for internationalized domain names.
1. Introduction 1. Introduction
At present, the encoding of Internet domain names is restricted to a At present, the encoding of Internet domain names is restricted to a
subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many
skipping to change at line 55 skipping to change at line 67
"subscribe idn" in the body of the message. Archives of the mailing "subscribe idn" in the body of the message. Archives of the mailing
list can also be found at ftp://ops.ietf.org/pub/lists/idn*. list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
1.1 Definitions and Conventions 1.1 Definitions and Conventions
A language is a way that humans interact. In computerised form, a text A language is a way that humans interact. In computerised form, a text
in a written language can be expressed as a string of characters. in a written language can be expressed as a string of characters.
The same set of characters can often be used for many written languages, The same set of characters can often be used for many written languages,
and many written languages can be expressed using different scripts. and many written languages can be expressed using different scripts.
The same characters are often shown with somewhat different glyphs The same characters are often shown with somewhat different glyphs
(shapes) (shapes) for display of a text depending on the font used, the
for display of a text depending on the font used, the automatic shaping automatic shaping applied, or the automatic formation of ligatures. In
applied, or the automatic formation of ligatures. In addition, the same addition, the same characters can be shown with somewhat different
characters can be shown with somewhat different glyphs (shapes) for glyphs (shapes) for display of a text depending on the language being
display used, even within the same font or trough automatic font change.
of a text depending on the language being used, even within the same
font
or trough automatic font change.
A character is a member of a set of elements used for organization, A character is a member of a set of elements used for organization,
control, or representation of textual data. control, or representation of textual data.
A graphic character is a character, other than a control function, A graphic character is a character, other than a control function,
that has a visual representation normally handwritten, printed, or that has a visual representation normally handwritten, printed, or
displayed. displayed.
Characters mentioned in this document are identified by their position Characters mentioned in this document are identified by their position
in the Unicode [UNICODE] character set. This character set is also in the Unicode [UNICODE] character set. This character set is also
skipping to change at line 128 skipping to change at line 137
(e.g. single shifts, SI/SO, or escape sequences) that are not part (e.g. single shifts, SI/SO, or escape sequences) that are not part
of the CCS per se, but which are defined by the character encoding of the CCS per se, but which are defined by the character encoding
architecture and which may require an external registry of particular architecture and which may require an external registry of particular
values (as for the ISO 2022 escape sequences). In such a case, the values (as for the ISO 2022 escape sequences). In such a case, the
CES is called a compound CES. (A CES that only involves a single CES is called a compound CES. (A CES that only involves a single
CCS is called a simple CES.) CCS is called a simple CES.)
Examples: ASCII, Latin-15, Shift-JIS, UTF-16BE, UTF-16LE, UTF-8. Examples: ASCII, Latin-15, Shift-JIS, UTF-16BE, UTF-16LE, UTF-8.
5. The mapping from an abstract character repertoire (ACR) to a 5. The mapping from an abstract character repertoire (ACR) to a
serialised serialised sequence of octets is called a Character Map (CM). A simple
sequence of octets is called a Character Map (CM). A simple character character map thus implicitly includes a CCS, a CEF, and a CES,
map thus implicitly includes a CCS, a CEF, and a CES, mapping from mapping from abstract characters to code units to octets. A compound
abstract characters to code units to octets. A compound character character map includes a compound CES, and thus includes more than one
map includes a compound CES, and thus includes more than one CCS CCS and CEF. In that case, the abstract character repertoire for the
and CEF. In that case, the abstract character repertoire for the
character map is the union of the repertoires covered by the coded character map is the union of the repertoires covered by the coded
character sets involved. character sets involved.
Character Maps are the things that in the IAB architecture get IANA Character Maps are the things that in the IAB architecture get IANA
charset identifiers. A sequence of encoded characters must be charset identifiers. A sequence of encoded characters must be
unambiguously mapped onto a sequence of octets by the charset. The unambiguously mapped onto a sequence of octets by the charset. The
charset must be specified in all instances, as in Internet charset must be specified in all instances, as in Internet
protocols, where textual content is treated as a ordered sequence protocols, where textual content is treated as a ordered sequence
of octets, and where the textual content must be reconstructible of octets, and where the textual content must be reconstructible
from that sequence of octets. Charset names are registered by the from that sequence of octets. Charset names are registered by the
skipping to change at line 214 skipping to change at line 222
1.3 Definition of "hostname" and "Internationalized Domain Name" 1.3 Definition of "hostname" and "Internationalized Domain Name"
In the DNS protocols, a name is referred to as a sequence of octets. In the DNS protocols, a name is referred to as a sequence of octets.
However, when discussing requirements for internationalized domain However, when discussing requirements for internationalized domain
names, what we are looking for are ways to represent characters that names, what we are looking for are ways to represent characters that
are meaningful for humans. are meaningful for humans.
In this document, this is referred to as a "hostname". While this term In this document, this is referred to as a "hostname". While this term
has been used for many different purposes over the years, it is used has been used for many different purposes over the years, it is used
here in the sense of "sequence of characters (not octets) representing a here in the sense of sequence of characters (not octets) representing a
domain name conforming to the limited hostname syntax". domain name conforming to the limited hostname syntax [RFC952].
This document attempts to define the requirements for an This document attempts to define the requirements for an
"Internationalized Domain Name" (IDN). This is defined as a sequence of "Internationalized Domain Name" (IDN). This is defined as a sequence of
characters that can be used in the context of functions where a hostname characters that can be used in the context of functions where a hostname
is used today, but contains one or more characters that are outside the is used today, but contains one or more characters that are outside the
set of characters specified as legal characters for host names. set of characters specified as legal characters for host names
[RFC1123].
1.4 A multilayer model of the DNS function 1.4 A multilayer model of the DNS function
The DNS can be seen as a multilayer function: The DNS can be seen as a multilayer function:
- The bottom layer is where the packets are passed across the Internet - The bottom layer is where the packets are passed across the Internet
in a DNS query and a DNS response. At this level, what matters is in a DNS query and a DNS response. At this level, what matters is
the format and meaning of bits and octets in a DNS packet. the format and meaning of bits and octets in a DNS packet.
- Above that is the "DNS service", created by an infrastructure of DNS - Above that is the "DNS service", created by an infrastructure of DNS
servers, NS records that point to those DNS servers, that is servers, NS records that point to those DNS servers, that is
pointed to by the root servers (listed in the "root cache file" on pointed to by the root servers (listed in the "root cache file" on
each DNS each DNS server, often called "named.cache". It is at this level
server, often called "named.cache". It is at this level that the that the statement "the DNS has a single root" [RFC2826] makes
statement "the DNS has a single root" [RFC2826] makes sense, but sense, but still, what are being transferred are octets, not
still, what are being transferred are octets, not characters. characters.
- Interfacing to the user is a service layer, often called "the resolver - Interfacing to the user is a service layer, often called "the resolver
library", and often embedded in the operating system or system library", and often embedded in the operating system or system
libraries of the client machines. It is at the top of this layer that libraries of the client machines. It is at the top of this layer that
the API calls commonly known as "gethostbyname" and "gethostbyaddress" the API calls commonly known as "gethostbyname" and "gethostbyaddress"
reside. These calls are modified to support IPv6 [RFC2553]. A reside. These calls are modified to support IPv6 [RFC2553]. A
conceptually similar layer exists in authoritative DNS servers, conceptually similar layer exists in authoritative DNS servers,
comprising the parts that generate "meaningful" strings in DNS files. comprising the parts that generate "meaningful" strings in DNS files.
Due to the popularity of the "master file" format, this layer often Due to the popularity of the "master file" format, this layer often
exists only in the administrative routines of the service maintainers. exists only in the administrative routines of the service maintainers.
skipping to change at line 340 skipping to change at line 349
[1] The DNS is essential to the entire Internet. Therefore, the service [1] The DNS is essential to the entire Internet. Therefore, the service
MUST NOT damage present DNS protocol interoperability. It MUST make the MUST NOT damage present DNS protocol interoperability. It MUST make the
minimum number of changes to existing protocols on all layers of the minimum number of changes to existing protocols on all layers of the
stack. It MUST continue to allow any system anywhere to resolve any stack. It MUST continue to allow any system anywhere to resolve any
internationalized domain name. internationalized domain name.
[2] The service MUST preserve the basic concept and facilities of domain [2] The service MUST preserve the basic concept and facilities of domain
names as described in [RFC1034]. It MUST maintain a single, global, names as described in [RFC1034]. It MUST maintain a single, global,
universal, and consistent hierarchical namespace. universal, and consistent hierarchical namespace.
[2.5] The DNS protocol (the packet formats that go on the wire) MUST [3] The DNS protocol (the packet formats that go on the wire) MUST
NOT limit the codepoints that can be used. A service defined on top of NOT limit the codepoints that can be used. A service defined on top of
the DNS, for instance the IDN-to-address function, MAY limit the the DNS, for instance the IDN-to-address function, MAY limit the
codepoints that can be used. The service descriptions MUST describe codepoints that can be used. The service descriptions MUST describe
what limitations are imposed. what limitations are imposed.
[2.6] The protocol MUST work for all features of DNS, IPv4, and [4] The protocol MUST work for all features of DNS, IPv4, and
IPv6. The protocol MUST NOT allow an IDN to be returned to a requestor IPv6. The protocol MUST NOT allow an IDN to be returned to a requestor
that requests the IP-to-(old)-domain-name mapping service. that requests the IP-to-(old)-domain-name mapping service.
[3] The same name resolution request MUST generate the same response, [5] The same name resolution request MUST generate the same response,
regardless of the location or localization settings in the resolver, in regardless of the location or localization settings in the resolver, in
the master server, and in any slave servers involved in the resolution the master server, and in any slave servers involved in the resolution
process. process.
[4] The protocol MUST NOT require that the current DNS cache [6] The protocol MUST NOT require that the current DNS cache
servers be modified to support IDN. If a cache server can have servers be modified to support IDN. If a cache server can have
additional functionality to support IDN better, this additional additional functionality to support IDN better, this additional
functionality MUST NOT cause problems for resolving correctly functionality MUST NOT cause problems for resolving correctly
functioning current domain names. functioning current domain names.
[5] A caching server MUST NOT return data in response to a query that [7] A caching server MUST NOT return data in response to a query that
would not have been returned if the same query had been presented to an would not have been returned if the same query had been presented to an
authoritative server. This applies fully for the cases when: authoritative server. This applies fully for the cases when:
- The caching server does not know about IDN - The caching server does not know about IDN
- The caching server implements the whole specification - The caching server implements the whole specification
- The caching server implements a valid subset of the specification - The caching server implements a valid subset of the specification
[7] The service MAY modify the DNS protocol [RFC1035] and other related [8] The service MAY modify the DNS protocol [RFC1035] and other related
work undertaken by the [DNSEXT] WG. However, these changes SHOULD be as work undertaken by the [DNSEXT] WG. However, these changes SHOULD be as
small as possible and any changes SHOULD be coordinated with the small as possible and any changes SHOULD be coordinated with the
[DNSEXT] WG. [DNSEXT] WG.
[8] The protocol supporting the service SHOULD be as simple as possible [9] The protocol supporting the service SHOULD be as simple as possible
from the user's perspective. Ideally, users SHOULD NOT realize that IDN from the user's perspective. Ideally, users SHOULD NOT realize that IDN
was added on to the existing DNS. was added on to the existing DNS.
[10] The best solution is one that maintains maximum feasible [10] The best solution is one that maintains maximum feasible
compatibility with current DNS standards as long as it meets the other compatibility with current DNS standards as long as it meets the other
requirements in this document. requirements in this document.
[11] The protocol should handle with care new revisions of the CCS.
Undefined codepoints should not be allowed unless a new revision of
the protocol can handle it. Protocol revisions should be tagged.
2.2 Internationalization 2.2 Internationalization
[11] Internationalized characters MUST be allowed to be represented and [12] Internationalized characters MUST be allowed to be represented and
used in DNS names and records. The protocol MUST specify what charset is used in DNS names and records. The protocol MUST specify what charset is
used when resolving domain names and how characters are encoded in DNS used when resolving domain names and how characters are encoded in DNS
records. records.
[12] Codepoints SHOULD be from the Universal Set as defined in [13] Codepoints SHOULD be from the Universal Set as defined in
ISO-10646 or Unicode. The specifics of versions MUST be defined in the ISO-10646 or Unicode. The specifics of versions MUST be defined in the
proposed solution. If multiple charsets are allowed, each charset MUST proposed solution. If multiple charsets are allowed, each charset MUST
be tagged and conform to [RFC2277]. be tagged and conform to [RFC2277].
[12.5] The protocol MUST NOT reject any non-IDN characters (to be [14] The protocol MUST NOT reject any non-IDN characters (to be
defined) in any queries or responses. defined) in any queries or responses.
[14] The protocol SHOULD NOT invent a new CCS for the purpose of IDN [15] The protocol SHOULD NOT invent a new CCS for the purpose of IDN
only and SHOULD use existing CES. The charset(s) chosen SHOULD also be only and SHOULD use existing CES. The charset(s) chosen SHOULD also be
non-ambiguous. non-ambiguous.
[15] The protocol SHOULD NOT make any assumptions about the location [16] The protocol SHOULD NOT make any assumptions about the location
in a domain name where internationalization might appear. In other in a domain name where internationalization might appear. In other
words, it SHOULD NOT differentiate between any part of a domain name words, it SHOULD NOT differentiate between any part of a domain name
because this MAY impose restrictions on future internationalization because this MAY impose restrictions on future internationalization
efforts. For example, the TLDs can be internationalized. efforts. For example, the TLDs can be internationalized.
[16] The protocol also SHOULD NOT make any localized restrictions in the [17] The protocol also SHOULD NOT make any localized restrictions in the
protocol. For example, an IDN implementation which only allows domain protocol. For example, an IDN implementation which only allows domain
names to use a single local script would immediately restrict names to use a single local script would immediately restrict
multinational organization. multinational organization.
[17] While there are a wide range of devices that use the DNS and a wide [18] While there are a wide range of devices that use the DNS and a wide
range of characteristics of international scripts and methods of range of characteristics of international scripts and methods of
domain name input and display, IDN is only concerned with the domain name input and display, IDN is only concerned with the
protocol. Therefore, there MUST be a single way of encoding an protocol. Therefore, there MUST be a single way of encoding an
internationalized domain name within the DNS. internationalized domain name within the DNS.
2.4 Canonicalization 2.4 Canonicalization
Matching rules are a complicated process for IDN. Canonicalization Matching rules are a complicated process for IDN. Canonicalization
of characters MUST follow precise and predictable rules to ensure of characters MUST follow precise and predictable rules to ensure
consistency. [CHARREQ] is RECOMMENDED as a guide on canonicalization. consistency. [CHARREQ] is RECOMMENDED as a guide on canonicalization.
The DNS has to match a host name in a request with a host name held The DNS has to match a host name in a request with a host name held
in one or more zones. It also needs to sort names into order. It is in one or more zones. It also needs to sort names into order. It is
expected that some sort of canonicalization algorithm will be used as expected that some sort of canonicalization algorithm will be used as
the first step of this process. This section discusses some of the the first step of this process. This section discusses some of the
properties which will be REQUIRED of that algorithm. properties which will be REQUIRED of that algorithm.
[22] To achieve interoperability, canonicalization MUST be done at a [19] To achieve interoperability, canonicalization MUST be done at a
single well-defined place in the DNS resolution process. The protocol single well-defined place in the DNS resolution process. The protocol
MUST specify canonicalization; it MUST specify exactly where in the MUST specify canonicalization; it MUST specify exactly where in the
DNS that canonicalization happens and does not happen; it MUST specify DNS that canonicalization happens and does not happen; it MUST specify
how additions to ISO 10646 will affect the stability of the DNS and how additions to ISO 10646 will affect the stability of the DNS and
the amount of work done on the root DNS servers. the amount of work done on the root DNS servers.
[23] The canonicalization algorithm MAY specify operations for case, [20] The canonicalization algorithm MAY specify operations for case,
ligature, and punctuation folding. ligature, and punctuation folding.
[24] In order to retain backwards compatibility with the current DNS, [21] In order to retain backwards compatibility with the current DNS,
the service MUST retain the case-insensitive comparison for [US-ASCII] the service MUST retain the case-insensitive comparison for [US-ASCII]
as specified in [RFC1035]. For example, Latin capital letter A (U+0041) as specified in [RFC1035]. For example, Latin capital letter A (U+0041)
MUST match Latin small letter a (U+0061). [UTR21] describes some of MUST match Latin small letter a (U+0061). [UTR21] describes some of
the issues with case mapping. Case-insensitivity for non [US-ASCII] the issues with case mapping. Case-insensitivity for non [US-ASCII]
MUST be discussed in the protocol proposal. MUST be discussed in the protocol proposal.
[25] Case folding MUST be locale independent. For example, Latin [22] Case folding MUST be locale independent. If it were
capital letter I (U+0049) case folded to lower case in the Turkish locale-dependent, then different clients would get different results.
context will become Latin small letter dotless i (U+0131). But in the For example, Latin capital letter I (U+0049) case folded to lower case
English context, it will become Latin small letter i (U+0069). in the Turkish context will become Latin small letter dotless i
(U+0131). But in the English context, it will become Latin small
letter i (U+0069).
[26] If other canonicalization is done, it MUST be done before the [23] If other canonicalization is done, it MUST be done before the
domain name is resolved. Further, the canonicalization MUST be easily domain name is resolved. Further, the canonicalization MUST be easily
upgradable as new languages and writing systems are added. upgradable as new languages and writing systems are added.
[27] Any conversion (case, ligature folding, punctuation folding, etc) [24] Any conversion (case, ligature folding, punctuation folding, etc)
from what the user enters into a client to what the client asks for from what the user enters into a client to what the client asks for
resolution MUST be done identically on any request from any client. resolution MUST be done identically on any request from any client.
[30] If the charset can be normalized, then it SHOULD be normalized [25] If the charset can be normalized, then it SHOULD be normalized
before it is used in IDN. Normalization SHOULD follow [UTR15]. before it is used in IDN. Normalization SHOULD follow [UTR15].
(conflict)
[31] The protocol SHOULD avoid inventing a new normalization form [26] The protocol SHOULD avoid inventing a new normalization form
provided a technically sufficient one is available. provided a technically sufficient one is available.
2.5 Operational Issues 2.5 Operational Issues
[32] Zone files SHOULD remain easily editable. [27] Zone files SHOULD remain easily editable.
[33] An IDN-capable resolver or server SHALL NOT generate more traffic [28] An IDN-capable resolver or server SHALL NOT generate more traffic
than a non-IDN-capable resolver or server would when resolving an than a non-IDN-capable resolver or server would when resolving an
ASCII-only domain name. The amount of traffic generated when resolving ASCII-only domain name. The amount of traffic generated when resolving
an IDN SHALL be similar to that generated when resolving an ASCII-only an IDN SHALL be similar to that generated when resolving an ASCII-only
name. name.
[34] The service SHOULD NOT add new centralized administration for the [29] The service SHOULD NOT add new centralized administration for the
DNS. A domain administrator SHOULD be able to create internationalized DNS. A domain administrator SHOULD be able to create internationalized
names as easily as adding current domain names. names as easily as adding current domain names.
[35] Within a single zone, the zone manager MUST be able to define [30] Within a single zone, the zone manager MUST be able to define
equivalence rules that suit the purpose of the zone, such as, but not equivalence rules that suit the purpose of the zone, such as, but not
limited to, and not necessarily, non-ASCII case folding, Unicode limited to, and not necessarily, non-ASCII case folding, Unicode
normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or
traditional/simplified Chinese equivalence. Such defined equivalences traditional/simplified Chinese equivalence. Such defined equivalences
MUST NOT remove equivalences that are assumed by (old or MUST NOT remove equivalences that are assumed by (old or
local-rule-ignorant) caches. local-rule-ignorant) caches.
[36] The protocol MUST work with DNSSEC. [31] The protocol MUST work with DNSSEC. The protocol MAY break
language sort order.
3. Security Considerations 3. Security Considerations
Any solution that meets the requirements in this document MUST NOT be Any solution that meets the requirements in this document MUST NOT be
less secure than the current DNS. Specifically, the mapping of less secure than the current DNS. Specifically, the mapping of
internationalized host names to and from IP addresses MUST have the internationalized host names to and from IP addresses MUST have the
same characteristics as the mapping of today's host names. same characteristics as the mapping of today's host names.
Specifying requirements for internationalized domain names does not Specifying requirements for internationalized domain names does not
itself raise any new security issues. However, any change to the DNS MAY itself raise any new security issues. However, any change to the DNS MAY
skipping to change at line 514 skipping to change at line 529
representation forms are permitted, the implications of this name-spoof representation forms are permitted, the implications of this name-spoof
MUST be throughly understood. MUST be throughly understood.
4. References 4. References
[CHARREQ] "Requirements for string identity matching and String [CHARREQ] "Requirements for string identity matching and String
Indexing", http://www.w3.org/TR/WD-charreq, July 1998, Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
World Wide Web Consortium. World Wide Web Consortium.
[DNSEXT] "IETF DNS Extensions Working Group", [DNSEXT] "IETF DNS Extensions Working Group",
namedroppers@internic.net, Olafur Gudmundson, Randy Bush. namedroppers@ops.ietf.org, Olafur Gudmundson, Randy Bush.
[RFC952] "DoD Internet Host Table Specification", rfc952.txt,
October 1985, K. Harrenstien, M.K. Stahl, E.J. Feinler.
[RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt, [RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt,
November 1987, P. Mockapetris. November 1987, P. Mockapetris.
[RFC1035] "Domain Names - Implementation and Specification", [RFC1035] "Domain Names - Implementation and Specification",
rfc1035.txt, November 1987, P. Mockapetris. rfc1035.txt, November 1987, P. Mockapetris.
[RFC1123] "Requirements for Internet Hosts -- Application and [RFC1123] "Requirements for Internet Hosts -- Application and
Support", rfc1123.txt, October 1989, R. Braden. Support", rfc1123.txt, October 1989, R. Braden.
skipping to change at line 568 skipping to change at line 586
[ISO10646] ISO/IEC 10646-1:2000 (note that an amendment 1 is in [ISO10646] ISO/IEC 10646-1:2000 (note that an amendment 1 is in
preparation), ISO/IEC 10646-2 (in preparation), plus preparation), ISO/IEC 10646-2 (in preparation), plus
corrigenda and amendments to these standards. corrigenda and amendments to these standards.
[UNICODE] The Unicode Consortium, "The Unicode Standard". Described at [UNICODE] The Unicode Consortium, "The Unicode Standard". Described at
http://www.unicode.org/unicode/standard/versions/. http://www.unicode.org/unicode/standard/versions/.
[UNICODE30] The Unicode Consortium, "The Unicode Standard -- Version [UNICODE30] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Same repertoire as ISO/IEC 3.0", ISBN 0-201-61633-5. Same repertoire as ISO/IEC
10646-1:2000. Described at 10646-1:2000. Described at http://www.unicode.org/unicode/
standard/versions/Unicode3.0.html.
http://www.unicode.org/unicode/standard/versions/Unicode3.0.html.
[US-ASCII] Coded Character Set -- 7-bit American Standard Code for [US-ASCII] Coded Character Set -- 7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986; also: ISO/IEC Information Interchange, ANSI X3.4-1986; also: ISO/IEC
646 (IRV). 646 (IRV).
[UAX15] "Unicode Normalization Forms", Unicode Standard Annex #15, [UAX15] "Unicode Normalization Forms", Unicode Standard Annex #15,
http://www.unicode.org/unicode/reports/tr15/, 2000-08-31, http://www.unicode.org/unicode/reports/tr15/, 2000-08-31,
M. Davis and M. Duerst, Unicode Consortium. M. Davis and M. Duerst, Unicode Consortium.
[UTR17] "Character Encoding Model", Unicode Technical Report #17, [UTR17] "Character Encoding Model", Unicode Technical Report #17,
skipping to change at line 601 skipping to change at line 618
Information Sciences Institute Information Sciences Institute
University of Southern California University of Southern California
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA Marina del Rey, CA
90292 USA 90292 USA
Tel: +1 310 448 8462 Tel: +1 310 448 8462
Fax: +1 310 823 6714 Fax: +1 310 823 6714
zita@isi.edu zita@isi.edu
James Seng James Seng
i-DNS.net International Pte Ltd.
8 Temesek Boulevand 8 Temesek Boulevand
#24-02 Suntec Tower 3 #24-02 Suntec Tower 3
Singapore 038988 Singapore 038988
Tel: +65 248 6208 Tel: +65 248 6208
Fax: +65 248 6198 Fax: +65 248 6198
Email: jseng@pobox.org.sg Email: jseng@pobox.org.sg
6. Acknowledgements 6. Acknowledgements
The editors gratefully acknowledge the contributions of: The editors gratefully acknowledge the contributions of:
Harald Tveit Alvestrand <Harald@Alvestrand.no> Harald Tveit Alvestrand <Harald@Alvestrand.no>
Mark Andrews <Mark.Andrews@nominum.com> Mark Andrews <Mark.Andrews@nominum.com>
RJ Atkinson <request not to have email> RJ Atkinson <request not to have email>
Alan Barret <apb@cequrux.com> Alan Barret <apb@cequrux.com>
Marc Blanchet <blanchet@mailviagenie.qc.ca>
Randy Bush <randy@psg.com> Randy Bush <randy@psg.com>
Andrew Draper <ADRAPER@altera.com> Andrew Draper <ADRAPER@altera.com>
Martin Duerst <duerst@w3.org> Martin Duerst <duerst@w3.org>
Patrik Faltstrom <paf@swip.net> Patrik Faltstrom <paf@swip.net>
Ned Freed <ned.freed@innosoft.com> Ned Freed <ned.freed@innosoft.com>
Olafur Gudmundsson <ogud@tislabs.com> Olafur Gudmundsson <ogud@tislabs.com>
Paul Hoffman <phoffman@imc.org> Paul Hoffman <phoffman@imc.org>
Simon Josefsson <jas+idn@pdc.kth.se> Simon Josefsson <jas+idn@pdc.kth.se>
Kent Karlsson <keka@im.se> Kent Karlsson <keka@im.se>
John Klensin <klensin+idn@jck.com> John Klensin <klensin+idn@jck.com>
Tan Juay Kwang <tanjk@i-dns.net> Tan Juay Kwang <tanjk@i-dns.net>
Dongman Lee <dlee@icu.ac.kr> Dongman Lee <dlee@icu.ac.kr>
Bill Manning <bmanning@ISI.EDU> Bill Manning <bmanning@ISI.EDU>
Dan Oscarsson <Dan.Oscarsson@trab.se> Dan Oscarsson <Dan.Oscarsson@trab.se>
J. William Semich <bill@mail.nic.nu> J. William Semich <bill@mail.nic.nu>
James Seng <jseng@pobox.org.sg> Yoshiro Yoneda <<yone@nic.ad.jp>
 End of changes. 41 change blocks. 
57 lines changed or deleted 76 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/