idnits 2.17.1 draft-yao-regext-bundling-registration-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 5, 2020) is 1232 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Yao 3 Internet-Draft L. Zhou 4 Intended status: Informational H. Li 5 Expires: June 8, 2021 CNNIC 6 N. Kong 7 Consultant 8 W. Tan 9 Cloud Registry 10 J. Xie 11 December 5, 2020 13 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for 14 Strict Bundling Registration 15 draft-yao-regext-bundling-registration-01 17 Abstract 19 This document describes an extension of Extensible Provisioning 20 Protocol (EPP) domain name mapping for the provisioning and 21 management of strict bundling registration of domain names. 22 Specified in XML, this mapping extends the EPP domain name mapping to 23 provide additional features required for the provisioning of bundled 24 domain names. This is a non-standard proprietary extension. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 8, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Requirement for Bundling Registration of Names . . . . . . . 5 65 6. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. RDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.2. BDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 70 7.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 71 7.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 72 7.1.3. EPP Query Command . . . . . . . . . . . . 10 73 7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 74 7.2.1. EPP Command . . . . . . . . . . . . . . . . 11 75 7.2.2. EPP Command . . . . . . . . . . . . . . . . 13 76 7.2.3. EPP Command . . . . . . . . . . . . . . . . . 14 77 7.2.4. EPP Command . . . . . . . . . . . . . . . 15 78 7.2.5. EPP Command . . . . . . . . . . . . . . . . 16 79 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 17 80 9. Internationalization Considerations . . . . . . . . . . . . . 19 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 83 12. Implementation Status and some clarifications . . . . . . . . 21 84 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 87 14.2. Informative References . . . . . . . . . . . . . . . . . 23 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 In RFC4290, the "variant(s)" are character(s) and/or string(s) that 93 are treated as equivalent to the base character. In this document, 94 variants are those strings that are treated to be equivalent to each 95 other according the domain name registration policy. Bundled domain 96 names are those which share the same TLD but whose second level 97 labels are variants, or those which have identical second level 98 labels for which certain parameters are shared in different TLDs. 99 For an example, Public Interest Registry has requested to implement 100 bundling of second level domains for .NGO and .ONG. So we have two 101 kinds of bundled domain names. The first one is in the form of 102 "V-label.TLD" in which the second level label (V-label) is a variant 103 sharing the same TLD; Second one is in the form of "LABEL.V-tld" in 104 which the second level label(LABEL) remains the same but ending with 105 a different TLD (V-tld). 107 Bundled domain names normally share some attributes. Policy-wise 108 bundling can be implemented in three ways. The first one is strict 109 bundling, which requires all bundled names to share many same 110 attributes. When creating, updating, or transferring of any of the 111 bundled domain names, all bundled domain names will be created, 112 updated or transferred atomically. The second one is partial 113 bundling, which requires the bundled domain names to be registered by 114 the same registrant. The third one is relaxed bundling, which has no 115 specific requirements on the domain registration. This document 116 mainly addresses the strict bundling names registration. 118 For the name variants, different registries have different policies. 119 Some registries adopt the policy that variant IDNs should be blocked. 120 But some registries adopt the policy that variant IDNs which are 121 identified as equivalent are allocated or delegated to the same 122 registrant. For an example, most registries offering Chinese Domain 123 Name (CDN) adopt a registration policy whereby a registrant can apply 124 for an original CDN in any forms: Simplified Chinese (SC) form, 125 Traditional Chinese (TC) form, or other variant forms, then the 126 corresponding variant CDN in SC form and that in TC form will also be 127 delegated to the same registrant. All variant names in the same TLD 128 share a common set of attributes. This document mainly discuss the 129 situation that variant IDNs which are identified as equivalent are 130 allocated or delegated to the same registrant. 132 The basic Extensible Provisioning Protocol (EPP) domain name mapping 133 [RFC5731] provides the facility for single domain name registration. 134 It does not specify how to register the strict bundled names which 135 share many of the attributes. 137 In order to meet the above requirements of strict bundled name 138 registration, this document describes an extension of the EPP domain 139 name mapping [RFC5731] for the provisioning and management of bundled 140 names. This document describes a non-standard proprietary extension. 141 This extension is especially useful for registries of practicing 142 Chinese domain name registration. This document is specified using 143 Extensible Markup Language (XML) 1.0 as described in 145 [W3C.REC-xml-20040204] and XML Schema notation as described in 146 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 148 The EPP core protocol specification [RFC5730] provides a complete 149 description of EPP command and response structures. A thorough 150 understanding of the base protocol specification is necessary to 151 understand the extension mapping described in this document. 153 This document uses many IDN concepts, so a thorough understanding of 154 the IDNs for Application (IDNA, described in [RFC5890], [RFC5891], 155 and [RFC5892]) and the variant approach discussed in [RFC4290] is 156 assumed. 158 2. Terminology 160 Variants in this document are those strings that are treated to be 161 equivalent to each other according the domain name registration 162 policy for certain TLDs. 164 Bundled domain names are those names with the form of 165 "LABEL.Variants" or "Variants.LABEL" where LABEL is a same DNS label 166 for the variants. These names are bundled together according to the 167 domain name registration policy. Bundled domain names are also 168 called variant IDNs. Bundled domain names should belong to the same 169 owner. If bundled domain names are under different TLDs, those TLDs 170 should be controlled by the same registry. 172 uLabel in this document is used to express the U-label of an 173 internationalized domain name as a series of characters where non- 174 ASCII characters will be represented in the format of "&#xXXXX;" 175 where XXXX is a UNICODE point by using the XML escaping mechanism. 176 U-Label is defined in [RFC5890]. 178 The XML namespace prefix "b-dn" is used for the namespace 179 "urn:ietf:params:xml:ns:epp:b-dn", but implementations must not rely 180 on it and instead employ a proper namespace-aware XML parser and 181 serializer to interpret and output the XML documents. 183 In examples, "C:" represents lines sent by a protocol client and "S:" 184 represents lines returned by a protocol server. Indentation and 185 white space in examples are provided only to illustrate element 186 relationships and are not a required feature of this specification. 188 XML is case sensitive. Unless stated otherwise, XML specifications 189 and examples provided in this document must be interpreted in the 190 character case presented to develop a conforming implementation. 192 3. Definitions 194 The following definitions are used in this document: 196 o Registered Domain Name (RDN), represents the valid domain name 197 that registrants submitted for the initial registration. 199 o Bundled Domain Name (BDN), represents the bundled domain name 200 produced according to the bundled domain name registration policy. 202 4. Overview 204 Domain registries have traditionally adopted a registration model 205 whereby metadata relating to a domain name, such as its expiration 206 date and sponsoring registrar, are stored as properties of the domain 207 object. The domain object is then considered an atomic unit of 208 registration, on which operations such as update, renewal and 209 deletion may be performed. 211 Bundled names brought about the need for multiple domain names to be 212 registered and managed as a single package. In this model, the 213 registry typically accepts a domain registration request (i.e. EPP 214 domain command) containing the domain name to be registered. 215 This domain name is referred to as the RDN in this document. As part 216 of the processing of the registration request, the registry generates 217 a set of bundled names that are related to the RDN, either 218 programmatically or with the guidance of registration policies, and 219 places them in the registration package together with the RDN. 221 The bundled names share many properties, such as expiration date and 222 sponsoring registrar, by sharing the same domain object. So when 223 registrants update any property of a domain object within a bundle 224 package, that property of all other domain objects in the bundle 225 package will be updated at the same time. 227 5. Requirement for Bundling Registration of Names 229 The bundled names whether they are in the form of "V-label.TLD" or in 230 the form of "LABEL.V-tld" should share some parameter or attributes 231 associated with domain names. Typically, bundled names will share 232 the following parameters or attributes: 233 o Registrar Ownership 234 o Registration and Expiry Dates 235 o Registrant, Admin, Billing, and Technical Contacts 236 o Name Server Association 237 o Domain Status 238 o Applicable grace periods (Add Grace Period, Renewal Grace Period, 239 Auto-Renewal Grace Period, Transfer Grace Period, and Redemption 240 Grace Period) 242 Because the domain names are bundled and share the same parameters or 243 attributes, the EPP command should do some processing for these 244 requirements: 245 o When performing a domain check, either BDN or RDN can be queried 246 for the EPP command, and will return the same response. 247 o When performing a domain info, either BDN or RDN can be queried, 248 the same response will include both BDN and RDN information with the 249 same attributes. 250 o When performing a domain Create, either of the bundle names will be 251 accepted. If the domain name is available, both BDN and RDN will be 252 registered. 253 o When performing a domain Delete, either BDN or RDN will be 254 accepted. If the domain name is registered, both BDN and RDN will be 255 deleted. 256 o When performing a domain renew, either BDN or RDN will be accepted. 257 Upon a successful domain renewal, both BDN and RDN will have their 258 expiry date extended by the requested term. Upon a successful domain 259 renewal, both BDN and RDN will conform to the same renew grace 260 period. 261 o When performing a domain transfer, either BDN or RDN will be 262 accepted. Upon successful completion of a domain transfer request, 263 both BDN and RDN will enter a pendingTransfer status. Upon approval 264 of the transfer request, both BDN and RDN will be owned and managed 265 by the same new registrant. 266 o When performing a domain update, either BDN or RDN will be 267 accepted. Any modifications to contact associations, name server 268 associations, domain status values and authorization information will 269 be applied to both BDN and RDN. 271 6. Object Attributes 273 This extension defines following additional elements to the EPP 274 domain name mapping [RFC5731]. All of these additional elements are 275 returned from command. 277 6.1. RDN 279 The RDN is an ASCII name or an IDN with the A-label [RFC5890] form. 280 In this document, its corresponding element is . An 281 optional attribute "uLabel" associated with is used to 282 represent the U-label [RFC5890] form. 284 For example: xn-- 285 fsq270a.example 287 6.2. BDN 289 The BDN is an ASCII name or an IDN with the A-label [RFC5890] form 290 which is converted from the corresponding BDN. In this document, its 291 corresponding element is . An optional attribute "uLabel" 292 associated with is used to represent the U-label [RFC5890] 293 form. 295 For example: xn-- 296 fsqz41a.example 298 7. EPP Command Mapping 300 A detailed description of the EPP syntax and semantics can be found 301 in the EPP core protocol specification [RFC5730]. The command 302 mappings described here are specifically for use in provisioning and 303 managing bundled names via EPP. 305 7.1. EPP Query Commands 307 EPP provides three commands to retrieve domain information: 308 to determine if a domain object can be provisioned within a 309 repository, to retrieve detailed information associated with a 310 domain object, and to retrieve domain-object transfer 311 status information. 313 7.1.1. EPP Command 315 This extension does not add any element to the EPP command or 316 response described in the EPP domain name mapping [RFC5731]. 317 However, when either RDN or BDN is sent for check, response should 318 contain both RDN and BDN information, which may also give some 319 explanation in the reason field to tell the registrant that the 320 associated domain name is a produced name according to some bundle 321 domain name policy. 323 Example response: 324 S: 325 S: 326 S: 327 S: 328 S: Command completed successfully 329 S: 330 S: 331 S: 333 S: 334 S: 335 S: xn--fsq270a.example 336 S: 337 S: 338 S: 339 S: xn--fsqz41a.example 340 S: 341 S: This associated domain name is 342 S: a produced name based on bundle name policy. 343 S: 344 S: 345 S: 346 S: 347 S: 348 S: ABC-12345 349 S: 54322-XYZ 350 S: 351 S: 352 S: 354 7.1.2. EPP Command 356 This extension does not add any element to the EPP command 357 described in the EPP domain mapping [RFC5731]. However, additional 358 elements are defined for the response. 360 When an command has been processed successfully, the EPP 361 element must contain child elements as described in the EPP 362 domain mapping [RFC5731]. In addition, unless some registration 363 policy has some special processing, the EPP element 364 should contain a child element that identifies the 365 extension namespace if the domain object has data associated with 366 this extension and based on its registration policy. The 367 element contains the which has the 368 following child elements: 370 o An element that contains the RDN, along with the 371 attribute described below. 373 o An optional element that contains the BDN, along with 374 the attribute described below. 376 The above elements contain the following attribute: 378 o An optional "uLabel" attribute represents the U-label of the 379 element. 381 Example response for an authorized client: 383 S: 384 S: 385 S: 386 S: 387 S: Command completed successfully 388 S: 389 S: 390 S: 392 S: xn--fsq270a.example 393 S: 58812678-domain 394 S: 395 S: 123 396 S: 123 397 S: 123 398 S: 399 S: ns1.example.cn 400 S: 401 S: 402 S: ClientX 403 S: ClientY 404 S: 2011-04-03T22:00:00.0Z 405 S: 406 S: 2012-04-03T22:00:00.0Z 407 S: 408 S: 409 S: 2fooBAR 410 S: 411 S: 412 S: 413 S: 414 S: 416 S: 417 S: 418 S: xn--fsq270a.example 419 S: 420 S: 421 S: xn--fsqz41a.example 422 S: 423 S: 424 S: 425 S: 426 S: 427 S: ABC-12345 428 S: 54322-XYZ 429 S: 430 S: 431 S: 433 Response for the unauthorized client has not been changed,see 434 [RFC5731] for detail. 436 An EPP error response must be returned if an command cannot be 437 processed for any reason. 439 7.1.3. EPP Query Command 441 This extension does not add any element to the EPP command 442 or response described in the EPP domain mapping [RFC5731]. 444 7.2. EPP Transform Commands 446 EPP provides five commands to transform domain objects: to 447 create an instance of a domain object, to delete an instance 448 of a domain object, to extend the validity period of a domain 449 object, to manage domain object sponsorship changes, and 450 to change information associated with a domain object. 452 When theses commands have been processed successfully, the EPP 453 element must contain child elements as described in the EPP 454 domain mapping [RFC5731]. Unless some registration policy has some 455 special processing, this EPP element should contain the 456 which has the following child elements: 458 o An element that contains the RDN, along with the 459 attribute described below. 461 o An optional element that contains the BDN, along with 462 the attribute described below. 464 The above elements contain the following attribute: 466 o An optional "uLabel" attribute represents the U-label of the 467 element. 469 7.2.1. EPP Command 471 This extension defines additional elements to extend the EPP 472 command described in the EPP domain name mapping [RFC5731] for 473 bundled names registration. 475 In addition to the EPP command elements described in the EPP domain 476 mapping [RFC5731], the command shall contain an 477 element. Unless some registration policy has some special 478 processing, the element should contain a child 479 element that identifies the bundle namespace, and a 480 child element that identifies the U-Label form of the 481 registered domain name with the uLabel attribute. 483 Example command: 485 C: 486 C: 487 C: 488 C: 489 C: 491 C: xn--fsq270a.example 492 C: 2 493 C: 123 494 C: 123 495 C: 123 496 C: 497 C: 2fooBAR 498 C: 499 C: 500 C: 501 C: 502 C: 504 C: 505 C: xn--fsq270a.example 506 C: 507 C: 508 C: 509 C: ABC-12345 510 C: 511 C: 512 When an command has been processed successfully, the EPP 513 element must contain child elements as described in the EPP 514 domain mapping [RFC5731]. In addition, unless some registration 515 policy has some special processing, the EPP element 516 should contain a child element that identifies the 517 extension namespace if the domain object has data associated with 518 this extension and based on its registration policy. The 519 element contains the element. 521 Example response: 523 S: 524 S: 525 S: 526 S: 527 S: Command completed successfully 528 S: 529 S: 530 S: 532 S: xn--fsq270a.example 533 S: 1999-04-03T22:00:00.0Z 534 S: 2001-04-03T22:00:00.0Z 535 S: 536 S: 537 S: 538 S: 540 S: 541 S: 542 S: xn--fsq270a.example 543 S: 544 S: 545 S: xn--fsqz41a.example 546 S: 547 S: 548 S: 549 S: 550 S: 551 S: ABC-12345 552 S: 54322-XYZ 553 S: 554 S: 555 S: 557 An EPP error response must be returned if an command cannot 558 be processed for any reason. 560 7.2.2. EPP Command 562 This extension does not add any element to the EPP command 563 described in the EPP domain mapping [RFC5731]. However, additional 564 elements are defined for the response. 566 When a command has been processed successfully, the EPP 567 element must contain child elements as described in the EPP 568 domain mapping [RFC5731]. In addition, unless some registration 569 policy has some special processing, the EPP element 570 should contain a child element that identifies the 571 extension namespace if the domain object has data associated with 572 this extension and based on its registration policy. The 573 element should contain the element. 575 Example response: 577 S: 578 S: 579 S: 580 S: 581 S: Command completed successfully 582 S: 583 S: 584 S: 586 S: 587 S: 588 S: xn--fsq270a.example 589 S: 590 S: 591 S: xn--fsqz41a.example 592 S: 593 S: 594 S: 595 S: 596 S: 597 S: ABC-12345 598 S: 54321-XYZ 599 S: 600 S: 601 S: 603 An EPP error response must be returned if a command cannot 604 be processed for any reason. 606 7.2.3. EPP Command 608 This extension does not add any element to the EPP command 609 described in the EPP domain name mapping [RFC5731]. However, when 610 either RDN or BDN is sent for renew, response should contain both RDN 611 and BDN information. When the command has been processed 612 successfully, the EPP element shall be contained in the 613 response if the domain object has data associated with bundled names. 614 Unless some registration policy has some special processing, this EPP 615 element should contain the which contains 616 element. 618 Example response: 620 S: 621 S: 622 S: 623 S: 624 S: Command completed successfully 625 S: 626 S: 627 S: 629 S: xn--fsq270a.example 630 S: 2012-04-03T22:00:00.0Z 631 S: 632 S: 633 S: 634 S: 636 S: 637 S: 638 S: xn--fsq270a.example 639 S: 640 S: 641 S: xn--fsqz41a.example 642 S: 643 S: 644 S: 645 S: 646 S: 647 S: ABC-12345 648 S: 54322-XYZ 649 S: 650 S: 651 S: 653 7.2.4. EPP Command 655 This extension does not add any element to the EPP command 656 described in the EPP domain name mapping [RFC5731]. However, 657 additional elements are defined for the response in the 658 EPP object mapping. When the command has been processed 659 successfully, the EPP element shall be contained in the 660 response if the domain object has data associated with bundled names. 661 Unless some registration policy has some special processing, this EPP 662 element should contain the which contains 663 element. 665 Example response: 667 S: 668 S: 669 S: 670 S: 671 S: Command completed successfully; action pending 672 S: 673 S: 674 S: 676 S: xn--fsq270a.example 677 S: pending 678 S: ClientX 679 S: 2011-04-03T22:00:00.0Z 680 S: ClientY 681 S: 2011-04-08T22:00:00.0Z 682 S: 2012-04-03T22:00:00.0Z 683 S: 684 S: 685 S: 686 S: 688 S: 689 S: 690 S: xn--fsq270a.example 691 S: 692 S: 693 S: xn--fsqz41a.example 694 S: 695 S: 696 S: 697 S: 698 S: 699 S: ABC-12345 700 S: 54322-XYZ 701 S: 702 S: 703 S: 705 7.2.5. EPP Command 707 This extension does not add any element to the EPP command 708 described in the EPP domain name mapping [RFC5731]. However, 709 additional elements are defined for the response in the EPP 710 object mapping. When the command has been processed successfully, 711 the EPP element shall be contained in the response if the 712 domain object has data associated with bundled names. Unless some 713 registration policy has some special processing, this EPP 714 element should contain the which contains 715 element. 717 Example response: 719 S: 720 S: 721 S: 722 S: 723 S: Command completed successfully 724 S: 725 S: 726 S: 728 S: 729 S: 730 S: xn--fsq270a.example 731 S: 732 S: 733 S: xn--fsqz41a.example 734 S: 735 S: 736 S: 737 S: 738 S: 739 S: ABC-12345 740 S: 54322-XYZ 741 S: 742 S: 743 S: 745 8. Formal Syntax 747 An EPP object name mapping extension for bundled names is specified 748 in XML Schema notation. The formal syntax presented here is a 749 complete schema representation of the object mapping suitable for 750 automated validation of EPP XML instances. The BEGIN and END tags 751 are not part of the schema; they are used to note the beginning and 752 ending of the schema for URI registration purposes. 754 BEGIN 755 757 763 766 769 770 771 Extensible Provisioning Protocol v1.0 772 Bundle Domain Extension Schema v1.0 773 774 776 779 781 785 786 787 789 790 792 796 797 798 799 800 801 803 804 805 806 807 808 809 810 811 813 814 816 817 818 819 820 821 822 824 827 829 END 831 9. Internationalization Considerations 833 EPP is represented in XML, which provides native support for encoding 834 information using the Unicode character set and its more compact 835 representations including UTF-8. Conformant XML processors recognize 836 both UTF-8 and UTF-16. Though XML includes provisions to identify 837 and use other character encodings through use of an "encoding" 838 attribute in an declaration, use of UTF-8 is recommend. 840 As an extension of the EPP domain name mapping, the elements, element 841 content described in this document must inherit the 842 internationalization conventions used to represent higher-layer 843 domain and core protocol structures present in an XML instance that 844 includes this extension. 846 10. IANA Considerations 848 This document uses URNs to describe XML namespaces and XML schemas 849 conforming to a registry mechanism described in [RFC3688]. IANA is 850 requested to assignment the following two URIs. 852 Registration request for the IDN namespace: 854 o URI: urn:ietf:params:xml:ns:epp:b-dn 855 o Registrant Contact: See the "Author's Address" section of this 856 document. 858 o XML: None. Namespace URI does not represent an XML specification. 860 Registration request for the IDN XML schema: 862 o URI: urn:ietf:params:xml:schema:epp:b-dn 864 o Registrant Contact: See the "Author's Address" section of this 865 document. 867 o XML: See the "Formal Syntax" section of this document. 869 The EPP extension described in this document should be registered by 870 IANA in the "Extensions for the Extensible Provisioning Protocol 871 (EPP)" registry described in [RFC7451]. The details of the 872 registration are as follows: 874 o Name of Extension: "Domain Name Mapping Extension for Strict 875 Bundling Registration" 877 o Document status: Informational 879 o Reference: This document 881 o Registrant Name and Email Address: See the "Author's Address" 882 section of this document. 884 o Top-Level Domains (TLDs): Any 886 o IPR Disclosure: https://datatracker.ietf.org/ipr/ 888 o Status: Active 890 o Notes: None 892 11. Security Considerations 894 Some registries and registrars have more than 15 years of the bundled 895 registration of domain names (especially Chinese domain names). They 896 have not found any significant security issues. One principle that 897 the registry and registrar should let the registrants know is that 898 bundled registered domain names will be created, transferred, 899 updated, and deleted together as a group. The registrants for 900 bundled domain names should remember this principle when doing some 901 operations to these domain names. [RFC5730] also introduces some 902 security consideration. 904 This document does not take a position regarding whether or not the 905 bundled domain names share a DS/DNSKEY key. The DNS administrator 906 can choose whether DS/DNSKEY information can be shared or not. If a 907 DS/DNSKEY key is shared then the bundled domain names share fate if 908 there is a key compromise. 910 12. Implementation Status and some clarifications 912 Note to RFC Editor: Please remove this section before publication. 914 o The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, 915 HKIRC, MONIC, SGNIC and more have followed the principles defined 916 in this document for many years. 918 o CNNIC and TELEINFO have implemented this extension in their EPP 919 based Chinese domain name registration system. 921 o Public Interest Registry, has requested to implement technical 922 bundling of second level domains for .NGO and .ONG. This means 923 that by registering and purchasing a domain in the .ngo TLD, for 924 an example, the NGO registrant is also registering and purchasing 925 the corresponding name in the .ong TLD (and vice-versa for 926 registrations in .ong). 928 o Patrick Mevzek has released a new version of Net::DRI, an EPP 929 client (Perl library, free software) implementing this extension. 931 o The idea and main texts of this document has passed IETF REGEXT WG 932 review. 934 13. Acknowledgements 936 The authors especially thank the authors of [RFC5730] and [RFC5731] 937 and the following ones of CNNIC: Weiping Yang, Chao Qi. 939 Useful comments were made by John Klensin, Scott Hollenbeck, Patrick 940 Mevzek and Edward Lewis. 942 14. References 944 14.1. Normative References 946 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 947 DOI 10.17487/RFC3688, January 2004, 948 . 950 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 951 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 952 . 954 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 955 Domain Name Mapping", STD 69, RFC 5731, 956 DOI 10.17487/RFC5731, August 2009, 957 . 959 [RFC5890] Klensin, J., "Internationalized Domain Names for 960 Applications (IDNA): Definitions and Document Framework", 961 RFC 5890, DOI 10.17487/RFC5890, August 2010, 962 . 964 [RFC5891] Klensin, J., "Internationalized Domain Names in 965 Applications (IDNA): Protocol", RFC 5891, 966 DOI 10.17487/RFC5891, August 2010, 967 . 969 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 970 Internationalized Domain Names for Applications (IDNA)", 971 RFC 5892, DOI 10.17487/RFC5892, August 2010, 972 . 974 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 975 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 976 February 2015, . 978 [W3C.REC-xml-20040204] 979 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 980 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 981 Edition)", World Wide Web Consortium FirstEdition REC-xml- 982 20040204", February 2004, 983 . 985 [W3C.REC-xmlschema-1-20041028] 986 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 987 ""XML Schema Part 1: Structures Second Edition", World 988 Wide Web Consortium Recommendation REC-xmlschema- 989 1-20041028", October 2004, 990 . 992 [W3C.REC-xmlschema-2-20041028] 993 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 994 Second Edition", World Wide Web Consortium Recommendation 995 REC-xmlschema-2-20041028", October 2004, 996 . 998 14.2. Informative References 1000 [RFC4290] Klensin, J., "Suggested Practices for Registration of 1001 Internationalized Domain Names (IDN)", RFC 4290, 1002 DOI 10.17487/RFC4290, December 2005, 1003 . 1005 Authors' Addresses 1007 Jiankang Yao 1008 CNNIC 1009 4 South 4th Street,Zhongguancun,Haidian District 1010 Beijing, Beijing 100190 1011 China 1013 Phone: +86 10 5881 3007 1014 Email: yaojk@cnnic.cn 1016 Linlin Zhou 1017 CNNIC 1018 4 South 4th Street,Zhongguancun,Haidian District 1019 Beijing, Beijing 100190 1020 China 1022 Phone: +86 10 5881 2677 1023 Email: zhoulinlin@cnnic.cn 1025 Hongtao Li 1026 CNNIC 1027 4 South 4th Street,Zhongguancun,Haidian District 1028 Beijing, Beijing 100190 1029 China 1031 Email: lihongtao@cnnic.cn 1033 Ning Kong 1034 Consultant 1036 Email: ietfing@gmail.com 1037 Wil Tan 1038 Cloud Registry 1039 Suite 32 Seabridge House, 377 Kent St 1040 Sydney, NSW 2000 1041 Australia 1043 Phone: +61 414 710899 1044 Email: wil@cloudregistry.net 1046 Jiagui Xie 1048 Email: jiagui1984@163.com