idnits 2.17.1 draft-ietf-idn-dnsii-trace-01.txt: -(156): 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 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 8 instances of lines with non-ascii characters in the document. 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC6890-compliant IPv4 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 150: '...th a domain name MUST be upgraded with...' RFC 2119 keyword, line 333: '... In essence, it SHOULD maintain uniqu...' RFC 2119 keyword, line 335: '...eme. The system SHOULD reject domain ...' RFC 2119 keyword, line 414: '...ne administrator MUST upgrade their na...' RFC 2119 keyword, line 488: '...ver (BIND, etc.) MAY NOT be capable of...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Note that your current DNS server (BIND, etc.) MAY NOT be capable of handling such a setup. IDNX capability MUST be patched or otherwise upgraded and installed into the existing server if this feature is desired. -- 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 (July 2002) is 7950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 112, but not defined == Unused Reference: 'IDNA' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'PUNYCODE' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'NAMEPREP' is defined on line 690, but no explicit reference was found in the text Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDN Edmon Chung & David Leung 2 Internet Draft Neteka Inc. 3 4 Intended Category: Informational July 2002 6 Transitional Reflexive ACE � IDN Transition (IDNX) 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 except that the right to 12 produce derivative works is not granted. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The reader is cautioned not to depend on the values that appear in 23 examples to be current or complete, since their purpose is primarily 24 educational. Distribution of this memo is unlimited. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document, while sharing a similar concept, is an overhaul of 34 TRACE-00 and describes a strategy for domain name server operators to 35 prepare and transition their services for multilingual domain names 36 (IDN � Internationalized Domain Names). 38 The TRACE-01 or IDNX (IDN Transition) approach accepts that users 39 with non-IDN aware applications will be attempting to access 40 multilingual domain names. Hence it is the registry or domain 41 operator's responsibility to provide an IDN solution that resolves 42 these issues to make it a seamless transition experience for 43 technically unsophisticated users. 45 In essence, the IDNX approach embraces a complementary server-side 46 implementation to smooth the transition. IDNX ready domain servers 47 should be backward compatible, and successfully resolve IDN requests 48 sent via non-IDN aware applications, whether they are formatted in 49 local encoding, UTF-8 or an identifiable variant; as well as forward 50 compatible, and be able to resolve ACE requests. 52 The IDNX approach also utilizes a dynamic CNAME mechanism (similar to 53 TRACE-00) to provision for the sub-delegation of multilingual domain 54 names to hosts running non-IDN aware DNS servers. 56 Table of Contents 58 Abstract...........................................................1 59 1. Introduction....................................................2 60 1.1 Terminology....................................................3 61 1.2 Assumptions....................................................3 62 2. Common Misconceptions...........................................3 63 3. The reality of a Purebred IDNA Approach.........................3 64 3.1 Lengthy Transition & User Confusion............................4 65 3.2 Registry Responsibilities......................................5 66 4. Complementary Server-end Brute Force Resolution.................5 67 4.1 The IDNX Premise...............................................5 68 4.2 Resolving Domain Names.........................................6 69 4.3 Extent of Resolution...........................................6 70 4.4 Ambiguity Resolution...........................................7 71 4.5 Complementing IDNA (OPTIONAL)..................................7 72 5. Delegating Multilingual Domain Names............................8 73 5.1 Dynamic CNAME..................................................8 74 5.2 Setting up a Multilingual Domain Name at the Registry..........9 75 5.2.1 Character Equivalence Policies (OPTIONAL)...................10 76 5.3 Setting up a Multilingual Domain Zone at the Host.............11 77 5.4 Complementing IDNA............................................11 78 6. Using Multilingual Domains on other Applications...............11 79 6.1 IDN in Email Addresses........................................11 80 6.2 Hosting Websites based on IDN.................................12 81 6.3 Other Known Issues about using IDN............................12 82 7. Security Considerations........................................13 83 References........................................................13 84 Acknowledgements..................................................14 86 1. Introduction 88 During the lengthy discussion at the IETF IDN workgroup, the question 89 about time-to-deployment is often being raised and considered a 90 critical concern. However little word was said on any actual 91 transition path towards IDN. This document provides a comprehensive 92 guide to the issues surrounding the deployment as well as information 93 on resolving them during the transition period. 95 This document is intended to be an informational paper offering 96 suggestions to implementers of IDN and registries wishing to provide 97 IDN registration to make it a more seamless transition for end users. 98 IDNX is a transitory approach and is complementary and compatible to 99 the eventual standard protocol for IDN. 101 In fact, some or all of the aspects and suggestions discussed in this 102 paper has been implemented at various domain registries already. The 103 extent of coverage differs from the different implementations. One 104 key observation however is that all are compatible and cause no 105 damage to the Internet at large. 107 1.1 Terminology 109 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 110 and "MAY" in this document are to be interpreted as described in RFC 111 2119 [RFC2119]. 113 1.2 Assumptions 115 This document assumes that the reader has basic knowledge of the DNS 116 and IDN. For more information on the IDN discussions and background 117 knowledge checkout: http://neteka.com/en/pages/products/position.html 119 2. Common Misconceptions 121 There is a common misconception among domain registries and 122 registrars that once a proposed IETF standard (in the form of an RFC: 123 Request for Comments) for multilingual and Internationalized domain 124 names (IDN�s) is published; Registries will immediately be able to 125 accept registrations and deliver working multilingual domain names to 126 end-users. In fact, the publishing of RFCs for IDN is but the 127 beginning of a long transition towards a common and universal 128 multilingual namespace. 130 Another common misconception is that a server-end approach would 131 cause a lengthier transition. That however is only based on a server 132 protocol overhaul for IDN and not the use of a server-end transitory 133 solution. This document specifically describes a solution for the 134 transition and utilizes a complementary server-end approach to smooth 135 the move with the end user in mind. 137 3. The reality of a Purebred IDNA Approach 139 Simply put, ACE is a process whereby multilingual domain names are 140 converted into an alphanumeric string containing only A-Z, 0-9 and 141 hyphens "-" (e.g. bq--ad9ebbvfnqerv.example). IDNA mandates that 142 this transformation take place before an application, for example the 143 browser, sends a DNS request over the Internet (over-the-wire) to a 144 registry name server. 146 Success of this "Client" only approach therefore has two inherent 147 pre-conditions; 149 1. Firstly, in order for IDNA to function universally, all software 150 programs that interact with a domain name MUST be upgraded with 151 the ACE standard (browsers, email applications, html editors, 152 audio/video streaming applications, word processors, operating 153 system tools, ftp agents, etc.). Or the user will have to type 154 in the ACE string to reach multilingual domains; and 156 2. The success of IDN�s will depend on the successful propagation of 157 those client software, which will be highly dependant on a) the 158 successful dustribution of client plug-in in the short-term and 159 b) the incorporation of the standard in next generations of 160 application software (e.g. MSIE and MS Outlook) 162 3.1 Lengthy Transition & User Confusion 164 A key concern with respect to a purebred client approach to IDN is 165 that there are simply no efficient or effective means to distribute 166 the client plug-ins. 168 Even if we assume that a dominant software provider, such as 169 Microsoft, with their penetration into the browser and email client 170 market, was to introduce a new version of its Internet Explorer and 171 Outlook line of products with the IDNA client built in, it will still 172 take a considerable amount of time before these new versions reach 173 the majority of desktops around the Internet. 175 Using Microsoft IE 6.0 as a yardstick for new browser adoption rates, 176 which yielded an eye-popping 34% penetration within 7 months of its 177 release, the industry is still effectively looking at a minimum of 178 24-36 months or more before a critical mass of Internet users will 179 have adopted an IDN standard-ready-browser. That is not taking into 180 consideration the lead-time for Microsoft to release the next version 181 of their software, let alone whether IDN will make the cut for its 182 next version, and that the IDNA components are stable. This will 183 realistically add another 12 months to the process. 185 Adoption rate from different regions however may be different and 186 correlated to the urgency of having a complete IDN system in place. 187 For example, regions where non-Latin based character sets may have 188 more adoption faster. However early set backs by domain providers 189 who have not addressed the transitional issues for the user may cause 190 loss of confidence by users of multilingual domain names. 192 Finally, the client side approach to internationalized domains is 193 especially susceptible to client plug-in software conflicts as 194 providers scramble to push out these plug-in software applications. 195 Client plug-in providers may purposefully or inadvertently interfere 196 with how the browsers handle multilingual characters causing greater 197 confusion. 199 To summarize, the purebred IDNA approach requires no changes to the 200 DNS infrastructure but does require fast and efficient distribution 201 of client software that supports the standard, which is difficult to 202 achieve. Registries that cannot provide reasonable access to IDNs 203 from the start will likely experience support headaches and many 204 dissatisfied users who are confused and frustrated because their 205 multilingual domain names do not work. Further, without general 206 accessibility, the value of multilingual domains will be compromised, 207 ultimately causing the move towards IDN to be even slower. 209 3.2 Registry Responsibilities 211 Because the average Internet user is not expected to be technically 212 sophisticated and know that they have to upgrade their existing 213 applications (such as the browser) before using multilingual domain 214 names, it is the opinion of the authors that it becomes the 215 registry�s responsibility to provide a multilingual domain deployment 216 that is transparent to its users. 218 In other words, the registry should be prepared to accept and resolve 219 multilingual domain requests from users with existing software when 220 they deploy and offer multilingual domain registrations to 221 registrants. 223 Of course, individual policies for each registry may differ. This 224 document intends to offer some suggested solutions to domain registry 225 operators in dealing with real life issues about the deployment of 226 multilingual domain names. 228 4. Complementary Server-end Brute Force Resolution 230 We understand that it will be a lengthy transition to IDNA given that 231 it requires upgrade of millions of clients and applications that are 232 already out there. IDNX complements it with a solution that can be 233 deployed at one single node (the registry) and make it possible for 234 the millions of existing users and hosts to immediately be able to 235 access and use multilingual domains. 237 4.1 The IDNX Premise 239 The premises of IDNX are: 241 1. To support and complement the adoption of the open IDN standard; 242 2. To present an option for a working solution that provides a 243 seamless transition to the IDN standard; 244 3. Be fully compliant with the IDN standard by preparing the 245 registry for multilingual domain requests sent via existing 246 applications as well as upgraded IDN aware applications; 247 4. Accepting and addressing the fact that multilingual domain 248 requests will be successfully sent to the registry from existing 249 software and will resolve those requests instead of avoid them; 250 5. To provide a transitory solution that will make multilingual 251 domain names functional immediately; 252 6. To allow the host for a multilingual domain name to use an 253 existing (BIND, etc.) DNS software by using only an ACE record 254 (only registry Servers need be updated or supplemented); 256 In short, the authors believe that a complementary server side 257 approach to IDN is a crucial component for the successful deployment 258 of IDNs at a registry. This document outlines possible approaches to 259 the resolving of an IDN and how IDNX can both accelerate adoption and 260 reduce the risk of deployment of the IDN standard for registries. 262 4.2 Resolving Domain Names 264 In general, there are three types of IDN requests that a registry 265 server may receive: 1. Domain in the form of UTF8 encoding; 2. Domain 266 in the form of its local encoding (GB, Big-5, JIS, KSC, ISO8859-1..13 267 etc.); 3. Domain is in an ACE (ASCII Compatible Encoding) format. 268 Each of these types includes both the possibility that the received 269 request is in its pure form or that it is a variant of the type. 270 Because the application (browser or the operating system) was not 271 designed for multilingual domain names, even though it does send out 272 the domain request, it often tampers with the characters before 273 sending, causing the advent of a variant being generated. 275 4.3 Extent of Resolution 277 Type 1 requests, where a domain is sent in the form of UTF8 encoded 278 characters, are generally received from more recent versions of 279 browsers and operating platforms. These include Microsoft Internet 280 Explorer 5 and above, Netscape 6 and above and applications based on 281 the Windows 2000 or XP platform. These applications were designed to 282 deal with multilingual characters using Unicode, however, because it 283 was not specifically programmed for IDNs, it sometimes malfunction 284 when presented with such. The result is that a variant of the 285 original UTF8 character is formed and sent to the DNS. 287 Type 2 requests, where a domain is sent in the form of local encoded 288 characters (GB, Big-5, JIS, KSC, ISO8859-1..13, etc.), are generally 289 received from earlier versions of browsers and operating platforms. 290 These include Microsoft Internet Explorer 4, Netscape 4 most other 291 applications based on the Windows 98 or earlier platform. These 292 applications were not designed to deal with multilingual characters 293 using Unicode at all and therefore will be sending out the IDN in its 294 local encoding. Mostly, the domain is also not tampered with before 295 sending; therefore a pure local encoding may be received. However 296 under some platforms and circumstances, it will also try to 297 reinterpret a multilingual domain name. The result is that a variant 298 of the original local encoding is formed and sent to the DNS. 300 Type 3 requests, where a domain is sent in the form of ACE encoded 301 characters (RACE, DUDE, UTF5, AMC-Z, etc.), means that the 302 application has been upgraded with an IDN client. Because of the 303 evolving standard, depending on the version or provider of the 304 client, the type of ACE string may be different. Additionally, these 305 client plug-ins are susceptible to buggy code, as they are being 306 created as beta products by providers experimenting with the evolving 307 IDN standard. Misbehaviors caused by browsers and operating systems, 308 which are not taken into consideration by the client software also 309 gives way to the creation of variants in ACE formats. 311 Even though variants are created as a derivation form the pure form, 312 these variations are consistent and predictable, and therefore can be 313 resolved definitively and uniquely. There is no guessing involved. 314 An IDNX server could be designed to handle both requests sent in its 315 pure form as well as its variants from the three types of 316 multilingual domain name requests. The extent of the coverage is 317 only dependent on the extent of research an implementer has put on 318 the subject and their understanding of the IDN issues. 320 4.4 Ambiguity Resolution 322 Another concern is for character encoding conflicts between the 323 various 8-bit encoding schemes (including UTF8 and local encoding 324 schemes). IDNX suggests the handling of these issues at the point of 325 registration. On the registration side, the domain name is 326 definitively registered using Unicode, regardless of whether Unicode 327 or local encoding was used as input. The desired domain name is 328 confirmed with the user at the interface, ensuring that the name 329 registered is accurate. 331 During the availability search, encoding conflict is checked to 332 ensure no existing domain name caused an encoding conflict with the 333 requested domain. In essence, it SHOULD maintain uniqueness of a 334 codepoint string (in its raw hex values) regardless of its original 335 encoding scheme. The system SHOULD reject domain names on a first 336 come first serve basis for domains that will cause conflict with any 337 local encoding or UTF8 string (or variants if applicable). 339 By taking care of both the domain registration and the resolution 340 side at a domain registry, IDNX can ensure a complete solution and 341 extensive coverage for multilingual domain resolution right from the 342 start. Not only will users with IDN aware plug-ins be able to access 343 the multilingual domain names offered by registries or domain 344 operators with IDNX, users with existing software, existing browsers 345 will also be able to successfully access these names, making it a 346 truly seamless and transparent transition. 348 4.5 Complementing IDNA (OPTIONAL) 350 Note that this is an optional feature that can be deployed 351 independently with other parts of the IDNX suggestions, this 352 particular functionality could be omitted without losing the other 353 benefits of deploying the IDNX solution. 355 To complement the propagation of IDNA clients, IDNX servers could 356 also improve the download experience by dynamically prompting the 357 user for download when users first try to access a multilingual 358 domain name. Because the IDNX solution includes a server-end 359 deployment, the server could be configured to act as a channel for 360 the IDN client at the point of access to multilingual domain names. 362 In essence, with an IDNX capable server, the registry would be able 363 to successfully intercept multilingual domain requests and offer the 364 user the option to download an IDN client plug-in. If the user 365 chooses to download the plug-in, then the domain would be resolved 366 using the ACE format. If the user declines the option to download, 367 IDNX, preserving the seamless resolution experience for the end-user, 368 would still resolve the domain. 370 The implementer should pay special attention in deploying this mode 371 of operation for an IDNX server. For example, the implementation 372 should avoid prompting the user too many times for the download. 373 There are three precautions that may be helpful: 375 1. Before prompting for download, ensure that the user do not 376 already have the client plug-in; 377 2. Cache the user and refrain from prompting again for a given 378 period of time; and 379 3. Since the download will likely make use of the http server, 380 setting up cookies may provide a solution for achieving 2. 382 More specifically, the implementer should take into consideration the 383 end-user and try not to annoy and inundate them with download 384 options. 386 Finally, note again that this is an optional feature that can be 387 independently deployed. 389 5. Delegating Multilingual Domain Names 391 Besides being backward compatible with existing client side 392 applications, the IDNX solution also intends to make it backward 393 compatible for name servers hosting delegated IDNs, as well as for 394 resolvers in the path of resolution. 396 The biggest challenge, aside from resolving the IDNs, for a registry 397 in rolling out multilingual domain names is how domain registrants 398 could host it. IDNX suggests a Dynamic CNAME mechanism, which when 399 deployed at the registry level, the delegated domain hosts could 400 simply use their existing name server (BIND, etc.) to load in the 401 long term ACE as the domain. It is also possible to further delegate 402 sub-domains to other hosts, just like with the current English only 403 domain names. 405 5.1 Dynamic CNAME 407 The ability to sub-delegate multilingual domain names to ACE only 408 hosts is achieved by using a dynamic CNAME mechanism (similar in 409 concept but different in practice to TRACE-00) to glue the 410 multilingual domain name to the long term ACE equivalent at the 411 registry DNS server. 413 The existing STD13 DNS servers do NOT support this feature. A 414 registry operator or zone administrator MUST upgrade their name 415 servers to an IDNX ready system if they wish to use Dynamic CNAME for 416 multilingual domain transition. The main reason for not using DNAME 417 or another form of resource record is that existing resolvers readily 418 support CNAME and not the others, thereby ensuring backward 419 compatibility. Furthermore, the use of a wildcard CNAME record also 420 allows Dynamic CNAME to be DNSSEC compatible (This will be further 421 discussed in Section 7). 423 The following is a brief explanation on how the dynamic CNAME should 424 work: 425 - Application sends www..example to resolver 426 - .example Registry responds with: 427 www..example CNAME www.xx--ACE.example 428 - Resolver then uses www.xx--ACE.example to query the host 429 - Therefore the host will only have to setup the xx--ACE.example zone 431 With Dynamic CNAME, the registrant for a multilingual domain name 432 will be able to host their domain with their existing DNS server 433 software and be able to create English sub-domains from it (e.g. 434 ldh..example). 436 If multilingual sub-domains are desired (e.g. ..example), 437 then the registrant could opt to also make their system IDNX capable. 439 This transitional strategy could also be deployed at the root level 440 so that multilingual TLDs could be issued and be backward compatibly 441 functional. Therefore, full multilingual addresses could be used 442 (i.e. ..). 444 5.2 Setting up a Multilingual Domain Name at the Registry 446 The concept of Dynamic CNAME is relatively simple, imagine the 447 multilingual domain name being setup at the registry as: 449 *..example IN CNAME *.xx--ACE.example 450 xx--ACE.example IN NS ns1.xx--ACE.example 452 Note again that you must upgrade to an IDNX ready DNS server in order 453 for this setup to work. Existing STD13 name servers (BIND, etc.) do 454 not readily support setting up of wildcard CNAME records as such. 456 An IDNX compatible DNS will therefore successfully provide a 457 requestor the corresponding ACE record of a multilingual domain 458 request via a CNAME response. Because STD13 DNS resolvers support a 459 CNAME RR, the resolution path would be seamless. Note that the 460 response from the registry server (as indicated in Section 5.1) 461 should be "CNAME www.xx--ACE.example" and NOT "CNAME *.xx-- 462 ACE.example". 464 In essence, no matter what the sub-domains may be for the 465 .example domain, it will be successfully sub-delegated to the 466 host server using its ACE name. 468 Conceptually, we could also setup the different types of possible 469 multilingual domain requests and variants as follows: 471 *..example IN CNAME *.xx--ACE.example 472 *..example IN CNAME *.xx--ACE.example 473 *..example IN CNAME *.xx--ACE.example 475 The actual implementation of an IDNX compatible server however may 476 cause the setup to be different. 478 For example, the implementation could make the forking of the 479 variants transparent to the zone administrator, so the administrator 480 only needs to provide one definitive record, for example, simply: 482 xx--ACE.example IN NS ns1.xx--ACE.example 484 Upon loading the zone file, the IDNX server would identify the xx-- 485 ACE.example domain as a multilingual domain and fork the variants out 486 automatically for resolution purposes. 488 Note that your current DNS server (BIND, etc.) MAY NOT be capable of 489 handling such a setup. IDNX capability MUST be patched or otherwise 490 upgraded and installed into the existing server if this feature is 491 desired. 493 5.2.1 Character Equivalence Policies (OPTIONAL) 495 This is an optional possible feature that can be implemented based on 496 the policy of the zone operator / domain registry. 498 By using the same concept, a registry may also choose to deploy 499 character equivalency policies for multilingual domain names. For 500 example to deal with identical Latin characters such as the capital 501 letter Alpha "A" and the English capital letter "A". Similarly, it 502 could also be applied to the mapping of Simplified and Traditional 503 Chinese characters. 505 Essentially, the zone operator may setup a Traditional Chinese domain 506 and dynamically CNAME it to the Simplified version in ACE format (or 507 vice versa). The operator again would ultimately determine the 508 extent of coverage. The more equivalency records are added, the more 509 variations would be taken care of, and the more complete the coverage 510 will be, but the fewer names would be available for registration. 512 For example: 513 *..example IN CNAME *.xx--ACE.example 514 *..example IN CNAME *.xx--ACE.example 516 denotes a multilingual domain name in an equivalent form. To 517 prevent conflicts, this should be considered like that discussed in 518 Section 4.4 for ambiguity resolution. That is, it should be taken 519 care of at the point of registration, when domain availability is 520 checked. 522 Take note again that this is just a possible transitory strategy. A 523 more permanent strategy for character equivalency issues may be 524 further discussed in a different context. 526 5.3 Setting up a Multilingual Domain Zone at the Host 528 At the host, the multilingual domain name will simply be setup as a 529 regular English only domain name with the ACE record. The host DNS 530 server does NOT need to be upgraded to IDNX. 532 For example: 534 xx--ACE.example IN SOA ns1.xx--ACE.example dnsmaster.xx 535 NS ns1.xx--ACE.example 536 MX 0 mail.xx--ACE.example 537 ns1 A 123.4.5.6 538 www A 123.4.5.7 539 mail A 123.4.5.8 541 As you may see, it is exactly identical to what you would do for 542 setting up an English only domain, and using English alphanumeric 543 characters only. 545 5.4 Complementing IDNA 547 Furthermore, because the IDNX architecture for registries allows for 548 the delegation of IDNs in ACE format to non-IDN aware host servers, 549 this again complements the evolving IDNA side standard whereby the 550 hosts do not necessarily have to upgrade their system for 551 multilingual domains. 553 6. Using Multilingual Domains on other Applications 555 Because domain names are used in many applications, they must be 556 taken into consideration for the transitional strategy as well. The 557 two more prominent applications are: email and website hosting. 559 6.1 IDN in Email Addresses 561 The IDNX approach will support the use of IDNs in email addresses 562 immediately. With a similar concept deployed at the email servers, 563 users will also be able to use multilingual user names along with 564 IDNs for their email address (i.e. @.example). 566 From Section 5.3, note that the MX RR (Mail Exchange Resource Record) 567 could be easily set in any existing DNS server (BIND, etc.) by simply 568 using the ACE equivalent of the multilingual domain name. It is 569 actually also possible to setup your existing mail server software 570 for email addresses with English user names (i.e. ldh@.example) 571 by using a domain independent IP setup. 573 In order to offer multilingualized user names for email addresses, an 574 email server with the IDNX concept incorporated for the management of 575 user names could be used. Similar to the domain situation, because 576 the email applications were not designed to handle multilingual email 577 addresses, some issues may arise. Also, similarly, we should take 578 that into consideration in the design and deployment of an IDNX ready 579 email server, to make the user experience seamless as multilingual 580 names are deployed. 582 The same three types of scenarios exist for multilingual email 583 addresses: 1. Address arrives in the form of UTF8 encoding; 2. 584 Address arrives in local encoding format; 3. Address has already been 585 converted to ACE before it arrives. For type 1 & 2, variants may 586 also be generated and are possibly caused by the multilingual email 587 address being converted into MIME format. As for type 3, the same 588 causes for domain names apply. That is, caused by experimental 589 software, versioning, as well as lack of consideration for 590 interaction with other applications. Unlike domain names, variants 591 of email addresses are less likely caused by malfunctioning of the 592 software agent during transport but rather as an effect by design. 594 Therefore, to successfully provide comprehensive coverage for 595 immediately usable multilingual email addresses before massive 596 distribution of client side plug-ins is achieved, we should 597 incorporate in the design, consideration for all these variants, 598 sharing a similar strategy as IDNX. 600 Furthermore, IDNs within the email headers could be inscribed in ACE 601 format. This inscription could take place at the SMTP server to 602 allow the user to send the email using their existing MUA. Again, 603 this strategy would further promote and complement the IDNA approach. 605 6.2 Hosting Websites based on IDN 607 Besides hosting the domain name (as discussed in Section 5.3), under 608 an IDNX registry, registrants can also use their existing web servers 609 to host websites for multilingual domain names. 611 To host the multilingual domain name site using an existing web 612 server, the user should configure their web server for IP hosting. 613 In order to offer virtual name hosting however, because it involves 614 the configuration of multilingual domain names, users should elect to 615 use a multilingual enhanced web server based on an IDNX type concept. 617 That is, having the web server capable of accepting the three types 618 of possible requests: 1. Http requests in the form of UTF8 encoding; 619 2. Http requests in the form of local encoding; 3. Http requests in 620 the form of ACE. For 1 & 2, there are possibility that the domain 621 name request comes in an http escaped form (i.e. %XX%XX) as well as a 622 variant of the pure form. The same variances for 3 applies. 624 6.3 Other Known Issues about using IDN 626 No matter how multilingual names are deployed, a set of problematic 627 glitches would arise as the transition takes place and as users learn 628 to understand more about these issues. The three main reasons being 629 that: 1. The average user is unaware of these problems; 2. System 630 administrators may arbitrarily block multilingual requests by setting 631 up their system that mistake IDNs to be malicious requests; and 3. 632 Existing software was not originally designed for IDNs. 634 For example, some browsers simply block all entry of multilingual 635 domain names, others try to implement some form of transformation 636 causing loss of character information, which is may be irrecoverable. 637 The DNS resolvers residing at the ISP level are very important 638 "messengers" in the DNS. Since the original DNS protocol itself is 639 arguably 8-bit capable, this middleman usually just pass requests 640 along the DNS path, however proxy and caching issues could complicate 641 matters. Proxy servers and cache servers will contribute to the 642 blocking of multilingual names, by misinterpreting them as malicious 643 requests or other undesired traffic. Consequently creating a barrier 644 for multilingual names to be successfully transported. 646 Multilingual email addresses also have its share of issues. There 647 are three main areas where issues may arise: during the sending of 648 emails through the SMTP servers; the retrieval of emails from the POP 649 servers; and client side blocks. For example, some existing MTAs 650 equipped with ASCII-check statements may simply deny receipt of 651 messages from a multilingual address, while others equipped with 652 virus scanning features, may reject non-ASCII characters in an e-mail 653 address misinterpreting them as potential malicious attacks. The 654 interfaces of some email user agents as well as mail portals are 655 equipped with ASCII-check statements, blocking all attempts to send 656 messages to multilingual email addresses. The major email clients 657 however will be able to manage multilingual email addresses when 658 setup correctly. 660 While the authors admits that there will be some stubborn known 661 issues surrounding the deployment and usage of multilingual domain 662 names, the IDNX strategy suggests a comprehensive solution for a 663 registry in the deployment of multilingual domain names to 664 substantially reduce complications brought by technical issues as 665 well as for customer support issues. 667 7. Security Considerations 669 Because DNSSEC provides coverage for wildcard records, the Dynamic 670 CNAME feature should not cause any additional security concerns. 672 Besides the above, this document does not talk about DNS security 673 issues, and it is believed that the proposal does not introduce 674 additional security problems not already existent and/or anticipated 675 by adding multilingual characters to the DNS. 677 References 679 [IDNA] Internationalizing Domain Names in Applications, 680 draft-ietf-idn-idna, Feb 2002, Patrik Faltstrom, 681 Paul Hoffman, Adam M. Costella 683 [PUNYCODE] Punycode: An encoding of Unicode for use with IDNA, 684 draft-ietf-idn-punycode, Feb 2002, Adam M. Costella 686 [STRINGPREP]Preparation of Internationalized Strings, 687 draft-hoffman-stringprep, Feb 2002, Paul Hoffman, 688 Marc Blanchet 690 [NAMEPREP] Nameprep: A Stringprep Profile for Internationalized 691 Domain Names, draft-ietf-idn-nameprep, Feb 2002, 692 Paul Hoffman, Marc Blanchet 694 Acknowledgements 696 The authors would like to take this opportunity to thank all those 697 who have provided precious comments and feedback during the 698 preparation of this paper. 700 Special thanks to the following persons whose comments have been 701 invaluable to this document: 703 Mark Davis 704 Eric Hall 705 Tedd Stirling 706 Maynard Kang 707 Deng Xiang 708 Prof. L. M. Tseng 709 Liana Ye 710 Martin Duerst 711 Dan Oscarsson 713 Authors: 715 Edmon Chung 716 Neteka Inc. 717 Suite 100, 243 College St. Toronto, 718 Ontario, Canada M5T 1R5 719 edmon@neteka.com 721 David Leung 722 Neteka Inc. 723 Suite 100, 243 College St. Toronto, 724 Ontario, Canada M5T 1R5 725 david@neteka.com