idnits 2.17.1 draft-ietf-regext-bundling-registration-11.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 (October 5, 2019) is 1664 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 N. Kong 3 Internet-Draft Consultant 4 Intended status: Informational J. Yao 5 Expires: April 7, 2020 L. Zhou 6 CNNIC 7 W. Tan 8 Cloud Registry 9 J. Xie 10 October 5, 2019 12 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for 13 Strict Bundling Registration 14 draft-ietf-regext-bundling-registration-11 16 Abstract 18 This document describes an extension of Extensible Provisioning 19 Protocol (EPP) domain name mapping for the provisioning and 20 management of strict bundling registration of domain names. 21 Specified in XML, this mapping extends the EPP domain name mapping to 22 provide additional features required for the provisioning of bundled 23 domain names. This is a non-standard proprietary extension. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 7, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Requirement for Bundling Registration of Names . . . . . . . 5 64 6. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. RDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.2. BDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 69 7.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 70 7.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 71 7.1.3. EPP Query Command . . . . . . . . . . . . 10 72 7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 73 7.2.1. EPP Command . . . . . . . . . . . . . . . . 11 74 7.2.2. EPP Command . . . . . . . . . . . . . . . . 13 75 7.2.3. EPP Command . . . . . . . . . . . . . . . . . 14 76 7.2.4. EPP Command . . . . . . . . . . . . . . . 15 77 7.2.5. EPP Command . . . . . . . . . . . . . . . . 16 78 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 17 79 9. Internationalization Considerations . . . . . . . . . . . . . 19 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 83 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 84 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 21 85 14.1. draft-ietf-regext-bundle-registration: Version 00 . . . 21 86 14.2. draft-ietf-regext-bundle-registration: Version 01 . . . 21 87 14.3. draft-ietf-regext-bundle-registration: Version 02 . . . 22 88 14.4. draft-ietf-regext-bundle-registration: Version 03 . . . 22 89 14.5. draft-ietf-regext-bundle-registration: Version 04 . . . 22 90 14.6. draft-ietf-regext-bundle-registration: Version 05 . . . 22 91 14.7. draft-ietf-regext-bundle-registration: Version 06 . . . 22 92 14.8. draft-ietf-regext-bundle-registration: Version 07 . . . 22 93 14.9. draft-ietf-regext-bundle-registration: Version 08 . . . 22 94 14.10. draft-ietf-regext-bundle-registration: Version 09 . . . 22 95 14.11. draft-ietf-regext-bundle-registration: Version 10 . . . 22 96 14.12. draft-ietf-regext-bundle-registration: Version 11 . . . 23 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 15.1. Normative References . . . . . . . . . . . . . . . . . . 23 100 15.2. Informative References . . . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 Bundled domain names are those which share the same TLD but whose 106 second level labels are variants, or those which have identical 107 second level labels for which certain parameters are shared in 108 different TLDs. For an example, Public Interest Registry has 109 requested to implement bundling of second level domains for .NGO and 110 .ONG. So we have two kinds of bundled domain names. The first one 111 is in the form of "V-label.TLD" in which the second level label 112 (V-label) is a variant sharing the same TLD; Second one is in the 113 form of "LABEL.V-tld" in which the second level label(LABEL) remains 114 the same but ending with a different TLD (V-tld). 116 Bundled domain names normally share some attributes. Policy-wise 117 bundling can be implemented in three ways. The first one is strict 118 bundling, which requires all bundled names to share many same 119 attributes. When creating, updating, or transferring of any of the 120 bundled domain names, all bundled domain names will be created, 121 updated or transferred atomically. The second one is partial 122 bundling, which requires the bundled domain names to be registered by 123 the same registrant. The third one is relaxed bundling, which has no 124 specific requirements on the domain registration. This document 125 mainly addresses the strict bundling names registration. 127 For the name variants, some registries adopt the policy that variant 128 IDNs which are identified as equivalent are allocated or delegated to 129 the same registrant. For example, most registries offering Chinese 130 Domain Name (CDN) adopt a registration policy whereby a registrant 131 can apply for an original CDN in any forms: Simplified Chinese (SC) 132 form, Traditional Chinese (TC) form, or other variant forms, then the 133 corresponding variant CDN in SC form and that in TC form will also be 134 delegated to the same registrant. All variant names in the same TLD 135 share a common set of attributes. 137 The basic Extensible Provisioning Protocol (EPP) domain name mapping 138 [RFC5731] provides the facility for single domain name registration. 139 It does not specify how to register the strict bundled names which 140 share many of the attributes. 142 In order to meet the above requirements of strict bundled name 143 registration, this document describes an extension of the EPP domain 144 name mapping [RFC5731] for the provisioning and management of bundled 145 names. This document describes a non-standard proprietary extension. 147 This extension is specially useful for registries of practising 148 Chinese domain name registration. This document is specified using 149 Extensible Markup Language (XML) 1.0 as described in 150 [W3C.REC-xml-20040204] and XML Schema notation as described in 151 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 153 The EPP core protocol specification [RFC5730] provides a complete 154 description of EPP command and response structures. A thorough 155 understanding of the base protocol specification is necessary to 156 understand the extension mapping described in this document. 158 This document uses many IDN concepts, so a thorough understanding of 159 the IDNs for Application (IDNA, described in [RFC5890], [RFC5891], 160 and [RFC5892]) and the variant approach discussed in [RFC4290] is 161 assumed. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119][RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 uLabel in this document is used to express the U-label of an 172 internationalized domain name as a series of characters where non- 173 ASCII characters will be represented in the format of "&#xXXXX;" 174 where XXXX is a UNICODE point by using the XML escaping mechanism. 175 U-Label is defined in [RFC5890]. 177 The XML namespace prefix "b-dn" is used for the namespace 178 "urn:ietf:params:xml:ns:epp:b-dn", but implementations MUST NOT rely 179 on it and instead employ a proper namespace-aware XML parser and 180 serializer to interpret and output the XML documents. 182 In examples, "C:" represents lines sent by a protocol client and "S:" 183 represents lines returned by a protocol server. Indentation and 184 white space in examples are provided only to illustrate element 185 relationships and are not a required feature of this specification. 187 XML is case sensitive. Unless stated otherwise, XML specifications 188 and examples provided in this document MUST be interpreted in the 189 character case presented to develop a conforming implementation. 191 3. Definitions 193 The following definitions are used in this document: 195 o Registered Domain Name (RDN), represents the valid domain name 196 that users submitted for the initial registration. 198 o Bundled Domain Name (BDN), represents the bundled domain name 199 produced according to the bundled domain name registration policy. 201 4. Overview 203 Domain registries have traditionally adopted a registration model 204 whereby metadata relating to a domain name, such as its expiration 205 date and sponsoring registrar, are stored as properties of the domain 206 object. The domain object is then considered an atomic unit of 207 registration, on which operations such as update, renewal and 208 deletion may be performed. 210 Bundled names brought about the need for multiple domain names to be 211 registered and managed as a single package. In this model, the 212 registry typically accepts a domain registration request (i.e. EPP 213 domain command) containing the domain name to be registered. 214 This domain name is referred to as the RDN in this document. As part 215 of the processing of the registration request, the registry generates 216 a set of bundled names that are related to the RDN, either 217 programmatically or with the guidance of registration policies, and 218 places them in the registration package together with the RDN. 220 The bundled names share many properties, such as expiration date and 221 sponsoring registrar, by sharing the same domain object. So when 222 users update any property of a domain object within a bundle package, 223 that property of all other domain objects in the bundle package will 224 be updated at the same time. 226 5. Requirement for Bundling Registration of Names 228 The bundled names whether they are in the form of "V-label.TLD" or in 229 the form of "LABEL.V-tld" should share some parameter or attributes 230 associated with domain names. Typically, bundled names will share 231 the following parameters or attributes: 232 o Registrar Ownership 233 o Registration and Expiry Dates 234 o Registrant, Admin, Billing, and Technical Contacts 235 o Name Server Association 236 o Domain Status 237 o Applicable grace periods (Add Grace Period, Renewal Grace Period, 238 Auto-Renewal Grace Period, Transfer Grace Period, and Redemption 239 Grace Period) 241 Because the domain names are bundled and share the same parameters or 242 attributes, the EPP command should do some processing for these 243 requirements: 244 o When performing a domain check, either BDN or RDN can be queried 245 for the EPP command, and will return the same response. 246 o When performing a domain info, either BDN or RDN can be queried, 247 the same response will include both BDN and RDN information with the 248 same attributes. 249 o When performing a domain Create, either of the bundle names will be 250 accepted. If the domain name is available, both BDN and RDN will be 251 registered. 252 o When performing a domain Delete, either BDN or RDN will be 253 accepted. If the domain name is registered, both BDN and RDN will be 254 deleted. 255 o When performing a domain renew, either BDN or RDN will be accepted. 256 Upon a successful domain renewal, both BDN and RDN will have their 257 expiry date extended by the requested term. Upon a successful domain 258 renewal, both BDN and RDN will conform to the same renew grace 259 period. 260 o When performing a domain transfer, either BDN or RDN will be 261 accepted. Upon successful completion of a domain transfer request, 262 both BDN and RDN will enter a pendingTransfer status. Upon approval 263 of the transfer request, both BDN and RDN will be owned and managed 264 by the same new registrant. 265 o When performing a domain update, either BDN or RDN will be 266 accepted. Any modifications to contact associations, name server 267 associations, domain status values and authorization information will 268 be applied to both BDN and RDN. 270 6. Object Attributes 272 This extension defines following additional elements to the EPP 273 domain name mapping [RFC5731]. All of these additional elements are 274 returned from command. 276 6.1. RDN 278 The RDN is an ASCII name or an IDN with the A-label [RFC5890] form. 279 In this document, its corresponding element is . An 280 optional attribute "uLabel" associated with is used to 281 represent the U-label [RFC5890] form. 283 For example: xn-- 284 fsq270a.example 286 6.2. BDN 288 The BDN is an ASCII name or an IDN with the A-label [RFC5890] form 289 which is converted from the corresponding BDN. In this document, its 290 corresponding element is . An optional attribute "uLabel" 291 associated with is used to represent the U-label [RFC5890] 292 form. 294 For example: xn-- 295 fsqz41a.example 297 7. EPP Command Mapping 299 A detailed description of the EPP syntax and semantics can be found 300 in the EPP core protocol specification [RFC5730]. The command 301 mappings described here are specifically for use in provisioning and 302 managing bundled names via EPP. 304 7.1. EPP Query Commands 306 EPP provides three commands to retrieve domain information: 307 to determine if a domain object can be provisioned within a 308 repository, to retrieve detailed information associated with a 309 domain object, and to retrieve domain-object transfer 310 status information. 312 7.1.1. EPP Command 314 This extension does not add any element to the EPP command or 315 response described in the EPP domain name mapping [RFC5731]. 316 However, when either RDN or BDN is sent for check, response SHOULD 317 contain both RDN and BDN information, which may also give some 318 explanation in the reason field to tell the user that the associated 319 domain name is a produced name according to some bundle domain name 320 policy. 322 Example response: 323 S: 324 S: 325 S: 326 S: 327 S: Command completed successfully 328 S: 329 S: 330 S: 332 S: 333 S: 334 S: xn--fsq270a.example 335 S: 336 S: 337 S: 338 S: xn--fsqz41a.example 339 S: 340 S: This associated domain name is 341 S: a produced name based on bundle name policy. 342 S: 343 S: 344 S: 345 S: 346 S: 347 S: ABC-12345 348 S: 54322-XYZ 349 S: 350 S: 351 S: 353 7.1.2. EPP Command 355 This extension does not add any element to the EPP command 356 described in the EPP domain mapping [RFC5731]. However, additional 357 elements are defined for the response. 359 When an command has been processed successfully, the EPP 360 element MUST contain child elements as described in the EPP 361 domain mapping [RFC5731]. In addition, unless some registration 362 policy has some special processing, the EPP element 363 SHOULD contain a child element that identifies the 364 extension namespace if the domain object has data associated with 365 this extension and based on its registration policy. The 366 element contains the which has the 367 following child elements: 369 o An element that contains the RDN, along with the 370 attribute described below. 372 o An OPTIONAL element that contains the BDN, along with 373 the attribute described below. 375 The above elements contain the following attribute: 377 o An optional "uLabel" attribute represents the U-label of the 378 element. 380 Example response for an authorized client: 382 S: 383 S: 384 S: 385 S: 386 S: Command completed successfully 387 S: 388 S: 389 S: 391 S: xn--fsq270a.example 392 S: 58812678-domain 393 S: 394 S: 123 395 S: 123 396 S: 123 397 S: 398 S: ns1.example.cn 399 S: 400 S: 401 S: ClientX 402 S: ClientY 403 S: 2011-04-03T22:00:00.0Z 404 S: 405 S: 2012-04-03T22:00:00.0Z 406 S: 407 S: 408 S: 2fooBAR 409 S: 410 S: 411 S: 412 S: 413 S: 415 S: 416 S: 417 S: xn--fsq270a.example 418 S: 419 S: 420 S: xn--fsqz41a.example 421 S: 422 S: 423 S: 424 S: 425 S: 426 S: ABC-12345 427 S: 54322-XYZ 428 S: 429 S: 430 S: 432 Response for the unauthorized client has not been changed,see 433 [RFC5731] for detail. 435 An EPP error response MUST be returned if an command cannot be 436 processed for any reason. 438 7.1.3. EPP Query Command 440 This extension does not add any element to the EPP command 441 or response described in the EPP domain mapping [RFC5731]. 443 7.2. EPP Transform Commands 445 EPP provides five commands to transform domain objects: to 446 create an instance of a domain object, to delete an instance 447 of a domain object, to extend the validity period of a domain 448 object, to manage domain object sponsorship changes, and 449 to change information associated with a domain object. 451 When theses commands have been processed successfully, the EPP 452 element MUST contain child elements as described in the EPP 453 domain mapping [RFC5731]. Unless some registration policy has some 454 special processing, this EPP element SHOULD contain the 455 which has the following child elements: 457 o An element that contains the RDN, along with the 458 attribute described below. 460 o An OPTIONAL element that contains the BDN, along with 461 the attribute described below. 463 The above elements contain the following attribute: 465 o An optional "uLabel" attribute represents the U-label of the 466 element. 468 7.2.1. EPP Command 470 This extension defines additional elements to extend the EPP 471 command described in the EPP domain name mapping [RFC5731] for 472 bundled names registration. 474 In addition to the EPP command elements described in the EPP domain 475 mapping [RFC5731], the command SHALL contain an 476 element. Unless some registration policy has some special 477 processing, the element SHOULD contain a child 478 element that identifies the bundle namespace, and a 479 child element that identifies the U-Label form of the 480 registered domain name with the uLabel attribute. 482 Example command: 484 C: 485 C: 486 C: 487 C: 488 C: 490 C: xn--fsq270a.example 491 C: 2 492 C: 123 493 C: 123 494 C: 123 495 C: 496 C: 2fooBAR 497 C: 498 C: 499 C: 500 C: 501 C: 503 C: 504 C: xn--fsq270a.example 505 C: 506 C: 507 C: 508 C: ABC-12345 509 C: 510 C: 511 When an command has been processed successfully, the EPP 512 element MUST contain child elements as described in the EPP 513 domain mapping [RFC5731]. In addition, unless some registration 514 policy has some special processing, the EPP element 515 SHOULD contain a child element that identifies the 516 extension namespace if the domain object has data associated with 517 this extension and based on its registration policy. The 518 element contains the element. 520 Example response: 522 S: 523 S: 524 S: 525 S: 526 S: Command completed successfully 527 S: 528 S: 529 S: 531 S: xn--fsq270a.example 532 S: 1999-04-03T22:00:00.0Z 533 S: 2001-04-03T22:00:00.0Z 534 S: 535 S: 536 S: 537 S: 539 S: 540 S: 541 S: xn--fsq270a.example 542 S: 543 S: 544 S: xn--fsqz41a.example 545 S: 546 S: 547 S: 548 S: 549 S: 550 S: ABC-12345 551 S: 54322-XYZ 552 S: 553 S: 554 S: 556 An EPP error response MUST be returned if an command cannot 557 be processed for any reason. 559 7.2.2. EPP Command 561 This extension does not add any element to the EPP command 562 described in the EPP domain mapping [RFC5731]. However, additional 563 elements are defined for the response. 565 When a command has been processed successfully, the EPP 566 element MUST contain child elements as described in the EPP 567 domain mapping [RFC5731]. In addition, unless some registration 568 policy has some special processing, the EPP element 569 SHOULD contain a child element that identifies the 570 extension namespace if the domain object has data associated with 571 this extension and based on its registration policy. The 572 element SHOULD contain the element. 574 Example response: 576 S: 577 S: 578 S: 579 S: 580 S: Command completed successfully 581 S: 582 S: 583 S: 585 S: 586 S: 587 S: xn--fsq270a.example 588 S: 589 S: 590 S: xn--fsqz41a.example 591 S: 592 S: 593 S: 594 S: 595 S: 596 S: ABC-12345 597 S: 54321-XYZ 598 S: 599 S: 600 S: 602 An EPP error response MUST be returned if a command cannot 603 be processed for any reason. 605 7.2.3. EPP Command 607 This extension does not add any element to the EPP command 608 described in the EPP domain name mapping [RFC5731]. However, when 609 either RDN or BDN is sent for renew, response SHOULD contain both RDN 610 and BDN information. When the command has been processed 611 successfully, the EPP element SHALL be contained in the 612 response if the domain object has data associated with bundled names. 613 Unless some registration policy has some special processing, this EPP 614 element SHOULD contain the which contains 615 element. 617 Example response: 619 S: 620 S: 621 S: 622 S: 623 S: Command completed successfully 624 S: 625 S: 626 S: 628 S: xn--fsq270a.example 629 S: 2012-04-03T22:00:00.0Z 630 S: 631 S: 632 S: 633 S: 635 S: 636 S: 637 S: xn--fsq270a.example 638 S: 639 S: 640 S: xn--fsqz41a.example 641 S: 642 S: 643 S: 644 S: 645 S: 646 S: ABC-12345 647 S: 54322-XYZ 648 S: 649 S: 650 S: 652 7.2.4. EPP Command 654 This extension does not add any element to the EPP command 655 described in the EPP domain name mapping [RFC5731]. However, 656 additional elements are defined for the response in the 657 EPP object mapping. When the command has been processed 658 successfully, the EPP element SHALL be contained in the 659 response if the domain object has data associated with bundled names. 660 Unless some registration policy has some special processing, this EPP 661 element SHOULD contain the which contains 662 element. 664 Example response: 666 S: 667 S: 668 S: 669 S: 670 S: Command completed successfully; action pending 671 S: 672 S: 673 S: 675 S: xn--fsq270a.example 676 S: pending 677 S: ClientX 678 S: 2011-04-03T22:00:00.0Z 679 S: ClientY 680 S: 2011-04-08T22:00:00.0Z 681 S: 2012-04-03T22:00:00.0Z 682 S: 683 S: 684 S: 685 S: 687 S: 688 S: 689 S: xn--fsq270a.example 690 S: 691 S: 692 S: xn--fsqz41a.example 693 S: 694 S: 695 S: 696 S: 697 S: 698 S: ABC-12345 699 S: 54322-XYZ 700 S: 701 S: 702 S: 704 7.2.5. EPP Command 706 This extension does not add any element to the EPP command 707 described in the EPP domain name mapping [RFC5731]. However, 708 additional elements are defined for the response in the EPP 709 object mapping. When the command has been processed successfully, 710 the EPP element SHALL be contained in the response if the 711 domain object has data associated with bundled names. Unless some 712 registration policy has some special processing, this EPP 713 element SHOULD contain the which contains 714 element. 716 Example response: 718 S: 719 S: 720 S: 721 S: 722 S: Command completed successfully 723 S: 724 S: 725 S: 727 S: 728 S: 729 S: xn--fsq270a.example 730 S: 731 S: 732 S: xn--fsqz41a.example 733 S: 734 S: 735 S: 736 S: 737 S: 738 S: ABC-12345 739 S: 54322-XYZ 740 S: 741 S: 742 S: 744 8. Formal Syntax 746 An EPP object name mapping extension for bundled names is specified 747 in XML Schema notation. The formal syntax presented here is a 748 complete schema representation of the object mapping suitable for 749 automated validation of EPP XML instances. The BEGIN and END tags 750 are not part of the schema; they are used to note the beginning and 751 ending of the schema for URI registration purposes. 753 BEGIN 754 756 762 765 768 769 770 Extensible Provisioning Protocol v1.0 771 Bundle Domain Extension Schema v1.0 772 773 775 778 780 784 785 786 788 789 791 795 796 797 798 799 800 802 803 804 805 806 807 808 809 810 812 813 815 816 817 818 819 820 821 823 826 828 END 830 9. Internationalization Considerations 832 EPP is represented in XML, which provides native support for encoding 833 information using the Unicode character set and its more compact 834 representations including UTF-8. Conformant XML processors recognize 835 both UTF-8 and UTF-16. Though XML includes provisions to identify 836 and use other character encodings through use of an "encoding" 837 attribute in an declaration, use of UTF-8 is RECOMMENDED. 839 As an extension of the EPP domain name mapping, the elements, element 840 content described in this document MUST inherit the 841 internationalization conventions used to represent higher-layer 842 domain and core protocol structures present in an XML instance that 843 includes this extension. 845 10. IANA Considerations 847 This document uses URNs to describe XML namespaces and XML schemas 848 conforming to a registry mechanism described in [RFC3688]. IANA is 849 requested to assignment the following two URIs. 851 Registration request for the IDN namespace: 853 o URI: urn:ietf:params:xml:ns:epp:b-dn 854 o Registrant Contact: See the "Author's Address" section of this 855 document. 857 o XML: None. Namespace URI does not represent an XML specification. 859 Registration request for the IDN XML schema: 861 o URI: urn:ietf:params:xml:schema:epp:b-dn 863 o Registrant Contact: See the "Author's Address" section of this 864 document. 866 o XML: See the "Formal Syntax" section of this document. 868 The EPP extension described in this document should be registered by 869 IANA in the "Extensions for the Extensible Provisioning Protocol 870 (EPP)" registry described in [RFC7451]. The details of the 871 registration are as follows: 873 o Name of Extension: "Domain Name Mapping Extension for Strict 874 Bundling Registration" 876 o Document status: Informational 878 o Reference: This document 880 o Registrant Name and Email Address: IESG, iesg@ietf.org 882 o Top-Level Domains (TLDs): Any 884 o IPR Disclosure: https://datatracker.ietf.org/ipr/ 886 o Status: Active 888 o Notes: None 890 11. Security Considerations 892 Some registries and registrars have more than 15 years of the bundled 893 registration of domain names (especially Chinese domain names). They 894 have not found any significant security issues. One principle that 895 the registry and registrar should let the registrants know is that 896 bundled registered domain names will be created, transferred, 897 updated, and deleted together as a group. The registrants for 898 bundled domain names should remember this principle when doing some 899 operations to these domain names. [RFC5730] also introduces some 900 security consideration. 902 This document does not take a position regarding whether or not the 903 bundled domain names share a DS/DNSKEY key. The DNS administrator 904 can choose whether DS/DNSKEY information can be shared or not. If a 905 DS/DNSKEY key is shared then the bundled domain names share fate if 906 there is a key compromise. 908 12. Implementation Status 910 Note to RFC Editor: Please remove this section before publication. 912 o The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, 913 HKIRC, MONIC, SGNIC and more have followed the principles defined 914 in this document for many years. 916 o CNNIC and TELEINFO have implemented this extension in their EPP 917 based Chinese domain name registration system. 919 o Public Interest Registry, has requested to implement technical 920 bundling of second level domains for .NGO and .ONG. This means 921 that by registering and purchasing a domain in the .ngo TLD, for 922 an example, the NGO registrant is also registering and purchasing 923 the corresponding name in the .ong TLD (and vice-versa for 924 registrations in .ong). 926 o Patrick Mevzek has released a new version of Net::DRI, an EPP 927 client (Perl library, free software) implementing this extension. 929 13. Acknowledgements 931 The authors especially thank the authors of [RFC5730] and [RFC5731] 932 and the following ones of CNNIC: Weiping Yang, Chao Qi. 934 Useful comments were made by John Klensin, Scott Hollenbeck, Patrick 935 Mevzek and Edward Lewis. 937 14. Change History 939 RFC Editor: Please remove this section. 941 14.1. draft-ietf-regext-bundle-registration: Version 00 943 o accepted as WG document. 945 14.2. draft-ietf-regext-bundle-registration: Version 01 947 o make this document to focus on the restrict bundled domain name 948 registration. 950 14.3. draft-ietf-regext-bundle-registration: Version 02 952 o Update the section of implementation status. 954 14.4. draft-ietf-regext-bundle-registration: Version 03 956 o This document is changed to informational category. 958 o Refine the text. 960 14.5. draft-ietf-regext-bundle-registration: Version 04 962 o Update the implementation section. 964 o Refine the text. 966 14.6. draft-ietf-regext-bundle-registration: Version 05 968 o Scope the XML namespaces to include 'epp'. 970 14.7. draft-ietf-regext-bundle-registration: Version 06 972 o add some examples for the transfer, update and renew command 974 o add some text to security consideration 976 14.8. draft-ietf-regext-bundle-registration: Version 07 978 o Update IANA consideration section based on Scott's comments 980 o Update security consideration based on Chair and Patrick Mevzek's 981 comments 983 14.9. draft-ietf-regext-bundle-registration: Version 08 985 o Refine some texts. 987 14.10. draft-ietf-regext-bundle-registration: Version 09 989 o Refine the texts. 991 14.11. draft-ietf-regext-bundle-registration: Version 10 993 o Update the texts based on IETF LC. 995 14.12. draft-ietf-regext-bundle-registration: Version 11 997 o Update the texts based on AD's comment. 999 15. References 1001 15.1. Normative References 1003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1004 Requirement Levels", BCP 14, RFC 2119, 1005 DOI 10.17487/RFC2119, March 1997, 1006 . 1008 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1009 DOI 10.17487/RFC3688, January 2004, 1010 . 1012 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1013 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1014 . 1016 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1017 Domain Name Mapping", STD 69, RFC 5731, 1018 DOI 10.17487/RFC5731, August 2009, 1019 . 1021 [RFC5890] Klensin, J., "Internationalized Domain Names for 1022 Applications (IDNA): Definitions and Document Framework", 1023 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1024 . 1026 [RFC5891] Klensin, J., "Internationalized Domain Names in 1027 Applications (IDNA): Protocol", RFC 5891, 1028 DOI 10.17487/RFC5891, August 2010, 1029 . 1031 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 1032 Internationalized Domain Names for Applications (IDNA)", 1033 RFC 5892, DOI 10.17487/RFC5892, August 2010, 1034 . 1036 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1037 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1038 February 2015, . 1040 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1041 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1042 May 2017, . 1044 [W3C.REC-xml-20040204] 1045 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1046 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 1047 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1048 20040204", February 2004, 1049 . 1051 [W3C.REC-xmlschema-1-20041028] 1052 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1053 ""XML Schema Part 1: Structures Second Edition", World 1054 Wide Web Consortium Recommendation REC-xmlschema- 1055 1-20041028", October 2004, 1056 . 1058 [W3C.REC-xmlschema-2-20041028] 1059 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 1060 Second Edition", World Wide Web Consortium Recommendation 1061 REC-xmlschema-2-20041028", October 2004, 1062 . 1064 15.2. Informative References 1066 [RFC4290] Klensin, J., "Suggested Practices for Registration of 1067 Internationalized Domain Names (IDN)", RFC 4290, 1068 DOI 10.17487/RFC4290, December 2005, 1069 . 1071 Authors' Addresses 1073 Ning Kong 1074 Consultant 1076 Email: ietfing@gmail.com 1078 Jiankang Yao 1079 CNNIC 1080 4 South 4th Street,Zhongguancun,Haidian District 1081 Beijing, Beijing 100190 1082 China 1084 Phone: +86 10 5881 3007 1085 Email: yaojk@cnnic.cn 1086 Linlin Zhou 1087 CNNIC 1088 4 South 4th Street,Zhongguancun,Haidian District 1089 Beijing, Beijing 100190 1090 China 1092 Phone: +86 10 5881 2677 1093 Email: zhoulinlin@cnnic.cn 1095 Wil Tan 1096 Cloud Registry 1097 Suite 32 Seabridge House, 377 Kent St 1098 Sydney, NSW 2000 1099 Australia 1101 Phone: +61 414 710899 1102 Email: wil@cloudregistry.net 1104 Jiagui Xie 1106 Email: jiagui1984@163.com