2. General RequirementsThese requirements address two concerns: The service offered to theusers (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 arequirement concerns the service, and "protocol" whenever a requirementis believed to constrain the possible implementation.2.1 Compatibility and Interoperability[1] The DNS is essential to the entire Internet. Therefore, the serviceMUST NOT damage present DNS protocol interoperability. It MUST make theminimum number of changes to existing protocols on all layers of thestack. It MUST continue to allow any system anywhere to resolve anyinternationalized domain name.[2] The service MUST preserve the basic concept and facilities of domainnames as described in [RFC1034]. It MUST maintain a single, global,universal, and consistent hierarchical namespace.[3] The DNS protocol (the packet formats that go on the wire) MUSTNOT limit the codepoints that can be used.  A service defined on top ofthe DNS, for instance the IDN-to-address function, MAY limit thecodepoints that can be used.  The service descriptions MUST describewhat limitations are imposed.[4] The protocol MUST work for all features of DNS, IPv4, andIPv6.  The protocol MUST NOT allow an IDN to be returned to a requestorthat requests the IP-to-(old)-domain-name mapping service.[5] The same name resolution request MUST generate the same response,regardless of the location or localization settings in the resolver, inthe master server, and in any slave servers involved in the resolutionprocess.[6] The protocol MUST NOT require that the current DNS cacheservers be modified to support IDN.  If a cache server can haveadditional functionality to support IDN better, this additionalfunctionality MUST NOT cause problems for resolving correctlyfunctioning current domain names.[7] A caching server MUST NOT return data in response to a query thatwould not have been returned if the same query had been presented to anauthoritative 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[8] The service MAY modify the DNS protocol [RFC1035] and other relatedwork undertaken by the [DNSEXT] WG. However, these changes SHOULD be assmall as possible and any changes SHOULD be coordinated with the[DNSEXT] WG.[9] The protocol supporting the service SHOULD be as simple as possiblefrom the user's perspective. Ideally, users SHOULD NOT realize that IDNwas added on to the existing DNS.[10] The best solution is one that maintains maximum feasiblecompatibility with current DNS standards as long as it meets the otherrequirements in this document.[11] The protocol should handle with care new revisions of the CCS.Undefined codepoints should not be allowed unless a new revision ofthe protocol can handle it.  Protocol revisions should be tagged.2.2 Internationalization[12] Internationalized characters MUST be allowed to be represented andused in DNS names and records. The protocol MUST specify what charset isused when resolving domain names and how characters are encoded in DNSrecords.[13] Codepoints SHOULD be from the Universal Set as defined inISO-10646 or Unicode.  The specifics of versions MUST be defined in theproposed solution.  If multiple charsets are allowed, each charset MUSTbe tagged and conform to [RFC2277].[14] The protocol MUST NOT reject any non-IDN characters (to bedefined) in any queries or responses.[15] The protocol SHOULD NOT invent a new CCS for the purpose of IDNonly and SHOULD use existing CES. The charset(s) chosen SHOULD also benon-ambiguous.[16] The protocol SHOULD NOT make any assumptions about the locationin a domain name where internationalization might appear.  In otherwords, it SHOULD NOT differentiate between any part of a domain namebecause this MAY impose restrictions on future internationalizationefforts.  For example, the TLDs can be internationalized.[17] The protocol also SHOULD NOT make any localized restrictions in theprotocol. For example, an IDN implementation which only allows domainnames to use a single local script would immediately restrictmultinational organization.[18] While there are a wide range of devices that use the DNS and a widerange of characteristics of international scripts and methods ofdomain name input and display, IDN is only concerned with theprotocol. Therefore, there MUST be a single way of encoding aninternationalized domain name within the DNS.2.4 CanonicalizationMatching rules are a complicated process for IDN. Canonicalizationof characters MUST follow precise and predictable rules to ensureconsistency. [CHARREQ] is RECOMMENDED as a guide on canonicalization.The DNS has to match a host name in a request with a host name heldin one or more zones. It also needs to sort names into order. It isexpected that some sort of canonicalization algorithm will be used asthe first step of this process. This section discusses some of theproperties which will be REQUIRED of that algorithm.[19] To achieve interoperability, canonicalization MUST be done at asingle well-defined place in the DNS resolution process.  The protocolMUST specify canonicalization; it MUST specify exactly where in theDNS that canonicalization happens and does not happen; it MUST specifyhow additions to ISO 10646 will affect the stability of the DNS andthe amount of work done on the root DNS servers.[20] The canonicalization algorithm MAY specify operations for case,ligature, and punctuation folding.[21] 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 ofthe issues with case mapping. Case-insensitivity for non [US-ASCII]MUST be discussed in the protocol proposal.[22] Case folding MUST be locale independent. If it werelocale-dependent, then different clients would get different results.For example, Latin capital letter I (U+0049) case folded to lower casein the Turkish context will become Latin small letter dotless i(U+0131). But in the English context, it will become Latin smallletter i (U+0069).[23] If other canonicalization is done, it MUST be done before thedomain name is resolved. Further, the canonicalization MUST be easilyupgradable as new languages and writing systems are added.[24] Any conversion (case, ligature folding, punctuation folding, etc)from what the user enters into a client to what the client asks forresolution MUST be done identically on any request from any client.[25] If the charset can be normalized, then it SHOULD be normalizedbefore it is used in IDN. Normalization SHOULD follow [UTR15].[26] The protocol SHOULD avoid inventing a new normalization formprovided a technically sufficient one is available.2.5 Operational Issues[27] Zone files SHOULD remain easily editable.[28] An IDN-capable resolver or server SHALL NOT generate more trafficthan a non-IDN-capable resolver or server would when resolving anASCII-only domain name.  The amount of traffic generated when resolvingan IDN SHALL be similar to that generated when resolving an ASCII-onlyname.[29] The service SHOULD NOT add new centralized administration for theDNS. A domain administrator SHOULD be able to create internationalizednames as easily as adding current domain names.[30] Within a single zone, the zone manager MUST be able to defineequivalence rules that suit the purpose of the zone, such as, but notlimited to, and not necessarily, non-ASCII case folding, Unicodenormalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, ortraditional/simplified Chinese equivalence. Such defined equivalencesMUST NOT remove equivalences that are assumed by (old orlocal-rule-ignorant) caches.[31] The protocol MUST work with DNSSEC.  The protocol MAY breaklanguage sort order.  3. Security ConsiderationsAny solution that meets the requirements in this document MUST NOT beless secure than the current DNS. Specifically, the mapping ofinternationalized host names to and from IP addresses MUST have thesame characteristics as the mapping of today's host names.Specifying requirements for internationalized domain names does notitself raise any new security issues. However, any change to the DNS MAYaffect the security of any protocol that relies on the DNS or onDNS names. A thorough evaluation of those protocols for securityconcerns will be needed when they are developed. In particular, IDNsMUST be compatible with DNSSEC and, if multiple charsets orrepresentation forms are permitted, the implications of this name-spoofMUST be throughly understood.4. 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@ops.ietf.org, Olafur Gudmundson, Randy Bush.[RFC952]    "DoD Internet Host Table Specification", rfc952.txt,             October 1985, K. Harrenstien, M.K. Stahl, E.J. Feinler. [RFC1034]   "Domain Names - Concepts and Facilities", rfc1034.txt,            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.[ISO10646]  ISO/IEC 10646-1:2000 (note that an amendment 1 is in            preparation), ISO/IEC 10646-2 (in preparation), plus            corrigenda and amendments to these standards.[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            Information Interchange, ANSI X3.4-1986; also: ISO/IEC            646 (IRV).[UAX15]     "Unicode Normalization Forms", Unicode Standard Annex #15,            http://www.unicode.org/unicode/reports/tr15/, 2000-08-31,            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,            http://www.unicode.org/unicode/reports/tr21/, 2000-09-12,            M. Davis, Unicode Consortium.5. Editors' ContactZita Wenzel, Ph.D.Information Sciences InstituteUniversity of Southern California4676 Admiralty WayMarina del Rey, CA90292  USATel: +1 310 448 8462Fax: +1 310 823 6714zita@isi.eduJames Sengi-DNS.net International Pte Ltd.8 Temesek Boulevand#24-02 Suntec Tower 3Singapore 038988Tel: +65 248 6208Fax: +65 248 6198Email: jseng@pobox.org.sg6. AcknowledgementsThe 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>Marc Blanchet <blanchet@mailviagenie.qc.ca>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>Kent Karlsson <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>Yoshiro Yoneda <<yone@nic.ad.jp>