draft-ietf-idn-iptr-01.txt   draft-ietf-idn-iptr-02.txt 
INTERNET-DRAFT Hongbo Shi INTERNET-DRAFT Hongbo Shi
draft-ietf-idn-iptr-01.txt Waseda University draft-ietf-idn-iptr-02.txt Waseda University
17 November 2000 Jiang Ming Liang 17 May 2001 Jiang Ming Liang
Expires: 17 May 2001 i-DNS.net Expires: 17 November 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
skipping to change at page 7, line 22 skipping to change at page 7, line 22
And, And,
4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8" 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
IPTR "zh-TW" "[difffoo.sample] in utf8" IPTR "zh-TW" "[difffoo.sample] in utf8"
IPTR "zh-CN" "[samefoo.sample] in utf8" IPTR "zh-CN" "[samefoo.sample] in utf8"
IPTR "ja-JP" "[samefoo.sample] in utf8" IPTR "ja-JP" "[samefoo.sample] in utf8"
IPTR "ko-KR" "[samefoo.sample] in utf8" IPTR "ko-KR" "[samefoo.sample] in utf8"
is allowed. is allowed.
8. Open Issues 8. Changes
1. Is it necessary to let a IDN aware server to send back all of
the corresponding IDNs to a resolver? Meanings,
+------------------------------------------------------+
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 Through the discussion on the IETF49 meeting in San Diego, we
used in query from clients, then servers can select minimum deleted the chapter "Open Issues" of our previous draft (version
size of corresponding IDNs. For working this effectively, you 01).
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 And,
is equivalent to 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
IPTR "zh-TW" "[difffoo.sample] in utf8"
IPTR "zh-CN" "[samefoo.sample] in utf8"
IPTR "ja-JP" "[samefoo.sample] in utf8"
IPTR "ko-KR" "[samefoo.sample] in utf8"
4.3.2.1.in-addr.arpa. IN IPTR "default" ASCII-domain-name is allowed.
Of course, ASCII includes ACE. 8. Changes
3. According to the consideration above, how about the following Through the discussion on the IETF49 meeting in San Diego, we
thinking? That means a response MAY include not only a deleted the chapter "Open Issues" of our previous draft (version
corresponding IDN in a specific LANGUAGE but also the LANGUAGE 01).
tags of the corresponding IDNs. And the client will load these
LANGUAGE tags in the DNS cache for the next IPTR query.
References References
[IDNREQ] Zita Wenzel & James Seng, "Requirements of International- [IDNREQ] Zita Wenzel & James Seng, "Requirements of International-
ized Domain Names", draft-ietf-idn-requirements. ized Domain Names", draft-ietf-idn-requirements.
[IDNE] Marc Blanchet & Paul Hoffman, "Internationalized domain [IDNE] Marc Blanchet & Paul Hoffman, "Internationalized domain
names using EDNS", draft-ietf-idn-idne. names using EDNS", draft-ietf-idn-idne.
[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of Interna- [NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
tionalized Host Names", draft-ietf-idn-nameprep. Internationalized 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 [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", November 1987, RFC1035 SPECIFICATION", November 1987, RFC1035
[RFC1766] H. Alvestrand, "Tags for the Identification of [RFC1766] H. Alvestrand, "Tags for the Identification of
Languages", March 1999, RFC 1766 Languages", March 1999, RFC 1766
 End of changes. 9 change blocks. 
82 lines changed or deleted 20 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/