idnits 2.17.1 draft-ietf-dnsop-private-use-tld-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 769 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6761]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 272: '... names MUST never be deployed in...' RFC 2119 keyword, line 276: '...ication software SHOULD NOT recognise ...' RFC 2119 keyword, line 277: '... and SHOULD use these names as t...' RFC 2119 keyword, line 279: '...Is and libraries SHOULD NOT recognise ...' RFC 2119 keyword, line 280: '...s as special and SHOULD NOT treat them...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2021) is 1083 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IANA-Special' is defined on line 474, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'BCP-219') (Obsoleted by RFC 9499) -- Duplicate reference: RFC1034, mentioned in 'STD13', was also mentioned in 'RFC1034'. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission R. Arends 3 Internet-Draft ICANN 4 Intended status: Best Current Practice J. Abley 5 Expires: October 12, 2021 Public Interest Registry 6 E. Lisse 7 Namibian Network Information Center (Pty) Ltd 8 April 10, 2021 10 Top-level Domains for Private Internets 11 draft-ietf-dnsop-private-use-tld-01 13 Abstract 15 There are no defined private-use namespaces in the Domain Name System 16 (DNS). For a domain name to be considered private-use, it needs to 17 be future-proof in that its top-level domain will never be delegated 18 from the root zone. The lack of a private-use namespace has led to 19 locally configured namespaces with a top-level domain that is not 20 future proof. 22 The DNS needs an equivalent of the facilities provided by BCP 5 (RFC 23 1918) for private internets, i.e. a range of short, semantic-free 24 top-level domains that can be used in private internets without the 25 risk of being globally delegated from the root zone. 27 This document describes a particular set of code points which, by 28 virtue of the way they have been designated in the ISO 3166 standard, 29 are thought to be plausible choices for the implementation of private 30 namespaces that are anchored in top-level domains. 32 The ISO 3166 standard is used for the definition of eligible 33 designations for country-code top-level Domains. This standard is 34 maintained by the ISO 3166 Maintenance Agency. The ISO 3166 standard 35 includes a set of user-assigned code elements that can be used by 36 those who need to add further names to their local applications. 38 Because of the rules set out by ISO in their standard, it is 39 extremely unlikely that these user-assigned code elements would ever 40 conflict with delegations in the root zone under current practices. 42 In order to avoid the operational and security consequences of 43 collisions between private and global use of these code elements as 44 top-level domains, this document specifies that such top-level 45 domains should never be deployed in the global namespace, and 46 reserves them accordingly in the Special-Use Names Registry 47 [RFC6761]. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on October 12, 2021. 66 Copyright Notice 68 Copyright (c) 2021 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (https://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction 84 2. The ISO 3166-1 alpha-2 and Two-Letter Top-Level Domains 85 2.1. ISO 3166-1 alpha-2 User-assigned Code Elements 86 3. Private-use top-level Domains 87 4. Domain Name Reservation Considerations 88 5. IAB Considerations 89 6. IANA Considerations 90 7. Security Considerations 91 8. Acknowledgements 92 9. Informative References 93 Appendix A. Examples of Current Uses of the User-assigned Code 94 Elements. 95 Authors' Addresses 97 1. Introduction 99 The Domain Name System (DNS) [RFC1034] is used to map names to 100 services, systems and other devices that are accessible across 101 networks. Many network operators configure such name mappings in 102 such a way that names referring to private resources, such as 103 services that are intended for use within private networks, are not 104 published in the DNS for general use over the Internet. Collections 105 of such names form a private namespace. 107 Private namespaces can be considered to be local sub-trees of the 108 familiar, global DNS namespace. An operator can choose where their 109 private namespace is anchored. Since it is useful for applications 110 to be able to make use of both private and global names, it is 111 important that the private and global namespaces do not overlap. 112 Some operators are known to have chosen top-level domains that do not 113 exist in the global namespace as anchors for their private 114 namespaces. Such deployments could theoretically use sub-domains of 115 a domain registered for the specific hosting entity, though not all 116 such configurations have such a domain available. 118 Many protocols outside the DNS have a defined set of elements for 119 private use, or an identifier that indicates private use, such as 120 "X-headers" MIME types [RFC2045], addresses for private internets 121 [BCP-5], the "x-" sub-tag in private-use language tags [BCP-47], 122 private-use Autonomous System Numbers [BCP-6], and private-use DNS 123 RRTypes and RCODEs [BCP-42]. 125 There is currently no such facility for the DNS namespace. A user is 126 required to resort to registering a globally unique domain where a 127 locally unique domain would suffice, or may configure a domain name 128 that is not currently delegated from the root zone. Additionally, 129 there are plenty of examples of device vendors that ship networking 130 devices with a default setting for DHCP [RFC2131] option 15 (domain 131 name) [RFC2132], containing a top-level domain that is believed to 132 not be delegated in the root zone. 134 In practice, the lack of a private-use namespace facility has led to 135 the deployment of arbitrary, unregistered, semantically meaningful 136 top-level domains, such as ".home", ".dhcp", ".lan", ".localdomain", 137 ".internal", ".dlink", ".ip" and ".corp" [ITHI]. These examples of 138 locally configured strings are derived from traffic to the ICANN 139 Managed Root Servers [IMRS] and are part of the most popular observed 140 query names [BCP-219]. 142 While these commonly chosen strings currently do not exist in the 143 root zone, there is no guarantee that these strings will not be 144 delegated in the root zone in the future. Therefore, there is no 145 guarantee that the local use of these strings (or other strings that 146 might be chosen for private use) will be stable, safe, and secure. 148 There are many uses for private-use names. It is not feasible to 149 assign a semantically meaningful, relatively short top-level label to 150 each individual private-use of a namespace in multiple languages. 151 Similar to "X-headers" MIME types, and analogous in concept to 152 address allocation for private internets, this document defines a 153 range of abstract, two-letter labels that are aligned with the user- 154 assigned two-letter code elements in the ISO 3166-1 alpha-2 155 [ISO3166-1] standard. 157 The ISO 3166 standard is used for the implementation of country-code 158 Top-Level Domains in the DNS. This standard is maintained by the ISO 159 3166 Maintenance Agency and includes a set of code elements 160 designated "user-assigned". Such user-assigned code points are in 161 use for a variety of applications where it is useful to avoid 162 conflict with codes assigned to countries or regions. 164 2. The ISO 3166-1 alpha-2 and Two-Letter Top-Level Domains 166 IANA's practice of governing the delegation of ASCII two-letter 167 domain names in the DNS [STD13] root zone is to align it with 168 assignment of two-letter (known as "alpha-2") code elements in the 169 ISO 3166-1 standard [ISO3166-1]. The ISO 3166-1 standard contains 170 many categories of code elements, with the "officially assigned" and 171 some "exceptionally reserved" code elements being used in the DNS to 172 represent entities as country-code top-level domains (ccTLDs) 173 [RFC1591]. The interrelationship is documented in "ICANN and the 174 ISO, A Common Interest in ISO Standard 3166" [ICANNISO]. 176 In addition to the assigned, available, and reserved code elements, 177 there are code elements designated as "user-assigned". The intent of 178 user-assigned code elements is to provide the user with a code 179 element when no other code element satisfies the intended use. 181 2.1. ISO 3166-1 alpha-2 User-assigned Code Elements 183 The ISO 3166-1 standard states in section 5.2: 185 "In addition, exactly 42 alpha-2 code elements are not used in the 186 ISO 3166, AA, QM to QZ, XA to XZ, ZZ." 188 And explains in clause 8.1 "Special Provisions": 190 "Users sometimes need to extend or alter the use of country-code 191 elements for special purposes. The following provisions give 192 guidance for meeting such needs within the framework of this part 193 of ISO 3166. " 195 And finally, clause 8.1.3 "User assigned code element": 197 "If users need code elements to represent country names not 198 included in this part of ISO 3166, the series of letters AA, QM to 199 QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA 200 to XZZ, and ZZA to ZZZ respectively and the series of numbers 900 201 to 999 are available. NOTE Users are advised that the above 202 series of codes are not universals, those code elements are not 203 compatible between different entities." 205 As shown above, the ISO 3166-1 user-assigned alpha-2 code elements 206 are defined to be AA, QM to QZ, XA to XZ, and ZZ. The ranges ("to") 207 are alphabetic and contain only characters in the US-ASCII definition 208 [STD80]. 210 Appendix A contains examples of the usage of ISO 3166-1 user-assigned 211 alpha-2 code elements in various organisations. 213 3. Private-use top-level Domains 215 The user-assigned classification of these code elements in the ISO 216 3166-1 alpha-2 standard allows for the assumption that these code 217 elements will not risk delegation as country-code top-level Domains 218 through future assignments to represent a country or territory. To 219 quote [XNIDN]: 221 "The use of ISO 3166-1 User-assigned elements removes the 222 possibility that the code will duplicate a present or future ccTLD 223 code." 225 The ISO 3166 user-assigned code elements are hence plausible choices 226 for network operators who have decided to use a top-level domain as 227 an anchor for their private namespace. They are safer choices than 228 some other labels that do not currently exist as top-level domains, 229 since new top-level domains are assigned from time to time. 231 The ISO 3166 standard is not maintained by the IETF, and it is 232 possible that the standard will change in the future. However, the 233 use of ISO 3166 alpha-2 user-assigned code elements as top-level 234 domain anchors for private namespaces under the current standard is 235 well-known. Regardless of any future changes to the ISO 3166 236 standard, choosing to add a top-level domain in the global namespace 237 that conflicted with any of these code points in the future could 238 have negative operational effects and pose security risks. 240 To avoid these negative operational consequences, this document 241 directs that the top-level domains corresponding to these ISO 3166 242 alpha-2 user-assigned code elements should never be deployed in the 243 global namespace; that is, they must never exist as an owner name in 244 the root zone of the DNS. 246 Using these code elements as top-level domains for the purpose of 247 private-use TLDs is in line with the intended use of these code 248 elements and follows the many examples of other standards and 249 protocols. Furthermore, they are short and free of any semantic 250 meaning. 252 This document does not recommend any specific ISO 3166-1 alpha-2 253 user-assigned code as a private use, but instead proposes that any of 254 them can be used by a network or application for private use. That 255 is, there is no attempt to choose just one of the ISO 3166-1 Alpha-2 256 user-assigned codes for use as private-use TLDs, just as other 257 organizations use multiple user-assigned codes for many internal 258 purposes. 260 Note that there may be software that treats labels beginning with XN 261 differently due to the use of the XN- prefix in internationalized 262 domain names [RFC5890]. 264 4. Domain Name Reservation Considerations 266 The information that follows is intended to satisfy the requirements 267 of [RFC6761]. The top-level domains corresponding to the ISO 3166 268 User-Assigned code elements are special in the following ways: 270 1. Users are free to use these names as they would any other top- 271 level domain. However, since this document specifies that these 272 names MUST never be deployed in the global DNS, users SHOULD be 273 aware that these names are likely to yield different results on 274 different networks. 276 2. Application software SHOULD NOT recognise these names as special 277 and SHOULD use these names as they would any other name. 279 3. Name resolution APIs and libraries SHOULD NOT recognise these 280 names as special and SHOULD NOT treat them differently. Name 281 resolution APIs SHOULD send queries for these names to their 282 configured caching DNS server(s). 284 4. Caching DNS servers MAY recognise these names as special and 285 SHOULD NOT, by default, attempt to look up NS records for the, or 286 otherwise query authoritative DNS servers on the global Internet 287 in an attempt to resolve these domains. Instead, caching DNS 288 servers SHOULD, by default, generate immediate (positive or 289 negative) responses for all such queries. This is to avoid 290 unnecessary load on the root name servers and other name servers. 291 Caching DNS servers SHOULD offer a configuration option (disabled 292 by default) to enable upstream resolution of such names, for use 293 in private networks where these domains are known to be handled 294 by an authoriative DNS server in said private network. 296 5. Authoritative DNS servers SHOULD recognise these names as special 297 and SHOULD, by default, generate immediate negative responses for 298 all such queries, unless explicitly configured by the 299 administrator to give positive answers from a private namespace. 301 6. DNS server operators SHOULD, if they are using private namespaces 302 anchored at these names, configure their authoritative DNS 303 servers to act as authoritative for these names. 305 7. DNS Registries/Registrars MUST NOT grant requests to register any 306 of these names in the normal way to any person or entity. These 307 names are reserved due to their use in private namespaces, and 308 fall outside the set of names available for allocation by 309 registries/registrars. Attempting to allocate one of these names 310 as if it were a normal DNS domain name will probably not work as 311 desired, for reasons 4, 5 and 6 above. 313 5. IAB Considerations 315 This document specifies that various two-character codes should never 316 be used in the global DNS as top-level domains, for technical, 317 operational and security reasons. This technical restriction has 318 implications for root zone management in the DNS, policy for which is 319 developed at ICANN. 321 As part of its review process for this document, the authors suggest 322 that the IAB exercise its relevant liaisons to ICANN (the 323 organisation and the community) to ensure that the content of this 324 document does not raise any concerns that the IAB feels are 325 important. The authors further suggest that the text in this section 326 be replaced prior to publication by a record of the IAB's review. 328 6. IANA Considerations 330 This document makes the observation that the policy of assigning 331 ccTLD labels is to align with the ISO-3166-1 alpha-2 standard 332 [RFC1591], which includes user-assigned code elements that will never 333 be assigned to a territory [ISO3166-1]. This is then consistent with 334 existing policies that those user-assigned codes will never be 335 delegated from the DNS root zone and, for that reason, will never 336 give rise to collisions with any future new TLD. 338 This document directs that the following rows be added to the 339 Special-Use Names Registry: 341 +------+-----------------+ 342 | Name | Reference | 343 +------+-----------------+ 344 | AA. | (this document) | 345 | | | 346 | QM. | (this document) | 347 | | | 348 | QN. | (this document) | 349 | | | 350 | QO. | (this document) | 351 | | | 352 | QP. | (this document) | 353 | | | 354 | QQ. | (this document) | 355 | | | 356 | QR. | (this document) | 357 | | | 358 | QS. | (this document) | 359 | | | 360 | QT. | (this document) | 361 | | | 362 | QU. | (this document) | 363 | | | 364 | QV. | (this document) | 365 | | | 366 | QW. | (this document) | 367 | | | 368 | QX. | (this document) | 369 | | | 370 | QY. | (this document) | 371 | | | 372 | QZ. | (this document) | 373 | | | 374 | XA. | (this document) | 375 | | | 376 | XB. | (this document) | 377 | | | 378 | XC. | (this document) | 379 | | | 380 | XD. | (this document) | 381 | | | 382 | XE. | (this document) | 383 | | | 384 | XF. | (this document) | 385 | | | 386 | XG. | (this document) | 387 | | | 388 | XH. | (this document) | 389 | | | 390 | XI. | (this document) | 391 | | | 392 | XJ. | (this document) | 393 | | | 394 | XK. | (this document) | 395 | | | 396 | XL. | (this document) | 397 | | | 398 | XM. | (this document) | 399 | | | 400 | XN. | (this document) | 401 | | | 402 | XO. | (this document) | 403 | | | 404 | XP. | (this document) | 405 | | | 406 | XQ. | (this document) | 407 | | | 408 | XR. | (this document) | 409 | | | 410 | XS. | (this document) | 411 | | | 412 | XT. | (this document) | 413 | | | 414 | XU. | (this document) | 415 | | | 416 | XV. | (this document) | 417 | | | 418 | XW. | (this document) | 419 | | | 420 | XX. | (this document) | 421 | | | 422 | XY. | (this document) | 423 | | | 424 | XZ. | (this document) | 425 | | | 426 | ZZ. | (this document) | 427 +------+-----------------+ 429 7. Security Considerations 431 Use of private-use identifiers of any sort is known to result in 432 unexpected collisions. This has repeatedly been shown for private- 433 use addresses, private-use identifiers (such as "x- headers") and 434 private-use names in the DNS. These unexpected collisions can easily 435 have security ramifications that are well beyond what the user 436 understands or expects. 438 8. Acknowledgements 440 This document is based on an earlier draft by Ed Lewis. David 441 Conrad, Paul Hoffman, Sion Lloyd, Alain Durand, Jaap Akkerhuis, Kal 442 Feher, Andrew Sullivan, Petr Spacek, Patrick Mevzek and Kim Davies 443 have played a role. 445 9. Informative References 447 [BCP-219] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 448 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 449 January 2019, . 451 [BCP-42] Eastlake 3rd, D., "Domain Name System (DNS) IANA 452 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 453 April 2013, . 455 [BCP-47] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 456 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 457 September 2009, . 459 [BCP-5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 460 and E. Lear, "Address Allocation for Private Internets", 461 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 462 . 464 [BCP-6] Mitchell, J., "Autonomous System (AS) Reservation for 465 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 466 2013, . 468 [CABForum] 469 "CA/Browser Forum Baseline Requirements for the Issuance 470 and Management of Publicly-Trusted Certificates, version 471 1.6.9", March 2020, . 474 [IANA-Special] 475 "Special-Use Domain Names", n.d., 476 . 479 [ICANNISO] 480 "ICANN and the International Organization for 481 Standardization (ISO)", n.d., 482 . 485 [ICAO] "International Civil Aviation Organization, Machine 486 Readable Travel Documents, Part 3; Specifications Common 487 to all MRTDs", n.d., . 490 [IMRS] "ICANN Managed Root Server", n.d., 491 . 493 [INTERPOL] 494 "Interpol Implementation data format for the interchange 495 of fingerprint, facial & smt information", n.d., 496 . 499 [ISO3166-1] 500 "ISO 3166-1:2013 Codes for the representation of names of 501 countries and their subdivisions - Part 1: Country codes", 502 2013, . 504 [ISO3901] "Information and documentation -- International Standard 505 Recording Code (ISRC)", n.d., 506 . 508 [ISO4217] "ISO 4217; Codes for the representation of currencies and 509 funds", n.d., 510 . 512 [ISO6166] "Securities and related financial instruments -- 513 International securities identification numbering system 514 (ISIN)", n.d., . 516 [ITHI] "ICANN's Identifier Technology Health Indicator; Queries 517 to frequently leaked strings", n.d., 518 . 520 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 521 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 522 . 524 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 525 RFC 1591, DOI 10.17487/RFC1591, March 1994, 526 . 528 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 529 Extensions (MIME) Part One: Format of Internet Message 530 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 531 . 533 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 534 RFC 2131, DOI 10.17487/RFC2131, March 1997, 535 . 537 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 538 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 539 . 541 [RFC5890] Klensin, J., "Internationalized Domain Names for 542 Applications (IDNA): Definitions and Document Framework", 543 RFC 5890, DOI 10.17487/RFC5890, August 2010, 544 . 546 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 547 RFC 6761, DOI 10.17487/RFC6761, February 2013, 548 . 550 [STD13] Mockapetris, P., "Domain names - concepts and facilities", 551 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 552 . 554 [STD80] Cerf, V., "ASCII format for network interchange", STD 80, 555 RFC 20, DOI 10.17487/RFC0020, October 1969, 556 . 558 [UNICODE] "CLDRv37 - Unicode Common Locale Data Repository version 559 37", April 2020, 560 . 562 [UNLOCODE] 563 "United Nations Code for Trade and Transport Locations; 564 UN/LOCODE Manual", n.d., 565 . 568 [WIPO] "World Intellectual Property Organization; Recommended 569 standard on two-letter codes for the representation of 570 states, other entities and intergovernmental 571 organizations.", n.d., 572 . 575 [WORLDBANK] 576 "Worldbank API V2 Country API", n.d.. 578 [XNIDN] "Results of IANA Selection of IDNA Prefix", February 2003, 579 . 581 Appendix A. Examples of Current Uses of the User-assigned Code 582 Elements. 584 Using code elements to represent an entity other than a country name 585 may appear to deviate from the intended use of the ISO 3166-1 586 standard. However, many organizations, including the IETF and the 587 ISO, have used the user-assigned range to represent entities other 588 than country names. The following list is not exhaustive but 589 illustrates the wide variety of current uses of codes within the ISO 590 3166-1 user-assigned alpha-2 range. 592 o The International Standard Recording Code (ISRC) [ISO3901] uses 593 code element "ZZ" from the User-assigned range for direct 594 registrants independent of any country. 596 o The ISO Currency Codes standard [ISO4217] uses code elements "XA" 597 to "XZ" from the user-assigned range for transactions and precious 598 metals. 600 o International Securities Identification Numbers [ISO6166] uses the 601 following code elements from the user-assigned range: 603 QS: internally used by Euroclear France 605 QT: internally used in Switzerland 607 QW: internally used in WM Datenservice Germany for historical data 609 XA: CUSIP Global Services substitute agencies 611 XB: NSD Russia substitute agencies 613 XC: WM Datenservice Germany substitute agencies 615 XD: SIX Telekurs substitute agencies 617 XF: internally assigned, non-unique numbers 619 XS: Euroclear and Clearstream international securities 621 o The International Civil Aviation Organization [ICAO] Machine 622 Readable Travel Documents standard uses code element "ZZ" from the 623 user-assigned range for UN travel documents. 625 o The World Intellectual Property Organization [WIPO] Standard 3 626 uses the following code elements from the user-assigned range: 628 QZ: Community Plant Variety Office (European Union) (CPVO). 630 XN: Nordic Patent Institute (NPI). 632 XU: International Union for the Protection of New Varieties of 633 Plants (UPOV). 635 XV: Visegrad Patent Institute (VPI) 637 XX: recommended to refer to unknown states, other entities or 638 organizations. 640 o The United Nations Code for Trade and Transport Locations 641 [UNLOCODE] uses the code element "XZ" from the user-assigned range 642 for international waters in accordance with ISO 3166-1 clause 643 8.1.3: 645 "3.2.5 In cases where no ISO 3166 country-code element is 646 available, e.g. installations in international waters or 647 international cooperation zones, the code element "XZ", available 648 for user assignment in accordance with clause 8.1.3 of ISO 649 3166-1/1997, will be used." 651 o The World Bank Country API [WORLDBANK] uses the following code 652 elements from the User-assigned range: 654 XC: Euro area 656 XD: High income 658 XE: Heavily indebted poor countries (HIPC) 660 XF: International Bank for Reconstruction and Development 662 XH: Blend 664 XI: International Development Association 666 XJ: Latin America and Caribbean (excluding high income) 668 XL: Least developed countries: UN classification 670 XM: Low income 672 XN: Lower middle income 674 XO: Low & middle income 676 XP: Middle income 678 XQ: Middle East & North Africa (excluding high income) 680 XT: Upper middle income 682 XU: North America 684 XX: Not classified 686 XY: Not Classified 688 o The Interpol Implementation data format for the interchange of 689 fingerprint, facial & scar-mark-tattoo information [INTERPOL] uses 690 code element "ZZ" from the user-assigned range as follows: 691 Destination Agency Identifier "ZZ/ALL" is reserved for 692 transactions which shall be distributed by INTERPOL AFIS to all 693 INTERPOL member states." 695 o The Certificate Authority Browser Forum Baseline Requirements for 696 the Issuance and Management of Publicly-Trusted Certificates 697 [CABForum] states that if a country is not represented by an 698 official ISO 3166-1 alpha-2 country-code, the CA may specify the 699 user-assigned code element "XX" to indicate that an official code 700 element has not been assigned. 702 o The UNICODE Common Locale Data Repository (CLDR) [UNICODE] version 703 37 uses the following code elements from the user-assigned range: 705 QO: Outlying Oceania; countries in Oceania that do not have a 706 subcontinent. 708 XA: Pseudo-Accents; special code indicating derived testing locale 709 with English + added accents and lengthened. 711 XB: Pseudo-Bidi; special code indicating derived testing locale 712 with forced RTL English. 714 ZZ: Unknown Region; used in APIs or as a replacement for invalid 715 code. 717 o The IETF Best Current Practice 47 [BCP-47] contains a section and 718 examples dedicated to private-use subtags, using code elements 719 from the user-assigned range: 721 "For example, the region subtags 'AA', 'ZZ', and those in the 722 ranges 'QM'-'QZ' and 'XA'-'XZ' (derived from the ISO 3166-1 723 alpha-2 private use codes) can be used to form a language tag. A 724 tag such as "zh-Hans-XQ" conveys a great deal of public, 725 interchangeable information about the language material" 727 o The IETF Proposed Standard "Internationalized Domain Names for 728 Applications" [RFC5890] uses the XN-- prefix. The method that was 729 used to decide on the prefix was explained in an email from the 730 IANA to the IETF IDN Working Group list [XNIDN]: 732 "The following steps will be used to select the two-character 733 code: 735 The code will be selected from among a subset of the entries on 736 the ISO 3166-1, clause 8.1.3 User-assigned alpha-2 code elements: 737 AA, QM to QZ, XA to XZ, and ZZ. The selection is limited to these 738 codes because of the following: 740 The use of ISO 3166-1 User-assigned elements removes the 741 possibility that the code will duplicate a present or future ccTLD 742 code." 744 Authors' Addresses 746 Roy Arends 747 ICANN 749 Email: roy.arends@icann.org 751 Joe Abley 752 Public Interest Registry 753 470 Moore Street 754 London, true N6C 2C2 755 Canada 757 Email: jabley@pir.org 759 Eberhard W. Lisse 760 Namibian Network Information Center (Pty) Ltd 762 Email: el@lisse.na