Internet Draft Dan Oscarsson draft-ietf-idn-udns-00.txt Telia ProSoft Updates: RFC 2181, 1035, 1034, 2535 9 July 2000 Expires: 9 January 2001 Using the Universal Character Set in the Domain Name System (UDNS) 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 Since the Domain Name System (DNS) [RFC1035] was created there have been a desire to use other characters than ASCII in domain names. Lately this desire have grown very strong and several groups have started to experiment with non-ASCII names. By using the Universal Character Set (UCS) [ISO10646] this document updates the Domain Name System so that non-ASCII domain names can be used while still being compatible with the current (RFC 1035) DNS. 1. Introduction While the need for non-ASCII domain names have existed since the creation of the DNS, the need have increased very much during the last few years. Currently there are at least two implementations using UTF-8 in use, and others using other methods. Dan Oscarsson Expires: 9 January 2001 [Page 1] Internet Draft Universal DNS 9 July 2000 To avoid several different implementations of non-ASCII names in DNS that do not work together, and to avoid breaking the current ASCII only DNS, there is an immediate need to standardise how DNS shall handle non-ASCII names. The basic handling of character data in DNS have several properties that need to be preserved: - The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). [RFC2181] - Any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. [RFC2181] - Names must be compared with case-insensitivity. [RFC1035] - The original case should be preserved when possible as data is entered into the system. This also implies that responses should preserve case when possible. [RFC1035] Some of the reasons for this are: + Domain names are used for many purposes. + One is domain names where company names or trademarks could be used. Very commonly companies and trademarks are using a combination of upper and lower case to enhance the image of the name. Many of them would prefer that when you, for example, lookup the domain name for an IP address, the correct case is returned. + An other is the e-mail address defined in the SOA record. While many systems now does a case-insensitive comparison on the user name part of the e-mail address, there may still be those that don't. And also here, e-mail addresses can be made more readable by mixing upper and lower case. + If you look up a host name form an IP address you may want to use the host name to compare with other data. Many services under Unix does this, and many of the are not case- insensitive. So they need the correct case returned. + There may be other uses of domain names that requires them to be unchanged. - The characters in the ASCII character set should still be encoded as ASCII. Dan Oscarsson Expires: 9 January 2001 [Page 2] Internet Draft Universal DNS 9 July 2000 This document specifies the update needed of the DNS protocol, user interface issues and the effect of other protocols. It is intended to full fill the requirements of internationalised domain names which currently worked on by the IDN working group [IDNREQ]. 1.1 Terminology 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]. IDN: Internationalised Domain Name, here used to mean a domain name containing non-ASCII characters. ACE: ASCII Compatible Encoding. Used to encode IDNs in a way compatible with the ASCII host name syntax. 1.2 Previous versions of this document The first version of this document was available as draft-oscarsson- i18ndns-00.txt. 2. The DNS Protocol The DNS protocol is used when communicating between DNS servers and other DNS servers or DNS clients. User interface issues like the format of zone files or how to enter or display domain names are not part of the protocol. The update of the protocol defined here can be used immediately as it is fully compatible with the DNS of today. As at this stage not all requirements are completed and many ideas for handling IDNs are being discussed, this version of the draft includes several alternatives to some of the aspects of the DNS internationalisation, with comments to help in the discussions. Using an alternative may result in not being able to use IDNs immediately as it may require all DNS servers taking part in a query to be updated first. The goal of this update in the DNS protocol is to add IDN handling with as little disruption as possible to software unaware of domain names with non-ASCII characters in them. To be able to do this it is necessary for the DNS servers to be able to identify if it is talking to software knowing about IDNs or not. And if the software does not understand IDNs, the DNS server must use an ASCII Compatible Encoding (ACE) of IDNs in the communication to avoid disruption the software. Dan Oscarsson Expires: 9 January 2001 [Page 3] Internet Draft Universal DNS 9 July 2000 ACE will be further discussed later. 2.1 Internationalisation aware software (IDN aware) Internationalisation aware DNS software (IDN aware) is software that handles the rules for handling international text as defined here. Only IDN aware software will get all requirements fulfilled. For a DNS server to know if it is talking to IDN aware software, DNS awareness must be signalled in some way that is compatible with the current non-IDN aware software (following [RFC1035]). 2.1.1 The IN bit Referring to section 4.1.1 in [RFC1035] and section 6.1 in [RFC2535] the the DNS query/response format header is updated by allocation the last un-allocated bit in the header. This bit is defined to be zero in old servers and resolvers. For description of all field see the sections in the above RFCs. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA|IN|AD|CD| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ IDN aware software identifies itself in a query or a response by setting the IN bit in the DNS query/response format header. As this bit is defined to be zero in old servers and resolvers they identify themselves as non-IDN aware. IDN aware software MUST set the IN bit in both queries and responses. Currently there is no need for a client to know that the DNS server knows about IDNs, but by always setting the IN bit in responses will allow clients to use this information if need arises in the future. 2.1.2 Alternatives Dan Oscarsson Expires: 9 January 2001 [Page 4] Internet Draft Universal DNS 9 July 2000 While the IN bit used above is the cleanest way, it is also the last free bit available in the DNS header since DNSSEC reserved the other two free ones. To avoid using the last free bit here are some alternative ways. Note: These alternatives are here to help show why the above IN bit is the best choice and to help discussions about how to do it. 2.1.2.1 Using the RA, AA or TC bit Use one of the bits that only have a meaning in a response as defined by RFC 1035: the RA, AA or TC bit. One of these bits could be defined to be a IN bit in queries and the old meaning in responses. Non-IDN DNS servers following RFC 1035 can be expected to ignore these bits in queries. Some of the drawbacks are: - Some old software may not zero the value of the bits in queries and will therefore look as if they are IDN aware. - The bit cannot be used in a response to inform the client that the server is IDN aware. - Not recommended by [IANADNS]. 2.1.2.2 Using the RCODE bits Use the bits of the RCODE value. It is defined by RFC 1035 to be used in responses. One of these bits could be defined to be a IN bit in queries or a value for all bits could be used, and the old meaning in responses. Non-IDN DNS servers following RFC 1035 can be expected to ignore these bits in queries. Some of the drawbacks are: - Their value are not defined in queries by RFC 1035. Most software could be expected to send them as zero as most zero the entire header before setting the values needed for the query. Instead of using just a bit one could use all bits. Using a value of all ones (all bits set to 1) would probably be a good flag even if old software fills it with random bits. - The bits cannot be used in a response to inform the client that the server is IDN aware. 2.1.2.3 Using the upper 8 bits of QTYPE The QTYPE is 16 bits but currently are codes above 255 not used. It would therefore be possible to use one of the upper 8 bits as an IN bit. Some of the drawbacks are: - Using an upper bit results in a a new value for the QTYPE. Software following RFC 1035 will see this as an unknown QTYPE and return an error response, forcing a new query using the QTYPE without the bit set. This will result in a overhead because of the Dan Oscarsson Expires: 9 January 2001 [Page 5] Internet Draft Universal DNS 9 July 2000 extra query/response that have to be done for all non-IDN aware servers and will make IDN queries slower and increase the DNS traffic. It will go away when all DNS servers is IDN aware, but that is many years in the future. 2.1.2.5 Using EDNS Using EDNS [RFC2671] additional information could be sent in the additional section of a query or response. The IN bit could then be sent in an OPT RR record. An example of doing it this way can be found in [IDNE]. Some of the drawbacks are: - As most software today do not implement EDNS and return an error response, forcing a new query to be sent without EDNS. This will result in a overhead because of the extra query/response that have to be done for all non-IDN aware servers and will make IDN queries slower and increase the DNS traffic. It will go away when all DNS servers is EDNS aware, but that is many years in the future. - Even a query for an ASCII only domain name will have the query overhead described above. The OPT RR will have to be sent here also, otherwise the server cannot know if the client can handle IDNs in the response. 2.2 Character data Character data need to be able to represent as much as possible of the characters in the world as well as being compatible with ASCII. It must also be well defined so that it can easily be handled and should be compact as only 63 octets is available without an extension of the protocol. 2.2.1 Native format of character data in the DNS protocol Character data used in the DNS protocol MUST, unless it is sent as an ACE to non-IDN aware software, use: - Use ISO 10646 (UCS) [ISO10646] as coded character set. - Be normalised using form C as defined in Unicode technical report #15 [UTR15]. See also [CHNORM]. - Encoded using the UTF-8 [RFC2279] character encoding scheme. In responses to non-IDN aware software, IDNs MUST be encoded using ACE. As all data is required to be normalised before sent using the DNS protocol, a DNS server do not need to normalise any data coming in through a request. But it MUST normalise data loaded from a zone file. Dan Oscarsson Expires: 9 January 2001 [Page 6] Internet Draft Universal DNS 9 July 2000 2.2.1.1 Alternative native formats Here are some alternative possibilities to the native format defined above and comments of why they were not selected, to help in discussions. See [IDNCOMP] for more examples. 2.2.1.1.1 Using other normalisation formats The Unicode normalisation form C does not remove any information in the character data while making it as compact as possible and have a well defined order of combining characters. One could use form KC or some other normalisation format that removes all forms that are not significant when testing for domain name equivalence, but that would remove a lot of information that is important in printing or displaying them. It would be like replacing all upper case letters in ASCII names with the lower case version. As normalisation form C is both compact and does not destroy any information it is also well suited to be the standard format to be used in all protocols using UCS. It is the one recommended by W3C. Software can be reused if all protocols use the same normalisation form. 2.2.1.1.2 Using other encoding schemes than UTF-8 While using another coded character set than UCS is possible, allowing only one simplifies software very much and reduces the possibility of incompatibilities. But using UTF-8 is not that compact for several languages. For some a single row of UCS is enough and for some 16-bit values is best. The native format could easily include a tag byte first defining subset/encoding of UCS allowing ISO 8859-1, UTF-8, UCS-2 or UTF-16 to be used. This would allow more compact format and therefore more characters into the 63 byte limit of a label, for some names. It would not make software much more complex as the coded character set is still the same. But unless the length limits are unacceptable or cannot be overridden is an easy way, having just one scheme is easiest. 2.2.1.2 Handling length limits The current DNS protocol limits a label to 63 octets. As IDNs take more than one octet for some characters, an IDN cannot have 63 characters in a label like an ASCII name can. For example a name using Hangul would have a maximum of 21 characters when encoded using UTF-8. There is currently no requirement on minimum length that is required in IDNs, but even if the need does not appear immediately it Dan Oscarsson Expires: 9 January 2001 [Page 7] Internet Draft Universal DNS 9 July 2000 will come. The limits imposed by RFC 1035 is 63 octets per label and 255 octets for the full name. The 255 limit is not a protocol limit but one to simplify implementations. When longer limits are allowed for IDNs, we still need to set a limit to simplify implementations. By following the limits defined in RFC 1035 the limits for IDNs (and ASCII only names) is defined as: A label is limited to a maximum of 63 character code points in UCS normalised using Unicode form C. The full name is limited to a maximum of 255 character code points normalised as for a label. Longer labels in DNS are supported as follows: 2.2.1.2.1 EDNS long label An extended label type is defined that allows as a minimum 255 octets per label. It can be defined as in [IDNE]. Even though a label now can have 255 octets, an ASCII only name by still only have 63 characters in it. All IDN aware software MUST implement the ENDS long label. As EDNS is not understood by older software, a query with an EDNS long label will fail and can only be returned in a response to an IDN aware client. It is recommended that only IDNs that fits into the 63 octets in the standard label are used until enough DNS software have been upgraded to avoid a lot of overhead in queries. 2.2.1.2.1 Alternative: encoded long label As an alternative to EDNS, it is possible to split a long label into several parts and encode it into several labels. It could be done like this: ..com. Where the octet indicates that part1 and part2 shall be joined together. This can be done inside the client (resolver) software and in the DNS server so that application software and the user will not be aware of it happening. While this solution can work through non-IDN aware software it is less clean than the EDNS solution. And there are always the possibility that some software assumes that part1 is a host name. 2.2.2 ASCII Compatible Encoding Dan Oscarsson Expires: 9 January 2001 [Page 8] Internet Draft Universal DNS 9 July 2000 When responding to non-IDN aware software (for example most current DNS software and current SMTP implementations) there is a need for a transition mechanism to support them. As a lot of software and protocols assume only the ASCII letters, digits and hyphen in each label, the transition mechanism should use an ASCII Compatible Encoding (ACE) to encode the IDNs. This ACE can then be used by DNS and other protocols when communicating with non-IDN aware software. The selected ACE will be defined in a separate document, but some of the basic ways to do it, is as follows: - Tag labels that are ACE names with a prefix or suffix. This would give names like: abcd.ra--XXXXX.com or abcd.XXXXX-.com where the XXXXX is the ACE name and the leading "ra--" or trailing "-" is the tag. Using this technique some labels may be using ACE and some not. One difficulty here is to have a tag that will never occur in a normal domain name. Labels longer than 63 octets could be split like this: abcd.ra--XXXXXZ.Zra--YYYY.com where during decoding the parts XXXXX and YYYY will be joined to form one label. This technique can probably mess up some programs that assume that a dot separates each label. - Use a special TLD. Here names would look like: XXXXX.YYYY.ACE where XXXXX.YYYY is the encoded name. Here we do not have the problem of selecting a tag that is unique as the TLD will be unique. - Using label aliases (not really an ACE). One could use a user defined or automatically generated aliases to labels that are returned to non-IDN aware software. This way labels could be made meaningful. One problem with this is to convert from the IDN to the ACE, you need access the DNS to lookup the alias. This may be difficult for some protocols that have no access to the DNS at the moment the conversion must be done. Dan Oscarsson Expires: 9 January 2001 [Page 9] Internet Draft Universal DNS 9 July 2000 2.3 Domain name matching One of the most difficult areas of making DNS universal is what names are equivalent to an other. For ASCII this was easily solved by case-insensitivity. It is also easily solved for many other Latin based alphabets. But when you look at the whole world you get a mixture of rules, some conflicting, including case-insensitivity, half width/full width, final/non-final forms and much more. This type of matching will be called "equivalence matching" here after 2.3.1 Equivalence matching rules To compare two domain names, both names must first be mapped to a format where all equivalent characters are mapped to one character so that the names then can be binary compared. This mapping is done from the native UCS normalised form C format as follows: 1) Fold case to lower case. 2) Do additional simplification. 3) Normalise to Unicode form C again. For the UCS character code range 0-255 (ASCII and ISO 8859-1) the case folding MUST be done by following the one to one mapping as defined in the Unicode 3.0 Character Database [UDATA]. Case folding and simplification for the rest of UCS will be defined in a separate document. 2.3.2 Matching of domain names in DNS servers To be able to handle correct domain name matching in lookups, the following MUST be followed by DNS servers: - Do matching on authorative data using the full name equivalence matching needed for the characters used in the data. - On non-authorative data, either do binary matching or case- insensitive matching on ASCII letters and binary matching on all others. - Implement the equivalence matching rules as defined above. Local variations are not allowed. The effect of the above is: - only servers handling authorative data must implement equivalence matching of names. And they need only implement the subset needed for the subset of characters of UCS they support in its authorative zones. Dan Oscarsson Expires: 9 January 2001 [Page 10] Internet Draft Universal DNS 9 July 2000 - it normally gives fast lookup because data is usually sent like: resolver <-> server <-> authorative server. While full equivalence matching can be complex and CPU consuming, the server in the middle will do caching with only simple and fast binary matching. So the impact of complex matching rules should not slow down DNS very much. 2.4 Inter operability between IDN aware DNS software and non-IDN aware While the current non-IDN aware DNS software MUST allow UTF-8 encoded domain names (if they follow RFC1035, 2181) a lot of software using DNS may not (for example SMTP). To not break all the old software only expecting or allowing ASCII in domain names, the following rules MUST be followed by an IDN aware DNS server: - A query with the IN bit set is assumed to be from IDN aware software. - A query with domain names having valid non-ASCII UTF-8 characters is assumed to be from IDN aware software even if the IN bit is not set. (this is because the query can have been sent from an IDN aware resolver through a non-IDN aware server). - Always encode using ACE the UTF-8 names into ASCII before sending it when responding to non-IDN aware software. - Never have ACE names in the response when responding to IDN aware software. - Always check for ACE names in requests. - Not do zone transfers to non-IDN aware software, if the zone contains non-ASCII. - Return the server failed error if a label cannot be encoded into ACE and fit in the 63 octets allowed. An IDN aware DNS resolver MUST: - Decode any ACE names before sending them using the DNS protocol. - Decode any ACE names received in a response. The result of this is: - Old software gets an ASCII only domain name using only the old set of allowed characters. - Both IDN aware DNS servers and resolver software must handle up coding of domain names. - Domain names used from old software will work in other protocols only allowing ASCII names. - We may get old software that is never fixed as it still works. - We do not get rid of this user unfriendly, encode everything in ASCII handling that many non-ASCII users complain about. Note: As a non-IDN aware DNS server only understands matching using ASCII case-insensitivity, it may cache IDN responses as different Dan Oscarsson Expires: 9 January 2001 [Page 11] Internet Draft Universal DNS 9 July 2000 even though the are IDN equivalent. This will result in more data cached but not give invalid responses. 2.4 DNSSEC DNSSEC [RFC2535] is complex and not yet fully studied. Especially the canonical DNS name order and signing of RRsets. The canonical DNS name order sorts names with letters as lower case. In IDN this means to fold to lower case, normalise and simplify as is done in lookups. This would mean that only a DNS server knowing the full equivalence rules could do the sorting. It would be better if this was not needed. Signing of RRsets is done on the canonical RR form. RFC 2535 is somewhat unclear if domain names inside the RDATA should be lower cased. If not, so that original format of RDATA is preserved, signing should be no problem in IDN aware DNS software. The full handling of DNSSEC and IDN data may have to be described in a separate document. 3. Characters allowed in domain names The DNS protocol do not place any restriction on characters used in a domain name. However applications that make use of DNS data may have restrictions imposed on what particular values are acceptable in their environment. If the client has such restrictions, it is solely responsible for validating the data from the DNS to ensure that it conforms before it makes any use of that data. [RFC2181] For example domains, hosts and e-mail addresses are represented in DNS and may have different rules. As the whole idea of making DNS universal is to get domain names with non-ASCII, the original recommendation in DNS [RFC1035] for host/domain names needs to be updated. But, the DNS may not itself place any restriction on the characters allowed in a domain name. Domain names are used for more than hosts and e-mail domains. It is recommended that domains, hosts and e-mail addresses all are extended to allow all letters, digits and some separators of UCS. This have to be defined in an other document. A beginning to this is available in [NAMEPREP]. Dan Oscarsson Expires: 9 January 2001 [Page 12] Internet Draft Universal DNS 9 July 2000 4. User interface issues Locally on a system or in a user interface a different character set than the one defined to be used in the DNS protocol may be used. Therefore software must map between the local character set and the character set of the protocol, so that human beings can understand it. This means that a zone file that is edited in a text editor by a person before being loaded into a DNS server must be allowed to be in the local character set. Software may not assume that the user can edit text encoded in UTF-8. A zone file transmitted between DNS software that is not handled by a human, can be transmitted using any format. When character data is presented to a human or entered by a human, software must, as good as possible, present it using local character set and allow it to be entered using the local character set. It is the responsibility of the software to convert between the local character set and the one used in the protocol, not the human. The down coding defined above allows all names to be entered and displayed for all users, as long as at least the ASCII characters are supported. 4.1 Applications using DNS software If an application does a call to DNS, it must present the data to the users in the local character set used by the user, down coding if necessary. Software used to access DNS should give the application programmer both the possibility of doing queries and getting responses using local character set, and using UTF-8. APIs like getipnodebyname should be updated with a IDN flag that results in the name being returned using the current locale, instead of native UTF-8 or ASCII format. 5. Effect on other protocols As now a domain name may include non-ASCII many other protocols that include domain names need to be updated. For example SMTP, HTTP and URIs. The ACE format can be used when interfacing with ASCII only software or protocols. Protocols like SMTP could be extended using ESMTP and a UTF8 option that defines that all headers are in UTF-8. It is recommended that protocols updated to handle i18n do this by encoding character data in the same standard format as defined for DNS in this document (UCS normalised form C). The use of encoding it Dan Oscarsson Expires: 9 January 2001 [Page 13] Internet Draft Universal DNS 9 July 2000 in ASCII or by tagged character sets should be avoided. DNS do not only have domain names in them, for example e-mail addresses are also included. So an e-mail address would be expected to be changed to include non-ASCII both before and after the @-sign. Software need to be updated to follow the user interface recommendations given above, so that a human will see the characters in their local character set, if possible. 5.1 An example: SMTP When using SMTP it may be extended to allow UTF-8 in headers and addresses. It will then have to, when transferring an e-mail to a SMTP system that have not been extended, encoded e-mail addresses and IDNs into an ACE. In this case an e-mail address could look like: ra--XXXXX.surname@ra--YYYYY.com where ra--XXXXX is the ACE of the given name and ra--YYYYY is the ACE of one part of the domain name. 6. Security Considerations As always with data, if software does not check for data that can be a problem, security may be affected. As more characters than ASCII is allowed, software only expecting ASCII and with no checks may now get security problems. 7. References [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate Requirement Levels", March 1997, RFC 2119. [RFC2181] R. Elz and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2535] D. Eastlake, "Domain Name System Security Extensions". RFC 2535, March 1999. Dan Oscarsson Expires: 9 January 2001 [Page 14] Internet Draft Universal DNS 9 July 2000 [RFC2671] P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [ISO10646] ISO/IEC 10646-1:2000. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) [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 [UTR15] M. Davis and M. Duerst, "Unicode Normalization Forms", Unicode Technical Report #15, Nov 1999, http://www.unicode.org/unicode/reports/tr15/. [UTR21] M. Davis, "Case Mappings", Unicode Technical Report #21, Dec 1999, http://www.unicode.org/unicode/reports/tr21/. [UDATA] The Unicode Character Database, ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt. The database is described in ftp://ftp.unicode.org/Public/UNIDATA/ UnicodeCharacterDatabase.html. [IDNREQ] James Seng, "Requirements of Internationalized Domain Names", draft-ietf-idn-requirement. [IANADNS] Donald Eastlake, Eric Brunner, Bill Manning, "Domain Name System (DNS) IANA Considerations",draft-ietf-dnsext-iana-dns. [IDNE] Marc Blanchet,Paul Hoffman, "Internationalized domain names using EDNS (IDNE)", draft-ietf-idn-idne. [CHNORM] M. Duerst, M. Davis, "Character Normalization in IETF Protocols", draft-duerst-i18n-norm. [IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals", draft-ietf-idn-compare. [NAMEPREP] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals", draft-ietf-idn-compare. 8. Acknowledgements Paul Hoffman giving many comments in our e-mail discussions. Ideas from drafts by Paul Hoffman, Stuart Kwan, James Gilroy and Kent Dan Oscarsson Expires: 9 January 2001 [Page 15] Internet Draft Universal DNS 9 July 2000 Karlsson. Magnus Gustavsson, Mark Davis, Kent Karlsson and Andrew Draper for comments on my draft. Discussions and comments by the members of the IDN working group. Author's Address Dan Oscarsson Telia ProSoft AB Box 85 201 20 Malmo Sweden E-mail: Dan.Oscarsson@trab.se Dan Oscarsson Expires: 9 January 2001 [Page 16]