idnits 2.17.1 draft-ietf-regext-bundling-registration-08.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2018) is 1985 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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, Ed. 5 Expires: May 22, 2019 L. Zhou 6 CNNIC 7 W. Tan 8 Cloud Registry 9 J. Xie 10 November 18, 2018 12 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for 13 Strict Bundling Registration 14 draft-ietf-regext-bundling-registration-08 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. 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 May 22, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. Requirement for Bundling Registration of Names . . . . . . . 5 76 6. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6 77 6.1. RDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 6.2. BDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 80 7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 81 7.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 82 7.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 83 7.1.3. EPP Query Command . . . . . . . . . . . . 10 84 7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 85 7.2.1. EPP Command . . . . . . . . . . . . . . . . 11 86 7.2.2. EPP Command . . . . . . . . . . . . . . . . 12 87 7.2.3. EPP Command . . . . . . . . . . . . . . . . . 13 88 7.2.4. EPP Command . . . . . . . . . . . . . . . 14 89 7.2.5. EPP Command . . . . . . . . . . . . . . . . 15 90 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 91 9. Internationalization Considerations . . . . . . . . . . . . . 18 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 95 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 96 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 21 97 14.1. draft-kong-epp-bundle-mapping: Version 00 . . . . . . . 21 98 14.2. draft-kong-epp-bundle-mapping: Version 01 . . . . . . . 21 99 14.3. draft-kong-epp-bundle-mapping: Version 02 . . . . . . . 21 100 14.4. draft-ietf-regext-bundle-mapping: Version 00 . . . . . . 21 101 14.5. draft-ietf-regext-bundle-mapping: Version 01 . . . . . . 21 102 14.6. draft-ietf-regext-bundle-mapping: Version 02 . . . . . . 21 103 14.7. draft-ietf-regext-bundle-mapping: Version 03 . . . . . . 21 104 14.8. draft-ietf-regext-bundle-mapping: Version 04 . . . . . . 21 105 14.9. draft-ietf-regext-bundle-mapping: Version 05 . . . . . . 22 106 14.10. draft-ietf-regext-bundle-mapping: Version 06 . . . . . . 22 107 14.11. draft-ietf-regext-bundle-mapping: Version 07 . . . . . . 22 108 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 109 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 110 15.2. Informative References . . . . . . . . . . . . . . . . . 23 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 113 1. Introduction 115 Bundled domain names are those which share the same TLD but whose 116 second level labels are variants, or those which has identical second 117 level labels for which certain parameters are shared in different 118 TLDs. For example, Public Interest Registry, request to implement 119 technical bundling of second level domains for .NGO and .ONG. So we 120 have two kinds of bundled domain names. First one is in the form of 121 "V-label.TLD" in which the second level labels (V-label) are variants 122 sharing the same TLD; Second one is in the form of "LABEL.V-tld" in 123 which the second level labels(LABEL) are same ending with the 124 different TLDs (V-tld); 126 Bundled domain names normally share some attributes. There are three 127 types of bundling. First one is strict bundling, which requires all 128 bundled names to share many same attributes. When creating, 129 updating, or transferring of any of the bundled domain names, all 130 bundled domain names will be created, updated or transferred. Second 131 one is partial bundling, which requires that at least the bundled 132 domain names if registered should be registered by the same 133 registrant. Third one is relax bundling, which has not specific 134 requirements to the domain registration. This document mainly focus 135 on strict bundling names registration. 137 For the name variants, some registries adopt the policy that variant 138 IDNs which are identified as equivalent are allocated or delegated to 139 the same registrant. For example, the specified registration policy 140 of Chinese Domain Name (CDN) is that a registrant can apply an 141 original CDN in any forms: Simplified Chinese (SC) form, Traditional 142 Chinese (TC) form, or other variant forms, then the corresponding 143 variant CDN in SC form and that in TC form will also be delegated to 144 the same registrant. All variant names in the same TLD contain same 145 attributes. 147 The basic Extensible Provisioning Protocol (EPP) domain name mapping 148 [RFC5731] provides the domain name registration one by one. It does 149 not specify how to register the strict bundled names which share many 150 same attributes. 152 In order to meet above requirements of the strict bundled names 153 registration, this document describes an extension of the EPP domain 154 name mapping [RFC5731] for the provisioning and management of bundled 155 names.This document is specified using the Extensible Markup Language 156 (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema 157 notation as described in [W3C.REC-xmlschema-1-20041028] and 158 [W3C.REC-xmlschema-2-20041028]. 160 The EPP core protocol specification [RFC5730] provides a complete 161 description of EPP command and response structures. A thorough 162 understanding of the base protocol specification is necessary to 163 understand the extension of mapping described in this document. 165 This document uses lots of the concepts of the IDN, so a thorough 166 understanding of the IDNs for Application (IDNA, described in 167 [RFC5890], [RFC5891], and [RFC5892]) and a thorough understanding of 168 variant approach discussed in [RFC4290] are both required. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 uLabel in this document is used to express U-label of the 177 internationalized domain name into series of characters where non- 178 ASCII characters will be represented with the format of U+XXXX where 179 XXXX is a UNICODE point. U-Label is defined in [RFC5890]. 181 "b-dn-1.0" in this document is used as an abbreviation for 182 urn:ietf:params:xml:ns:epp:b-dn-1.0. 184 In examples, "C:" represents lines sent by a protocol client and "S:" 185 represents lines returned by a protocol server. Indentation and 186 white space in examples are provided only to illustrate element 187 relationships and are not a REQUIRED feature of this specification. 189 XML is case sensitive. Unless stated otherwise, XML specifications 190 and examples provided in this document MUST be interpreted in the 191 character case presented to develop a conforming implementation. 193 3. Definitions 195 The following definitions are used in this document: 197 o Registered Domain Name (RDN), represents the valid domain name 198 that users submitted for registration by the first time. 200 o Bundled Domain Name (BDN), represents the bundled domain name 201 produced according to the bundled domain name registration policy. 203 4. Overview 205 Domain registries have traditionally adopted a registration model 206 whereby metadata relating to a domain name, such as its expiration 207 date and sponsoring registrar, are stored as properties of the domain 208 object. The domain object is then considered an atomic unit of 209 registration, on which operations such as update, renewal and 210 deletion may be performed. 212 Bundled names, brought about the need for multiple domain names to be 213 registered and managed as a single package. In this model, the 214 registry typically accepts a domain registration request (i.e. EPP 215 domain command) containing the domain name to be registered. 216 This domain name is referred to as the RDN in this document. As part 217 of the processing of the registration request, the registry generates 218 a set of bundled names that are related to the RDN, either 219 programmatically or with the guidance of registration policies, and 220 place them in the registration package together with the RDN. 222 The bundled names share many same properties, such as expiration date 223 and sponsoring registrar, by sharing one domain object. So when 224 users update any property of a domain object within a bundle package, 225 that property of all other domain objects in the bundle package will 226 be updated at the same time. 228 5. Requirement for Bundling Registration of Names 230 The bundled names whether they are in the form of "V-label.TLD" or in 231 the form of "LABEL.V-tld" should share some parameter or attributes 232 assoicated with domain names. Typically, Bundled names will share 233 the following parameters or attributes: 234 o Registrar Ownership 235 o Registration and Expiry Dates 236 o Registrant, Admin, Billing, and Technical Contacts 237 o Name Server Association 238 o Domain Status 239 o Applicable grace periods (Add Grace Period, Renewal Grace Period, 240 Auto-Renewal Grace Period, Transfer Grace Period, and Redemption 241 Grace Period) 243 Because the domain names are bundled and share the same parameters or 244 attributes, the EPP command should do some processing for these 245 requirements: 246 o When performing a domain check, either BDN or RDN can be queried 247 for the EPP command, and will return the same response. 248 o When performing a domain info, either BDN or RDN can be queried, 249 the same response will include both BDN and RDN information with the 250 same attributes. 251 o When performing a domain Create, either BDN or RDN will be 252 accepted. If the domain name is available, both BDN and RDN will be 253 registered. 254 o When performing a domain Delete, either BDN or RDN will be 255 accepted. If the domain name is available, both BDN and RDN will be 256 deleted. 257 o When performing a domain renew, either BDN or RDN will be accepted. 258 Upon a successful domain renewal,both BDN and RDN will have their 259 expiry date extended by the requested term. Upon a successful domain 260 renewal, both BDN and RDN will conform to the same renew grace 261 period. 262 o When performing a domain transfer, either BDN or RDN will be 263 accepted. Upon successful completion of a domain transfer request, 264 both BDN and RDN will enter a pendingTransfer status. Upon approval 265 of the transfer request, both BDN and RDN will be owned and managed 266 by the same new registrant. 267 o When performing a domain update, either BDN or RDN will be 268 accepted. Any modifications to contact associations, name server 269 associations, domain status values and authorization information will 270 be applied to both BDN and RDN. 272 6. Object Attributes 274 This extension defines following additional elements to the EPP 275 domain name mapping [RFC5731]. All of these additional elements can 276 be got from command. 278 6.1. RDN 280 The RDN is an ASCII name or an IDN with the A-label [RFC5890] form. 281 In this document, its corresponding element is . An 282 optional attribute "uLabel" associated with is used to 283 represent the U-label [RFC5890] form. An optional boolean 284 "activated" attribute, with a default true value, is used to indicate 285 the presence of the label in the zone file. 287 For example: xn-- 288 fsq270a.example 290 6.2. BDN 292 The BDN is an ASCII name or an IDN with the A-label [RFC5890] form 293 which is converted from the corresponding BDN. In this document, its 294 corresponding element is . An optional attribute "uLabel" 295 associated with is used to represent the U-label [RFC5890] 296 form. 298 For example: xn-- 299 fsqz41a.example 301 7. EPP Command Mapping 303 A detailed description of the EPP syntax and semantics can be found 304 in the EPP core protocol specification [RFC5730]. The command 305 mappings described here are specifically for use in provisioning and 306 managing bundled names via EPP. 308 7.1. EPP Query Commands 310 EPP provides three commands to retrieve domain information: 311 to determine if a domain object can be provisioned within a 312 repository, to retrieve detailed information associated with a 313 domain object, and to retrieve domain-object transfer 314 status information. 316 7.1.1. EPP Command 318 This extension does not add any element to the EPP command or 319 response described in the EPP domain name mapping [RFC5731]. 320 However, when either RDN or BDN is sent for check, response SHOULD 321 contain both RDN and BDN information, which may also give some 322 explanation in the reason field to tell the user that the associated 323 domain name is a produced name according to some bundle domain name 324 policy. 326 Example Response for an authorized client: 328 S: 329 S: 330 S: 331 S: 332 S: Command completed successfully 333 S: 334 S: 335 S: 337 S: 338 S: 339 xn--fsq270a.example 340 S: 341 S: 342 S: 343 xn--fsqz41a.example 344 S: This associated domain name is 345 a produced name 346 based on bundle name policy. 347 S: 348 S: 349 S: 350 S: 351 S: ABC-12345 352 S: 54322-XYZ 353 S: 354 S: 355 S: 357 7.1.2. EPP Command 359 This extension does not add any element to the EPP command 360 described in the EPP domain mapping [RFC5731]. However, additional 361 elements are defined for the response. 363 When an command has been processed successfully, the EPP 364 element MUST contain child elements as described in the EPP 365 domain mapping [RFC5731]. In addition, the EPP element 366 SHOULD contain a child element that identifies the 367 extension namespace if the domain object has data associated with 368 this extension and based on its service policy. The 369 element contains the which has the following child 370 elements: 372 o An element that contains the RDN, along with the 373 attributes described below. 375 o An OPTIONAL element that contains the BDN, along with 376 the attributes described below. 378 The above elements contain the following attributes: 380 o An optional "uLabel" attribute represents the U-label of the 381 element. 383 Example Response for an authorized client: 385 S: 386 S: 387 S: 388 S: 389 S: Command completed successfully 390 S: 391 S: 392 S: 394 S: xn--fsq270a.example 395 S: 58812678-domain 396 S: 397 S: 123 398 S: 123 399 S: 123 400 S: 401 S: ns1.example.cn 402 403 S: 404 S: ClientX 405 S: ClientY 406 S: 2011-04-03T22:00:00.0Z 407 408 S: 2012-04-03T22:00:00.0Z 409 410 S: 411 S: 2fooBAR 412 S: 413 S: 414 S: 415 S: 416 S: 418 S: 419 S: xn--fsq270a.example 421 S: xn--fsqz41a.example 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 reponse 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]. This EPP element SHOULD 455 contain the which has the following child elements: 457 o An element that contains the RDN, along with the 458 attributes described below. 460 o An OPTIONAL element that contains the BDN, along with 461 the attributes 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. The element SHOULD contain a child 477 element that identifies the bundle namespace and the 478 location of the bundle name schema. 480 Example command: 482 C: 483 C: 484 C: 485 C: 486 C: 488 C: xn--fsq270a.example 489 C: 2 490 C: 123 491 C: 123 492 C: 123 493 C: 494 C: 2fooBAR 495 C: 496 C: 497 C: 498 C: 499 C: 501 C: 502 C: xn--fsq270a.example 503 C: 504 C: 505 C: ABC-12345 506 C: 507 C: 509 When an command has been processed successfully, the EPP 510 element MUST contain child elements as described in the EPP 511 domain mapping [RFC5731]. In addition, the EPP element 512 SHOULD contain a child element that identifies the 513 extension namespace if the domain object has data associated with 514 this extension and based on its service policy. The 515 element contains the element. 517 Example Response for an authorized client: 519 S: 520 S: 521 S: 522 S: 523 S: Command completed successfully 524 S: 525 S: 526 S: 528 S: xn--fsq270a.example 529 S: 1999-04-03T22:00:00.0Z 530 S: 2001-04-03T22:00:00.0Z 531 S: 532 S: 533 S: 534 S: 536 S: 537 S: xn--fsq270a.example 539 S: xn--fsqz41a.example 541 S: 542 S: 543 S: 544 S: 545 S: ABC-12345 546 S: 54322-XYZ 547 S: 548 S: 549 S: 551 Response for the unauthorized client has not been 552 changed,see [RFC5731] for detail. 554 An EPP error response MUST be returned if an command cannot 555 be processed for any reason. 557 7.2.2. EPP Command 559 This extension does not add any element to the EPP command 560 described in the EPP domain mapping [RFC5731]. However, additional 561 elements are defined for the response. 563 When a command has been processed successfully, the EPP 564 element MUST contain child elements as described in the EPP 565 domain mapping [RFC5731]. In addition, the EPP element 566 SHOULD contain a child element that identifies the 567 extension namespace if the domain object has data associated with 568 this extension and based on its service policy. The 569 element SHOULD contain the element. 571 Example response: 573 S: 574 S: 575 S: 576 S: 577 S: Command completed successfully 578 S: 579 S: 580 S: 582 S: 583 S: 584 xn--fsq270a.example 585 S: 586 xn--fsqz41a.example 587 S: 588 S: 589 S: 590 S: 591 S: ABC-12345 592 S: 54321-XYZ 593 S: 594 S: 595 S: 597 An EPP error response MUST be returned if a command cannot 598 be processed for any reason. 600 7.2.3. EPP Command 602 This extension does not add any element to the EPP command 603 described in the EPP domain name mapping [RFC5731]. However, when 604 either RDN or BDN is sent for renew, response SHOULD contain both RDN 605 and BDN information. When the command has been processed 606 successfully, the EPP element SHOULD be contained in the 607 resoponse if the domain object has data associated with bundled 608 names. This EPP element SHOULD contain the 609 which contains element. 611 Example Response for an authorized client: 613 S: 614 S: 615 S: 616 S: 617 S: Command completed successfully 618 S: 619 S: 620 S: 622 S: xn--fsq270a.example 623 S: 2012-04-03T22:00:00.0Z 624 S: 625 S: 626 S: 627 S: 629 S: 630 S: xn--fsq270a.example 632 S: xn--fsqz41a.example 634 S: 635 S: 636 S: 637 S: 638 S: ABC-12345 639 S: 54322-XYZ 640 S: 641 S: 642 S: 644 7.2.4. EPP Command 646 This extension does not add any element to the EPP command 647 described in the EPP domain name mapping [RFC5731]. However, 648 additional elements are defined for the response in the 649 EPP object mapping. When the command has been processed 650 successfully, the EPP element SHOULD be contained in the 651 resoponse if the domain object has data associated with bundled 652 names. This EPP element SHOULD contain the 653 which contains element. 655 Example Response for an authorized client: 657 S: 658 S: 659 S: 660 S: 661 S: Command completed successfully; action pending 662 S: 663 S: 664 S: 666 S: xn--fsq270a.example 667 S: pending 668 S: ClientX 669 S: 2011-04-03T22:00:00.0Z 670 S: ClientY 671 S: 2011-04-08T22:00:00.0Z 672 S: 2012-04-03T22:00:00.0Z 673 S: 674 S: 675 S: 676 S: 678 S: 679 S: xn--fsq270a.example 681 S: xn--fsqz41a.example 683 S: 684 S: 685 S: 686 S: 687 S: ABC-12345 688 S: 54322-XYZ 689 S: 690 S: 691 S: 693 7.2.5. EPP Command 695 This extension does not add any element to the EPP command 696 described in the EPP domain name mapping [RFC5731]. However, 697 additional elements are defined for the response in the EPP 698 object mapping. When the command has been processed successfully, 699 the EPP element SHOULD be contained in the resoponse if 700 the domain object has data associated with bundled names. This EPP 701 element SHOULD contain the which contains 702 element. 704 Example Response for an authorized client: 706 S: 707 S: 708 S: 709 S: 710 S: Command completed successfully 711 S: 712 S: 713 S: 715 S: 716 S: xn--fsq270a.example 718 S: xn--fsqz41a.example 720 S: 721 S: 722 S: 723 S: 724 S: ABC-12345 725 S: 54322-XYZ 726 S: 727 S: 728 S: 730 8. Formal Syntax 732 An EPP object name mapping extension for bundled names is specified 733 in XML Schema notation. The formal syntax presented here is a 734 complete schema representation of the object mapping suitable for 735 automated validation of EPP XML instances. The BEGIN and END tags 736 are not part of the schema; they are used to note the beginning and 737 ending of the schema for URI registration purposes. 739 BEGIN 740 742 749 752 754 756 757 758 Extensible Provisioning Protocol v1.0 759 Bundle Domain Extension Schema v1.0 760 761 763 766 768 772 773 774 776 777 779 784 787 788 789 790 791 792 794 795 796 797 798 799 803 804 805 806 809 810 812 813 814 815 817 818 819 821 824 826 END 828 9. Internationalization Considerations 830 EPP is represented in XML, which provides native support for encoding 831 information using the Unicode character set and its more compact 832 representations including UTF-8. Conformant XML processors recognize 833 both UTF-8 and UTF-16. Though XML includes provisions to identify 834 and use other character encodings through use of an "encoding" 835 attribute in an declaration, use of UTF-8 is RECOMMENDED. 837 As an extension of the EPP domain name mapping, the elements, element 838 content described in this document MUST inherit the 839 internationalization conventions used to represent higher-layer 840 domain and core protocol structures present in an XML instance that 841 includes this extension. 843 10. IANA Considerations 845 This document uses URNs to describe XML namespaces and XML schemas 846 conforming to a registry mechanism described in [RFC3688]. IANA is 847 requested to assignment the following two URIs. 849 Registration request for the IDN namespace: 851 o URI: urn:ietf:params:xml:ns:epp:b-dn-1.0 853 o Registrant Contact: See the "Author's Address" section of this 854 document. 856 o XML: None. Namespace URI does not represent an XML specification. 858 Registration request for the IDN XML schema: 860 o URI: urn:ietf:params:xml:schema:epp:b-dn-1.0 862 o Registrant Contact: See the "Author's Address" section of this 863 document. 865 o XML: See the "Formal Syntax" section of this document. 867 The EPP extension described in this document should be registered by 868 IANA in the "Extensions for the Extensible Provisioning Protocol 869 (EPP)" registry described in [RFC7451]. The details of the 870 registration are as follows: 872 o Name of Extension: "Domain Name Mapping Extension for Strict 873 Bundling Registration" 875 o Document status: Informational 877 o Reference: This document 879 o Registrant Name and Email Address: IESG, iesg@ietf.org 881 o Top-Level Domains (TLDs): Any 883 o IPR Disclosure: https://datatracker.ietf.org/ipr/ 885 o Status: Active 887 o Notes: None 889 11. Security Considerations 891 Some registries and registrars have more than 15 years of the bundled 892 registration of domain names (especially Chinese domain names). They 893 have not found some significant security issues. One principle that 894 the registry and registrar should let the registrants know is that 895 bundled registered domain names will be created, transfered, updated, 896 and deleted together as a group. The registrants for bundled domain 897 names should remember this principle when doing some operations to 898 these domain names. [RFC5730] also introduces some security 899 consideration. 901 This document does not take a position regarding whether or not the 902 bundled domain names share a DS/DNSKEY key. The DNS administrator 903 can choose whether DS/DNSKEY information can be shared or not. If a 904 DS/DNSKEY key is shared then the bundled domain names share fate if 905 there is a key compromise. 907 12. Implementation Status 909 Note to RFC Editor: Please remove this section before publication. 911 o The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, 912 HKIRC, MONIC, SGNIC and more have followed the principles defined 913 in this document for many years. 915 o CNNIC and TELEINFO have implemented this extension in their EPP 916 based Chinese domain name registration system. 918 o Public Interest Registry, has requested to implement technical 919 bundling of second level domains for .NGO and .ONG. This means 920 that by registering and purchasing a domain in the .ngo TLD, for 921 example, the NGO registrant is also registering and purchasing the 922 corresponding name in the .ong TLD (and vice-versa for 923 registrations in .ong). 925 o Patrick Mevzek has released a new version of Net::DRI, an EPP 926 client (Perl library, free software) implementing this extension. 928 13. Acknowledgements 930 The authors especially thank the authors of [RFC5730] and [RFC5731] 931 and the following ones of CNNIC: Weiping Yang, Chao Qi. 933 Useful comments were made by John Klensin, Scott Hollenbeck, Patrick 934 Mevzek and Edward Lewis. 936 14. Change History 938 RFC Editor: Please remove this section. 940 14.1. draft-kong-epp-bundle-mapping: Version 00 942 o EPP extensiton for bundled domain name registrations. 944 14.2. draft-kong-epp-bundle-mapping: Version 01 946 o Change the proposed category from EXP to STD. 948 o Add the section of Implementation Status. 950 o Refine the text, and update the examples. 952 14.3. draft-kong-epp-bundle-mapping: Version 02 954 o Refine the texts. 956 14.4. draft-ietf-regext-bundle-mapping: Version 00 958 o accepted as WG document. 960 14.5. draft-ietf-regext-bundle-mapping: Version 01 962 o make this document to focus on the restrict bundled domain name 963 registration. 965 14.6. draft-ietf-regext-bundle-mapping: Version 02 967 o Update the section of implementation status. 969 14.7. draft-ietf-regext-bundle-mapping: Version 03 971 o This document is changed to informational category. 973 o Refine the text. 975 14.8. draft-ietf-regext-bundle-mapping: Version 04 977 o Update the implementation section. 979 o Refine the text. 981 14.9. draft-ietf-regext-bundle-mapping: Version 05 983 o Scope the XML namespaces to include 'epp'. 985 14.10. draft-ietf-regext-bundle-mapping: Version 06 987 o add some examples for the transfer, update and renew command 989 o add some text to security consideration 991 14.11. draft-ietf-regext-bundle-mapping: Version 07 993 o Update IANA consideration section based on Scott's comments 995 o Update security consideration based on Chair and Patrick Mevzek's 996 comments 998 15. References 1000 15.1. Normative References 1002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1003 Requirement Levels", BCP 14, RFC 2119, 1004 DOI 10.17487/RFC2119, March 1997, 1005 . 1007 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1008 DOI 10.17487/RFC3688, January 2004, 1009 . 1011 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1012 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1013 . 1015 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1016 Domain Name Mapping", STD 69, RFC 5731, 1017 DOI 10.17487/RFC5731, August 2009, 1018 . 1020 [RFC5890] Klensin, J., "Internationalized Domain Names for 1021 Applications (IDNA): Definitions and Document Framework", 1022 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1023 . 1025 [RFC5891] Klensin, J., "Internationalized Domain Names in 1026 Applications (IDNA): Protocol", RFC 5891, 1027 DOI 10.17487/RFC5891, August 2010, 1028 . 1030 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 1031 Internationalized Domain Names for Applications (IDNA)", 1032 RFC 5892, DOI 10.17487/RFC5892, August 2010, 1033 . 1035 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1036 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1037 February 2015, . 1039 [W3C.REC-xml-20040204] 1040 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1041 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 1042 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1043 20040204", February 2004, 1044 . 1046 [W3C.REC-xmlschema-1-20041028] 1047 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1048 ""XML Schema Part 1: Structures Second Edition", World 1049 Wide Web Consortium Recommendation REC-xmlschema- 1050 1-20041028", October 2004, 1051 . 1053 [W3C.REC-xmlschema-2-20041028] 1054 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 1055 Second Edition", World Wide Web Consortium Recommendation 1056 REC-xmlschema-2-20041028", October 2004, 1057 . 1059 15.2. Informative References 1061 [bundle.name] 1062 ICANN, "Registry Services Technical Evaluation Panel 1063 (RSTEP) Report on Public Interest Registry's Request to 1064 Implement Technical Bundling in .NGO and .ONG", July 2014, 1065 . 1068 [Final.Integrated.Issues.Report] 1069 ICANN, "The IDN Variant Issues Project: A Study of Issues 1070 Related to the Management of IDN Variant TLDs", February 1071 2012, . 1074 [RFC4290] Klensin, J., "Suggested Practices for Registration of 1075 Internationalized Domain Names (IDN)", RFC 4290, 1076 DOI 10.17487/RFC4290, December 2005, 1077 . 1079 Authors' Addresses 1081 Ning Kong 1082 Consultant 1084 Email: ietfing@gmail.com 1086 Jiankang Yao (editor) 1087 CNNIC 1088 4 South 4th Street,Zhongguancun,Haidian District 1089 Beijing, Beijing 100190 1090 China 1092 Phone: +86 10 5881 3007 1093 Email: yaojk@cnnic.cn 1095 Linlin Zhou 1096 CNNIC 1097 4 South 4th Street,Zhongguancun,Haidian District 1098 Beijing, Beijing 100190 1099 China 1101 Phone: +86 10 5881 2677 1102 Email: zhoulinlin@cnnic.cn 1104 Wil Tan 1105 Cloud Registry 1106 Suite 32 Seabridge House, 377 Kent St 1107 Sydney, NSW 2000 1108 Australia 1110 Phone: +61 414 710899 1111 Email: wil@cloudregistry.net 1113 Jiagui Xie 1115 Email: jiagui1984@163.com