idnits 2.17.1 draft-ietf-idn-dnsii-mdnp-02.txt: -(206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(217): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(232): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(388): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(394): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(396): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(441): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(451): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(453): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(506): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(515): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(517): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(519): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(587): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(597): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(599): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 19 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Since the PTR record is usually used for display purposes only, the rejection (the IP address will then be used) or ACE format is acceptable. If the response is however used for further resolution, an ACE format MUST not be used. -- 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 (February 2001) is 8471 days in the past. Is this intentional? 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: 'RFC 1034' is mentioned on line 91, but not defined == Missing Reference: 'RFC 1035' is mentioned on line 92, but not defined == Missing Reference: 'Unicode' is mentioned on line 225, but not defined == Missing Reference: 'UCS-2' is mentioned on line 242, but not defined == Missing Reference: 'UCS-4' is mentioned on line 242, but not defined == Unused Reference: 'DNSII-MDNR' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'ISO10646' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 644, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSII-MDNR' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' ** Downref: Normative reference to an Informational RFC: RFC 2130 ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDN Working Group Edmon Chung & David Leung 2 Internet Draft Neteka Inc. 3 February 2001 5 The DNSII Multilingual Domain Name Protocol 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. Internet-Drafts are draft documents valid for a maximum of 16 six months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts as 18 reference material or to cite them other than as "work in progress." 20 The reader is cautioned not to depend on the values that appear in 21 examples to be current or complete, since their purpose is primarily 22 educational. Distribution of this memo is unlimited. 24 The list of current Internet-Drafts can be accessed at 25 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 A copy of this particular draft is also archived at 30 http://www.dnsii.org. 32 Abstract 34 The core thinking for DNSII is that multilingual DNS requests SHOULD 35 be signaled within a DNS label whether by way of a binary tag or an 36 alphanumeric prefix, and that compatibility to legacy client 37 applications SHOULD be taken into concern alongside legacy server 38 implementations. 40 Besides the original specifications, four alternatives including the 41 use of EDNS are included for discussion purposes in this document. 43 Historically, the DNS is capable of handling only names within the 44 basic English alphanumeric character set (plus the hyphen), yet the 45 standards were so elegantly and openly designed that the extension of 46 the DNS into a multilingual and symbols based system proves to be 47 possible with simple adjustments. 49 These adjustments will be made on both the client side and the server 50 side. However, DNSII works on the principal that it is preferable to 51 make the transition to multilingual domain names seamless and 52 transparent to the end-user. Which means initially the server SHOULD 53 take the primary responsibility for the technical implementation of 54 the changes required for a multilingual Internet. 56 The DNSII protocol is designed to allow the preservation of 57 interoperability, consistency and simplicity of the original DNS, 58 while being expandable and flexible for the handling of any character 59 or symbol used for the naming of an Internet domain. DNSII intends 60 to provide a platform for the implementation of multilingual domain 61 names. 63 Table Of Contents 65 1. Introduction....................................................2 66 1.1 Terminology....................................................2 67 1.2 DNSII..........................................................3 68 2. DNSII Protocol..................................................3 69 2.1 InPacket DNSII Identifier......................................3 70 2.2 InPacket Label Encoding Type (ILET)............................4 71 2.3 The Rationale for using ILET...................................5 72 2.4 Considerations for Specific Requests...........................6 73 2.4.1 PTR Records..................................................6 74 3. Alternate Implementations.......................................7 75 3.1 Restricted ILET Values.........................................7 76 3.2 Reduced ILET Bit Allocation....................................8 77 3.3 DNSII over EDNS................................................9 78 3.3.1 DNSII Identifier using EDNS..................................9 79 3.3.2 ILET using EDNS OPT RRs.....................................10 80 4. Implementation & Deployment Strategies.........................11 81 5. IDN Requirements Considerations................................12 82 6. DNSSEC, EDNS and IPv6 Considerations...........................12 83 7. Intellectual Property Considerations...........................13 84 8. References.....................................................13 86 1. Introduction 88 This Internet-draft describes details of the DNSII Multilingual 89 Domain Name protocol. The Internet-Draft assumes that the reader is 90 familiar with the concepts discussed in the widely distributed RFCs 91 "Domain Names Concepts and Facilities" [RFC 1034] and "Domain Names 92 Implementation and Specification" [RFC 1035]. 94 1.1 Terminology 96 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 97 and "MAY" in this document are to be interpreted as described in RFC 98 2119 [RFC2119]. 100 A number of multilingual characters are used in this document for 101 examples. Please select your view encoding type to UTF-8 for it to 102 be displayed properly. 104 1.2 DNSII 106 The DNSII specifications takes a radically different approach: it 107 successfully identifies the difference between original DNS and DNSII 108 packets within the labels and at the same time allows the use of 109 multiple charsets to be easily incorporated in a standardized manner. 110 It causes no harm to the current DNS because it embraces the original 111 format for DNS laid out in RFC1035, complemented with the ideas 112 incorporated in EDNS [RFC2671]. 114 2. DNSII Protocol 116 The DNSII Protocol consists mainly of two parts: the InPacket DNSII 117 Identifier and the InPacket Label Encoding Type. In addition, there 118 are several special considerations for specific record types. 120 2.1 InPacket DNSII Identifier 122 In the DNSII specifications, an InPacket DNSII Identifier MUST be 123 inserted before a label to signify that it contains extended 124 characters that are not supported by the current DNS. 126 This DNSII flag, which is the first two bits of a label, effectively 127 distinguishes a DNSII compliant request from the existing format, 128 without having to conduct a guess from a name check whether the 129 incoming packet is multilingual aware. This is a substantial 130 improvement over character encoding schemes and multilingual 131 implementations in which it is almost impossible to determine the 132 language of an incoming request. The DNSII flag makes the process 133 clear and simple. 135 Currently: 136 "00" regular label [RFC1035] 137 "11" a redirection for DNS compression [RFC1035] 138 "01" indicates the use of EDNS for multiple UDP packets [RFC2671] 140 DNSII calls for the use of the bit sequence "10" to identify that the 141 querying node is DNSII aware. This will mean that all the possible 142 variations at top two label bits will be used. Therefore, in 143 consideration, following two bits MUST be reserved for future 144 flagging use. The 2 bits SHOULD be arbitrarily set to "00". This 145 effectively opens up 3 more possible implementations for future 146 enhancements. 148 The motivation for this approach is the belief there should be no 149 ambiguity in name resolution. Any name that the client wishes to 150 resolve, should resolve, regardless of the client side-encoding 151 scheme. 153 2.2 InPacket Label Encoding Type (ILET) 155 Immediately following the 2 assigned DNSII flag and the 2 reserved 156 bits are 12 bits assigned to determine the InPacket Label Encoding 157 Type (ILET). 159 The ILET is a 12-bit number that is used to determine the encoding 160 scheme used by the characters of the label. The MIBenum numbers 161 [RFC1700] SHOULD be used in this field. The allocation of 12 bits 162 aligns perfectly with the MIBenum specification, of which the value 163 goes up to over 2200. With 12 bits, the total possible values would 164 be 4096 (with 11 bits, the largest value that can be represented is 165 only 2047, slightly short of the specification). The reason for the 166 adoption of MIBenum is to make use of the existing list of encoding 167 numbering schemes rather than re-inventing the wheel. 169 The value in the ILET field SHOULD only be allowed for the valid 170 encoding schemes defined in the MIBenum list. After identifying the 171 encoding type, the regular count-label scheme of the DNS resumes. 172 The resulting label should look like this: 174 1 1 1 1 1 1 175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 176 +---+---+-------+---------------+ 177 |1 0| z | ILET | 178 +---------------+---------------+ 179 | COUNT | characters... | 180 +---------------+---------------+ 182 To minimize the size of a DNS packet, if the entire label is 183 constituted in characters only from the ANSI table, the DNS label 184 will appear identical to current implementations. The first two bits 185 will remain "00". 186 For example, using the DNSII format the label for "dns" MAY be 187 represented as: 189 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 190 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 191 | 1 0| 0 0| 0 0 0 0 0 0 0 0 0 0 1 1| MIBenum 3 = ANSI 192 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 193 | 3 | 6 4 | "d"=64 194 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 195 | 6 E | 7 3 | "n"=6E "s"=73 196 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 198 Or, the same domain label "dns" MAY also be represented as: 200 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 201 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 202 | 3 | d | 203 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 204 | n | s | 205 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 206 With a multilingual domain name ns.�����������.tld as an example: 208 1 1 1 1 1 1 1 1 1 1 1 1 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 210 +---------------------------------------------------------------+ 211 |1 0| z | ANSI=3 | 2 | n | 212 +---------------------------------------------------------------+ 213 | s |1 0|0 0| UCS-2=1000 | 4 | 214 +---------------------------------------------------------------+ 215 | ��� (U+57DF) | ��� (U+540D) | 216 +---------------------------------------------------------------+ 217 | ��� (U+7CFB) | ��� (U+7D71) | 218 +---------------------------------------------------------------+ 219 |0 0| 3 | t | l | d | 220 +---------------------------------------------------------------+ 221 | 0 | 222 +---------------+ 223 From the above example, we can see that the DNSII format is used for 224 the first label "ns", as well as for the second label, which is in 225 Chinese (the MIBenum for UCS-2 or ISO 10646 [Unicode] is 1000). The 226 third label "tld" however uses the current format. 228 In any case, the count-label-count-label mechanism is largely 229 preserved. Especially in the case of extended characters where in 230 other proposals, the "count" no longer represents the character 231 count. In the above example, the domain is still represented as 2ns4 232 �����������3t ld0, exactly in line with the original specifications. 234 Note that the first label in any query could be represented in DNSII 235 format to alert the destination server that it is DNSII aware. This 236 is not required but is specifically configured for the considerations 237 with CNAME, A6, DNAME and PTR records. 239 This approach is used to ensure that there is no confusion about the 240 encoding format of the label. ILET allows the capability of 241 employing all existing encoding schemes (UTF-7, UTF-8, ISO 10646 242 [UCS-2], ISO 10646 [UCS-4]). ILET also allows the flexibility of 243 employing future encoding schemes. 245 2.3 The Rationale for using ILET 247 Besides being able to preserve the count-label-count-label structure, 248 which in itself is actually a very important part because of the 249 problematic non-uniform byte encoding schemes, the use of ILET aligns 250 perfectly with previous IETF specifications as well as beneficial for 251 tricky case folding and canonicalization issues. 253 We know that all protocols MUST identify, for all character data, 254 which charset is in use [RFC2277], therefore it is necessary to 255 specify whatever encoding scheme, whether it be UTF-8, UTF-7, 16-bit 256 UCS-2 or ISO 8859 that is being used. In essence, we understand that 257 it is paramount that a charset be clearly identified, especially in 258 situation like the DNS where no direct communication is established. 260 At times and in specific cases, language information may be required 261 to achieve a particular level of quality for the purpose of 262 displaying a text stream. For example, UTF-8 encoded Han may require 263 transmission of a language tag to select the specific glyphs to be 264 displayed at a particular level of quality. 266 Note that information other than language may be used to achieve the 267 required level of quality in a display process. In particular, a 268 font tag is sufficient to produce identical results. However, the 269 association of a language with a specific block of text has 270 usefulness far beyond its use in display. In particular, as the 271 amount of information available in multiple languages on the World 272 Wide Web grows, it becomes critical to specify which language is in 273 use in particular documents, to assist automatic indexing and 274 retrieval of relevant documents._ [RFC2130] 275 In effect, this means for different languages, it is beneficial to be 276 able to identify the language in order to perform specific functions 277 to the characters, including case folding. With ILET, the local 278 encoding scheme could be used and with them there are well defined 279 folding methods. Therefore, the use of ILET enables an optimized 280 folding mechanism brought about by the preservation of local encoding 281 schemes, which is otherwise very difficult or virtually impossible to 282 do if only UTF-8 is used. 284 For the DNS however, a language tag is less feasible because if a 285 name is consisted of multiple languages, it would be very difficult 286 for tagging to be performed. The possibility of having multiple 287 languages is very sound, and is used frequently as trademarks around 288 the world. For example the famous Toys"ϯ"Us name, uses a character 289 from the Cyrillic language set. 291 2.4 Considerations for Specific Requests 293 For certain requests, an ANSI only name could result in a 294 multilingual domain as an answer. These include PTR, CNAME, A6 and 295 DNAME requests. Special considerations are made within the DNSII 296 protocol to make sure that non-DNSII aware servers will not be fed 297 with a DNSII format packet. 299 2.4.1 PTR Records 301 For all PTR requests, the first label of the query MUST use DNSII 302 format to alert the destination server. Upon which, a DNSII packet 303 will be replied should the name contain extended characters. 305 If the DNSII format is not used, and the PTR record stumbles upon a 306 multilingual domain name, one of the following responses SHOULD be 307 given: 309 a. The implementer of DNSII MAY chose to reject the request; 311 or 313 b. An ACE format domain with a "for.ref.only" suffix MAY be returned; 315 or 317 c. A DNSII compliant server MAY return an 8-bit format of the 318 requested domain. 320 Since the PTR record is usually used for display purposes only, the 321 rejection (the IP address will then be used) or ACE format is 322 acceptable. If the response is however used for further resolution, 323 an ACE format MUST not be used. 325 2.4.2 CNAME, A6 & DNAME 327 For queries concerning the record types CNAME, A6 or DNAME, a DNSII 328 aware server should first check to see if the incoming request is 329 DNSII compliant (flagged by the "10" bits in the first label): 331 If so, and the domain to be returned includes extended characters, 332 the response SHOULD be in DNSII format. 334 If not, any multilingual domains returned should be in an 8 bit form. 336 For the above record types it is strongly RECOMMENDED not to 337 associate an alphanumeric label to a multilingual label as the 338 RDATA. However, it is permissible to associate a multilingual label 339 with an alphanumeric label as the RDATA. 341 3. Alternate Implementations 343 The DNSII-MDNP is intended to be a framework for the implementation 344 of multilingual domain names. While the core concepts and the design 345 principles remain consistent, it is possible to contemplate 346 alternative implementations. The four alternatives introduced here 347 include the arbitrary restriction of ILET values, the reduction of 348 ILET bit allocation for reflecting ISO 10646 transformations only, 349 and finally two implementations using DNSII over EDNS. 351 3.1 Restricted ILET Values 353 One possible implementation guideline is for the ILET to be 354 restricted to values only representing ISO 10646 transformations 355 including UCS-2, UCS-4, UTF-7, UTF-8, UTF-16 and other as they become 356 available and included as a standard MIBenum. 358 Although this takes away some of the benefits of keeping the local 359 encoding scheme which includes the issues of case folding, 360 canonicalization and other related concerns, it creates a system that 361 on one hand contains only encoding schemes from ISO 10646, but on the 362 other hand still provides the flexibility of deploying new encoding 363 schemes that stem from ISO 10646, such as the 32-bit format that is 364 due to be used soon. 366 We understand it is specified that in protocols, which up to now have 367 used US-ASCII only, UTF-8 forms a simple upgrade path; however, its 368 use should be negotiated either by negotiating a protocol version or 369 by negotiating charset usage, and a fallback to UTF-7 MUST be 370 available. [RFC2130] With DNSII, the required fallback to UTF-7 371 could easily be done by setting the ILET value to reflect UTF-7. 373 3.2 Reduced ILET Bit Allocation 375 Furthering the restriction of the ILET to ISO 10646 transformations 376 only, the ILET bit allocations could also be reduced from 12 bit to 5 377 bit. This successfully creates a total of 32 possible values. The 378 reserved bits are also reduced to one. 380 1 1 1 1 1 1 381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 382 +---+-+---------+---------------+ 383 |1 0|z| ILET | COUNT | 384 +---------------+---------------+ 385 | characters... | 386 +---------------+ 388 For example, the label "�����������" will now be reflected in DNS packets 389 in the following form: 391 1 1 1 1 1 1 1 1 1 1 1 1 392 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 393 +---------------------------------------------------------------+ 394 |1 0|z| ILET=1 | 4 | ��� (U+57DF) | 395 +---------------------------------------------------------------+ 396 | ��� (U+540D) | ��� (U+7CFB) | 397 +---------------------------------------------------------------+ 398 | ��� (U+7D71) | 399 +--------------------------------+ 401 To start off with, the ILET values MAY be determined as follows: 403 0 = reserved for ANSI 1 = UTF-7 404 2 = UCS-2 3 = UTF-8 405 4 = UCS-4 5 = UTF-16 406 6 = 6 octets per character 7 = 7 octets per character 407 8 = UCS-8 (8 octets per character) 9 = UTF-31 408 etc. 410 The ILET number will be the number of octets that should be read each 411 time, with exceptions at 0,3,5,9 or any number that is just after a 412 full UCS. ILET=3 corresponds to UTF8 because ILET=2 = UCS2 and UTF-8 413 is a compatibility transformation for UCS-2 (in 16bit) in 8bit. A 414 possible future expansion to UCS-8 is also included to make the 415 schema truly future prove. 417 This arrangement opens up opportunity and versatility of the use of 418 private schemes that make use of odd byte length characters or 419 symbols such as 6, 7 or even 18octet representations without the need 420 for the DNS to update or adjust to, while maintaining the integrity 421 and unique nature of domain names. 423 3.3 DNSII over EDNS 425 While DNSII and EDNS could coexist, it is possible to implement the 426 DNSII concept onto an EDNS based platform. It is however preferable 427 to use both EDNS and the DNSII scheme together as described in 428 Section 6, because EDNS(0) compliant servers may have trouble when 429 the label count exceeds the value of 63 (and smaller than 127) 430 because then, the EDNS mechanism MAY be reiterated. 432 Nevertheless, it is possible to utilize EDNS to act as a DNSII 433 Identifier. The short-comings and pit-falls are however further laid 434 in another draft DNSII-EDNS. 436 3.3.1 DNSII Identifier using EDNS 438 EDNS could simply be used in place of the DNSII Identifier. Assuming 439 that the reduced ILET values introduced in Section 3.2 is used, the 440 ILET will fit nicely into one octet immediately following the ELT 441 portion. The resulting representation for the domain "host.����������� 442 .tld" would be as follows: 444 1 1 1 1 1 1 1 1 1 1 1 1 445 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 446 +---------------------------------------------------------------+ 447 20|0 0| 4 | h | o | s | 448 +---------------------------------------------------------------+ 449 | t |0 1|0 0 0 0 1 0| ILET=UCS-2=2 | 4 | 450 +---------------------------------------------------------------+ 451 | ��� (U+57DF) | ��� (U+540D) | 452 +---------------------------------------------------------------+ 453 | ��� (U+7CFB) | ��� (U+7D71) | 454 +---------------------------------------------------------------+ 455 |0 0| 3 | t | l | d | 456 +---------------------------------------------------------------+ 457 | 0 | 458 +---------------+ 460 The OPT RR could be used not only for version control but also as a 461 notification for the destination server on the level of conformance 462 of the inquirer. This is especially beneficial when considering the 463 issues raised in Section 2.4 where ANSI only requests my result in a 464 multilingual response. 466 Proposed identifications within the OPT RR (used in this document for 467 discussion purposes): 468 ELT = 0b000010 469 EDNS-VERSION = 2 (DNSII) 470 OPTION-CODE = 1 (IDN) 471 OPTION-DATA = conformance level (defined in DNSII-MDNR Section 4) 472 Plus other information if required 474 The conformance level SHOULD be included in the first octet of the 475 OPTION-DATA field and reflect the value corresponding to: 477 BASIC conformance = 1 478 INTERMEDIATE conformance = 2 479 FULL conformance = 3 481 A resulting DNSII OPT RR from a fully compliant inquirer SHOULD be in 482 the form: 484 1 1 1 1 1 1 1 1 1 1 1 1 485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 486 +---------------------------------------------------------------+ 487 | NAME=0 | TYPE = OPT = 41 | Sender's UDP | 488 +---------------------------------------------------------------+ 489 | Payload Size |EXTENDED-RCODE=0|EDNS-VERSION=2| z | 490 +---------------------------------------------------------------+ 491 | z | RDLENGTH = 5 | OPTION-CODE = | 492 +---------------------------------------------------------------+ 493 | IDN = 1 | OPTION-LENGTH = 1 | Conformance=3 | 494 +---------------------------------------------------------------+ 496 3.3.2 ILET using EDNS OPT RRs 498 Instead of using the OPT RR only as a notification of DNSII 499 awareness, it utilized to indicate the type of encoding that is being 500 used in the labels. In other words, the ILET value could be included 501 in the OPT RR instead of within the label. 503 The ILET value will be included right after the conformance level 504 octet in the OPTION-DATA field within the OPT RR RDATA. 506 The resulting QNAME labels and OPT RR for the domain "www.����������� 507 .tld" from a fully compliant inquirer sending the name in UCS-2 508 would become: 510 1 1 1 1 1 1 1 1 1 1 1 1 511 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 512 +---------------------------------------------------------------+ 513 |0 0| 3 | w | w | w | 514 +---------------------------------------------------------------+ 515 |0 1|0 0 0 0 1 0| 4 | ��� (U+57DF) | 516 +---------------------------------------------------------------+ 517 | ��� (U+540D) | ��� (U+7CFB) | 518 +---------------------------------------------------------------+ 519 | ��� (U+7D71) |0 0| 3 | t | 520 +---------------------------------------------------------------+ 521 | l | d | 0 | 522 +-----------------------------------------------+ 524 (OPT RR containing ILET information) 525 : : 526 / / 527 +---------------------------------------------------------------+ 528 | NAME=0 | TYPE = OPT = 41 | Sender's UDP | 529 +---------------------------------------------------------------+ 530 | Payload Size |EXTENDED RCODE=0|EDNS-VERSION=2| z | 531 +---------------------------------------------------------------+ 532 | z | RDLENGTH = 9 | OPTION-CODE = | 533 +---------------------------------------------------------------+ 534 | IDN = 1 | OPTION-LENGTH = 4 | Conformance=3 | 535 +---------------------------------------------------------------+ 536 | 1 | 0 | 0 | 0 | 537 +---------------------------------------------------------------+ 539 Note that instead of allocating only 12 bits for the ILET, the 540 MIBenum value is expressed over 4 octets with each octet carrying a 541 numeric value. Since UCS-2 is used and the MIBenum value for UCS-2 = 542 1000, the 4 octets corresponds to the values 1, 0, 0, 0 respectively. 544 If the reduced ILET values are used, only 1 octet is required to 545 reflect the encoding scheme being used. 547 4. Implementation & Deployment Strategies 549 The first step in any multilingual domain name implementation should 550 be to encourage an 8-bit clean approach to DNS. However, even when 551 the system is 8-bit clean the problem with conflicting characters 552 still exists. This is where the DNSII protocol becomes most 553 valuable. 555 Although the DNSII protocol could be implemented at any level of the 556 DNS, the following phased rollout is contemplated. 558 (1) Registry Level - The most meaningful starting point for 559 deployment would be at the registry level since this creates the 560 demand from the end users to use multilingual and extended character 561 domain names for Second Level Domains. 563 (2) Host Level - At the same time, registrants of the new extended 564 domain names could start to implement DNSII to host these special 565 kinds of domain names. All other hosts that do not wish to use 566 extended characters do not have to migrate to the DNSII. 568 (3) Client Level - Once the multilingual aspect and the DNSII 569 specifications become mainstream, the user level resolvers will begin 570 to migrate. This will include both the client resolver as well as 571 the ISP's DNS. 573 (4) Root Level - Eventually, as the DNSII is proven to be stable and 574 beneficial for the Internet at large, it could be used in the Root 575 Level so that new multilingual TLDs could be created. 577 5. IDN Requirements Considerations 579 The DNSII protocol specification is in line with most if not all of 580 the requirements identified by the IDN work group. 582 6. DNSSEC, EDNS and IPv6 Considerations 584 The use of DNSII should not require any adjustments with the 585 implementation of DNSSEC, EDNS or IPv6. EDNS as well as compression 586 in fact will be done exactly the same as the existing system. 587 For example, the domain host.dns.�����������.tld running with EDNS as 588 well as compression after host will look as follows: 590 1 1 1 1 1 1 1 1 1 1 1 1 591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 592 +---------------------------------------------------------------+ 593 20|0 1| ELT |0 0| 3 | d | n | 594 +---------------------------------------------------------------+ 595 | s |1 0|0 0| UCS-2=1000 | 4 | 596 +---------------------------------------------------------------+ 597 | ��� (U+57DF) | ��� (U+540D) | 598 +---------------------------------------------------------------+ 599 | ��� (U+7CFB) | ��� (U+7D71) | 600 +---------------------------------------------------------------+ 601 |0 0| 3 | t | l | d | 602 +---------------------------------------------------------------+ 603 | 0 | 604 +---------------+ 605 : : 606 / / 607 +---------------------------------------------------------------+ 608 |0 0| 4 | h | o | s | 609 +---------------------------------------------------------------+ 610 | t |1 1| 21 | 611 +-----------------------------------------------+ 613 7. Intellectual Property Considerations 615 It is the intention of Neteka to submit the DNSII protocol and other 616 elements of the multilingual domain name server software to IETF for 617 review, comment or standardization. 619 Neteka Inc. has applied for one or more patents on the technology 620 related to multilingual domain name server software and multilingual 621 email server software suite. If a standard is adopted by IETF and 622 any patents are issued to Neteka with claims that are necessary for 623 practicing the standard, any party will be able to obtain the right 624 to implement, use and distribute the technology or works when 625 implementing, using or distributing technology based upon the 626 specific specifications under fair, reasonable and non-discriminatory 627 terms. 629 Other DNSII related documents and discussions could be found at 630 http://www.dnsii.org. 632 8. References 634 [DNSII-MDNR] E. Chung, D. Leung, _DNSII Multilingual Domain Name 635 Resolution_, August 2000 637 [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, 638 October 1994. 640 [ISO10646] ISO/IEC 10646-1:2000. International Standard - 641 Information technology -- Universal Multiple-Octet Coded 642 Character Set (UCS) 644 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 645 Facilities," STD 13, RFC 1034, USC/ISI, November 1987 647 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 648 Specification," STD 13, RFC 1035, USC/ISI, November 1987 650 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 651 Requirement Levels," RFC 2119, March 1997 653 [RFC2130] C. Weider, et al. _The Report of the IAB Character Set 654 Workshop held 29 February - 1 March, 1996_ RFC 2130, 655 April 1997 657 [RFC2277] H. Alvestrand, _IETF Policy on Character Sets and 658 Languages_ RFC 2277, January 1998 660 [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", 661 August 1999, RFC 2671. 663 Authors: 665 Edmon Chung 666 Neteka Inc. 667 2462 Yonge St. Toronto, 668 Ontario, Canada M4P 2H5 669 edmon@neteka.com 671 David Leung 672 Neteka Inc. 673 2462 Yonge St. Toronto, 674 Ontario, Canada M4P 2H5 675 david@neteka.com