idnits 2.17.1 draft-klensin-i18n-newclass-02.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 652 lines 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.) ** There are 20 instances of lines with control characters in the document. ** The abstract seems to contain references ([Hardie-Class]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 2002) is 7803 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: 'Hardie-Class' is mentioned on line 45, but not defined == Missing Reference: 'Klen-3071' is mentioned on line 125, but not defined == Missing Reference: 'Klen-role' is mentioned on line 384, but not defined == Missing Reference: 'DUDE' is mentioned on line 437, but not defined == Unused Reference: 'RFC2870' is defined on line 587, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS10646' -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2870 (Obsoleted by RFC 7720) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT John C. Klensin 2 June 19, 2002 3 Expires December 2002 5 Internationalizing the DNS -- A New Class 6 draft-klensin-i18n-newclass-02.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026 except that the right to produce 12 derivative works is not granted. The above restriction will be removed 13 by the author in a subsequent version of this draft; the author should 14 be contacted for permission if needed sooner. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 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 0. Abstract 33 Several mechanisms have been proposed for placing multilingual names 34 (more properly, names normally written in non-ASCII character sets) 35 into the DNS or addressing the need for multilingual access to the 36 Internet in other ways. Most of them involve, to one extent or 37 another, workarounds to the current system. This document proposes a 38 "go back and fix it" approach, replacing the "IN" Class in the DNS with 39 one that is not limited to ASCII from its initial definitions. Some of 40 the deployment issues, politics, and other drawbacks are also briefly 41 discussed. 43 The draft is being republished at this time, with a few corrections 44 and some new text, because it is complementary to a recent draft by 45 Ted Hardie [Hardie-Class] and because it may be part of the foundation 46 for a different DNS internationalization proposal. The author is no 47 longer convinced, if he ever was, that this proposal is adequate for 48 DNS internationalization, at least without considerable enhancement. 50 A mailing list has been initiated for discussion of this draft, its 51 successors, and closely-related issues in the Internationalization 52 context at ietf-i18n-dns-newclass@imc.org. To subscribe to the 53 mailing list, send a message to ietf-i18n-dns-newclass-request@imc.org 54 with the single word "subscribe" (without the quotes) in the body of 55 the message. To unsubscribe from the list, use that same address with 56 the single word "unsubscribe" in the body of the message. Issues 57 related to the relationship of the model proposed here to general 58 issues of multilingual access to the DNS should be raised in the IETF 59 IDN WG working group, see 60 http://www.ietf.org/html.charters/idn-charter.html. 62 Table of Contents 64 1. Introduction and Context 65 2. Overview of the Proposal 66 3. Technical alternatives and the deployment and transition nightmare 67 3.1 Preparation and comparison of names 68 3.2 Registrations in both places 69 3.3 Search rules and search failures 70 3.4 A "new class" solution versus an "edns/utf-8" one. 71 3.5 A "new class" approach versus an "ACE" one. 72 3.6 A "new class" approach versus a "directory" one. 73 3.7 Another look at legacy applications 74 3.8 New Classes and IPv6 Transition 75 4. Bringing RR types forward 76 5. Pushing into layers eight through ten 77 5.1 The root server question 78 5.2 Other administrative challenges 79 5.3 Thinking about deployment 80 6. Summary 81 7. References 82 7.1 Normative references 83 7.2 Non-normative references 84 8. Acknowledgements 85 9. Author's address 87 1. Introduction and Context 89 There have been a large number of proposals, both inside and outside 90 the IETF, for getting multilingual (or "internationalized") access to 91 the DNS. With the exception of a few proposals that focus on doing 92 the work in a separate system that permits searching (see [Klen-role, 93 Klen-search, Meal-SLS], and others) and several suggested or deployed 94 commercial products), all involve inserting the names into the 95 existing DNS structure. This would be done either by using special 96 conventions and preprocessing of international characters into an 97 ASCII representation or by using a character set repertorie that 98 includes more than ASCII [ASCII] and some encoding to place characters 99 from that repertorie into the system. 101 To a considerable degree, while the objective is multilingual access 102 to names (i.e., access from multiple languages), very few of the 103 proposals address languages at all. For a number of good reasons, 104 which are adequately discussed elsewhere, discussion has focused on 105 access to the system with characters other than those that appear in 106 ASCII and, in particular, characters drawn from ISO 10646 [IS10646]. 107 This document, too, addresses characters, not languages, and 108 "non-ASCII", "international", "multinational", and, following ISO's 109 example, "universal character set" ("UCS") terminology are used 110 interchangably below. When "multilingual" is used, it refers to the 111 languages in which words or names appear, not what is placed into the 112 DNS. 114 When the DNS was designed, it was anticipated that there might be 115 future extension through the use of "Classes". All common current uses 116 on the public Internet use the "IN" class. Two additional classes are 117 known to have been defined and used: one for the old Chaosnet protocols 118 and one for Hesiod-based protocols. Potential extensions via the Class 119 mechanisms may have been one of the reasons that DNS labels and other 120 fields were defined as binary, rather than ASCII, forms. 122 Applications using the IN Class have historically assumed labels 123 limited to seven-bit ASCII characters and, more specifically, a 124 "protocol element" character set derived from ARPANET "hostname" rules 125 (see [Klen-3071]). This document explores the question of what the 126 DNS, and "DNS names", might have looked like had we been designing it 127 today. I.e., it assumes that multilingual usage would be a priority 128 but that current technology and existing standards are available. It 129 also outlines the issues associated with a transition mechanism. 131 The proposal is radical in the sense that it implies a major 132 restructuring of DNS usage and, indeed, of the Internet, to make the 133 DNS seamlessly capable of working with multinational (or, more 134 properly, "universal") character sets. Such a restructuring is, and 135 should be, quite frightening. It is worth considering only if the 136 long-term risks and problems of other proposals are severe enough to 137 justify a radical approach. It is the working hypothesis of this 138 document that they are. At a relatively technical level, this would 139 require changing every DNS resolver and server, and application that 140 accesses either, on the Internet that wished to use non-ASCII names. 141 Legacy (unconverted) systems would be at a significant disadvantage in 142 referencing new names (some of which might use only a subset of ASCII 143 characters but might still not be registered in the older Class), just 144 as legacy systems were during the transition between Hostnames and the 145 DNS. There are also a number of problems, such as the weaknesses of 146 the DNS as a directory system, which it does not solve (see section 147 3.6, below). 149 It also does not significantly address the very complex issues of 150 normalization, mapping, and canonicalization that are needed for the 151 use of Unicode (or, in all likelihood, with any future alternate 152 approach to a universal character set). The key issues in that area 153 are addressed in the existing "stringprep" [stringprep] proposal and 154 its profiles. See section 3.1 for further discussion on this issue. 156 2. Overview of the Proposal 158 Suppose we introduce a new Class (let's call it UC for "universal 159 characters" just as a placeholder, but I hope that isn't what we would 160 choose), which is just like IN (i.e., inherits its RR definitions, but 161 see below), except: 163 * Labels and all fields containing text are defined as IS 10646 164 characters, coded in UTF-8 (or, in principle, some other _single_ 165 system, i.e., we do not permit multiple character sets in the 166 structure). 168 * A new RR is introduced that maps a new-type label (in the new 169 class) into a restricted-ASCII (traditional) label. The intent is 170 that the resolver then looks up the restricted-ASCII label in the IN 171 class and proceeds as usual. Probably it would need to have 172 "nothing else there" restrictions like CNAME, but (to put it mildly) 173 I haven't thought that through. An alternative would be to adopt a 174 search rule strategy, looking first with Qclass=UC and then 175 Qclass=IN. The new RR might not be needed if one adopted a search 176 rule strategy, or strong administrative rules requiring that all 177 Class IN records be transposed into Class UC (see below). 179 * A second new RR is introduced that indicates that a delegated 180 subdomain of a zone in Class=UC is in Class=IN, and not in 181 Class=UC. This would be a variation on "NS", but would specify 182 both the Class and the name associated with the relevant name 183 server. (Note that a references from Class=IN to Class=UC makes no 184 sense and mechanisms for it should not be provided.) 186 It is not clear at this time whether both the second and third 187 "crossreference" RRs would be necessary, but almost certainly at least 188 one would be. 190 This brief outline obviously leaves out many critical details which 191 would need to be worked out, only some of which are explored in this 192 draft of the document. 194 3. Technical alternatives and the deployment and transition nightmare 196 A "new class" proposal would obviously not be easy to deploy, but, 197 realistically, neither are any of the other ideas if the definition 198 of deployment involves users having access to Internet names drawn 199 from a broad range of languages. It would cleanly separate 200 "international character set" name spaces from the "ASCII" one -- 201 i.e., "old" clients and systems would never see the non-ASCII types. 202 In the international name space, English, and the character code 203 points used to represent it, becomes just one of many such languages 204 and their corresponding character code points. It might even let us 205 fix a few other things along the line, as long as they were 206 sufficiently straightforward to not create significant delays. E.g., 207 there are several RR types in the current Class that are either 208 obsolete or have never been widely used, and we might be able to 209 eliminate them by not carrying them forward. 211 While other transition models are possible, the cleanest one would be 212 to conclude that the new Class was intended, over time, to simply 213 obsolete and replace Class=IN. If registrations in Class=IN were 214 transferred into (or explicitly referenced from) the new class (or a 215 "search rule" system was employed), then the transition model would be 216 very similar to that of the hosttable-> DNS transition. In particular, 217 "old" clients and systems would see a smaller and smaller fraction of 218 the Internet until they converted and we would expect some user-level 219 tools to arise to work around slow conversions. 221 3.1 Preparation and comparison of names 223 Subsets of ASCII, or character codes whose character repertoires are 224 themselves subsets of ASCII, have long been the character repertoire 225 of choice for the protocol elements of protocols that use characters 226 in such elements. While some of the reasons for this --arguably 227 including the decision to use characters from a Roman- (Latin-) based 228 alphabet-- are simply historical, ASCII has the advantages of 229 containing a very small (by world averages) set of characters, of 230 permitting an extremely easy case-mapping algorithm (and case-mapping 231 is important in Roman-based and several other languages), of requiring 232 no "composed" characters, and of raising no significant issues with 233 canonicalization, collation, or identity-matching. 235 To varying degrees, as soon as the character repertoire moves beyond 236 the requirements of ASCII, comparison issues intrude: it is necessary 237 for a DNS server to determine whether the name specified in a query 238 matches the name that appears in its tables for a domain. And that, in 239 turn, requires either that strict rules be applied to how names are 240 stored and how queries are presented or that the server be able to 241 interpret a somewhat-ambiguous (or "fuzzy") query. The latter option 242 is infeasible given the design of DNS servers (although non-DNS systems 243 might permit it -- see section 3.6 and [klen-role]). The former has 244 been the focus on the "nameprep" efforts within the IDN Working Group. 246 In general, the mechanisms and rules being developed as part of the 247 "nameprep" effort would need to be applied to a "new class" system, 248 just as they would need to be applied to "edns/UTF-8" or "ACE" 249 systems. However, one potential advantage of a "new class" approach, 250 and possibly of an EDNS-based one, is that it would be possible to 251 move some of the comparison and mapping functions out of a pre-query 252 sequence on the client and onto the server. That, in turn, would 253 permit case mapping and matching for non-ASCII texts to be handled in 254 a way much more similar to ASCII text today (e.g., storage of mixed 255 case materials in zone files with queries in any case and return of 256 the registrant-desired form). To the extent that centralizing complex 257 functions on the servers improves reliability, it would also have that 258 benefit. 260 3.2 Registrations in both places 262 A "multilingual" name registrant could choose whether to register the 263 multilingual name exclusively or whether to register ASCII-based names 264 as well (giving most of the useful properties of the two-sided business 265 card analogies). Such ASCII-based names could be registered in the new 266 class; they could presumably also be registered in the old class for 267 compatibility with legacy systems. We would not expect reverse 268 mappings to work from IN-space to UC-space; PTR lookups in Class IN 269 would yield ASCII names; PTR lookups in Class UC would yield IS 10646- 270 based names. And we would expect all other fields that contain text to 271 contain IS 10646-based text, not just ASCII. Finally, moving critical 272 portions of the normalization and comparison work to the server might 273 make it easier to deal with some of the issues of in superimposing 274 internationalized names on DNNSec a bit easier, or at least possible 275 to have better-behaved. 277 There is probably no practical way to automate dual registrations in 278 the general case (keeping in mind that naming and identification issues 279 that exist near the root also exist deep in the DNS tree), so decisions 280 about legacy registrations would need to be administrative and policy 281 based. See section 5. Search rules (see next section) might be an 282 acceptable substitute for dual registrations, but have their own 283 disadvantages. 285 3.3 Search rules and search failures 287 Unless all relevant records in Class=IN are copied into Class=UC and 288 the two are kept synchronized (very difficult if not impossible to 289 maintain), there will be a requirement for searching from the newer 290 class to the older one. That requirement could, in principle, be kept 291 in the servers and off the network by providing for new servers to 292 automaticaly search in Class=IN if nothing is found in Class=UC without 293 intervening interactions with the resolver. This could introduce 294 significant complexity and a number of special cases into the server 295 and might or might not be wise. Since a new Class causes 296 multiplicative effects on the number of probes potentially required to 297 complete a search, minimizing the number of similar RR types in the new 298 Class becomes technically advantageous as well as aesthetically so (see 299 section 4). 301 The potential need to make queries in both Class=UC and Class=IN for a 302 given user-supplied name provides an immediate, and strong, reason why 303 the fundamental domain hierarchy structure of both Classes should be 304 identical, even if the servers are not. If identity of servers is not 305 practical (it probably would not be significantly below the top level, 306 if there), the portion of the Class=UC tree that shared names with the 307 Class=IN tree would need to be identically structured. Almost by 308 definition, as non-ASCII non-terminal nodes are introduced into the 309 Class=UC tree, that tree would diverge from, or become a superset of, 310 the Class=IN one. The alternatives would, at best, be hopelessly 311 confusing to users. 313 But, if searching mechanisms from Class=UC to Class=IN will be in 314 regular use, it is tempting to rely on those mechanisms rather than 315 doing any forward copying of data. This would increase overhead in 316 comparison to having all information copied into the UC class as 317 early as possible, but the range of alternatives needs to be studied 318 carefully, especially with regard to domain trees that contain 319 non-ASCII names and UC-capable servers at some nodes and only ASCII 320 names and legacy servers at others. The special, cross-Class NS RR 321 suggested above would help with such trees, but some searching 322 strategies might make strict bottom-to-top conversion of subtrees 323 (rather than level-skipping) very valuable if not necessary. 325 Having two classes also raises issues for which the answers seem 326 obvious, but decisions must be made and made explicit. For example, it 327 seems clear that one should search 328 ((QClass=UC, Qtype=MX, ...) 329 (QClass=UC, Qtype=A6, ...) 330 ... 331 (QClass=IN, Qtype=MX, ...) 332 ... 333 But, at least in theory, a case could be made for looking for MX RRs in 334 "IN" before looking for address records in "UC". 336 3.4 A "new class" solution versus an "edns/utf-8" one. 338 Some of the proposals before the IDN working group (and elsewhere) 339 depend on the use of "extensible DNS" ("edns") facilities to permit 340 extended labels and the use of UTF-8 encoding in them. Proponents 341 point out that edns is extremely useful for IPv6 and DNNSEC, so will 342 probably deploy quickly anyway; its use for non-ASCII DNS labels would 343 both benefit from and reinforce those deployment pressures. One of the 344 barriers to the deployment and heavy use of extensible DNS [RFC2671] is 345 that its use in the current, Class=IN, environment depends somewhat on 346 updating of intermediate servers. In other words, an updated client 347 and updated primary server may not be able to properly interoperate 348 because caches or secondary servers may still be running older code. 349 In principle, and probably in practice, this is not an issue with a new 350 Class: absent serious errors of configuration, name servers delegations 351 and caches for the new class would be only to servers supporting that 352 class. 354 3.5 A "new class" approach versus an "ACE" one. 356 Several of the proposals in the IDN working group (and elsewhere) 357 depend on encoding ISO 10646 characters into an ASCII-compatible format 358 (an ASCII-compatible encoding, hence "ACE") so that the names, however 359 ugly, would survive passage into applications that have intrinsic 360 seven-bit limitations. That group of applications is somewhat more 361 diverse than what is usually thought of as "internet applications". 362 For example, X.509 certificates are used in SSL and assume seven-bit 363 characters. The ACE codings would work with those applications, 364 although they would look nothing like the graphic characters of the 365 original character set and language. 367 While this document has assumed using the UTF-8 encoding of IS 10646 368 directly in the names and labels of the UC class, UTF-8 is just 369 another encoding and not an especially efficient one. There may be 370 applications-based arguments for using an ASCII, or ASCII-compatible, 371 encoding to represent character codes in the new Class as well. 372 However, since all codes in the new Class would be using the same 373 system, one could devise a system that did not require a switching or 374 labeling mechanism to identify the use of the coding system versus the 375 appearance of codes in the ASCII range intended to be interpreted as 376 ASCII. I.e., prefixes or suffixes might become unnecessary and it 377 might be possible to use higher-density encodings, such as MIME's 378 base64, or a serious compression algorithm applied to UCS-2 or UCS-4 379 (or the similar UTF-16 or UTF-32), rather than UTF-8 or those 380 encodings more commonly suggested as ACE mechanisms. 382 3.6 A "new class" approach versus a "directory" one. 384 Many of the issues raised in [Klen-role] are not addressed by this 385 proposal. Neither it, nor any other DNS-based solution, would turn 386 the DNS into a searchable directory ([klen-search] does provide a 387 model for a searchable directory, but the work is not done in the 388 DNS). Nor can they address imprecise matching, keyword matching, 389 nearest applicable server location, searching on the content of data 390 fields, and so on. This proposal does provide a plausible solution 391 to reverse-mapping problems, deployment, and has known scaling 392 properties: all areas where the notions outlined in [klen-role] are 393 weaker. It would probably be somewhat faster than a directory 394 approach layered on the DNS, since there would be no requirement for 395 a two-stage lookup process. But, ultimately, the two proposals are 396 complementary: There is a strong applications case for introducing a 397 directory layer. While the directory layer could be used to support 398 multilingual names -- treating the ASCII-based names in the DNS as 399 protocol elements rather than names that ought to be user visible -- 400 it could also be used with a DNS that actually and cleanly supported 401 multilingual names as suggested here. 403 3.7 Another look at legacy applications 405 As suggested above, there are some applications, many with origins 406 outside the IETF, that cannot be easily upgraded to use of non-ASCII 407 (or, generally, non-seven-bit), character codes. It is difficult to 408 know what to do about those applications. If we are really serious 409 about converting the Internet to support applications in all 410 languages (which is ultimately the assumption underlying this 411 document), then the answer may be more clear: the overhead of dealing 412 with the UCS to ASCII interface ought to fall on those applications, 413 as an intermediate step until the protocols themselves can be 414 upgraded. In other words, we might anticipate a four-stage 415 conversion process for those applications: 417 (i) Completely legacy (non-updated) code would continue to reference 418 Class=IN (no other option is possible). 420 (ii) Applications code would be upgraded to make QClass=UC inquiries 421 and to represent the UCS codes for their databases and 422 presentations in some ASCII-compatible form compatible with their 423 protocol definitions. In other words, the DNS would return some 424 native form variation on UCS, conversion to ASCII-compatible form 425 would occur, when needed, on the applications side of the DNS 426 interface. 428 (iii) The protocols would be upgraded to international norms and usage. 430 (iv) The applications code would be changed to conform to the new 431 protocols, eliminating the workaround of stage (ii). 433 If these conversions and downgrades, espeically those of step (ii), 434 are incorporated into the DNS, we are stuck with their overhead and 435 appearance forever. That is, of course, also true of any encoding 436 tricks (e.g., the "ACEs" under consideration in the IETF IDN WG, e.g., 437 [DUDE]) used to represent non-ASCII names in Class=IN without putting 438 applications at obvious risk. And different applications, with 439 different constraints, may have to convert them to application- 440 specific formats anyway. Somewhat different strategies, available 441 with the new class approach only, could eliminate the need to make 442 workarounds and kludges a permanent part of their systems and the 443 Internet infrastructure. 445 3.8 New Classes and IPv6 Transition 447 The transition to IPv6 has raised an interesting general DNS issue 448 because it may require that DNS servers support a dual stack 449 arrangement to permit access of records from resolvers based on both 450 IPv4 and IPv6 systems. (This document will not attempt to fully 451 explain that problem and its implications.) It is possible that, were 452 a new Class developed as an incremental replacement for Class=IN, it 453 could be used as a mechanism for handling IPv6 queries. 455 4. Bringing RR types forward 457 In principle, one could populate the UC Class with all of the types of 458 the IN one, possibly eliminating those that are clearly obsolete, as 459 mentioned above. A narrow reading of many of the existing definitional 460 documents might even require this, although we can be assured that no 461 queries or registrations in class=UC exist today. But it might be 462 interesting to evaluate the implications of taking a harder line, 463 partially to shorten search paths and minimize the size of zone files. 464 Several RR types have been added "experimentally"; it would probably be 465 wise to leave those for which there isn't considerable deployment and 466 justification behind. We might also consider leaving AAAA RRs behind 467 as obsolete or redundant, since A6 is the more general of the two. 468 And, more radically, one might consider eliminating type A RRs, writing 469 IPv4 addresses in IPv6 form, e.g., 471 kakameymi.example. UC A6 0 ::FFFF:10.0.0.44 473 and letting APIs to resolvers translate them back into IPv4 format if 474 needed. By doing this, the potential need to query for A6, AAAA, and A 475 RRs in sequence would disappear, resulting in some performance 476 improvement, especially for the "not found" cases. 478 Of course, similar logic might apply to a lighter-weight successor of 479 A6, or even a variation of AAAA with a specialized high-order coding 480 convention. 482 This might raise entry barriers too much to be worthwhile, but, if 483 feasible (and we really believe in IPv6 deployment), it would yield a 484 much cleaner environment for both forward and reverse mappings. 486 On the other hand, eliminating other types in favor of A6 might be 487 advancing the technology in too many ways at once. For example, while 488 the A6 RR appears to be fully general, there is so far little few real 489 experience on using it (or other IPv6 RRs) and none of that experience 490 is at large scale. It may be wise to go somewhat cautiously into 491 directions that tie the new class to such less-than-complete-tested 492 approaches. 494 5. Pushing into layers eight through ten 496 (For those who don't know, these layers have become an internal joke in 497 the IETF community whose exact origins are unknown to this author. The 498 layers are characterized as "financial", "political", and "religious", 499 with some debate about the order.) 501 A new DNS class really would be new. Current Internet administrative 502 procedures and lines of authority with regard to the DNS have assumed 503 that Class=IN is the only class at issue. It is to be hoped that IETF 504 could identify technical criteria and other important tradeoffs but 505 leave the non-technical issues and resolution of policy and political 506 tradeoffs to ICANN and related bodies. 508 5.1 The root server question 510 The design of the DNS is such that there is no inherent reason why 511 root servers for a new class would need to be the same as those for 512 IN. However, the same considerations for root server selection that 513 apply to the Class=IN root [rfc2870] would presumably apply to the 514 Class=UC root as well. There would be several other administrative 515 and operational advantages for keeping many or all of the root servers 516 the same --or at least co-locating them-- as long as loads, software 517 availability, and similar factors permitted. 519 5.2 Other administrative challenges 521 Just as the root servers would not need to be the same, the 522 introduction of a new Class would, in theory, permit revisiting the 523 entire top-level structure and administration of the the Class=IN DNS 524 (e.g., there would be no requirement that the TLD names or model be 525 the same). Doing so would probably be unwise if we wanted to see 526 this deployed in our lifetimes, but the possibility must be 527 identified and, at least briefly, considered. 529 5.3 Thinking about deployment 531 It is clear that, like any other multilingual approach, software 532 supporting a new DNS class would deploy much more quickly in areas 533 which clearly need it than in areas that perceive they do not. The 534 requirement for communication with, and access to sites in, non- 535 English-speaking areas would tend to drive deployment in other areas 536 with this and many other approaches. The so-called "ACE" approaches 537 within Class=IN (and perhaps some others) using the IN Class would 538 permit non-updated sites to see multilingual names in their ugly 539 encoded forms; it is possible that would actually act as a 540 disincentive to updating and conversion since the names would still 541 be somewhat visible; this proposal would not make multilingual names 542 available in any form to legacy systems. On the other hand, some 543 have argued that the use of ACE-type systems in the current Class 544 would make the full horrors of kludgy and insufficient implementation 545 of multilingual names visible to all, encouraging the deployment of 546 either the type of system outlined here, or a search-based one, or 547 both. 549 Whatever thinking is done about deployment tradeoffs should consider 550 Internet growth rates, especially in non-English-speaking areas. 551 Whatever solution is adopted, we will need to live with it for a long 552 time. If no old systems are ever converted, but new ones installed 553 after a particular date have updated software installed, and 554 "doubling every year" behavior continues, then the legacy base 555 represents half of the Internet a year later, a quarter of the 556 installed base a year after that, and so on. So, a sufficiently 557 important change, incorporated into relevant shipping software, has a 558 very large percentage impact even if there is no actual updating of 559 systems. This is something to keep in mind, especially if the 560 alternatives are overhead-laden kludges that we will need to support 561 forever. 563 6. Summary 565 <> 567 7. References 569 7.1 Normative references 571 [ASCII] American National Standards Institute (formerly United States of 572 America Standards Institute), X3.4, 1968, "USA Code for Information 573 Interchange". ANSI X3.4-1968 has been replaced by newer versions with 574 slight modifications, but the 1968 version remains definitive for the 575 Internet. 577 [IS10646] ISO/IEC 10646-1:2000 Information technology -- Universal 578 Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and 579 Basic Multilingual Plane and ISO/IEC 10646-2:2001 Information 580 technology -- Universal Multiple-Octet Coded Character Set (UCS) -- 581 Part 2: Supplementary Planes. 583 7.2 Non-normative references 585 [RFC2671] Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999. 587 [RFC2870] Root Name Server Operational Requirements. R. Bush, D. 588 Karrenberg, M. Kosters, R. Plzak. June 2000 590 [hardie-class] Hardie, T., "A DNS RR for Pointers to RRs outside 591 class IN", work in progress, 592 (http://search.ietf.org/internet-drafts/draft-hardie-out-rr-00.txt) 594 [klen-3071] Klensin, J., "Reflections on the DNS, RFC 1591, and 595 Categories of Domains", RFC 3071, February 2001. 597 [klen-role] Klensin, J., "Role of the Domain Name System", work in 598 progress 599 (http://search.ietf.org/internet-drafts/draft-klensin-dns-role-03.txt) 601 [klen-search] Klensin, J., "A Search-based access model for the DNS", 602 work in progress 603 (http://search.ietf.org/internet-drafts/draft-klensin-dns-search-03.txt) 605 [meal-sls] Mealling, M. and L. Daigle, "Service Lookup System (SLS)", 606 work in progress. 607 (http://search.ietf.org/internet-drafts/draft-mealling-sls-00.txt) 609 [stringprep] Hoffman, P. and M. Blanchet, "Preparation of 610 Internationalized Strings ('stringprep')", work in progress, 611 (http://search.ietf.org/internet-drafts/draft-hoffman-stringprep-03.txt) 613 8. Acknowledgements 615 Rob Austein and Randy Bush made very significant contributions to the 616 thinking and some of the text that went into early versions of this 617 draft through a series of email discussions. Others, including Marc 618 Blanchet, Vint Cerf, Kilnam Chon (with apologies for writing his name 619 in ASCII characters rather than Korean ones), Patrik Faltstrom (with 620 apologies for the ASCII transposition), Paul Hoffman, David Lawrence, 621 and Zita Wenzel have made suggestions or challenged some of the ideas 622 in their embryonic form, leading to clarifications and clearer 623 thinking. More recent discussions with Erik Nordmark, Ted Hardie, and 624 Dan Oscarsson, and observation of many discussions on the IDN WG list 625 contributed to the changes in draft 02. Patrik Faltstrom first 626 pointed out the possible IPv6 implications of a new class approach. 627 The author, of course, bears ultimate responsibility for the ideas as 628 presented. 630 9. Author's address 632 John C Klensin 633 1770 Massachusetts Ave, #322 634 Cambridge, MA 02140 635 klensin+irnss@jck.com 637 Expires December 2002