[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] draft-ietf-idn-requirements-03.txt
- To: Zita Wenzel <zita@ISI.EDU>
- Subject: Re: [idn] draft-ietf-idn-requirements-03.txt
- From: James Seng <jseng@pobox.org.sg>
- Date: Thu, 29 Jun 2000 04:20:35 +0800
- CC: idn@ops.ietf.org
- Delivery-date: Thu, 29 Jun 2000 23:06:06 -0700
- Envelope-to: idn-data@psg.com
Send it out :-) Thanks Zita! It is not easy to go thru the mails to compile
this.
This would be one agenda for next IETF meeting. I suggest everyone here spend
a little time to go thru it.
*cheers*
-James Seng
Zita Wenzel wrote:
>
> Dear IDN Working Group:
>
> Here is a new draft of the Internet-Draft "Requirements of
> Internalizationed Domain Names". The changes include the following:
>
> 1. Date changed from 12 May to 28 June (and expiration from 12 October
> to 28 November). All key words "MUST", "MUST NOT", REQUIRED", "SHALL",
> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" are capitalized in the text. Minor grammar, punctuation,
> and formatting changes have also been done to aid clarity and
> consistency.
>
> 2. Section 1.2 (last paragraph):
>
> "...with the further 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." (removed)
>
> 3. Section 1.5 (4th paragraph):
>
> "This doesn't preclude the fact that IDN should work with any kind of
> DNS queries." (changed "will" to "with")
>
> 4. Section 2.1:
>
> [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." (added with conflict)
>
> [4] Replaced with "The protocol SHOULD allow creation of caching
> servers that do not understand the charset in which a request or
> response is encoded. The caching server SHOULD perform correctly for
> IDN as well as for current domain names (without the authoritative bit)
> as the master server would have if presented with the same request."
>
> [6] Removed.
>
> [7] "must be approved by the DNSEXT WG" changed to "should be
> coordinated with the DNSEXT WG".
>
> [9] Removed.
>
> [12] Replaced with "This document RECOMMENDS Unicode only. If multiple
> charsets are allowed, each charset MUST be tagged and conform to
> [RFC2277]." Note change of RFC from 1766 to 2277.
>
> 5. Section 2.2:
>
> [12.5] "IDN MUST NOT return illegal code points in responses, SHOULD
> reject queries with illegal codepoints." (1 request to add; 1 request
> to remove)
>
> [13] One request to remove.
>
> [17] Replaced with "While there are a wide range of devices that use the
> DNS and a wide range of characteristics of international scripts and
> methods of domain name input and display, IDN is only concerned with
> the protocol. Therefore, there MUST be a single way of encoding an
> internationalized domain name within the DNS."
>
> [18-20] Removed (along with section heading) and replaced with "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."
>
> 6. Section 2.4:
>
> Paragraph numbering [21] and [22] removed.
>
> [22] "To achieve interoperability, canonicalization MUST be done at a
> single well-defined place in the DNS resolution process. The protocol
> 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." (added)
>
> [28] and [29] removed.
>
> [30] "Normalization should follow [UTR15]." (added)
>
> [31] "(such as in an ISO standard.)" (removed)
>
> 7. Section 2.5:
>
> [36] Replaced with "The protocol MUST work with DNSSEC."
>
> 8. Section 2.6 (section heading removed):
>
> [38-40] Removed and replaced with "The protocol MUST work for all
> features of DNS, IPv4, and IPv6."
>
> 9. Section 3:
>
> Removed list of RFCs that may be affected.
>
> 10. References:
>
> Added RFCs 1342, 2277, 2278, 2585, and 2586 (the latter two to update
> IDs). Removed RFC 1766. Also changed references to these in the
> text.
>
> Added "Approved status" to [UTR21].
> Added draft-ietf-idn-compare-00.txt.
>
> 11. Editors:
>
> Added Zita Wenzel's contact information.
>
> 12. Acknowledgements:
>
> Placed in alpha order.
>
> 13. N.B.: No consensus was seen on normalization form and order of
> decomposing, normalization, folding, canonicalization.
>
> Respectfully submitted,
>
> Zita
>
> -------------- draft-ietf-idn-requirements-03.txt ---------------
>
> IETF IDN Working Group Editors Zita Wenzel, James Seng
> Internet Draft draft-ietf-idn-requirements-03.txt
> 28 June 2000 Expires 28 November 2000
>
> Requirements of Internationalized Domain Names
>
> Status of this Memo
>
> This document is an Internet-Draft and is in full conformance with
> all provisions of Section 10 of RFC2026.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as
> Internet-Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six
> months and may be updated, replaced, or obsoleted by other
> documents at any time. It is inappropriate to use Internet-
> Drafts as reference material or to cite them other than as
> "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> Abstract
>
> This document describes the requirement for encoding international
> characters into DNS names and records. This document is guidance for
> developing protocols for internationalized domain names.
>
> 1. Introduction
>
> 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
> other text based items on the Internet have already been at least
> partially internationalized. It is important for domain names to be
> similarly internationalized or for an equivalent solution to be found.
> This document assumes that the most effective solution involves putting
> non-ASCII names inside some parts of the overall DNS system.
>
> 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
> "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*.
>
> 1.1 Definitions and Conventions
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
>
> Characters mentioned in this document are identified by their position
> in the Unicode [UNICODE] character set. The notation U+12AB, for
> example, indicates the character at position 12AB (hexadecimal) in the
> Unicode character 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
> further explain the meanings and principles adopted by the document. It
> is not a requirement for the protocol to satisfy the examples.
>
> A character is a member of a set of elements used for organization,
> control, or representation of data.
>
> A coded character is a character with its coded representation.
>
> A coded character set ("CCS") is a set of unambiguous rules that
> establishes a character set and the relationship between the characters
> of the set and their coded representation.
>
> A graphic character or glyph is a character, other than a control
> function, that has a visual representation normally handwritten,
> printed, or displayed.
>
> 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
> a single CCS; for example, UTF-8 [RFC2279] applies only to ISO 10646.
> 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
> 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
> to procedures documented in [RFC2278].
>
> 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
> used in many languages, and many languages can be expressed using
> different scripts. A particular charset MAY have different glyphs
> (shapes) depending on the language being used.
>
> 1.2 Description of the Domain Name System
>
> The Domain Name System is defined by [RFC1034] and [RFC1035], with
> clarifications, extensions and modifications given in [RFC1123],
> [RFC1996], [RFC2181], and others. Of special importance here is the
> security extensions described in [RFC2535] and companions.
>
> 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 certain that the set of terms used in this document are
> well-defined and non-ambiguous, the definitions are given here.
>
> 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
> complete copy of the records for that zone. Slave servers MAY be either
> authorized by the zone owner (secondary servers) or unauthorized
> (so-called "stealth secondaries"). Master and authorized slave servers
> are listed in the NS records for the zone, and are termed
> "authoritative" servers. In many contexts, outside this document the
> term "primary" is used interchangeably with "master" and "secondary" is
> used interchangeably with "slave".
>
> A caching server holds temporary copies of DNS records; it uses records
> to answer queries about domain names. Further explanation of these
> terms can be found in [RFC1034] and [RFC1996].
>
> DNS names can be represented in multiple forms, with different
> properties for internationalization. The most important ones are:
>
> - Domain name: The binary representation of a name used internally in
> the DNS protocol. This consists of a series of components of 1-63
> octets, with an overall length limited to 255 octets (including the
> length fields).
>
> - Master file format domain name: This is a representation of the name
> as a sequence of characters in some character sets; the common
> convention (derived from [RFC1035] section 5.1) is to represent the
> 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
> mechanism (\x or \NNN) where not, and separating the components of the
> name by the dot character (".").
>
> 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
> [RFC1034] Section 3.5 and [RFC1123]. In most implementations of
> applications today, domain names in the Internet have been limited to
> 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
> case-independent fashion), the digits, and the hyphen.
>
> 1.3 Definition of "hostname" and "Internationalized Domain Name"
>
> In the DNS protocols, a name is referred to as a sequence of octets.
> However, when discussing requirements for internationalized domain
> names, what we are looking for are ways to represent characters that
> are meaningful for humans.
>
> 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
> here in the sense of "sequence of characters (not octets) representing a
> domain name conforming to the limited hostname syntax".
>
> This document attempts to define the requirements for an
> "Internationalized Domain Name" (IDN). This is defined as a sequence of
> 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
> set of characters specified as legal characters for host names.
>
> 1.4 A multilayer model of the DNS function
>
> The DNS can be seen as a multilayer function:
>
> - 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
> the format and meaning of bits and octets in a DNS packet.
>
> - Above that is the "DNS service", created by an infrastructure of DNS
> 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
> server, often called "named.cache". It is at this level that the
> statement "the DNS has a single root" [RFC2826] makes sense, but
> still, what are being transferred are octets, not characters.
>
> - Interfacing to the user is a service layer, often called "the resolver
> library", and often embedded in the operating system or system
> libraries of the client machines. It is at the top of this layer that
> the API calls commonly known as "gethostbyname" and
> "gethostbyaddress" reside. These calls are modified to support IPv6
> [RFC2553]. A conceptually similar layer exists in authoritative DNS
> servers, comprising the parts that generate "meaningful" strings in
> DNS files. Due to the popularity of the "master file" format, this
> layer often exists only in the administrative routines of the service
> maintainers.
>
> - The user of this layer (resolver library) is the application programs
> that use the DNS, such as mailers, mail servers, Web clients, Web
> servers, Web caches, IRC clients, FTP clients, distributed file
> systems, distributed databases, and almost all other applications on
> TCP/IP.
>
> Graphically, one can illustrate it like this:
>
> +---------------+ +---------------------+
> | Application | | (Base data) |
> +---------------+ +---------------------+
> | Application service interface |
> | For ex. GethostbyXXXX interface | (no standard)
> +---------------+ +---------------------+
> | Resolver | | Auth DNS server |
> +---------------+ +---------------------+
> | <----- DNS service interface -----> |
> +------------------------------------------------------------------+
> | DNS service |
> | +-----------------------+ +--------------------+ |
> | | Forwarding DNS server | | Caching DNS server | |
> | +-----------------------+ +--------------------+ |
> | |
> | +-------------------------+ |
> | | Parent-zone DNS servers | |
> | +-------------------------+ |
> | |
> | +-------------------------+ |
> | | Root DNS servers | |
> | +-------------------------+ |
> | |
> +------------------------------------------------------------------+
>
> 1.5 Service model of the DNS
>
> 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
> expects as a result (the reply).
>
> The most used ones in the current DNS are:
>
> - Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get
> 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.
>
> - 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.
>
> - Domain delegation service (NS). Enter a domain name and get back
> nameserver records (designated hosts who provides authoritive
> nameservice) for the domain.
>
> New services are being defined, either as entirely new services (IPv6
> to hostname mapping using binary labels) or as embellishments to other
> services (DNSSEC returning information about whether a given DNS
> service is performed securely or not).
>
> These services exist, conceptually, at the Application/Resolver
> interface, NOT at the DNS-service interface. This document attempts to
> set requirements for an equivalent of the "used services" given above,
> where "hostname" is replaced by "Internationalized Domain Name". This
> 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
> 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
> advantage of the new service.
>
> 2. General Requirements
>
> These requirements address two concerns: The service offered to the
> users (the application service), and the protocol extensions, if needed,
> added to support this service.
>
> In the requirements, we attempt to use the term "service" whenever a
> requirement concerns the service, and "protocol" whenever a requirement
> is believed to constrain the possible implementation.
>
> 2.1 Compatibility and Interoperability
>
> [1] The DNS is essential to the entire Internet. Therefore, the service
> MUST NOT damage present DNS protocol interoperability. It MUST make 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
> internationalized domain name.
>
> [2] The service MUST preserve the basic concept and facilities of
> domain names as described in [RFC1034]. It MUST maintain a single,
> global, universal, and consistent hierarchical namespace.
>
> [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
> process.
>
> [4] The protocol SHOULD allow creation of caching servers that do
> not understand the charset in which a request or response is encoded.
> The caching server SHOULD perform correctly for IDN as well as for
> current domain names (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
> would not have been returned if the same query had been presented to an
> authoritative server. This applies fully for the cases when:
>
> - The caching server does not know about IDN
> - The caching server implements the whole specification
> - The caching server implements a valid subset of the specification
>
> [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 SHOULD be coordinated with the
> [DNSEXT] WG.
>
> [8] The protocol supporting the service SHOULD be as simple as possible
> from the user's perspective. Ideally, users SHOULD NOT realize that IDN
> was added on to the existing DNS.
>
> [10] The best solution is one that maintains maximum feasible
> compatibility with current DNS standards as long as it meets the other
> requirements in this document.
>
> 2.2 Internationalization
>
> [11] Internationalized characters MUST be allowed to be represented and
> 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
> records.
>
> [12] This document RECOMMENDS Unicode only. If multiple charsets are
> allowed, each charset MUST be tagged and conform to [RFC2277].
>
> [12.5] IDN MUST NOT return illegal code points in responses, SHOULD
> reject queries with illegal codepoints. (one request to add; one request
> to remove)
>
> [13] CES(s) chosen SHOULD NOT encode ASCII characters differently
> depending on the other characters in the string. In other words, unless
> 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
> only and SHOULD use existing CES. The charset(s) chosen SHOULD also be
> non-ambiguous.
>
> [15] The protocol SHOULD NOT make any assumptions about the location in
> a domain name where internationalization might appear. In other words,
> it SHOULD NOT differentiate between any part of a domain name because
> this MAY impose restrictions on future internationalization efforts.
>
> [16] The protocol also SHOULD NOT make any localized restrictions in the
> protocol. For example, an IDN implementation which only allows domain
> names to use a single local script would immediately restrict
> multinational organization.
>
> [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
> domain name input and display, IDN is only concerned with the protocol.
> Therefore, there MUST be a single way of encoding an 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
>
> Matching rules are a complicated process for IDN. Canonicalization
> of characters MUST follow precise and predictable rules to ensure
> 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
> 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
> the first step of this process. This section discusses some of the
> properties which will be REQUIRED of that algorithm.
>
> [22] To achieve interoperability, canonicalization MUST be done at a
> single well-defined place in the DNS resolution process. The protocol
> 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 MAY specify operations for case,
> ligature, and punctuation folding.
>
> [24] In order to retain backwards compatibility with the current DNS,
> the service MUST retain the case-insensitive comparison for [US-ASCII]
> as specified in [RFC1035]. For example, Latin capital letter A (U+0041)
> MUST match Latin small letter a (U+0061). [UTR21] describes some of
> the issues with case mapping. Case-insensitivity for non [US-ASCII]
> MUST be discussed in the protocol proposal.
>
> [25] Case folding MUST be locale independent. For example, Latin
> 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
> English context, it will become Latin small letter i (U+0069).
>
> [26] If other canonicalization is done, it MUST be done before the
> domain name is resolved. Further, the canonicalization MUST be easily
> upgradable as new languages and writing systems are added.
>
> [27] Any conversion (case, ligature folding, punctuation folding, etc)
> 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.
>
> [30] If the charset can be normalized, then it SHOULD be normalized
> before it is used in IDN. Normalization SHOULD follow [UTR15].
> (conflict)
>
> [31] The protocol SHOULD avoid inventing a new normalization form
> provided a technically sufficient one is available.
>
> 2.5 Operational Issues
>
> [32] Zone files SHOULD remain easily editable.
>
> [33] An IDN-capable resolver or server SHALL NOT generate more traffic
> than a non-IDN-capable resolver or server would when resolving an
> ASCII-only domain name. The amount of traffic generated when resolving
> an IDN SHALL be similar to that generated when resolving an ASCII-only
> name.
>
> [34] The service SHOULD NOT add new centralized administration for the
> DNS. A domain administrator SHOULD be able to create internationalized
> names as easily as adding current domain names.
>
> [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
> limited to, and not necessarily, non-ASCII case folding, Unicode
> normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or
> traditional/simplified Chinese equivalence. Such defined equivalences
> MUST NOT remove equivalences that are assumed by (old or
> local-rule-ignorant) caches.
>
> [36] The protocol MUST work with DNSSEC.
>
> [37] The protocol MUST work for all features of DNS, IPv4, and IPv6.
>
> 4. Security Considerations
>
> Any solution that meets the requirements in this document MUST NOT be
> less secure than the current DNS. Specifically, the mapping of
> internationalized host names to and from IP addresses MUST have the
> same characteristics as the mapping of today's host names.
>
> Specifying requirements for internationalized domain names does not
> 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
> DNS names. A thorough evaluation of those protocols for security
> concerns will be needed when they are developed. In particular, IDNs
> MUST be compatible with DNSSEC and, if multiple charsets or
> representation forms are permitted, the implications of this name-spoof
> MUST be throughly understood.
>
> 5. References
>
> [CHARREQ] "Requirements for string identity matching and String
> Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
> World Wide Web Consortium.
>
> [DNSEXT] "IETF DNS Extensions Working Group",
> namedroppers@internic.net, Olafur Gudmundson, Randy Bush.
>
> [RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt,
> November 1987, P. Mockapetris.
>
> [RFC1035] "Domain Names - Implementation and Specification",
> rfc1035.txt, November 1987, P. Mockapetris.
>
> [RFC1123] "Requirements for Internet Hosts -- Application and
> Support", rfc1123.txt, October 1989, R. Braden.
>
> [RFC1996] "A Mechanism for Prompt Notification of Zone Changes
> (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie.
>
> [RFC2119] "Key words for use in RFCs to Indicate Requirement
> Levels", rfc2119.txt, March 1997, S. Bradner.
>
> [RFC2181] "Clarifications to the DNS Specification", rfc2181.txt,
> July 1997, R. Elz, R. Bush.
>
> [RFC2277] "IETF Policy on Character Sets and Languages",
> 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,
> March 1999, D. Eastlake.
>
> [RFC2553] "Basic Socket Interface Extensions for IPv6", rfc2553.txt,
> March 1999, R. Gilligan et al.
>
> [RFC2825] "A Tangled Web: Issues of I18N, Domain Names, and the
> Other Internet protocols", rfc2825.txt, May 2000,
> L. Daigle et al.
>
> [RFC2826] "IAB Technical Comment on the Unique DNS Root",
> rfc2826.txt, May 2000, Internet Architecture Board.
>
> [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
> 3.0", ISBN 0-201-61633-5. Described at
> http://www.unicode.org/unicode/standard/versions/
> Unicode3.0.html
>
> [US-ASCII] Coded Character Set -- 7-bit American Standard Code for
> Information Interchange, ANSI X3.4-1986.
>
> [UTR15] "Unicode Normalization Forms", Unicode Technical Report
> #15, http://www.unicode.org/unicode/reports/tr15/,
> Nov 1999, M. Davis & M. Duerst, Unicode Consortium.
>
> [UTR21] "Case Mappings", Unicode Technical Report #21,
> http://www.unicode.org/unicode/reports/tr21/, Dec 1999,
> M. Davis, Unicode Consortium. Approved status.
>
> 6. Editors' Contact
>
> 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
> 8 Temesek Boulevand
> #24-02 Suntec Tower 3
> Singapore 038988
> Tel: +65 248 6208
> Fax: +65 248 6198
> Email: jseng@pobox.org.sg
>
> 7. Acknowledgements
>
> The editors gratefully acknowledge the contributions of:
>
> 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>
> Patrik Faltstrom <paf@swip.net>
> Ned Freed <ned.freed@innosoft.com>
> Olafur Gudmundsson <ogud@tislabs.com>
> Paul Hoffman <phoffman@imc.org>
> Simon Josefsson <jas+idn@pdc.kth.se>
> Karlsson Kent <keka@im.se>
> John Klensin <klensin+idn@jck.com>
> 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>
>
> -------------- draft-ietf-idn-requirements-03.txt ---------------