idnits 2.17.1 draft-ietf-idn-dnsii-mdnr-01.txt: -(313): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(354): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(356): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(427): 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 5 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 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 'SHOULD not' in this paragraph: The INTERMEDIATE compliant name server will be able to process the DNSII identifier and ILET without rejecting the query. The authoritative zone as well as its direct sub-domains however SHOULD not include the use of the DNSII flags because ILET values are not understood at this compliancy level. -- 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 8464 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) == Unused Reference: 'DNSII-MDNP' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC1700' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'ISO10646' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 670, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSII-MDNP' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' Summary: 6 errors (**), 0 flaws (~~), 10 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 DNSII Multilingual Domain Name Resolution 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 This document outlines a resolution process that forms a framework 35 for the resolution of multilingual domain names. Additionally, a 36 tunneling mechanism utilizing additional RRs is introduced for the 37 transition to a fully multilingual capable name space. 39 The Internet-Draft for DNSII-MDNP was focused purely on discussing 40 the ultimate packet protocol that is being sent around the Internet 41 for multilingual domain names. This paper complements the previous 42 paper by outlining the contemplated resolution process with the DNSII 43 protocol throughout the DNS name resolution process. 45 Whether the DNSII protocol is implemented exactly as specified in 46 DNSII-MDNP is less relevant, rather it is the idea of having a 47 multilingual packet identifier and the fall back process that 48 matters. The DNSII-MDNR successfully addresses the transitional 49 issues at each node of the DNS resolution process providing a clear 50 migration path and strategy for the deployment of a multilingual 51 enabled DNS system. It also outlines the conformance levels required 52 for basic or complete implementations for applications, resolvers and 53 name servers. 55 Table of Contents 57 1. Introduction....................................................2 58 1.1 Terminology....................................................2 59 1.2 Multilingual Domain Name Resolution............................3 60 1.2 DNSII-MDNR.....................................................3 61 2. DNSII Proposal with respect to the DNS Layers...................3 62 3. The Resolution Process..........................................5 63 3.1 Steady State Resolution........................................5 64 3.2 Client-End or Inquirer Transitional Fall-Back Strategy.........6 65 3.2.1 Tunneling MDNP through DNSII RR..............................6 66 3.2.2 Tunneling ILET RRs...........................................8 67 3.3 Resolvers & Server-End Transitional Fallback Strategy..........9 68 3.3.1 Tunneling MDNP Responses through DNSII ANS RR................9 69 3.3.2 Reinsertion of ILET and DNSII Identifier....................10 70 4. DNSII Conformance Levels.......................................10 71 4.1 Application Conformance Levels................................11 72 4.2 Resolver Conformance Levels...................................11 73 4.3 Authoritative Server Conformance Levels.......................11 74 5. Transition Schedule & Strategy.................................12 75 6. Summary of Discussion..........................................12 76 6.1 Client/Application Resolution Strategy........................13 77 6.2 Resolver Resolution Strategy..................................13 78 6.3 Authoritative Name Server Resolution Strategy.................13 79 7. Security Considerations........................................14 80 8. Intellectual Property Considerations...........................14 81 9. References.....................................................14 83 1. Introduction 85 This Internet-Draft describes details of the contemplated resolution 86 process after the deployment of DNSII-MDNP, or other multilingual 87 domain name efforts containing a bit flag multilingual packet 88 identifier or otherwise InPacket identifications for that matter. 90 The reader is assumed to be familiar with the concepts discussed in 91 the DNSII-MDNP Internet-Draft . 93 1.1 Terminology 95 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 96 and "MAY" in this document are to be interpreted as described in RFC 97 2119 [RFC2119]. 99 A number of multilingual characters are used in this document for 100 examples. Please select your view encoding type to Big-5 101 (Traditional Chinese) for them to be displayed properly. 103 1.2 Multilingual Domain Name Resolution 105 The original specifications for the DNS were designed to be open 106 enough for simple implementation of a multilingual naming system with 107 slight adjustments as laid out in DNSII-MDNP. The transition and 108 especially its resolution process during migration is however a 109 tricky problem. Several things that MUST be kept in mind is that 110 there is a initial phase, an intermediate phase and an ultimate 111 steady state phase. DNSII-MDNP only described the ideal protocol at 112 steady state, with incorporated flexibility for transition from the 113 present to multilingual as well as again towards future unknown 114 grounds. 116 It is important to remember that the ultimate form SHOULD be 117 determined and then the transition scheme laid out. While an ASCII 118 translation system might seem favorable in the short-run, it 119 effectively creates an alternative universe which is counter to the 120 spirit of the DNS. However an ASCII translation is implemented, it 121 immediately creates a "human-multilingual" universe and a "machine- 122 ASCII" universe. This document introduces a tunneling mechanism to 123 transition the DNS from today's monolingual system, through an 8-bit 124 or 7-bit migration scheme towards a truly sustainable multilingual 125 name space, arriving at a DNSII type system. 127 1.2 DNSII-MDNR 129 While DNSII-MDNP describes the framework for the ultimate protocol 130 format of a multilingual DNS, DNSII-MDNR will discuss how the packet 131 SHOULD be transported and interpreted throughout the DNS. The 132 document will describe both the intended resolution process as well 133 as part of the transition strategy from the existing DNS to a DNSII 134 enabled system. 136 2. DNSII Proposal with respect to the DNS Layers 138 The following diagram illustrates the use of DNSII-MDNP at a steady 139 state. Section 3 will discuss the fallback strategies while Section 140 4 will talk about issues on conformance levels. 142 +---------------+ 143 | | NamePrep: 144 | Application | Canonicalize in Form C/KC 145 | | Insert DNSII Identifier +---------------------+ 146 | | Insert appropriate ILET | (Base data) | 147 +---------------+ +---------------------+ 148 | | 149 | DNS Packet with DNSII | (no standard) 150 | Identifier & ILET | RECOMMENDS 151 | | UCS-2/4 152 +---------------+ | 153 | Resolver | Canonicalize, Case Fold +---------------------+ 154 | | (for cache lookup) or | Auth DNS server | 155 +---------------+ leave as is & Resolve | (Canonicalize, | 156 | | Case Fold & Lookup) | 157 | Pass Along without +---------------------+ 158 | Altering Case or Canonicalization | 159 | | 160 | <----- DNS service interface -----> | 161 +------------------------------------------------------------------+ 162 | DNS service | 163 | +-----------------------+ +--------------------+ | 164 | | Forwarding DNS server | | Caching DNS server | | 165 | +-----------------------+ +--------------------+ | 166 | | 167 | +-------------------------+ | 168 | | Parent-zone DNS servers | | 169 | +-------------------------+ | 170 | | 171 | +-------------------------+ | 172 | | Root DNS servers | | 173 | +-------------------------+ | 174 | | 175 +------------------------------------------------------------------+ 177 Please note that at each level, the domain name is being 178 canonicalized. This is to ensure that at the end, characters that 179 can be represented by a single code point will not be otherwise 180 compared resulting in inconsistent reply to a humanly identical name. 181 It is RECOMMENDED that applications SHOULD conduct canonicalization 182 while servers MUST. Duplicating the process is fine because if a 183 character is already composed, it will not compose again with another 184 character. 186 This arrangement is very similar to the ASCII case folding 187 experienced in the DNS today. In the original specifications, it was 188 RECOMMENDED that query sent be left as they are and case folding done 189 only at the server end. Some application implementations however do 190 perform the case folding at the user end. As the query arrives at 191 the server, it is still case folded. 193 Case folding for multilingual domain names should follow the existing 194 implementations for ASCII names, where the application SHOULD and the 195 server MUST. 197 3. The Resolution Process 199 It is inevitable that at the end of the day, the entire DNS chain 200 SHOULD be updated in order for multilingual domain names to be as 201 efficiently resolved as names under the current DNS. DNSII strives 202 to provide a schema that ultimately brings the system to a desirable 203 steady state while carefully giving considerations to all the 204 transition issues. These include the considerations that at the 205 application end, there is already a preference and an installed base 206 of character encoding that may or may not conform to the desires of 207 the server end operations. The use of ILET is therefore highly 208 desirable and essential. 210 3.1 Steady State Resolution 212 At steady state, the resolution process of multilingual domain names 213 SHOULD be identical to the existing system. Additional steps of 214 going through alphanumeric translation are unnecessary and 215 undesirable. 217 With DNSII, the contemplated steady state process resembles the well- 218 known DNS model laid out in RFC1035. 220 Local Host | Foreign 221 | 222 +---------+ +----------+ | +---------+ 223 | | user queries | |queries | | | 224 | |(DNSII identifier | | | | | 225 | | ILET=UCS without | | | | | 226 | User | Transformation) | | | | Foreign | 227 | Program |------------------>| Resolver |---------|->| Name | 228 | | | | | | Server | 229 | |<------------------| |<--------|--| | 230 | | user responses | |responses| | | 231 | | | | | | | 232 +---------+ +----------+ | +---------+ 233 | ^ | 234 cache additions | | references | 235 v | | 236 +----------+ | 237 | cache | | 238 +----------+ | 240 Eventually, an ISO 10646 UCS without transformation is desired as the 241 common format. The benefits of having a uniform byte length encoding 242 far exceeds the seemingly easier transformation solution. Especially 243 considering that the DNS requires a label count that should reflect 244 the number of characters in a label. Of course there exists 245 combination characters in the ISO 10646 specifications as well, but 246 after canonicalization, only the ones that must use combinations 247 remain and they are usually meaningful depictions. 249 The importance of this count value is further demonstrated by 250 scrambling efforts to extend the size of this field or to compress 251 character encoding to accommodate multilingual characters. With 252 DNSII, this no longer constitutes an issue because any language will 253 be able to share the same number of characters thanks to the use of 254 ISO 10646. As a matter of fact, the desire to use uniform byte 255 length characters formed part of the original intent of the ISO 10646 256 initiative anyway. 258 3.2 Client-End or Inquirer Transitional Fall-Back Strategy 260 For a DNSII aware Client, it will be able to create DNSII packets 261 which provides precise character data of the domain name in question. 262 However, if it encounters a non-compliant resolver, it MUST be able 263 to fallback to a format acceptable by current resolvers. 265 +---------+ +----------+ 266 | | (1) user queries | | (2) if Resolver is 267 | | (DNSII identifier | | DNSII compliant, 268 | | ILET=UCS without | | Packet is resolved 269 | User | Transformation) | | accordingly. If 270 | Program |----------------------->| Resolver | not fallback to (3) 271 | | | | 272 | |<-----------------------| | 273 | | (3) Upon the detection | | 274 | | of the DNSII Flag | | 275 | | resolver will reply | | 276 | | with _Format Error_ | | 277 | | | | 278 | |----------------------->| | (5) Current resolu- 279 | | (4) Send QNAME using | | tion process begins 280 | | local encoding or | | with the DNSII RR 281 | | UTF-8 with or without | | passed along as an 282 | | Additional DNSII RR | | Additional RR 283 +---------+ +----------+ 285 3.2.1 Tunneling MDNP through DNSII RR 287 An additional DNSII RR would be tunneled through using the format of 288 a TXT RR with the RDATA part containing the multilingual labels in a 289 DNSII compliant format. The TTL of the RR MUST be set to zero to 290 avoid caching. 292 It is not feasible to have a new RR type just for DNSII because the 293 resolver might reject RRs with unknown types. For the name used in 294 the QNAME as well as the NAME field of the DNSII RR UTF-8 MAY be used 295 as the default fallback encoding. However, an arbitrary ASCII name 296 MAY also be used just for the purpose of tunneling. The TTL for 297 responses to tunneled requests MUST be set to zero to avoid caching 298 at any level in the DNS. More detailed description in Section 3.4. 300 For older DNS servers, requests with a non-empty additional 301 information section MAY produce error returns, however since the 302 deployment of DNSSEC, especially for TSIG considerations, this no- 303 longer constitutes a problem. Basic security prepared servers such 304 as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR. 306 It is possible to use ACE/RACE type translations at this level, 307 however it is more advisable to use a truly arbitrary label such as 308 _-for-tunneling-only-_. So doing requires only reserving one 309 arbitrary name while ACE/RACE creates one more arbitrary name for 310 each new multilingual name registered, which will eventually 311 contribute to the fracturing of the DNS. 313 As an example, a tunneling packet for the domain name: host. ���W�t�� 314 .tld. (4host4���W�t��3 tld0) will be represented as: 316 (in the QNAME field) 318 1 1 1 1 1 1 1 1 1 1 1 1 319 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 320 +---------------------------------------------------------------+ 321 12|0 0| 4 | h | o | s | 322 +---------------------------------------------------------------+ 323 16| t | 20 | - | f | 324 +---------------------------------------------------------------+ 325 20| 0 | r | - | t | 326 +---------------------------------------------------------------+ 327 24| u | n | n | e | 328 +---------------------------------------------------------------+ 329 28| l | i | n | g | 330 +---------------------------------------------------------------+ 331 32| - | o | n | l | 332 +---------------------------------------------------------------+ 333 36| y | - | 3 | t | 334 +---------------------------------------------------------------+ 335 40| l | d | 0 |... 336 +-----------------------------------------------+ 337 (The Additional DNSII RR Tunneled in TXT RR form) 339 : : 340 / / 341 +---------------------------------------------------------------+ 342 80|1 1| 12 | TYPE = TXT = 16 | 343 +---------------------------------------------------------------+ 344 84| CLASS = IN = 1 | TTL | 345 +---------------------------------------------------------------+ 346 88| = 0 | RDLENGTH = 22 | 347 +---------------------------------------------------------------+ 348 92|0 0| 4 | h | o | s | 349 +---------------------------------------------------------------+ 350 96| t |1 0|0 0| UCS-2=1000 | 4 | 351 +---------------------------------------------------------------+ 352 100|1 1| 13 |1 0|z| ILET=2 | 4 | 353 +---------------------------------------------------------------+ 354 104| �� (U+57DF) | �W (U+540D) | 355 +---------------------------------------------------------------+ 356 108| �t (U+7CFB) | �� (U+7D71) | 357 +---------------------------------------------------------------+ 358 112|1 1| 38 | 359 +-------------------------------+ 361 The reason a DNSII RR is attached is to alert the authoritative DNS 362 server that the query is DNSII compliant while being able to tunnel 363 the request through non-compliant resolvers without any loss of 364 information. 366 3.2.2 Tunneling ILET RRs 368 Another fallback strategy is to tunnel just the ILET instead of the 369 entire DNSII label. If UTF-8 or a local encoding is used as the 370 QNAME, then the arbitrary ASCII label is no longer necessary. The 371 tunneled RR therefore need only consist of an ILET indicating the 372 encoding format used. 374 Within the RDATA of an ILET RR masked as a TXT RR the first 4 bytes 375 will be used to indicate that it is an ILET and the following 4 bytes 376 to reflect the MIBenum of the encoding used. 378 Following the example given in 3.2.1, the QNAME would be in UTF-8 379 (MIBenum = 106), while the additional ILET RR would be in the form: 381 : : 382 / / 383 +---------------------------------------------------------------+ 384 80|1 1| 12 | TYPE = TXT = 16 | 385 +---------------------------------------------------------------+ 386 84| CLASS = IN = 1 | TTL | 387 +---------------------------------------------------------------+ 388 88| = 0 | RDLENGTH = 22 | 389 +---------------------------------------------------------------+ 390 92| I | L | E | T | 391 +---------------------------------------------------------------+ 392 96| 0 | 1 | 0 | 6 | 393 +---------------------------------------------------------------+ 395 3.3 Resolvers & Server-End Transitional Fallback Strategy 397 The tunneling scheme described in Section 3.2 assumes that the 398 authoritative server is fully DNSII compliant. This assertion is 399 laid out in Section 4.3 where it is discussed that only fully 400 compliant servers SHOULD serve multilingual names directly under 401 their authoritative zone. In any other case, the arbitrary domain 402 "-for-tunneling-only-" should result in an NXDomain response. 404 For security aware servers, an NXT RR of the last name wrapped by its 405 first name in the zone records will be returned because of the 406 leading "-" for the tunneling label. 408 If the application end is not DNSII compliant, the fallback 409 resolution strategy for resolvers would simply be to pass along the 410 labels in their 8-bit format and determine the existence of the 411 requested name as usual. If a tunneled DNSII RR is detected, by way 412 of a label constituting entirely of _-for-tunneling-only-_ and the 413 existence of a valid DNSII RR, the resolver should attempt to resolve 414 the name according to the DNSII specification and tunnel the answer 415 back to the inquirer. 417 3.3.1 Tunneling MDNP Responses through DNSII ANS RR 419 To tunnel a DNSII compliant answer through a non-compliant resolver, 420 another DNSII ANS RR is tunneled. Also using the TXT RR format as a 421 mask. TXT RRs are best used because it is a valid RR and its RDATA 422 is an unrestricted byte stream determined only by the RDLENGTH. The 423 RDATA for a DNSII ANS RR would be the entire content of a regular 424 response RR attached to a DNSII format name. 426 Continuing on the example given in Section 3.2, suppose an A record 427 is requested and the IP address returned for the domain host.���W�t�� 428 .tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the 429 following form will be included: 431 : : 432 / / 433 +---------------------------------------------------------------+ 434 114|1 1| 12 | TYPE = TXT = 16 | 435 +---------------------------------------------------------------+ 436 118| CLASS = IN = 1 | TTL | 437 +---------------------------------------------------------------+ 438 122| = 0 | RDLENGTH = 16 | 439 +---------------------------------------------------------------+ 440 126|1 1| 92 | TYPE = A = 1 | 441 +---------------------------------------------------------------+ 442 130| CLASS = IN = 1 | TTL | 443 +---------------------------------------------------------------+ 444 134| = 3600 | RDLENGTH = 4 | 445 +---------------------------------------------------------------+ 446 138| 123 | 4 | 5 | 6 | 447 +---------------------------------------------------------------+ 449 Note that compression is available in the DNSII RRs. While the 450 tunneling TXT mask uses the ASCII tunneling name and therefore points 451 back to the QNAME at offset 12, the tunneled A Record response uses 452 the offset corresponding to the DNSII compliant labels at 92. While 453 the TTL of the TXT mask MUST be zero, the tunneled A Record RR 454 contains a regular TTL, in this case 3600. 456 3.3.2 Reinsertion of ILET and DNSII Identifier 458 When a resolver receives an incoming query with a tunneled DNSII/ILET 459 RR, it SHOULD reconfigure the query into a fully compliant format 460 before engaging in further resolution. If a "00" query is received, 461 the resolver should convert the label into UTF-8, set the DNSII 462 identifier "10" on and set the ILET to UTF-8. 464 In the scenario where the client end is not DNSII compliant, either a 465 local encoding 8-bit stream or a UTF-8 encoded stream without the 466 DNSII flag nor ILET will be transported. During the transition 467 period, should this occur, the above forced UTF-8 conversion and ILET 468 insertion would take place and it would be up to the authoritative 469 server to determine the existence of the requested domain. InZone 470 DNSII handling mechanism will serve to take care of these 471 transitional exceptions. 473 4. DNSII Conformance Levels 475 DNSII is designed for a smooth transition from the existing ASCII 476 based DNS to a multilingual capable DNS. Therefore, it is not 477 necessary for all servers and applications to be switched to 478 multilingual capable before starting the deployment. 480 4.1 Application Conformance Levels 482 The BASIC compliancy for applications would be to remove validity 483 checks for domain names. The resolution process will determine a 484 non-existing domain name, so there really is no need to prevent a DNS 485 packet with multilingual labels to be sent through the wires. 487 The INTERMEDIATE compliancy for applications involves the insertion 488 of the DNSII identifier as well as the ILET according to the local 489 inputting and screen scheme. If a user is using a JIS format scheme, 490 it should set the ILET to reflect it being used. At the same time, 491 the tunneling mechanism discussed in Section 3.2 MUST also be in 492 place. 494 FULLY compliant applications will send all DNS packets with the DNSII 495 identifier and the ILET set to UCS-2/4. The fallback scheme discussed 496 in Section 3.2 MUST also be in place. InZone DNSII mechanisms SHOULD 497 also be available to deal with local encoding exceptions. 499 4.2 Resolver Conformance Levels 501 The BASIC compliancy for resolvers would be to allow an 8-bit clean 502 approach to name resolution. Also, it should be made sure that the 503 additional DNSII RR (TXT) will not be truncated during resolution. 505 The INTERMEDIATE compliant resolvers MUST understand how to process 506 the DNSII identifier as well as not reject the ILET. Interpretation 507 of the name is not required so it is NOT necessary for the resolvers 508 to be able to map all or any of the ILET values (with the alternative 509 approach in DNSII-MDNP, the ILET value corresponds to the byte length 510 of the characters contained in the label, which makes the count 511 workable even if the ILET value is not known by the resolver). In 512 this scenario caching will be for exact comparison only (label to 513 label with ILET intact). The important criteria is for the resolver 514 to be able to pass along the DNS query to the corresponding 515 authoritative server and obtain a correct response. 517 FULLY compliant resolvers will be able to process the DNSII identifer 518 and know all the ILET values for full function name mapping. Cache 519 name lookup will be fully enabled and inquiry fallback mechanism 520 discussed in Section 3.2.2 SHOULD be performed in the event of 521 encountering a non-compliant server. 523 4.3 Authoritative Server Conformance Levels 525 Authoritative servers MUST be fully compliant before attempting to 526 serve multilingual sub-domains under its authoritative zone. They 527 should however prepare for the transition towards a multilingual name 528 space even if they do not intend to deploy it right away. 530 The BASIC compliancy for authoritative name servers is to allow an 8- 531 bit clean approach towards sub-domains that are not directly under 532 its authority (i.e. sub-sub-domains). 534 The INTERMEDIATE compliant name server will be able to process the 535 DNSII identifier and ILET without rejecting the query. The 536 authoritative zone as well as its direct sub-domains however SHOULD 537 not include the use of the DNSII flags because ILET values are not 538 understood at this compliancy level. 540 FULLY compliant name servers will be able to handle DNSII compliant 541 label formats at its sub-domain levels. That is, fully compliant 542 root servers will be able to serve multilingual TLDs, fully compliant 543 TLD servers will be able to serve multilingual SLDs, etc. 545 5. Transition Schedule & Strategy 547 DNSII is designed to allow a gradual adoption of multilingual domain 548 names on the Internet. The transition strategy is therefore geared 549 to be demand-pull instead of a technology-push incentive. However, 550 to provide a platform for a demand-pull approach, it is required for 551 operators to first safeguard their system. The simple approach as 552 laid out in Section 4 is to propose that servers take a 8-bit clean 553 approach on name resolution. 555 As discussed in DNSII-MDNP, it is reasonable for the deployment of 556 DNSII-MDNP at the registry level first to draw demand for the service 557 and let the host level DNSs with multilingual names to begin 558 migration first. DNS operators around the world should however 559 prepare for the transition and begin the deployment of DNSII 560 depending on their interest in serving multilingual domain names, 561 according to the conformance levels laid out in Section 4, beginning 562 from BASIC compliancy for operators that are least interested to a 563 FULLY compliant server for operators who wishes to provide 564 multilingual capabilities for their users. 566 The root servers could easily be adjusted to be a BASIC compliant 567 authoritative name server. Once the demand is proven and the 568 stability of the system tested, they too could transition to fully 569 compliant authoritative servers so that multilingual TLDs could be 570 rolled out. 572 6. Summary of Discussion 574 This document introduces the contemplated transition and steady state 575 resolution process for multilingual domain names with a DNSII 576 compliant format. Two tunneling mechanisms using the TXT RR was 577 introduced for the preservation of information during transitional 578 resolution. 580 6.1 Client/Application Resolution Strategy 582 Send Query in DNSII format 583 IF RCODE = Format Error 584 THEN send query in UTF-8/Local Encoding AND append DNSII RR 585 IF RCODE = Format Error 586 THEN send Query in ASCII with _-for-tunneling-only-_ label 587 AND append DNSII RR 588 AND check for DNSII ANS RR in response 589 ELSE proceed and check for DNSII ANS RR in response 590 ELSE proceed as usual 592 6.2 Resolver Resolution Strategy 594 (*)IF incoming request is in pure DNSII format 595 THEN resolve according to ILET in cache and by recursive lookup 596 IF encounter RCODE = Format Error 597 THEN send query in UTF-8 AND append DNSII RR 598 IF RCODE = Format Error 599 THEN send query in ASCII with _-for-tunneling-only-_ 600 label 601 AND append DNSII RR 602 AND check for DNSII ANS RR in response 603 ELSE proceed and check for DNSII ANS RR in response 604 ELSE proceed as usual with pure DNSII Format (*) 605 AND respond in pure DNSII format 606 ELSE IF incoming request has tunneled MDNP information 607 THEN resolve using the information in the appended DNSII RR 608 Reset Query using DNSII Format and go through (*) 609 AND convert back to tunneling format before responding to query 610 With DNSII ANS RR appended to response 611 AND set TTL for regular RRs in the Answer field to be = 0 612 ElSE IF incoming request is in the original "00" label format 613 AND no tunneled information is included 614 AND the label contains characters beyond A-z, 0-9 or "-" 615 THEN force convert all labels to UTF-8 616 AND query using DNSII Format and go through (*) 617 ELSE proceed as usual (existing ASCII based names) 619 6.3 Authoritative Name Server Resolution Strategy 621 IF incoming request is in pure DNSII format 622 THEN resolve according to ILET 623 AND respond in pure DNSII format 624 ELSE IF incoming request has tunneled MDNP information 625 THEN resolve using the information in the appended DNSII RR 626 AND convert back to tunneling format before responding to query 627 With DNSII ANS RR appended to response 628 AND set TTL for regular RRs in the Answer field to be = 0 629 ELSE use InZone DNSII mechanisms AND use 8-bit clean approach 630 7. Security Considerations 632 DNSII RRs will be secured through transaction authentication, while 633 DNSII ANS RRs could have their own SIG RRs. In general, the DNSII- 634 MDNR should not constitute any extra burden on DNS security. 636 8. Intellectual Property Considerations 638 It is the intention of Neteka to submit the DNSII protocol and other 639 elements of the multilingual domain name server software to IETF for 640 review, comment or standardization. 642 Neteka Inc. has applied for one or more patents on the technology 643 related to multilingual domain name server software and multilingual 644 email server software suite. If a standard is adopted by IETF and 645 any patents are issued to Neteka with claims that are necessary for 646 practicing the standard, any party will be able to obtain the right 647 to implement, use and distribute the technology or works when 648 implementing, using or distributing technology based upon the 649 specific specifications under fair, reasonable and non-discriminatory 650 terms. 652 Other DNSII related documents and discussions could be found at 653 http://www.dnsii.org. 655 9. References 657 [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name 658 Protocol", August 2000 660 [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 661 1700, October 1994. 663 [ISO10646] ISO/IEC 10646-1:2000. International Standard -- 664 Information technology -- Universal Multiple-Octet Coded 665 Character Set (UCS) 667 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 668 Facilities," STD 13, RFC 1034, USC/ISI, November 1987 670 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 671 Specification," STD 13, RFC 1035, USC/ISI, November 672 1987 674 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 675 Requirement Levels," RFC 2119, March 1997 676 Authors: 678 Edmon Chung 679 Neteka Inc. 680 2462 Yonge St. Toronto, 681 Ontario, Canada M4P 2H5 682 edmon@neteka.com 684 David Leung 685 Neteka Inc. 686 2462 Yonge St. Toronto, 687 Ontario, Canada M4P 2H5 688 david@neteka.com