draft-ietf-idn-requirements-02.txt   draft-ietf-idn-requirements-03.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-02.txt Internet Draft draft-ietf-idn-requirements-03.txt
28 June 2000 Expires 28 November 2000
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 page 10, line ? skipping to change at line 57
"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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Characters mentioned in this document are identified by their position Characters mentioned in this document are identified by their position
Expires 12th of October 2000 [Page 1]
in the Unicode [UNICODE] character set. The notation U+12AB, for in the Unicode [UNICODE] character set. The notation U+12AB, for
example, indicates the character at position 12AB (hexadecimal) in the example, indicates the character at position 12AB (hexadecimal) in the
Unicode character set. Note that the use of this notation is not an Unicode character set. Note that the use of this notation is not an
indication of a requirement to use Unicode. indication of a requirement to use Unicode.
Examples quoted in this document should be considered as a method to Examples quoted in this document should be considered as a method to
further explain the meanings and principles adopted by the document. It further explain the meanings and principles adopted by the document. It
is not a requirement for the protocol to satisfy the examples. is not a requirement for the protocol to satisfy the examples.
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,
skipping to change at page 10, line ? skipping to change at line 87
printed, or displayed. printed, or displayed.
A character encoding scheme or "CES" is a mapping from one or more A character encoding scheme or "CES" is a mapping from one or more
coded character sets to a set of octets. Some CESs are associated with coded character sets to a set of octets. Some CESs are associated with
a single CCS; for example, UTF-8 [RFC2279] applies only to ISO 10646. a single CCS; for example, UTF-8 [RFC2279] applies only to ISO 10646.
Other CESs, such as ISO 2022, are associated with many CCSs. Other CESs, such as ISO 2022, are associated with many CCSs.
A charset is a method of mapping a sequence of octets to a sequence of A charset is a method of mapping a sequence of octets to a sequence of
abstract characters. A charset is, in effect, a combination of one or abstract characters. A charset is, in effect, a combination of one or
more CCS with a CES. Charset names are registered by the IANA according more CCS with a CES. Charset names are registered by the IANA according
to procedures documented in RFC 2278. to procedures documented in [RFC2278].
A language is a way that humans interact. In written form, a language A language is a way that humans interact. In written form, a language
is expressed in characters. The same set of characters can often be is expressed in characters. The same set of characters can often be
used in many languages, and many languages can be expressed using used in many languages, and many languages can be expressed using
different scripts. A particular charset may have different glyphs different scripts. A particular charset MAY have different glyphs
(shapes) depending on the language being used. (shapes) depending on the language being used.
1.2 Description of the Domain Name System 1.2 Description of the Domain Name System
The Domain Name System is defined by [RFC1034] and [RFC1035], with The Domain Name System is defined by [RFC1034] and [RFC1035], with
clarifications, extensions and modifications given in [RFC1123], clarifications, extensions and modifications given in [RFC1123],
[RFC1996], [RFC2181] and others. Of special importance here is the [RFC1996], [RFC2181], and others. Of special importance here is the
security extensions described in [RFC2535] and companions. security extensions described in [RFC2535] and companions.
Over the years, many different words have been used to describe the Over the years, many different words have been used to describe the
components of resource naming on the Internet [URI], [URN], ...; to make components of resource naming on the Internet (e.g., [URI], [URN]); to make
certain that the set of terms used in this document are well-defined and certain that the set of terms used in this document are well-defined and
non-ambiguous, the definitions are given here. non-ambiguous, the definitions are given here.
A master server for a zone holds the main copy of that zone. This copy A master server for a zone holds the main copy of that zone. This copy
is sometimes stored in a zone file. A slave server for a zone holds a is sometimes stored in a zone file. A slave server for a zone holds a
complete copy of the records for that zone. Slave servers may be either complete copy of the records for that zone. Slave servers MAY be either
authorized by the zone owner (secondary servers) or unauthorized authorized by the zone owner (secondary servers) or unauthorized
Expires 12th of October 2000 [Page 2]
(so-called "stealth secondaries"). Master and authorized slave servers (so-called "stealth secondaries"). Master and authorized slave servers
are listed in the NS records for the zone, and are termed are listed in the NS records for the zone, and are termed
"authoritative" servers. In many contexts, outside this document the "authoritative" servers. In many contexts, outside this document the
term "primary" is used interchangeably with "master" and "secondary" is term "primary" is used interchangeably with "master" and "secondary" is
used interchangeably with "slave". used interchangeably with "slave".
A caching server holds temporary copies of DNS records; it uses records A caching server holds temporary copies of DNS records; it uses records
to answer queries about domain names. Further explanation of these terms to answer queries about domain names. Further explanation of these terms
can be found in [RFC1034] and [RFC1996]. can be found in [RFC1034] and [RFC1996].
skipping to change at page 10, line ? skipping to change at line 143
corresponding to the ASCII values for [a-zA-Z0-9-], using an escape corresponding to the ASCII values for [a-zA-Z0-9-], using an escape
mechanism (\x or \NNN) where not, and separating the components of the mechanism (\x or \NNN) where not, and separating the components of the
name by the dot character ("."). name by the dot character (".").
The form specified for most protocols using the DNS is a limited form of The form specified for most protocols using the DNS is a limited form of
the master file format domain name. This limited form is defined in the master file format domain name. This limited form is defined in
[RFC1034] Section 3.5 and [RFC1123]. In most implementations of [RFC1034] Section 3.5 and [RFC1123]. In most implementations of
applications today, domain names in the Internet have been limited to applications today, domain names in the Internet have been limited to
the much more restricted forms used, e.g., in email. Those names are the much more restricted forms used, e.g., in email. Those names are
limited to the ASCII upper and lower-case characters (interpreted in a limited to the ASCII upper and lower-case characters (interpreted in a
case-independent fashion), the digits, and the hyphen, with the further case-independent fashion), the digits, and the hyphen.
restrictions that a name may not consist entirely of digits and that a
hyphen cannot occur at the beginning or end of a component or following
another hyphen.
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 is ways to represent characters, names, what we are looking for are ways to represent characters that
something 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".
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.
Expires 12th of October 2000 [Page 3]
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 passed across the Net in a DNS - The bottom layer is where the packets are passed across the Internet
query and a DNS response. At this level, what matters is the format in a DNS query and a DNS response. At this level, what matters is
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, and is pointed to servers, NS records that point to those DNS servers, that is
by the root servers (listed in the "root cache file" on each DNS pointed to by the root servers (listed in the "root cache file" on each DNS
server, often called "named.cache". It is at this level that the server, often called "named.cache". It is at this level that the
statement "the DNS has a single root" [UNIROOT] makes sense, but statement "the DNS has a single root" [RFC2826] makes sense, but
still, what are being transferred are octets, not characters. still, what are being transferred are octets, not 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.
- The user of this layer (resolver library) is the application programs - The user of this layer (resolver library) is the application programs
that use the DNS, such as mailers, mail servers, Web clients, Web that use the DNS, such as mailers, mail servers, Web clients, Web
servers, Web caches, IRC clients, FTP clients, distributed file servers, Web caches, IRC clients, FTP clients, distributed file
systems, distributed databases, and almost all other applications on systems, distributed databases, and almost all other applications on
TCP/IP. (preference not fact) TCP/IP.
Graphically, one can illustrate it like this: Graphically, one can illustrate it like this:
+---------------+ +---------------------+ +---------------+ +---------------------+
| Application | | (Base data) | | Application | | (Base data) |
+---------------+ +---------------------+ +---------------+ +---------------------+
| Application service interface | | Application service interface |
| For ex. GethostbyXXXX interface | (no standard) | For ex. GethostbyXXXX interface | (no standard)
+---------------+ +---------------------+ +---------------+ +---------------------+
| Resolver | | Auth DNS server | | Resolver | | Auth DNS server |
skipping to change at page 10, line ? skipping to change at line 221
| +-------------------------+ | | +-------------------------+ |
| | Parent-zone DNS servers | | | | Parent-zone DNS servers | |
| +-------------------------+ | | +-------------------------+ |
| | | |
| +-------------------------+ | | +-------------------------+ |
| | Root DNS servers | | | | Root DNS servers | |
| +-------------------------+ | | +-------------------------+ |
| | | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Expires 12th of October 2000 [Page 4]
1.5 Service model of the DNS 1.5 Service model of the DNS
The Domain Name Service is used for multiple purposes, each of which is The Domain Name Service is used for multiple purposes, each of which is
characterized by what it puts into the system (the query) and what it characterized by what it puts into the system (the query) and what it
expects as a result (the reply). expects as a result (the reply).
The most used ones in the current DNS are: The most used ones in the current DNS are:
- Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get - Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get
back an IPv4 or IPv6 address. back an IPv4 or IPv6 address.
Hostname-to-Mail server service (MX): As above, but the expected
return value is a hostname and a priority, for smtp servers. - Hostname-to-Mail server service (MX): As above, but the expected
return value is a hostname and a priority for SMTP servers.
- Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in - Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in
in-addr.arpa or ip6.int form respectively) and get back a hostname. in-addr.arpa or ip6.int form respectively) and get back a hostname.
- Domain delegation service (NS). Enter a domain name and get back - Domain delegation service (NS). Enter a domain name and get back
nameserver records (designated hosts who provides authoritive nameserver records (designated hosts who provides authoritive
nameservice) for the domain. nameservice) for the domain.
New services are being defined, either as entirely new services (IPv6 to New services are being defined, either as entirely new services (IPv6 to
hostname mapping using binary labels) or as embellishments to other hostname mapping using binary labels) or as embellishments to other
services (DNSSEC returning information about whether a given DNS service services (DNSSEC returning information about whether a given DNS service
is performed securely or not). is performed securely or not).
These services exist, conceptually, at the Application/Resolver These services exist, conceptually, at the Application/Resolver
skipping to change at page 10, line ? skipping to change at line 251
New services are being defined, either as entirely new services (IPv6 to New services are being defined, either as entirely new services (IPv6 to
hostname mapping using binary labels) or as embellishments to other hostname mapping using binary labels) or as embellishments to other
services (DNSSEC returning information about whether a given DNS service services (DNSSEC returning information about whether a given DNS service
is performed securely or not). is performed securely or not).
These services exist, conceptually, at the Application/Resolver These services exist, conceptually, at the Application/Resolver
interface, NOT at the DNS-service interface. This document attempts to interface, NOT at the DNS-service interface. This document attempts to
set requirements for an equivalent of the "used services" given above, set requirements for an equivalent of the "used services" given above,
where "hostname" is replaced by "Internationalized Domain Name". This where "hostname" is replaced by "Internationalized Domain Name". This
doesn't preclude the fact that IDN should work will any kind of DNS doesn't preclude the fact that IDN should work with any kind of DNS
queries. IDN is a new service, since existing protocols like SMTP or queries. IDN is a new service. Since existing protocols like SMTP or
HTTP use the old service. it is a matter of great concern how the new HTTP use the old service, it is a matter of great concern how the new
and old services work together, and how other protocols can take and old services work together, and how other protocols can take
advantage of the new service. advantage of the new service.
2. General Requirements 2. General Requirements
These requirements address two concerns: The service offered to the These requirements address two concerns: The service offered to the
users (the application service), and the protocol extensions, if needed, users (the application service), and the protocol extensions, if needed,
added to support this service. added to support this service.
In the requirements, we attempt to use the term "service" whenever a In the requirements, we attempt to use the term "service" whenever a
requirement concerns the service, and "protocol" whenever a requirement requirement concerns the service, and "protocol" whenever a requirement
is believed to constrain the possible implementation. is believed to constrain the possible implementation.
2.1 Compatibility and Interoperability 2.1 Compatibility and Interoperability
skipping to change at page 10, line ? skipping to change at line 270
users (the application service), and the protocol extensions, if needed, users (the application service), and the protocol extensions, if needed,
added to support this service. added to support this service.
In the requirements, we attempt to use the term "service" whenever a In the requirements, we attempt to use the term "service" whenever a
requirement concerns the service, and "protocol" whenever a requirement requirement concerns the service, and "protocol" whenever a requirement
is believed to constrain the possible implementation. is believed to constrain the possible implementation.
2.1 Compatibility and Interoperability 2.1 Compatibility and Interoperability
[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.
[3] The same name resolution request must generate the same response,
regardless of the location or localization settings in the resolver, in
Expires 12th of October 2000 [Page 5] [2.5] The DNS service layer (the packet formats that go on the wire)
MUST NOT limit the codepoints that can be used. This interface SHOULD
NOT assign meaning to name strings; the application service layer,
where "gethostbyname" et al reside, MAY constrain the name strings to
be used in certain services. (conflict)
[3] The same name resolution request MUST generate the same response,
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] If the service allows more than one charset, the protocol should [4] The protocol SHOULD allow creation of caching servers that do
also allow creation of caching servers that do not understand the not understand the charset in which a request or response is encoded.
charset in which a request or response is encoded. Such caching servers The caching server SHOULD perform correctly for IDN as well as for
should work as well for IDNs as they do for current domain names. The current domain names (without the authoritative bit) as the master
caching server performs correctly if it gives essentially the same server would have if presented with the same request.
answer (without the authoritative bit) as the master server would have
if presented with the same request.
[5] A caching server must not return data in response to a query that [5] 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
[6] The service should be able to be upgraded at any time with new [7] The service MAY modify the DNS protocol [RFC1035] and other related
features and retain backwards compatibility with the current work undertaken by the [DNSEXT] WG. However, these changes SHOULD be as
specification. small as possible and any changes SHOULD be coordinated with the
[DNSEXT] WG.
[7] The service may modify the DNS protocol [RFC1035] and other related
work undertaken by the DNSEXT WG. However, these changes should be as
small as possible and any changes must be approved by the DNSEXT WG.
[8] The protocol supporting the service should be as simple as possible [8] 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.
[9] A fall-back strategy or mechanism based upon ASCII may be needed
during a transition period during deployment and adoption of IDN.
Therefore, if an encoding is not mapped into ASCII, then there might be
an ASCII-only representation compatible with the current DNS and there
should be a way for a program to find the ASCII-only representation for
IDN. This is depending on how the protocol will handle exceptions.
[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.
2.2 Internationalization 2.2 Internationalization
[11] Internationalized characters must be allowed to be represented and [11] 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] This document does not recommend any charset for IDN. If more than [12] This document RECOMMENDS Unicode only. If multiple charsets are
one charset is used, or might be used in future, in the protocol, then allowed, each charset MUST be tagged and conform to [RFC2277].
the protocol must specify all the charsets being used and for what
purpose. It must also conform to [RFC1766] by tagging the charset. No
implicit rules should be allowed for multiple charsets. A CCS(s) chosen
Expires 12th of October 2000 [Page 6]
must at least cover the range of characters as currently defined (and as [12.5] IDN MUST NOT return illegal code points in responses, SHOULD
being added) by ISO 10646/Unicode. reject queries with illegal codepoints. (one request to add; one request
to remove)
[13] CES(s) chosen should not encode ASCII characters differently [13] CES(s) chosen SHOULD NOT encode ASCII characters differently
depending on the other characters in the string. In other words, unless depending on the other characters in the string. In other words, unless
IDN names are identified and coded differently from ASCII-only ones, IDN names are identified and coded differently from ASCII-only ones,
characters in the ASCII set should remain as specified in [US-ASCII]. characters in the ASCII set SHOULD remain as specified in [US-ASCII]
(one request to remove).
[14] The protocol should not invent a new CCS for the purpose of IDN [14] 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 in [15] The protocol SHOULD NOT make any assumptions about the location in
a domain name where internationalization might appear. In other words, a domain name where internationalization might appear. In other words,
it should not differentiate between any part of a domain name because it SHOULD NOT differentiate between any part of a domain name because
this may impose restrictions on future internationalization efforts. this MAY impose restrictions on future internationalization efforts.
[16] The protocol should also not make any localized restrictions in the [16] 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] Because of the wide range of devices that use the DNS and the wide [17] While there are a wide range of devices that use the DNS and a wide
range of characteristics of international scripts, the service might range of characteristics of international scripts and methods of
need to allow more than one method of domain name input and display. domain name input and display, IDN is only concerned with the
However, there must be a single way of encoding an internationalized protocol. Therefore, there MUST be a single way of encoding an
domain name within the core of the DNS. internationalized domain name within the DNS.
2.3 Localization
[18] The service should be able to handle localized requirements of
different languages. For example, IDN must be able to handle
bi-directional writing for scripts such as Arabic.
[19] Historically, "." has been the separator of labels in the host
names. The service should not use different separators for different
languages.
[20] Most of the localization work could be handled by the user [18] The protocol SHOULD NOT place any restrictions on the
interface. It should not matter how the domain names are input or application service layer. It SHOULD only specify changes in the DNS
presented, such as in a reverse order or bi-directional, or with the service layer and within the DNS itself.
introduction of a new separator. However, the final wire format must be
in canonical order.
2.4 Canonicalization 2.4 Canonicalization
[21] 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 a recommended as a guide on canonicalization. consistency. [CHARREQ] is RECOMMENDED as a guide on canonicalization.
[22] 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.
Expires 12th of October 2000 [Page 7] [22] To achieve interoperability, canonicalization MUST be done at a
single well-defined place in the DNS resolution process. The protocol
properties which will be required of that algorithm. MUST specify canonicalization; it MUST specify exactly where in the
DNS that canonicalization happens and does not happen; it MUST specify
how additions to ISO 10646 will affect the stability of the DNS and
the amount of work done on the root DNS servers.
[23] The canonicalization algorithm might specify operations for case, [23] 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, [24] In order to retain backwards compatibility with the current DNS,
the service must retain the case-insensitive comparison for US-ASCII as the service MUST retain the case-insensitive comparison for [US-ASCII]
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). [UTR-21] 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 has to the issues with case mapping. Case-insensitivity for non [US-ASCII]
be discussed in the protocol proposal. MUST be discussed in the protocol proposal.
[25] Case folding must be locale independent. For example, Latin [25] Case folding MUST be locale independent. For example, Latin
capital letter I (U+0049) case folded to lower case in the Turkish capital letter I (U+0049) case folded to lower case in the Turkish
context will become Latin small letter dotless i (U+0131). But in the context will become Latin small letter dotless i (U+0131). But in the
English context, it will become Latin small letter i (U+0069). English context, it will become Latin small letter i (U+0069).
[26] If other canonicalization is done, then it must be done before the [26] 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, ...) [27] 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.
[28] If the protocol specifies a canonicalization algorithm, a caching
server should perform correctly regardless of how much (or how little)
of that algorithm it has implemented. [1 request to remove]
[29] If the protocol requires a canonicalization algorithm, all requests
sent to a caching server must already be in the canonical form.
[30] If the charset can be normalized, then it should be normalized [30] If the charset can be normalized, then it SHOULD be normalized
before it is used in IDN. (conflict) before it is used in IDN. Normalization SHOULD follow [UTR15].
(conflict)
[31] The protocol should avoid inventing a new normalization form [31] The protocol SHOULD avoid inventing a new normalization form
provided a technically sufficient one is available (such as in an ISO provided a technically sufficient one is available.
standard).
2.5 Operational Issues 2.5 Operational Issues
[32] Zone files should remain easily editable. [32] Zone files SHOULD remain easily editable.
[33] An IDN-capable resolver or server shall not generate more traffic [33] 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 [34] 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 [35] Within a single zone, the zone manager MUST be able to define
Expires 12th of October 2000 [Page 8]
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 character set of a signed zone file should be the same as the [36] The protocol MUST work with DNSSEC.
character set of the unsigned zone file. The protocol must allow offline
DNSSEC signing. It should be possible to look at the
signed file and see that it is the same as the unsigned one.
2.6 Others
[37] The service may provide the same DNS resources using
internationalized text as it currently provides using ASCII text.
[38] To get full semantics for IDN, an upgrade of the DNS and related
software may be needed.
[39] The protocol should consider new features of DNS such as DNSSEC and
DNAME. For example, DNAME might be useful to simplify canonicalization
for IDN.
[40] The protocol must work for IPv4 and IPv6.
3. Technical Analysis
There are many standard protocols and RFCs which depend on
domain names and have make various assumptions about the characters
in them always conforming to [RFC1034] and the other restriction
discussed above (see [IABIDN]). We expect that the protocols
listed below to be affected:
I RFC2813 Internet Relay Chat : Server Protocol
I RFC2805 Media Gateway Control Protocol Architecture and Requirements
S RFC2789 Mail Monitoring MIB
S RFC2782 A DNS RR for specifying the location of services (DNS SRV)
I RFC2775 Internet Transparency
I RFC2772 6Bone Backbone Routing Guidelines
I RFC2768 Network Policy and Services: A Report of a Workshop on
Middleware
I RFC2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)
S RFC2766 Network Address Translation - Protocol Translation (NAT-PT)
S RFC2765 Stateless IP/ICMP Translation Algorithm (SIIT)
I RFC2763 Dynamic Hostname Exchange Mechanism for IS-IS
E RFC2756 Hyper Text Caching Protocol (HTCP/0.0)
S RFC2748 The COPS (Common Open Policy Service) Protocol
S RFC2744 Generic Security Service API Version 2 : C-bindings
S RFC2743 Generic Security Service Application Program Interface
I RFC2705 Media Gateway Control Protocol (MGCP) Version 1.0
I RFC2694 DNS extensions to Network Address Translators (DNS_ALG)
E RFC2693 SPKI Certificate Theory
S RFC2673 Binary Labels in the Domain Name System
Expires 12th of October 2000 [Page 9]
S RFC2672 Non-Terminal DNS Name Redirection
S RFC2671 Extension Mechanisms for DNS (EDNS0)
I RFC2663 IP Network Address Translator (NAT) Terminology and
Considerations
S RFC2661 Layer Two Tunneling Protocol "L2TP"
E RFC2654 A Tagged Index Object for use in the Common Indexing Protocol
I RFC2637 Point-to-Point Tunneling Protocol (PPTP)
I RFC2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP
S RFC2632 S/MIME Version 3 Certificate Handling
S RFC2622 Routing Policy Specification Language (RPSL)
S RFC1616 Hypertext Transfer Protocol -- HTTP/1.1
I RFC2614 An API for Service Location
S RFC2609 Service Templates and Service: Schemes
B RFC2606 Reserved Top Level DNS Names
I RFC2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP
S RFC2600 Internet Official Protocol Standards
S RFC2595 Using TLS with IMAP, POP3 and ACAP
I RFC2553 Basic Socket Interface Extensions for IPv6
I RFC2546 6Bone Routing Practice
S RFC2543 SIP: Session Initiation Protocol
I RFC2541 DNS Security Operational Considerations
E RFC2540 Detached Domain Name System (DNS) Information
S RFC2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
S RFC2538 Storing Certificates in the Domain Name System (DNS)
S RFC2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
S RFC2546 DSA KEYs and SIGs in the Domain Name System (DNS)
S RFC2535 Domain Name System Security Extensions
I RFC2517 Building Directories from DNS: Experiences from WWWSeeker
S RFC2511 Internet X.509 Certificate Request Message Format
B RFC2505 Anti-Spam Recommendations for SMTP MTAs
S RFC2500 Internet Official Protocol Standards
S RFC2486 The Network Access Identifier
S RFC2459 Internet X.509 Public Key Infrastructure Certificate and CRL
Profile
S RFC2421 Voice Profile for Internet Mail - version 2
I RFC2412 The OAKLEY Key Determination Protocol
S RFC2408 Internet Security Association and Key Management Protocol
(ISAKMP)
S RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP
S RFC2401 Security Architecture for the Internet Protocol
S RFC2400 INTERNET OFFICIAL PROTOCOL STANDARDS
S RFC2396 Uniform Resource Identifiers (URI): Generic Syntax
I RFC2377 Naming Plan for Internet Directory-Enabled Applications
I RFC2367 "PF_KEY Key Management API, Version 2"
I RFC2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed
Pages Document
E RFC2345 Domain Names and Company Name Retrieval
S RFC2326 Real Time Streaming Protocol (RTSP)
B RFC2317 Classless IN-ADDR.ARPA delegation
S RFC2308 Negative Caching of DNS Queries (DNS NCACHE)
S RFC2300 INTERNET OFFICIAL PROTOCOL STANDARDS
S RFC2298 An Extensible Message Format for Message Disposition
Notifications
S RFC2280 Routing Policy Specification Language (RPSL)
S RFC2249 Mail Monitoring MIB
S RFC2247 Using Domains in LDAP/X.500 Distinguished Names
I RFC2230 Key Exchange Delegation Record for the DNS
B RFC2219 Use of DNS Aliases for Network Services
S RFC2200 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC2187 "Application of Internet Cache Protocol (ICP), version 2"
B RFC2182 Selection and Operation of Secondary DNS Servers
S RFC2181 Clarifications to the DNS Specification
E RFC2168 Resolution of Uniform Resource Identifiers using the Domain
Name System
I RFC2167 Referral Whois (RWhois) Protocol V1.5
S RFC2163 Using the Internet DNS to Distribute MIXER Conformant Global
Address Mapping (MCGAM)
S RFC2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between
X.400 and RFC 822/MIME
I RFC2151 A Primer On Internet and TCP/IP Tools and Utilities
I RFC2146 U.S. Government Internet Domain Names
S RFC2142 MAILBOX NAMES FOR "COMMON SERVICES, ROLES AND FUNCTIONS"
S RFC2137 Secure Domain Name System Dynamic Update
S RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
I RFC2133 Basic Socket Interface Extensions for IPv6
S RFC2131 Dynamic Host Configuration Protocol
I RFC2130 The Report of the IAB Character Set Workshop
I RFC2101 IPv4 Address Behaviour Today
S RFC2078 "Generic Security Service Application Program Interface,
Version 2"
S RFC2074 Remote Network Monitoring MIB Protocol Identifiers
I RFC2072 Router Renumbering Guide
S RFC2068 Hypertext Transfer Protocol -- HTTP/1.1
S RFC2065 Domain Name System Security Extensions
E RFC2052 A DNS RR for specifying the location of services (DNS SRV)
S RFC2034 SMTP Service Extension for Returning Enhanced Error Codes
I RFC2010 Operational Criteria for Root Name Servers
E RFC2009 GPS-Based Addressing and Routing
S RFC2000 INTERNET OFFICIAL PROTOCOL STANDARDS
S RFC1996 A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY)
S RFC1995 Incremental Zone Transfer in DNS
S RFC1985 SMTP Service Extension for Remote Message Queue Starting
I RFC1983 Internet Users' Glossary
S RFC1982 Serial Number Arithmetic
S RFC1964 The Kerberos Version 5 GSS-API Mechanism
I RFC1958 Architectural Principles of the Internet
I RFC1955 New Scheme for Internet Routing and Addressing (ENCAPS) for
IPNG
S RFC1933 Transition Mechanisms for IPv6 Hosts and Routers
S RFC1920 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1919 Classical versus Transparent IP Proxies
I RFC1912 Common DNS Operational and Configuration Errors
I RFC1900 Renumbering Needs Work
S RFC1891 SMTP Service Extension for Delivery Status Notifications
I RFC1887 An Architecture for IPv6 Unicast Address Allocation
S RFC1886 DNS Extensions to support IP version 6
S RFC1880 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1877 PPP Internet Protocol Control Protocol Extensions for Name
Server Addresses
E RFC1876 A Means for Expressing Location Information in the Domain Name
System
E RFC1845 SMTP Service Extension for Checkpoint/Restart
I RFC1816 U.S. Government Internet Domain Names
S RFC1800 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1794 DNS Support for Load Balancing
E RFC1788 ICMP Domain Name Messages
S RFC1780 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1739 A Primer On Internet and TCP/IP Tools
S RFC1720 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1713 Tools for DNS debugging
E RFC1712 DNS Encoding of Geographical Location
I RFC1711 Classifications in E-mail Routing
I RFC1709 K-12 Internetworking Guidelines
I RFC1707 CATNIP: Common Architecture for the Internet
I RFC1706 DNS NSAP Resource Records
I RFC1705 Six Virtual Inches to the Left: The Problem with IPng
I RFC1703 Principles of Operation for the TPC.INT Subdomain: Radio
Paging -- Technical Procedures
I RFC1671 IPng White Paper on Transition and Other Considerations
E RFC1664 Using the Internet DNS to Distribute
RFC1327 Mail Address Mapping Tables
E RFC1637 DNS NSAP Resource Records
I RFC1636 Report of IAB Workshop on Security in the Internet
Architecture "February 8-10, 1994"
I RFC1630 Universal Resource Identifiers in WWW
I RFC1621 Pip Near-term Architecture
I RFC1616 X.400(1988) for the Academic and Research Community in Europe
S RFC1612 DNS Resolver MIB Extensions
S RFC1611 DNS Server MIB Extensions
S RFC1610 INTERNET OFFICIAL PROTOCOL STANDARDS
E RFC1608 Representing IP Information in the X.500 Directory
S RFC1600 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1597 Address Allocation for Private Internets
I RFC1594 FYI on Questions and Answers "Answers to Commonly asked ""New
Internet User"" Questions"
I RFC1591 Domain Name System Structure and Delegation
I RFC1588 WHITE PAGES MEETING REPORT
I RFC1569 Principles of Operation for the TPC.INT Subdomain: Radio
Paging -- Technical Procedures
I RFC1546 Host Anycasting Service
S RFC1540 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1537 Common DNS Data File Configuration Errors
I RFC1536 Common DNS Implementation Errors and Suggested Fixes
I RFC1535 A Security Problem and Proposed Correction With Widely
Deployed DNS Software
I RFC1530 Principles of Operation for the TPC.INT Subdomain: General
Principles and Policy
E RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote
Printing -- Technical Procedures
S RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment
and Aggregation Strategy
S RFC1500 INTERNET OFFICIAL PROTOCOL STANDARDS
- RFC1486 An Experiment in Remote Printing
- RFC1480 The US Domain
- RFC1470 FYI on a Network Management Tool Catalog: Tools for Monitoring
and Debugging TCP/IP Internets and Interconnected Devices
- RFC1464 Using the Domain Name System To Store Arbitrary String
Attributes
- RFC1459 Internet Relay Chat Protocol
- RFC1454 Comparison of Proposals for Next Version of IP
- RFC1430 A Strategic Plan for Deploying an Internet X.500 Directory
Service
- RFC1415 FTP-FTAM Gateway Specification
- RFC1410 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1401 Correspondence between the IAB and DISA on the use of DNS
throughout the Internet
- RFC1395 BOOTP Vendor Information Extensions
- RFC1392 Internet Users' Glossary
- RFC1386 The US Domain
- RFC1385 EIP: The Extended Internet Protocol A Framework for
Maintaining Backward Compatibility
- RFC1383 An Experiment in DNS Based IP Routing
- RFC1360 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1348 DNS NSAP RRs
- RFC1347 "TCP and UDP with Bigger Addresses (TUBA)," A Simple Proposal
for Internet Addressing and Routing
- RFC1335 A Two-Tier Address Structure for the Internet: A Solution to
the Problem of Address Space Exhaustion
- RFC1325 FYI on Questions and Answers "Answers to Commonly asked ""New
Internet User"" Questions"
- RFC1309 Technical Overview of Directory Services Using the X.500
Protocol
- RFC1308 Executive Introduction to Directory Services Using the X.500
Protocol
- RFC1291 Mid-Level Networks Potential Technical Services
- RFC1280 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1279 X.500 and Domains
- RFC1274 The COSINE and Internet X.500 Schema
- RFC1250 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1207 FYI on Questions and Answers "Answers to Commonly asked
""Experienced Internet User"" Questions"
- RFC1206 FYI on Questions and Answers "Answers to Commonly asked ""New
Internet User"" Questions"
- RFC1200 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1183 New DNS RR Definitions
- RFC1177 FYI on Questions and Answers "Answers to Commonly asked ""New
Internet User"" Questions"
- RFC1175 FYI on Where to Start - A Bibliography of Internetworking
Information
- RFC1174 IAB Recommended Policy on Distributing Internet Identifier
Assignment And "IAB Recommended Policy Change to Internet
""Connected"" Status"
- RFC1168 INTERMAIL AND COMMERCIAL MAIL RELAY SERVICES
- RFC1147 FYI on a Network Management Tool Catalog: Tools for Monitoring
and Debugging TCP/IP Internets and Interconnected Devices
- RFC1123 Requirements for Internet Hosts -- Application and Support
- RFC1101 DNS Encoding of Network Names and Other Types
- RFC1100 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1085 ISO Presentation Services on top of TCP/IP-based internets
- RFC1083 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
- RFC1034 DOMAIN NAMES - CONCEPTS AND FACILITIES
- RFC0830 A Distributed System for Internet Name Service
S - Standards Track I - Informational
E - Experimental B - Best Current Practice
All idn protocol proposal documents must fully detail the expected [37] The protocol MUST work for all features of DNS, IPv4, and IPv6.
effects of leaking of the specified encoding to protocols other than the
DNS resolution protocol.
4. Security Considerations 4. Security Considerations
Any solution that meets the requirements in this document must not Any solution that meets the requirements in this document MUST NOT be
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
affect the security of any protocol that relies on the DNS or on affect the security of any protocol that relies on the DNS or on
DNS names. A thorough evaluation of those protocols for security DNS names. A thorough evaluation of those protocols for security
concerns will be needed when they are developed. In particular, IDNs concerns will be needed when they are developed. In particular, IDNs
must be compatible with DNSSEC and, if multiple charsets or MUST be compatible with DNSSEC and, if multiple charsets or
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.
5. References 5. 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@internic.net, Olafur Gudmundson, Randy Bush.
[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.
[RFC1766] Tags for the Identification of Languages, rfc1766.txt,
March 1995, H. Alvestrand.
[RFC1996] "A Mechanism for Prompt Notification of Zone Changes [RFC1996] "A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie. (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", rfc2119.txt, March 1997, S. Bradner. Levels", rfc2119.txt, March 1997, S. Bradner.
[RFC2181] "Clarifications to the DNS Specification", rfc2181.txt, [RFC2181] "Clarifications to the DNS Specification", rfc2181.txt,
July 1997, R. Elz, R. Bush. July 1997, R. Elz, R. Bush.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", [RFC2277] "IETF Policy on Character Sets and Languages",
RFC 2279, January 1998. rfc2277.txt, January 1998, H. Alvestrand.
[RFC2278] "IANA Charset Registration Procedures", rfc2278.txt,
January 1998, N. Freed and J. Postel.
[RFC2279] "UTF-8, a transformation format of ISO 10646",
rfc2279.txt, F. Yergeau, January 1998.
[RFC2535] "Domain Name System Security Extensions", rfc2535.txt, [RFC2535] "Domain Name System Security Extensions", rfc2535.txt,
March 1999, D. Eastlake. March 1999, D. Eastlake.
[RFC2553] "Basic Socket Interface Extensions for IPv6", rfc2553.txt, [RFC2553] "Basic Socket Interface Extensions for IPv6", rfc2553.txt,
March 1999, R. Gilligan and al. March 1999, R. Gilligan et al.
[UNIROOT] "IAB Technical Comment on the Unique DNS Root", [RFC2825] "A Tangled Web: Issues of I18N, Domain Names, and the
draft-iab-unique-dns-root-00.txt, iab@iab.org Other Internet protocols", rfc2825.txt, May 2000,
L. Daigle et al.
[IABIDN] "A Tangled Web:issues of I18N domain names, and the [RFC2826] "IAB Technical Comment on the Unique DNS Root",
other Internet protocols", rfc2825.txt rfc2826.txt, May 2000, Internet Architecture Board.
iab@iab.org
[IDNCOMP] "Comparison of Internationalized Domain Name Proposals",
draft-ietf-idn-compare-00.txt, June 2000, P. Hoffman.
[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Described at 3.0", ISBN 0-201-61633-5. Described at
http://www.unicode.org/unicode/standard/versions/ http://www.unicode.org/unicode/standard/versions/
Unicode3.0.html 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. Information Interchange, ANSI X3.4-1986.
[UTR15] "Unicode Normalization Forms", Unicode Technical Report [UTR15] "Unicode Normalization Forms", Unicode Technical Report
#15, http://www.unicode.org/unicode/reports/tr15/, #15, http://www.unicode.org/unicode/reports/tr15/,
Nov 1999, M. Davis & M. Duerst, Unicode Consortium. Nov 1999, M. Davis & M. Duerst, Unicode Consortium.
[UTR21] "Case Mappings", Unicode Technical Report #21, [UTR21] "Case Mappings", Unicode Technical Report #21,
http://www.unicode.org/unicode/reports/tr21/, Dec 1999, http://www.unicode.org/unicode/reports/tr21/, Dec 1999,
M. Davis, Unicode Consortium. M. Davis, Unicode Consortium. Approved status.
6. Editors' Contact 6. Editors' Contact
Zita Wenzel Zita Wenzel, Ph.D.
[ ... ] Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, CA
90292 USA
Tel: +1 310 448 8462
Fax: +1 310 823 6714
zita@isi.edu
James Seng James Seng
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
7. Acknowledgements 7. Acknowledgements
The editor gratefully acknowledges 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>
RJ Atkinson <request not to have email>
Alan Barret <apb@cequrux.com>
Randy Bush <randy@psg.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>
Andrew Draper <ADRAPER@altera.com> Ned Freed <ned.freed@innosoft.com>
Bill Manning <bmanning@ISI.EDU>
Paul Hoffman <phoffman@imc.org>
James Seng <jseng@pobox.org.sg>
Randy Bush <randy@psg.com>
Alan Barret <apb@cequrux.com>
Olafur Gudmundsson <ogud@tislabs.com> Olafur Gudmundsson <ogud@tislabs.com>
Karlsson Kent <keka@im.se> Paul Hoffman <phoffman@imc.org>
Dan Oscarsson <Dan.Oscarsson@trab.se>
J. William Semich <bill@mail.nic.nu>
RJ Atkinson <request not to have email>
Simon Josefsson <jas+idn@pdc.kth.se> Simon Josefsson <jas+idn@pdc.kth.se>
Ned Freed <ned.freed@innosoft.com> Karlsson Kent <keka@im.se>
Dongman Lee <dlee@icu.ac.kr>
Mark Andrews <Mark.Andrews@nominum.com>
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>
Bill Manning <bmanning@ISI.EDU>
Dan Oscarsson <Dan.Oscarsson@trab.se>
J. William Semich <bill@mail.nic.nu>
James Seng <jseng@pobox.org.sg>
 End of changes. 84 change blocks. 
466 lines changed or deleted 161 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/