idnits 2.17.1 draft-jhbae-nliasa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 22 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 109 has weird spacing: '...ressing hiera...' == Line 116 has weird spacing: '...express the c...' == Line 137 has weird spacing: '...ding to the t...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '1' on line 530 looks like a reference -- Missing reference section? '2' on line 446 looks like a reference -- Missing reference section? '3' on line 397 looks like a reference -- Missing reference section? '4' on line 351 looks like a reference -- Missing reference section? '5' on line 354 looks like a reference -- Missing reference section? '6' on line 357 looks like a reference -- Missing reference section? '7' on line 362 looks like a reference -- Missing reference section? '8' on line 363 looks like a reference -- Missing reference section? 'RFC811' on line 534 looks like a reference -- Missing reference section? 'RFC1034' on line 537 looks like a reference -- Missing reference section? 'RFC1035' on line 540 looks like a reference -- Missing reference section? 'Alvestrand' on line 543 looks like a reference -- Missing reference section? 'Klensin1' on line 547 looks like a reference -- Missing reference section? 'Klensin2' on line 551 looks like a reference -- Missing reference section? 'ARROUYE' on line 555 looks like a reference -- Missing reference section? 'Mealling' on line 559 looks like a reference -- Missing reference section? 'Popp' on line 563 looks like a reference -- Missing reference section? 'UNICODE' on line 566 looks like a reference -- Missing reference section? 'UTR15' on line 569 looks like a reference -- Missing reference section? 'UTR21' on line 573 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT JH. BAE 2 November 21, 2001 CH. LEE 3 Expires May 21, 2002 Netpia dot Com 5 Native Language Internet Address Service (NLIAS) 6 draft-jhbae-nliasa-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This Internet-Draft will expire on May, 2002. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 This Draft is to introduce Native Language Internet Address Service 38 that becomes popular as an alternative Domain name service. 39 This draft describes the backgrounds, rationale and the 40 specification of the Native Language Internet Address Service. 42 Generally in internet service when user types a word to connect to 43 the sepecific website, a quey typed in is so called as Keyword. 44 However, keyword is a word used to descibe the service, which is to 45 type a word related to the information the user wants to get in the 46 serach engine. So the author, myself, would like to use Native 47 Language Internet Address instead of Keyword. 49 1. Overview 51 As Internet service and the Internet infrastructure grow very fast, 52 Internet Name Service that is a basis for the Internet service is also 53 being developed rapidly. All the development is being carried out to 54 give more convenience to the Internet users and these efforts are 55 shown in many ways. 57 IP address and DNS(Domain Name System) are the general Internet 58 addressing schemes from the start of the Internet era to nowadays. 59 In case of DNS service, it is being extended to IDN for the 60 convenience of end users. In addition to these traditional addressing 61 schemes, a new approach, called Native Language Internet Address, is 62 actively being discussed among in the Internet society. 64 This document surveys the development trend of Internet Addressing 65 schemes and describes the rationale and the architecture of Native 66 Language Internet Address Service as an alternative Internet 67 Addressing schemes. 69 2. Introduction 71 2.1 Development of Internet Address 73 Internet Address, as of today, has been advanced to allow multilingual 74 characters in the domain names using IDN. However, from the viewpoint 75 of the end user convenience, IDN is not an ultimate destination of the 76 Internet Address development, but it is just one of the intermediate 77 steps. 78 Among many Internet addresses, this document discusses the Native 79 Language Internet Address Service that has been discussed in a few 80 drafts. 82 The development stages of Internet Addresses are as follows: 84 1) IP Address (210.103.175.31) 85 2) Domain Name (netpia.com) 86 3) I18N Domain Name (multilingual.com) 87 4) Full I18N Domain Name (multilingual.multilingual) 88 5) Native Language Internet Address (multilingual keyword) 89 As the number of IP address which is a combination of numbers has 90 increased, the server management with only host IP addresses and host 91 names becomes more inconvenient. To resolve this problem, domain name 92 has emerged. Domain name, however, also has problems of limited 93 namespaces using LDH[1] only. As the Internet has spread to 94 non-English speaking countries, the need for using their own characters 95 as Internet Name has increased. 97 As a result, IDN(Internationalized Domain Name) has emerged but it 98 neither provide the community with the full convenience, nor is 99 fully serviced as well. Now, more convenient addresses, known as, 100 Native Language Internet Address has emerged. 101 From, above 1) to 4), the technical advancement has been 102 achieved through the need of community. Native Language Internet 103 Address, 5), is, conceptually, a brand new Internet address requires 104 legal support as well as the technical advancement and community's 105 need. 107 Native Language Internet Address is based on the assumption that it is 108 better to recognize an Internet address without current Internet 109 addressing hierarchies such as TLD and 2LD, and this is a more 110 advanced Internet addressing schemes. 112 A legal background of Native Language Internet Address is as follows. 114 Netpia.co.kr 115 | | 116 | +-----> Hangul character itself can express the ccTLD. 117 | That is a character code corresponds to .kr. 118 +-------> It identify the characteristic of organizations 119 according to the traditional trademark principles. 120 Therefore, 2LD becomes unnecessary. 122 The character sets or languages can be used as ccTLD or TLD by 123 character set identification system. For example, Hangul character set 124 itself becomes ccTLD. This means that the language itself can identify 125 the country so .kr is not needed any more and can be omitted. 126 Also, the traditional trademarks already imply the organizations. 127 So the `.co', which implies company or corporation, can be omitted. 129 For example, in "seoulsichung.go.kr", the Native Language Internet 130 Address "seoulsichung" (City hall of Seoul), itself identifies the 131 governmental organization. As an another example, in 132 "seouldaehackyo.ac.kr", the Native Language Internet Address, since 133 "seouldaehackyo" (The Seoul National University) itself implies 134 the educational institution ,".ac" is notnecessary. 136 That is, 2LD such as ".co", ".go", ".or", which identify the 137 characteristic of organizations already according to the traditional 138 trademark principles, so it can be omitted in the domain names. 140 In other words, ccTLD and gTLD can be resolved by the character set 141 identification system. By the traditional trademark principles, the 142 trademark name itself identifies 2LD and the organization, 143 for example, .co, .go, .or and etc. As technology advances, the system 144 can identify the 2LD or TLD(ccTLD) from the name even if the user does 145 not specifies it. It is a kind of more advanced system so that the 146 users can use the internet more conveniently. 148 There are two more important advantages in this approach. 149 First, from the user's point, the availability of internet is one 150 factor to consider. In the traditional domain system, the domain is 151 the combination of English alphabets and numbers designed for 152 universal use. However, this can be an obstacle to the Internet access 153 for the non-English speaking people. But the Native Language Internet 154 Address can identifiy the Internet Address by the very real name in 155 the native language or notation, which make the Internet more 156 available to the local, non-Enlgish speaking people. Second, the 157 stability and the user friendliness of the system without using 2LD or 158 TLD are another advantage of the system, which has been verified by 159 the commercial service experience of the last 2 years. 161 In the traditional domain names, as the combination of English 162 alphabets, in an abbreviated form, are used for the name, the 163 organization identification is needed to reduce the conflict of the 164 names. In Native Language Internet Address, a real trademark or a name 165 is used in itself. The conflict can be minimized by using the real 166 name, although the registration policy permits abbreviated name by 167 warning the possible conflict. (legal issues) 169 Native Language Internet Address has emerged as a result of Internet 170 Address development toward the convenience of the community and it 171 made the Internet more accessible for the community by using the real 172 names in its native language, which was not possible in the 173 traditional Internet Addressing scheme. As mentioned above, Native 174 Language Internet Address is an advanced method derived from the 175 community needs and the technical and legal developments 176 of traditional internet addresses. 178 2.2 Overview of Native Language Internet Address Service 180 Native Language Internet Address Service connects the traditional 181 domain name to the unique information such as organizational name, 182 trademark, service name, person's name, telephone number, HAM or 183 pager number, barcode and so on. Native Language Internet Address 184 should be serviced in a regional legal boundary. Also, Native Language 185 Internet Address is provided by user's locale information to map that 186 information with the address of the cyber world. 188 2.3 Characteristics 190 Since the characteristics of Native Language Internet Address can 191 express all the unique aspects of a given name, it should include all 192 unique identifiers that a user can understand. Because Native Language 193 Internet Address Service respects the registered names and can extend 194 the implied name space easily, the name space shortage problem can be 195 relatively alleviated. 197 Although it fails to satisfy all the needs of Internet Address as any 198 other method, it enhances the accessibility and convenience of the end 199 user, especially in non-English speaking regions. 201 3. Current Native Language Internet Address Service 203 Until now, four different attempts have been tried to provide the 204 Native Language Internet Address Service. 206 The following requirements should be satisfied for the future of 207 Internet and its community. 209 1) user friendliness 210 2) consistency 211 3) extensibility 212 4) stability 213 5) recognizability 214 6) universal validity 216 Service methods are as follows: 218 1) by application 219 2) by OS support 220 3) by network device 221 4) by N/S extension 223 One of the service methods is to provide Native Language Internet 224 Address Service by every application. This method is simple and easy 225 method to do service, but each implementation may be responded with 226 different answers. This causes a lot of confusions to the community 227 who uses Native Language Internet Address as Internet Address, that 228 is, it lacks the uniformity. This makes the Internet as a closed 229 private service like most of the local communication service provides, 230 which is not the goal of Internet service. 232 Another try is to enhance the OS resolver or to use special 233 networkdevices to provide the Native Language Internet Address Service 234 But these methods are still in the experimental stage and lots of time 235 and efforts are needed to apply these methods to the community. 236 For now, these lack the extensibility and the universal validity. 238 Yet another method that uses the NS query is being tried in many ways. 239 This method is based on the fact that, in many applications, the 240 Native Language Internet Address typed in (though sometimes this is 241 not the case) by the end user is transferred to the NS. In fact, there 242 are various attempts to extend the name server. These alternative NS 243 or extended NS can actively respond to the queries from various 244 applications. 246 This method has advantages that it can provide the same response from 247 different applications, which means that this can provide the 248 uniqueness of the Internet Address. 250 Even though DNS was not made to provide the Native Language Internet 251 Address Service, it gives a hint on what should be done to provide the 252 Native Language Internet Address Service. Naming Service should 253 provide an unique service for the various applications. Native 254 Language Internet Address Service falls on these category. That means 255 that it can provide consistency. 257 Future Native Language Internet Address Service must support not only 258 specific application program, but also the general naming scheme to be 259 usable as an Internet Address. It should be compatible with the 260 existing service and easily extensible to the future Internet 261 applications. And it also shouldn't affect the existing services. 263 4. Native Language Internet Address Service 265 4.1 Overview 267 There exists many identification methods for our daily lives 268 a personal home page, e-mail, ICQ number, telephone number, fax number 269 and snail mail address are examples to name a few. 270 These identifiers are used in a real life without serious problems 271 and it is being extended to the Internet service. In fact, I send fax 272 and telephone calls using the desktop PC. Also, there is some service 273 providers which allows users to have an effect of sending a snail 274 mails just by sending an e-mail in Korea. 276 Native Language Internet Address will provide a framework to 277 interconnect these identifiers easily. For example, I have to search 278 the address book many times to send some faxes to my friends. If there 279 is a fax program that can send just by typing the name of receiver, 280 the service would be much convenient. 281 This problem is not limited to the fax number. We have many problems 282 to memorize many identifiers and sometimes we even fail to find the 283 specific identifier we need. It would be more convenient to use Native 284 Language Internet Address Service not only for the fax program but 285 also for many other application programs. 287 4.2 NLIAS (Native Language Internet Address System) 289 As mentioned above, Native Language Internet Address should evolve as a 290 form of Naming System which can resolve the queries generated from 291 various applications. Differentiating this service from DNS, we call 292 it as NLIAS(Native Language Internet Address System). 294 +--- Name Server -------------+ 295 | +----------+ +-----------+ | 296 | | | | | | 297 | | DNS | | NLIAS | | 298 | | | | | | 299 | +----------+ +-----------+ | 300 +-----------------------------+ 302 4.3 Client Server Model 304 The Native Language Internet Address System should be a C/S model like 305 Domain Name System. The server should respond to the queries without 306 difficulty from various users. For this, a C/S model is adequate 307 because it is simple and it reduces overhead. Especially, the new 308 protocol should not increase the network loads. 310 5. Requirements 312 For the technical requirements described below, we define a "service" 313 for those related to something provided to the end users and we define 314 "protocol" for those related to implementation. 316 5.1 Requirements for Compatibility and Interoperability 318 [1] Service should be a separate system from DNS. In these days DNS is 319 so important that it can be referred as Internet itself. 320 It should be a separated Naming System from DNS. After the 321 verification of stability, the attempts to integrate into DNS 322 should be pursued. 323 [2] Native Language Internet Address Service can provide the basic IP 324 Address in no time. Otherwise, the DNS should be queried. 325 [3] The response from the same Native Language Internet Address should 326 be same regardless of the server type whether it is a cache server 327 or a root server. 328 [4] Cache server should not respond with old data for those query. 329 [5] Protocol should not depend on some specific character sets. 330 [6] Unique Native Language Internet Address for each language 331 (character set) should be serviced. 333 5.2 Requirement for the Internationalization 335 [1] The character set used in the service should be extended from the 336 Unicode. 337 [2] Protocol should do the Name Preparation for the Native Language 338 Internet Address before the service. 339 [3] Conflicts on Native Language Internet Address should be reduced by 340 Name Preparation. 341 [4] For the case mapping, the upper case letters should be converted 342 to the lower case ones since most user use lower case letters. 343 [5] Service should be based on the user's language. 345 5.3 Requirement for the service administration 347 [1] Service should be restricted to 1:1 match. 348 [2] Native Language Internet Address Table should be easily modifiable 349 [3] Native Language Internet Address System should not give any 350 influence on the traffic of the DNS system. 351 [4] Native Language Internet Address should be maintained according to 352 the character set. No two different character sets can share the 353 same table. The character sets means the extension of Unicode. 354 [5] Native Language Internet Address has n:1 correspondence with the 355 Internet Resource. Internet Resource means the information table 356 for the Native Language Internet Address. 357 [6] In a given Native Language Internet Address table, the Native 358 Language Internet Address should be unique. The same Native 359 Language Internet Address can be in another Native Language 360 Internet Address table even if the Native Language Internet 361 Address implies the same meaning. 362 [7] The categorization of the table is defined by that of Unicode. 363 [8] A Native Language Internet Address in a given table is 364 case-insensitive. For example, "abc" and "ABC" cannot exist in the 365 same table. If both exist in the same table, one of them is 366 ignored. 368 6. Structural Overview 370 6.1 Interoperable view 372 A B 373 +------------+ +---------+ +--------+ 374 | | Query | | Query | | 375 | Individual |--------->| NLIAS |--------->| NLIAS | 376 | User |<---------| Servers |<---------| Root | 377 | | Resource | at ISP | Resource | Server | 378 | | | | | | 379 +------------+ +---------+ +--------+ 381 When the user types in the multi-lingual Native Language Internet 382 Address to the application, the Native Language Internet Address will 383 be converted to the Unicode character string and then transmitted to 384 the Native Language Internet Address Server, say A. Native Language 385 Internet Address server A forwards the query to one of many root 386 Native Language Internet Address Servers, say B. 388 The corresponding root server B will respond with the resource by 389 identifying the character set string based on the unicode. After this, 390 Native Language Internet Address Server A caches the result so that A 391 can respond for the the subsequent query for this Native Language 392 Internet Address. The query should include at least the following 393 information. 395 [1] Native Language Internet Address 396 [2] Resource Information (application information) 397 [3] Language Information 399 6.2 Client Side 401 Local Foreign 402 +-------------+ Local Code +----------+ Unicode | +---------+ 403 | | String | | String | | | 404 | User |------------>| Resolver |------------|-->| NLIAS | 405 | Application |<------------| |<-----------|---| Servers | 406 | | Resource | | Resource | | | 407 +-------------+ +----------+ | +---------+ 409 The end user application should be changed to accommodate the 410 internationalized native Native Language Internet Address service. 411 In other words, the resolver should take into account the multilingual 412 characters. This includes the locale information of the client and the 413 queried protocol information (ex: http, ftp, irc) as well as the 414 encoding of the Native Language Internet Address itself. 415 The definitions on character encoding schemes are defined in Unicode 416 Technical Report 17. 418 6.3 Server Side 420 +-------------+ +-------------+ +-----------+ 421 | | Packets | | Packets | | 422 | Cache |------------>| ROOT |------------>| Native | 423 | NLIAS | | NLIAS | | Language | 424 | Server |<------------| Server |<------------| Internet | 425 | | | | | Address | 426 | | | | | Table | 427 | | Resource | | Resource | | 428 +-------------+ +-------------+ +-----------+ 430 Note) Packets should include not only the unicode Native Language 431 Internet Address but also the locale and the type of the protocol. 433 The packet transmitted by the resolver includes the information about 434 the language used by a user or an application. Therefore, it transmits 435 the query string to the authoritative server for the corresponding 436 locale. The authoritative server (Root server) searches a Native 437 Language Internet Address table for the matching string and returns 438 the resource information if exists. 440 Native Language Internet Address Server follows these steps for the 441 Native Language Internet Address. 443 [1] It searches the currently maintained caches; If a matched resource 444 is found, it returns the resource information. Otherwise, it asks 445 for the root server query. 446 [2] Root Server returns the resource information for the queried 447 Native Language Internet Address. If no matching resource is found, 448 "NOT FOUND" will be returned instead. 450 6.4 Cache Server and Root Server 452 Cache Server refers a NLIAS server with no authority on the Native 453 Language Internet Address zone file and does not refer to a separate 454 system. This server caches the response information for some finite 455 time and responds directly to the same Native Language Internet Address 456 query. But it turns off the flag which indicates the response comes 457 from the authorative server. If the queried Native Language Internet 458 Address is not cached, it queries to the root server. 460 6.5 Usage in application programs. 462 There are many Internet applications. Each of these applications 463 require somewhat different return values for the Native Language 464 Internet Address. For the web browser, the expected result is an URL. 465 For the mail client, an e-mail address should be returned for the 466 Native Language Internet Address queries. This means that each 467 application may require different identifiers for the same Native 468 Language Internet Address. Soon there may be some telephony system 469 which dials up automatically just by saying the "Native Language 470 Internet Address". NLIAS should be designed to accommodate these 471 applications. 473 In order to satisfy these requirements, Native Language Internet 474 Address System should be mapped to an information group and the 475 information groups should be designed to be easily extended for 476 the future applications as well as the existing applications. 478 Native Language Internet Address -+- Applicaton1 - Application1 value 479 +- Applicaton2 - Application2 value 480 +- Applicaton3 - Application3 value 482 ex) Netpia -+- Web Browser - www.netpia.com 483 +- News Client - news.netpia.com 484 +- Mail Client - webmaster@netpia.com 485 +- Telnet Cleint - telnet.netpia.com 486 +- FTP Clent - ftp.netpia.com 487 +- Phone - +82 2 3665 0123 489 6.6 Consideration on Internationalization 491 Native Language Internet Address System is not limited to be serviced 492 on English speaking regions. Various languages should be supported 493 for the international service. Until now, Unicode is used as an 494 encoding scheme to support the international service so far, but the 495 Native Language Internet Address System should support the local 496 regional codes so that it can be more extensible. Also Native Language 497 Internet Address Service should be based on the local service. It can 498 be supported best in the corresponding local region by the traditional 499 trademark principles. Native Language Internet Address System should 500 consider the legal aspect since the legal issues as well as the 501 technical issues must be developed. 503 7. Conclusion 505 As mentioned above, Native Language Internet Address Service should be 506 another connection service that makes it easier to type and memorize 507 the various resources without any modification nor change on the 508 existing service. 510 8. Author's Address 512 Jinhyun Bae 513 Netpia.com, Inc. 514 35-1, Youngdeungpo-Dong 8-ga, Youngdeungpo-Gu Seoul, Korea 150-038 516 Tel : +82-2-2165-3060 517 Fax : +82-2-668-4913 518 E-mail: piano@netpia.com 520 Changhum Lee 521 Netpia.com, Inc. 522 35-1, Youngdeungpo-Dong 8-ga, Youngdeungpo-Gu Seoul, Korea 150-038 524 Tel : +82-2-2165-3051 525 Fax : +82-2-668-4913 526 E-mail: chang@netpia.com 528 9. definition 530 [1] LDH : Letters, Digits, and Hyphen 532 10. Reference 534 [RFC811] "Hostnames Server", RFC 811. 535 March 1982, K. Harrenstien 537 [RFC1034] "Domain Names - Concepts and Facilities", RFC 1034. 538 November 1987, P. Mockapetris. 540 [RFC1035] "Domain Names - Implementation and Specification", RFC 1035. 541 November 1987, P. Mockapetris. 543 [Alvestrand] "Definitions for talking about directories". 544 draft-alvestrand-directory-defs-02.txt. 545 April 2001, H. Alvestrand. 547 [Klensin1] "Role of the Domain Name System". 548 draft-klensin-dns-role-01.txt. 549 May 2001, J. Klensin. 551 [Klensin2] "A Search-based access model for the DNS". 552 draft-klensin-dns-search-01.txt. 553 July 2001, J. Klensin. 555 [ARROUYE] "Keyword Lookup Systems As a Class of Naming Systems" 556 draft-arrouye-kls-00.txt 557 August 1, 2001, Y. Arrouye and V. Parikh and N. Popp 559 [Mealling] "Service Lookup System". 560 draft-mealling-sls-00.txt. 561 July 2001, M. Mealling and L. Daigle. 563 [Popp] "Common Name Resolution Protocol", draft-ietf-cnrp-10.txt. 564 June 2001, N. Popp, M. Mealling, and M. Moseley. 566 [UNICODE] The Unicode Consortium, "The Unicode Standard". Described at 567 http://www.unicode.org/unicode/standard/versions/. 569 [UTR15] "Unicode Normalization Forms", Unicode Standard Annex #15, 570 http://www.unicode.org/unicode/reports/tr15/, 2000-08-31, 571 M. Davis and M. Duerst, Unicode Consotium. 573 [UTR21] "Case Mappings", Unicode Technical Report #21, 574 http://www.unicode.org/unicode/reports/tr21/, 2000-09-12, 575 M. Davis, Unicode Consortium.