draft-ietf-idn-iptr-00.txt   draft-ietf-idn-iptr-01.txt 
INTERNET-DRAFT Hongbo Shi INTERNET-DRAFT Hongbo Shi
draft-ietf-idn-iptr-00.txt Waseda University draft-ietf-idn-iptr-01.txt Waseda University
Jiang Ming Liang 17 November 2000 Jiang Ming Liang
i-DNS.net Expires: 17 May 2001 i-DNS.net
Internationalized PTR Resource Record (IPTR) Internationalized PTR Resource Record (IPTR)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 32
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This draft attempts to address the problem of how an IP address should This draft attempts to address the problem of how an IP address SHOULD
be properly mapped to a set of internationalized domain names(iDNs). be properly mapped to a set of Internationalized Domain Names(IDNs).
It is currently unspecified how a PTR record can be used for this It is currently unspecified how a PTR record can be used for this
purpose. In addition, the syntax of the PTR resource record may be purpose. In addition, the syntax of the PTR resource record may be
too restrictive for such a mapping in a more culturally meaningful too restrictive for such a mapping in a more culturally meaningful
context. This document suggests a new TYPE called IPTR using EDNS0 context. This document suggests a new TYPE called IPTR using EDNS0
and a mechanism to combind language information with such a mapping. and a mechanism to combined language information with such a mapping.
1. Introduction 1. Introduction
Reverse mapping is a very important and essential function in the DNS. Reverse mapping is a very important and essential function in the DNS.
In today's Domain Name System, PTR RRs are used to support address-to- In today's Domain Name System, PTR RRs are used to support address-
domain mappings. However, a current PTR RR does not provide support to-domain mappings. However, a current PTR RR does not provide support
for proper address-to-iDN mappings, without certain modifications. for proper address-to-IDN mappings, without certain modifications.
Modifying the PTR structure will also affect the current reverse Modifying the PTR structure will also affect the current reverse
mapping architecture. This document describes a new RR TYPE named mapping architecture. This document describes a new RR TYPE named IPTR
IPTR to provide address-to-iDN mappings and it also specifies that on to provide address-to-IDN mappings and it also specifies that on
receiving of a IPTR query a name server should respond with all the receiving of a IPTR query a name server should respond with all the
corresponding IPTR RRs in one response. This document also specifies corresponding IPTR RRs in one response. In short, "one IP several
that an IPTR RR SHOULD refer to one primary iDN per language only. IDNs".
1.1 Terminology 1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in RFC and "MAY" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
1.2 Background and Designs 1.2 Background and Designs
When Internationalized Domain Names come into wide use, an Internet When Internationalized Domain Names come into wide use, an Internet
host is likely to have domain names in different languages. In host is likely to have domain names in different languages. In
today's Internet, because of the design of the PTR record and today's Internet, even thought the [RFC2181] redefine the
implementation of most resolvers, IP address to domain names mapping consideration of PTR, because of the design of the PTR mapping
is limited to "one IP one domain name", the primary domain name of the algorithm and implementation of most resolvers, IP address to domain
host. This is more restrictive in a world of iDNs, for choosing one names mapping is still limited to "one IP one domain name".
name in one particular language as the primary could have cultural
implications. The authors also believe that putting language For example, BIND treats PTRs specially so that the normal sorting
information into address-to-name mappings will be benifitial to future preference (e.g. cyclic/random) doesn't apply. But as usual, "fixed"
applications. order is always used. So a client that is querying a BIND server and
doesn't look beyond the first PTR RR, no matter how many times it
queries the name. In other words, PTR RRset is different from A RRset,
where the first record in the RRset might differ from query to query.
This is more restrictive in a world of IDNs, for choosing some names
in a particular language. Briefly, according to the use of PTR, it is
no meaning of returning an IDN in an unknown language.
The authors also believe that putting language information into
address-to-name mappings will be benifitial to future applications.
The design purpose of the IPTR RR type is to provide a mechanism that The design purpose of the IPTR RR type is to provide a mechanism that
can map an IP address to all of the corresponding iDNs per language. can map an IP address to the corresponding IDN per language. It also
means that IPTR suggests a new mapping algorithm for the reverse
mapping by using an language information.
CNAME MUST continue to work for IPTR as it works now for PTR records. CNAME MUST continue to work for IPTR as it works now for PTR records.
An IPTR RR SHOULD be limited to one primary iDN per language.
The behavior of a resolver on the use of IPTR will be specified in a The behavior of a resolver on the use of IPTR will be specified in a
seperate draft or a later version of this draft. seperate draft or a later version of this draft.
1.3 Functional Description 1.3 Functional Description
DNS query and responses involving IPTR type MUST have the following DNS query and responses involving IPTR type MUST have the following
properties: properties:
- When the QTYPE is IPTR, the corresponding iDNs SHOULD be returned - When the QTYPE is IPTR, the corresponding IDNs SHOULD be
in one response. returned in one response.
- The characters in the label MUST be encoded using UTF-8 - The characters in the label MUST be encoded using UTF-8
[RFC2279]. [RFC2279].
- The entire label MUST be encoded EDNS [RFC2671]. - The entire label MUST be encoded EDNS [RFC2671].
- An exceptional handling of PTR for the IDN is REQUIRED.
2. IPTR definition 2. IPTR definition
The structure of an IPTR RR is somewhat like the MX RR. :) In addtion The structure of an IPTR RR is somewhat like the MX RR. In addtion to
to the IP address in the IN-ADDR.ARPA domain and the domain name field the IP address in the IN-ADDR.ARPA domain and the domain name field
(similar to a PTR RR), a new field called LANGUAGE has been defined. (similar to a PTR RR), a new field called LANGUAGE has been defined.
A domain name in an IPTR RR MUST be encoded in UTF8. Below is an A domain name in an IPTR RR MUST be encoded in UTF8. And IDN in this
example of an IPTR RR: document MUST be NAMEPREPPED. [NAMEPREP] Below is an example of an
IPTR RR:
1.2.3.4.IN-ADDR.ARPA. IPTR "language" "name-in-utf8" 1.2.3.4.IN-ADDR.ARPA. IPTR "LANGUAGE" "name-in-utf8"
[RFC1766] describes the ISO 639/ISO 3166 conventions. A language name [RFC1766] describes the ISO 639/ISO 3166 conventions. A language name
is always written in lower case, while country codes are written in is always written in lower case, while country codes are written in
upper case. The "language" field in an IPTR RR MUST follow the con- upper case. At here, the "LANGUAGE" field in an IPTR RR SHOULD be done
ventions defined in [RFC1766]. in a case-insensitive manner and MUST follow the conventions defined
in [RFC1766].
For Example: For Example:
4.3.2.1.IN-ADDR.ARPA. IPTR "zh-cn" "name-in-utf8" 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name-in-utf8"
4.3.2.1.IN-ADDR.ARPA. IPTR "zh-tw" "name-in-utf8" 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name-in-utf8"
4.3.2.1.IN-ADDR.ARPA. IPTR "ja-jp" "name-in-utf8" 4.3.2.1.IN-ADDR.ARPA. IPTR "ja-JP" "name-in-utf8"
4.3.2.1.IN-ADDR.ARPA. IPTR "ko-kr" "name-in-utf8" 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name-in-utf8"
The notion of canonical names and aliases described in 3.6.2 [RFC1034] The notion of canonical names and aliases described in 3.6.2
must be preserved for IPTR record types. An IPTR RR SHOULD be limited [RFC1034], and 10.2 [RFC2181] MUST be preserved for IPTR record types.
to one primary iDN per language, similar to the a PTR RR. An IPTR RR SHOULD be limited to one primary IDN per LANGUAGE, similar
to the a PTR RR.
3. IPTR on IPv6 3. IPTR on IPv6
Mapping IPv6 to IDNs can be similarly supported. This document recom-
Mapping IPv6 to iDNs can be similarly supported. This document recom-
mands to continue using the IP6.INT domain defined in [RFC1886] for mands to continue using the IP6.INT domain defined in [RFC1886] for
IPTR mappings. For example, the lookup corresponding to the address IPTR mappings. For example, the lookup corresponding to the address
4321:0:1:2:3:4:567:89ab would be: 4321:0:1:2:3:4:567:89ab would be:
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
IPTR "language" "name-in-utf8" IPTR "LANGUAGE" "name-in-utf8"
4. Packet format for IPTR 4. Packet format for IPTR
EDNS0[RFC2671] is REQUIRED to implement IPTR. EDNS0[RFC2671] is REQUIRED to implement IPTR.
0 1 2 3 4 0 1 2 3 4
bits 0 1 2 3 4 5 6 7 8 9 0 1...9 0...8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 ... bits 0 1 2 3 4 5 6 7 8 9 0 1...9 0...8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 ...
+-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+ +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+
|0 1| ELT | LANGUAGE | Size | IDN label... | |0 1| ELT | LANGUAGE | Size | IDN label... |
+-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+ +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+
LANGUAGE: An argument for IPTR to define the kind of languages LANGUAGE: An argument for IPTR to define the kind of language
used in the following IDN label. The size is 2 octets. used in the following IDN label. The size is 2 octets.
ELT: To be defined. ELT: To be defined in [IDNE].
5. IPTR query/response 5. Coexistence
5.1 IDN Consideration
IPTR described above is based on "a set of IDNs", strictly speaking, a
set of canonical IDNs. On the other hand, confusion about IDN, such as
"IDN MUST exist with ASCII domain name" has led to a belief that PTR
record should have exactly RRs in its RRSet. In short, the phenomenon
"IDN ONLY" will exist. Thus, the exceptional handling of PTR is
REQUIRED.
On the other hand, IDN is still RECOMMENDED to exist with more than
one ASCII domain name.
5.2 PTR Extension
In the case of "IDN ONLY", if IPTR RR is not NULL, PTR RR MUST contain
a domain name in ACE to coexist with those IDN unaware systems. Else a
"Syntax Error" message SHOULD be sent back, when an administrator con-
figures DNS zone files.
5.3 IPTR and PTR
It is a kind of backward compatible handle for those IDN unaware sys-
tems that can not provide the IPTR function. Besides, if a client can
not find the corresponding LANGUAGE IDN finally, then the correspond-
ing PTR RR SHOULD be used as the answer.
6. IPTR query/response
When the QTYPE is IPTR in a query, all of the corresponding IPTR RRs When the QTYPE is IPTR in a query, all of the corresponding IPTR RRs
SHOULD be returned in one response. DNS messages are limited to 512 SHOULD be returned in one response. DNS messages are limited to 512
octets or less in size when sent over UDP. Therefore, if all the RRs octets or less in size when sent over UDP. Therefore, if all the RRs
cannot fit in one UDP packet, this draft describe two solutions. One cannot fit in one UDP packet, this draft describe two solutions. One
is for recent environment and the other is for the near future. is for recent environment and the other is for the near future.
5.1 Transport 6.1 Transport
Today, DNS queries and responses are carried in UDP datagrams or over Today, DNS queries and responses are carried in UDP datagrams or over
TCP connections.[RFC1034] specifies, IPTR RRSet is RECOMMENDED to be TCP connections.[RFC1034] specifies, IPTR RRSet is RECOMMENDED to be
returned in one response. The size of a DNS message could exceed 512 returned in one response. The size of a DNS message could exceed 512
octets, when multiple RRs are present. Therefore, this draft makes octets, when multiple RRs are present. Therefore, this draft makes the
the two following recommendations. two following recommendations.
- "Use UDP first, if UDP is not large enough then change to TCP" is - "Use UDP first, if UDP is not large enough then change to TCP" is
RECOMMENDED. RECOMMENDED.
The server MUST send back the response with the TC bit set. Then The server MUST send back the response with the TC bit set. Then
the resolver SHOULD resend the query using TCP on server port the resolver SHOULD resend the query using TCP on server port
53(decimal). This behavior is consistent with the current DNS 53(decimal). This behavior is consistent with the current DNS
specification[RFC1035]. specification[RFC1035].
- In future, EDNS0 is REQUIRED to send large packets. - In future, EDNS0 is REQUIRED to send large packets.
Then, before a client send a query to ask for IPTR record, it
MUST query the server whether it knows the EDNS0 first. If the
server knows EDNS0, then the client MAY send the IPTR query.
Else, unfortunally, the client MUST change the QTYPE to PTR.
Hence, the size of the UDP payload is no longer limited to 512 Hence, the size of the UDP payload is no longer limited to 512
octets any more. octets any more.
5.2 Standard sample 6.2 Standard sample
A resolver who wants to find the iDNs corresponding to an IP address A resolver who wants to find the IDNs corresponding to an IP
1.2.3.4 whould pursue a query of the form QTYPE=IPTR, QCLASS=IN, address 1.2.3.4 whould pursue a query of the form QTYPE=IPTR,
QNAME=4.3.2.1.IN-ADDR.ARPA, and would receive: QCLASS=IN, QNAME=4.3.2.1.IN-ADDR.ARPA, and would receive:
+------------------------------------------------------+ +------------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA | Header | OPCODE=SQUERY, RESPONSE, AA |
+------------------------------------------------------+ +------------------------------------------------------+
Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR | Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR |
+------------------------------------------------------+ +------------------------------------------------------+
Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-cn" "name1-in-utf8" | Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name1-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-tw" "name2-in-utf8" | | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name2-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "ja-jp" "name3-in-utf8" | | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-JP" "name3-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-kr" "name4-in-utf8" | | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name4-in-utf8" |
+------------------------------------------------------+ +------------------------------------------------------+
Authority | ... | Authority | ... |
+------------------------------------------------------+ +------------------------------------------------------+
Additional | ... | Additional | ... |
+------------------------------------------------------+ +------------------------------------------------------+
6 Open Issues 7. IPTR Usage
1. API issues on the resolver side. The "foo1.example" in following samples MAY or MAY NOT be
represented in the same characters.
2. the granularity of the language info. (per domain name? per 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8"
label? within label?) IPTR "zh-CN" "[foo1.example] in utf8"
IPTR "ja-JP" "[foo1.example] in utf8"
IPTR "ko-KR" "[foo1.example] in utf8"
Practically, we believe it is enough for the iPTR info to be Moreover,
expressed as |01|ELT|language|size|utf8|size|utf8|...|, mean-
ing the LANGUAGE TAG is used to define the language of the
Fully Quantified Domain Name. However, FQDNs could still
exist in the form of "English-in-utf8.Chinese-in-utf8.English-
in-utf8." And more than 1 language can exist in the same
label. Should such level of detailedness be supported? Or a
simple meta-type like "mixed-language" is enough?
3. If language info should somehow be relatable to an iDN 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8"
itself(nothing to do with PTR...) and how? IPTR "zh-TW" "[foo2.example] in utf8"
...
IPTR "zh-CN" "[foo1.example] in utf8"
IPTR "zh-CN" "[foo2.example] in utf8"
...
IPTR "ja-JP" "[foo1.example] in utf8"
IPTR "ja-JP" "[foo2.example] in utf8"
...
IPTR "ko-KR" "[foo1.example] in utf8"
IPTR "ko-KR" "[foo2.example] in utf8"
...
As a suggestion, if a new RR TYPE INAME is established to will exist also. And "foo2.example" MUST be different from
relate iDN to current domain name, there will be two merit. "foo1.example", if they are in signed with same LANGUAGE. Or a
One is we don't to do anything with PTR. Second is if we cache "Syntax Error" SHOULD be sent back, when an administrator config-
the INAME RRs to the DNS caches, then it can reduce the upper ures the zone files. Furthermore "foo2.example" in the samples
layer name servers' jobs. Actually, the feature of the new RR above MAY or MAY NOT be represented in the same characters.
TYPE is quite similar to CNAME and DNAME, meaning name-to-
name.
FQIDN: Fully Qualified Internationalized Domain Name. Thus,
Then the INAME RR is expressed following: 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
IPTR "zh-TW" "[samefoo.sample] in utf8"
iDN INAME traditional domain name occurs a "Syntax Error".
About the first merit, When the client looks up an IP address And,
to iDNs then the server will reponse not only corresponding
PTR RR but corresponding INAME RRs to the client. Further-
more, the problem in LANGUAGE TAG can be avoided.
For example: 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
4.3.2.1.IN-ADDR.ARPA PTR traditional-domain-name IPTR "zh-TW" "[difffoo.sample] in utf8"
iDN-1 INAME traditional-domain-name IPTR "zh-CN" "[samefoo.sample] in utf8"
iDN-2 INAME traditional-domain-name IPTR "ja-JP" "[samefoo.sample] in utf8"
IPTR "ko-KR" "[samefoo.sample] in utf8"
About the second merit, INAME is not only can be used in is allowed.
address-to-name mapping but name-to-address mapping.
For example: 8. Open Issues
traditional domain name IN A host address
iDN-1 INAME traditional-domain-name
iDN-2 INAME traditional-domain-name
When the client looks up an iDN or traditional domain name to 1. Is it necessary to let a IDN aware server to send back all of
its corresponding IP address, if the server reponses not only the corresponding IDNs to a resolver? Meanings,
A RR but INAME RRs to the client. And the client cache these
RRs to its DNS cache. Then the next time, maybe some queries +------------------------------------------------------+
can be resolved in DNS cache. Header | OPCODE=SQUERY, RESPONSE, AA |
+------------------------------------------------------+
Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR |
+------------------------------------------------------+
Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name1-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name2-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name3-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name4-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name5-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name6-in-utf8" |
+------------------------------------------------------+
Authority | ... |
+------------------------------------------------------+
Additional | ... |
+------------------------------------------------------+
Or, just using current fixed/cyclic/random options to return
one of the corresponding IDNs per LANGUAGE? In short, "one IP
one IDN per LANGUAGE". Such like
+------------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+------------------------------------------------------+
Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR |
+------------------------------------------------------+
Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name1-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name4-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name5-in-utf8" |
| 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name6-in-utf8" |
+------------------------------------------------------+
Authority | ... |
+------------------------------------------------------+
Additional | ... |
+------------------------------------------------------+
2. If QTYPE is IPTR, should an IDN aware server send all of the
corresponding IDNs to the resolver? Is this kind of behavior
friendly to implent the resolver? How about letting a server
just feedback the corresponding PTR record, if a server
doesn't find the corresponding LANGUAGE IDN that a client
requires.
In the following case, it is wasteful to return all the
corresponding IDNs to the clients.
4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8"
IPTR "zh-TW" "[foo2.example] in utf8"
...
IPTR "zh-CN" "[foo1.example] in utf8"
IPTR "zh-CN" "[foo2.example] in utf8"
...
IPTR "ja-JP" "[foo1.example] in utf8"
IPTR "ja-JP" "[foo2.example] in utf8"
...
IPTR "ko-KR" "[foo1.example] in utf8"
IPTR "ko-KR" "[foo2.example] in utf8"
...
The benefit of the IPTR is introducing LANGUAGE. It SHOULD be
used in query from clients, then servers can select minimum
size of corresponding IDNs. For working this effectively, you
should introduce default LANGUAGE if no corresponding LANGUAGE
exists. The default MUST be ASCII. So that default IPTR can be
natural extension of PTR. I.E.
4.3.2.1.in-addr.arpa. IN PTR ASCII-domain-name
is equivalent to
4.3.2.1.in-addr.arpa. IN IPTR "default" ASCII-domain-name
Of course, ASCII includes ACE.
3. According to the consideration above, how about the following
thinking? That means a response MAY include not only a
corresponding IDN in a specific LANGUAGE but also the LANGUAGE
tags of the corresponding IDNs. And the client will load these
LANGUAGE tags in the DNS cache for the next IPTR query.
References References
[IDNE] Mrc Blanchet & Paul Hoffman, "Internationalized domain names [IDNREQ] Zita Wenzel & James Seng, "Requirements of International-
using EDNS", draft-ietf-idn-idne. ized Domain Names", draft-ietf-idn-requirements.
[IDNE] Marc Blanchet & Paul Hoffman, "Internationalized domain
names using EDNS", draft-ietf-idn-idne.
[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of Interna-
tionalized Host Names", draft-ietf-idn-nameprep.
[RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES",
November 1987, RFC1034 November 1987, RFC1034
[RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICA- [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
TION", November 1987, RFC1035 SPECIFICATION", November 1987, RFC1035
[RFC1766] H. Alvestrand, "Tags for the Identification of Languages", [RFC1766] H. Alvestrand, "Tags for the Identification of
March 1999, RFC 1766 Languages", March 1999, RFC 1766
[RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP version [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP
6", December 1995, RFC1886 version 6", December 1995, RFC1886
[RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specifica-
tion", July 1997, RFC2181
[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
10646", January 1998, RFC 2279. 10646", January 1998, RFC 2279.
[RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", August [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)",
1999, RFC 2671. August 1999, RFC 2671.
[ISO 639] ISO 639:1988 (E/F) - Code for the representation of names of [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names
languages - The International Organization for Standardization, 1st edi- of languages - The International Organization for Standardization,
tion, 1988 17 pages Prepared by ISO/TC 37 - Terminology (principles and 1st edition, 1988 17 pages Prepared by ISO/TC 37 - Terminology
coordination). (principles and coordination).
[ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of
of countries - The International Organization for Standardization, 3rd names of countries - The International Organization for Standardi-
edition, 1988-08-15. zation, 3rd edition, 1988-08-15.
Acknowledgements Acknowledgements
James Seng has given many comments in our e-mail discussions. James Seng and Yoshiro Yoneya have given many comments in our e-
mail discussions. Harald Alvestrand, Mark Davis have given many
suggestions in the idn-wg mailing list discussions. And there are
also a lot of people who have given us their comments in the idn-wg
and BIND-user mailing list discussions.
Authors' Information Authors' Information
Hongbo Shi Hongbo Shi
Waseda University Waseda University
3-4-1 Okubo, Shinjyuku-ku 3-4-1 Okubo, Shinjyuku-ku
Tokyo, 169-8555 Japan Tokyo, 169-8555 Japan
shi@goto.info.waseda.ac.jp shi@goto.info.waseda.ac.jp
Jiang Ming Liang Jiang Ming Liang
 End of changes. 50 change blocks. 
118 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/