Re: [idn] draft-ietf-idn-requirements-03.txt

[James Seng <jseng@pobox.org.sg>]

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 ---------------