draft-ietf-idn-requirements-03.txt   draft-ietf-idn-requirements-04.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-03.txt Internet Draft draft-ietf-idn-requirements-04.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 line 52 skipping to change at line 50
This document assumes that the most effective solution involves putting This document assumes that the most effective solution involves putting
non-ASCII names inside some parts of the overall DNS system. non-ASCII names inside some parts of the overall DNS system.
This document is being discussed on the "idn" mailing list. To join the This document is being discussed on the "idn" mailing list. To join the
list, send a message to <majordomo@ops.ietf.org> with the words list, send a message to <majordomo@ops.ietf.org> with the words
"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", A language is a way that humans interact. In computerised form, a text
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this in a written language can be expressed as a string of characters.
document are to be interpreted as described in [RFC2119]. The same set of characters can often be used for many written languages,
and many written languages can be expressed using different scripts.
The same characters are often shown with somewhat different glyphs
(shapes)
for display of a text depending on the font used, the automatic shaping
applied, or the automatic formation of ligatures. In addition, the same
characters can be shown with somewhat different glyphs (shapes) for
display
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,
control, or representation of textual data.
A graphic character is a character, other than a control function,
that has a visual representation normally handwritten, printed, or
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. The notation U+12AB, for in the Unicode [UNICODE] character set. This character set is also
example, indicates the character at position 12AB (hexadecimal) in the known as the UCS [ISO10646]. The notation U+12AB, for example, indicates
Unicode character set. Note that the use of this notation is not an the character at position 12AB (hexadecimal) in the Unicode character
indication of a requirement to use Unicode. set. Note that the use of this notation is not an 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, Unicode Technical Report 17 [UTR17] defines a character encoding
control, or representation of data. model in several levels (much of the text below is quoted from
Unicode Technical Report 17 [UTR17]):
A coded character is a character with its coded representation. 1. A abstract character repertoire (ACR) is defined as the set of
abstract characters to be encoded, normally a familiar alphabet
or symbol set. The word abstract just means that these objects
are defined by convention (such as the 26 letters of the English
alphabet, uppercase and lowercase forms). Examples: the ASCII
repertoire, the Latin-15 repertoire, the JIS X 0208 repertoire,
the UCS repertiore (of a particular version).
A coded character set ("CCS") is a set of unambiguous rules that 2. A coded character set (CCS) is defined to be a mapping from a
establishes a character set and the relationship between the characters set of abstract characters to the set of non-negative integers.
of the set and their coded representation. This range of integers need not be contiguous. An abstract
character is defined to be in a coded character set if the coded
character set maps from it to an integer. That integer is said
to be the code point for the abstract character. That abstract
character is then an encoded character. Examples: ASCII, Latin-15,
JIS X 0208, the UCS.
A graphic character or glyph is a character, other than a control 3. A character encoding form (CEF) is a mapping from the set of integers
function, that has a visual representation normally handwritten, used in a CCS to the set of sequences of code units. A code unit
printed, or displayed. is an integer occupying a specified binary width in a computer
architecture, such as a septet, an octet, or a 16-bit unit. The
encoding form enables character representation as actual data in
a computer. The sequences of code units do not necessarily have the
same length. Examples: ASCII, Latin-15, Shift-JIS, UTF-16, UTF-8.
A character encoding scheme or "CES" is a mapping from one or more 4. A character encoding scheme (CES) is a mapping of code units into
coded character sets to a set of octets. Some CESs are associated with serialized octet sequences. Character encoding schemes are relevant
a single CCS; for example, UTF-8 [RFC2279] applies only to ISO 10646. to the issue of cross-platform persistent data involving code units
Other CESs, such as ISO 2022, are associated with many CCSs. wider than a byte, where byte-swapping may be required to put data
into the byte polarity canonical for a particular platform.
A charset is a method of mapping a sequence of octets to a sequence of The CES may involve two or more CCS's, and may include code units
abstract characters. A charset is, in effect, a combination of one or (e.g. single shifts, SI/SO, or escape sequences) that are not part
more CCS with a CES. Charset names are registered by the IANA according of the CCS per se, but which are defined by the character encoding
to procedures documented in [RFC2278]. architecture and which may require an external registry of particular
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
CCS is called a simple CES.)
A language is a way that humans interact. In written form, a language Examples: ASCII, Latin-15, Shift-JIS, UTF-16BE, UTF-16LE, UTF-8.
is expressed in characters. The same set of characters can often be
used in many languages, and many languages can be expressed using 5. The mapping from an abstract character repertoire (ACR) to a
different scripts. A particular charset MAY have different glyphs serialised
(shapes) depending on the language being used. sequence of octets is called a Character Map (CM). A simple character
map thus implicitly includes a CCS, a CEF, and a CES, mapping from
abstract characters to code units to octets. A compound character
map includes a compound CES, and thus includes more than one CCS
and CEF. In that case, the abstract character repertoire for the
character map is the union of the repertoires covered by the coded
character sets involved.
Character Maps are the things that in the IAB architecture get IANA
charset identifiers. A sequence of encoded characters must be
unambiguously mapped onto a sequence of octets by the charset. The
charset must be specified in all instances, as in Internet
protocols, where textual content is treated as a ordered sequence
of octets, and where the textual content must be reconstructible
from that sequence of octets. Charset names are registered by the
IANA according to procedures documented in [RFC2278]. In many cases,
the same name is used for both a character map and for a character
encoding scheme, such as UTF-16BE. Typically this is done for simple
character maps when such usage is clear from context.
6. A transfer encoding syntax (TES) is a reversible transform of encoded
data which may (or may not) include textual data represented in
one or more character encoding schemes. Examples: 8bit,
Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE).
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 (e.g., [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
(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
skipping to change at line 142 skipping to change at line 201
octets of the name as ASCII characters where the octet is in the set octets of the name as ASCII characters where the octet is in the set
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 upper- and lower-case letters a-z (interpreted in a
case-independent fashion), the digits, and the hyphen. case-independent fashion), the digits, and the hyphen-minus, all in
ASCII.
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
skipping to change at line 173 skipping to change at line 233
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 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" [RFC2826] 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,
skipping to change at line 279 skipping to change at line 340
[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 service layer (the packet formats that go on the wire) [2.5] The DNS protocol (the packet formats that go on the wire) MUST
MUST NOT limit the codepoints that can be used. This interface SHOULD NOT limit the codepoints that can be used. A service defined on top of
NOT assign meaning to name strings; the application service layer, the DNS, for instance the IDN-to-address function, MAY limit the
where "gethostbyname" et al reside, MAY constrain the name strings to codepoints that can be used. The service descriptions MUST describe
be used in certain services. (conflict) what limitations are imposed.
[2.6] 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
that requests the IP-to-(old)-domain-name mapping service.
[3] The same name resolution request MUST generate the same response, [3] 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 SHOULD allow creation of caching servers that do [4] The protocol MUST NOT require that the current DNS cache
not understand the charset in which a request or response is encoded. servers be modified to support IDN. If a cache server can have
The caching server SHOULD perform correctly for IDN as well as for additional functionality to support IDN better, this additional
current domain names (without the authoritative bit) as the master functionality MUST NOT cause problems for resolving correctly
server would have if presented with the same request. functioning current domain names.
[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
[7] The service MAY modify the DNS protocol [RFC1035] and other related [7] The service MAY modify the DNS protocol [RFC1035] and other related
skipping to change at line 324 skipping to change at line 389
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 RECOMMENDS Unicode only. If multiple charsets are [12] Codepoints SHOULD be from the Universal Set as defined in
allowed, each charset MUST be tagged and conform to [RFC2277]. ISO-10646 or Unicode. The specifics of versions MUST be defined in the
proposed solution. If multiple charsets are allowed, each charset MUST
[12.5] IDN MUST NOT return illegal code points in responses, SHOULD be tagged and conform to [RFC2277].
reject queries with illegal codepoints. (one request to add; one request
to remove)
[13] CES(s) chosen SHOULD NOT encode ASCII characters differently [12.5] The protocol MUST NOT reject any non-IDN characters (to be
depending on the other characters in the string. In other words, unless defined) in any queries or responses.
IDN names are identified and coded differently from ASCII-only ones,
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
a domain name where internationalization might appear. In other words, in a domain name where internationalization might appear. In other
it SHOULD NOT differentiate between any part of a domain name because words, it SHOULD NOT differentiate between any part of a domain name
this MAY impose restrictions on future internationalization efforts. because this MAY impose restrictions on future internationalization
efforts. For example, the TLDs can be internationalized.
[16] The protocol also SHOULD 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] While there are a wide range of devices that use the DNS and a wide [17] 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.
[18] The protocol SHOULD NOT place any restrictions on the
application service layer. It SHOULD only specify changes in the DNS
service layer and within the DNS itself.
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
skipping to change at line 434 skipping to change at line 491
[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
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. [36] The protocol MUST work with DNSSEC.
[37] The protocol MUST work for all features of DNS, IPv4, and IPv6. 3. Security Considerations
4. 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
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 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@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.
skipping to change at line 504 skipping to change at line 559
[RFC2825] "A Tangled Web: Issues of I18N, Domain Names, and the [RFC2825] "A Tangled Web: Issues of I18N, Domain Names, and the
Other Internet protocols", rfc2825.txt, May 2000, Other Internet protocols", rfc2825.txt, May 2000,
L. Daigle et al. L. Daigle et al.
[RFC2826] "IAB Technical Comment on the Unique DNS Root", [RFC2826] "IAB Technical Comment on the Unique DNS Root",
rfc2826.txt, May 2000, Internet Architecture Board. rfc2826.txt, May 2000, Internet Architecture Board.
[IDNCOMP] "Comparison of Internationalized Domain Name Proposals", [IDNCOMP] "Comparison of Internationalized Domain Name Proposals",
draft-ietf-idn-compare-00.txt, June 2000, P. Hoffman. draft-ietf-idn-compare-00.txt, June 2000, P. Hoffman.
[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version [ISO10646] ISO/IEC 10646-1:2000 (note that an amendment 1 is in
3.0", ISBN 0-201-61633-5. Described at preparation), ISO/IEC 10646-2 (in preparation), plus
http://www.unicode.org/unicode/standard/versions/ corrigenda and amendments to these standards.
Unicode3.0.html
[UNICODE] The Unicode Consortium, "The Unicode Standard". Described at
http://www.unicode.org/unicode/standard/versions/.
[UNICODE30] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Same repertoire as ISO/IEC
10646-1:2000. Described at
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. Information Interchange, ANSI X3.4-1986; also: ISO/IEC
646 (IRV).
[UTR15] "Unicode Normalization Forms", Unicode Technical Report [UAX15] "Unicode Normalization Forms", Unicode Standard Annex #15,
#15, http://www.unicode.org/unicode/reports/tr15/, http://www.unicode.org/unicode/reports/tr15/, 2000-08-31,
Nov 1999, M. Davis & M. Duerst, Unicode Consortium. M. Davis and M. Duerst, Unicode Consortium.
[UTR17] "Character Encoding Model", Unicode Technical Report #17,
http://www.unicode.org/unicode/reports/tr17/, 2000-08-31,
K. Whistler and M. Davis, 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/, 2000-09-12,
M. Davis, Unicode Consortium. Approved status. M. Davis, Unicode Consortium.
6. Editors' Contact 5. Editors' Contact
Zita Wenzel, Ph.D. Zita Wenzel, Ph.D.
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
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 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>
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>
Karlsson Kent <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> James Seng <jseng@pobox.org.sg>
 End of changes. 28 change blocks. 
82 lines changed or deleted 150 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/