idnits 2.17.1 draft-ietf-idn-iptr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 51: '... that an IPTR RR SHOULD refer to one p...' RFC 2119 keyword, line 75: '... CNAME MUST continue to work for IPT...' RFC 2119 keyword, line 76: '... An IPTR RR SHOULD be limited to one...' RFC 2119 keyword, line 83: '...olving IPTR type MUST have the followi...' RFC 2119 keyword, line 86: '... corresponding iDNs SHOULD be returned...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 244 has weird spacing: '...in name to...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Sep 2000) is 8618 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 58, but not defined == Unused Reference: 'IDNE' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'ISO 639' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'ISO 3166' is defined on line 278, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'IDNE' ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 639' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 3166' Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Hongbo Shi 2 draft-ietf-idn-iptr-00.txt Waseda University 3 Jiang Ming Liang 4 i-DNS.net 5 Sep 2000 7 Internationalized PTR Resource Record (IPTR) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This draft attempts to address the problem of how an IP address should 32 be properly mapped to a set of internationalized domain names(iDNs). 33 It is currently unspecified how a PTR record can be used for this 34 purpose. In addition, the syntax of the PTR resource record may be 35 too restrictive for such a mapping in a more culturally meaningful 36 context. This document suggests a new TYPE called IPTR using EDNS0 37 and a mechanism to combind language information with such a mapping. 39 1. Introduction 41 Reverse mapping is a very important and essential function in the DNS. 42 In today's Domain Name System, PTR RRs are used to support address-to- 43 domain mappings. However, a current PTR RR does not provide support 44 for proper address-to-iDN mappings, without certain modifications. 46 Modifying the PTR structure will also affect the current reverse 47 mapping architecture. This document describes a new RR TYPE named 48 IPTR to provide address-to-iDN mappings and it also specifies that on 49 receiving of a IPTR query a name server should respond with all the 50 corresponding IPTR RRs in one response. This document also specifies 51 that an IPTR RR SHOULD refer to one primary iDN per language only. 53 1.1 Terminology 55 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 56 and "MAY" in this document are to be interpreted as described in RFC 57 2119 [RFC2119]. 59 1.2 Background and Designs 61 When Internationalized Domain Names come into wide use, an Internet 62 host is likely to have domain names in different languages. In 63 today's Internet, because of the design of the PTR record and 64 implementation of most resolvers, IP address to domain names mapping 65 is limited to "one IP one domain name", the primary domain name of the 66 host. This is more restrictive in a world of iDNs, for choosing one 67 name in one particular language as the primary could have cultural 68 implications. The authors also believe that putting language 69 information into address-to-name mappings will be benifitial to future 70 applications. 72 The design purpose of the IPTR RR type is to provide a mechanism that 73 can map an IP address to all of the corresponding iDNs per language. 75 CNAME MUST continue to work for IPTR as it works now for PTR records. 76 An IPTR RR SHOULD be limited to one primary iDN per language. 78 The behavior of a resolver on the use of IPTR will be specified in a 79 seperate draft or a later version of this draft. 81 1.3 Functional Description 83 DNS query and responses involving IPTR type MUST have the following 84 properties: 86 - When the QTYPE is IPTR, the corresponding iDNs SHOULD be returned 87 in one response. 89 - The characters in the label MUST be encoded using UTF-8 90 [RFC2279]. 92 - The entire label MUST be encoded EDNS [RFC2671]. 94 2. IPTR definition 96 The structure of an IPTR RR is somewhat like the MX RR. :) In addtion 97 to the IP address in the IN-ADDR.ARPA domain and the domain name field 98 (similar to a PTR RR), a new field called LANGUAGE has been defined. 99 A domain name in an IPTR RR MUST be encoded in UTF8. Below is an 100 example of an IPTR RR: 102 1.2.3.4.IN-ADDR.ARPA. IPTR "language" "name-in-utf8" 104 [RFC1766] describes the ISO 639/ISO 3166 conventions. A language name 105 is always written in lower case, while country codes are written in 106 upper case. The "language" field in an IPTR RR MUST follow the con- 107 ventions defined in [RFC1766]. 109 For Example: 111 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-cn" "name-in-utf8" 112 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-tw" "name-in-utf8" 113 4.3.2.1.IN-ADDR.ARPA. IPTR "ja-jp" "name-in-utf8" 114 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-kr" "name-in-utf8" 116 The notion of canonical names and aliases described in 3.6.2 [RFC1034] 117 must be preserved for IPTR record types. An IPTR RR SHOULD be limited 118 to one primary iDN per language, similar to the a PTR RR. 120 3. IPTR on IPv6 122 Mapping IPv6 to iDNs can be similarly supported. This document recom- 123 mands to continue using the IP6.INT domain defined in [RFC1886] for 124 IPTR mappings. For example, the lookup corresponding to the address 125 4321:0:1:2:3:4:567:89ab would be: 126 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. 127 IPTR "language" "name-in-utf8" 129 4. Packet format for IPTR 131 EDNS0[RFC2671] is REQUIRED to implement IPTR. 133 0 1 2 3 4 134 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 ... 135 +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+ 136 |0 1| ELT | LANGUAGE | Size | IDN label... | 137 +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+ 139 LANGUAGE: An argument for IPTR to define the kind of languages 140 used in the following IDN label. The size is 2 octets. 141 ELT: To be defined. 143 5. IPTR query/response 145 When the QTYPE is IPTR in a query, all of the corresponding IPTR RRs 146 SHOULD be returned in one response. DNS messages are limited to 512 147 octets or less in size when sent over UDP. Therefore, if all the RRs 148 cannot fit in one UDP packet, this draft describe two solutions. One 149 is for recent environment and the other is for the near future. 151 5.1 Transport 153 Today, DNS queries and responses are carried in UDP datagrams or over 154 TCP connections.[RFC1034] specifies, IPTR RRSet is RECOMMENDED to be 155 returned in one response. The size of a DNS message could exceed 512 156 octets, when multiple RRs are present. Therefore, this draft makes 157 the two following recommendations. 159 - "Use UDP first, if UDP is not large enough then change to TCP" is 160 RECOMMENDED. 162 The server MUST send back the response with the TC bit set. Then 163 the resolver SHOULD resend the query using TCP on server port 164 53(decimal). This behavior is consistent with the current DNS 165 specification[RFC1035]. 167 - In future, EDNS0 is REQUIRED to send large packets. 169 Hence, the size of the UDP payload is no longer limited to 512 170 octets any more. 172 5.2 Standard sample 174 A resolver who wants to find the iDNs corresponding to an IP address 175 1.2.3.4 whould pursue a query of the form QTYPE=IPTR, QCLASS=IN, 176 QNAME=4.3.2.1.IN-ADDR.ARPA, and would receive: 178 +------------------------------------------------------+ 179 Header | OPCODE=SQUERY, RESPONSE, AA | 180 +------------------------------------------------------+ 181 Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR | 182 +------------------------------------------------------+ 183 Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-cn" "name1-in-utf8" | 184 | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-tw" "name2-in-utf8" | 185 | 4.3.2.1.IN-ADDR.ARPA. IPTR "ja-jp" "name3-in-utf8" | 186 | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-kr" "name4-in-utf8" | 187 +------------------------------------------------------+ 188 Authority | ... | 189 +------------------------------------------------------+ 190 Additional | ... | 191 +------------------------------------------------------+ 193 6 Open Issues 195 1. API issues on the resolver side. 197 2. the granularity of the language info. (per domain name? per 198 label? within label?) 200 Practically, we believe it is enough for the iPTR info to be 201 expressed as |01|ELT|language|size|utf8|size|utf8|...|, mean- 202 ing the LANGUAGE TAG is used to define the language of the 203 Fully Quantified Domain Name. However, FQDNs could still 204 exist in the form of "English-in-utf8.Chinese-in-utf8.English- 205 in-utf8." And more than 1 language can exist in the same 206 label. Should such level of detailedness be supported? Or a 207 simple meta-type like "mixed-language" is enough? 209 3. If language info should somehow be relatable to an iDN 210 itself(nothing to do with PTR...) and how? 212 As a suggestion, if a new RR TYPE INAME is established to 213 relate iDN to current domain name, there will be two merit. 214 One is we don't to do anything with PTR. Second is if we cache 215 the INAME RRs to the DNS caches, then it can reduce the upper 216 layer name servers' jobs. Actually, the feature of the new RR 217 TYPE is quite similar to CNAME and DNAME, meaning name-to- 218 name. 220 FQIDN: Fully Qualified Internationalized Domain Name. 222 Then the INAME RR is expressed following: 224 iDN INAME traditional domain name 226 About the first merit, When the client looks up an IP address 227 to iDNs then the server will reponse not only corresponding 228 PTR RR but corresponding INAME RRs to the client. Further- 229 more, the problem in LANGUAGE TAG can be avoided. 231 For example: 232 4.3.2.1.IN-ADDR.ARPA PTR traditional-domain-name 233 iDN-1 INAME traditional-domain-name 234 iDN-2 INAME traditional-domain-name 236 About the second merit, INAME is not only can be used in 237 address-to-name mapping but name-to-address mapping. 239 For example: 240 traditional domain name IN A host address 241 iDN-1 INAME traditional-domain-name 242 iDN-2 INAME traditional-domain-name 244 When the client looks up an iDN or traditional domain name to 245 its corresponding IP address, if the server reponses not only 246 A RR but INAME RRs to the client. And the client cache these 247 RRs to its DNS cache. Then the next time, maybe some queries 248 can be resolved in DNS cache. 250 References 252 [IDNE] Mrc Blanchet & Paul Hoffman, "Internationalized domain names 253 using EDNS", draft-ietf-idn-idne. 255 [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", 256 November 1987, RFC1034 258 [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICA- 259 TION", November 1987, RFC1035 261 [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", 262 March 1999, RFC 1766 264 [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP version 265 6", December 1995, RFC1886 267 [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO 268 10646", January 1998, RFC 2279. 270 [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", August 271 1999, RFC 2671. 273 [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names of 274 languages - The International Organization for Standardization, 1st edi- 275 tion, 1988 17 pages Prepared by ISO/TC 37 - Terminology (principles and 276 coordination). 278 [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names 279 of countries - The International Organization for Standardization, 3rd 280 edition, 1988-08-15. 282 Acknowledgements 284 James Seng has given many comments in our e-mail discussions. 286 Authors' Information 288 Hongbo Shi 289 Waseda University 290 3-4-1 Okubo, Shinjyuku-ku 291 Tokyo, 169-8555 Japan 292 shi@goto.info.waseda.ac.jp 294 Jiang Ming Liang 295 i-DNS.net 296 8 Temasek Boulevard 297 #24-02 Suntec Tower Three 298 Singapore 038988 299 jiang@i-DNS.net