idnits 2.17.1 draft-ietf-regext-bundling-registration-03.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 24 characters in excess of 72. 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 (April 28, 2018) is 2162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5890' is mentioned on line 170, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force N. Kong 2 Internet-Draft J. Yao, Ed. 3 Intended status: Informational X. Li 4 Expires: October 30, 2018 CNNIC 5 W. Tan 6 Cloud Registry 7 J. Xie 8 April 28, 2018 10 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for 11 Strict Bundling Registration 12 draft-ietf-regext-bundling-registration-03 14 Abstract 16 This document describes an extension of Extensible Provisioning 17 Protocol (EPP) domain name mapping for the provisioning and 18 management of strict bundling registration of domain names. 19 Specified in XML, this mapping extends the EPP domain name mapping to 20 provide additional features required for the provisioning of bundled 21 domain names. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 30, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 5. Requirement for Bundling Registration of Names . . . . . . . 5 74 6. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6 75 6.1. RDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6.2. BDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 78 7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 79 7.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 80 7.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 81 7.1.3. EPP Query Command . . . . . . . . . . . . 10 82 7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 83 7.2.1. EPP Command . . . . . . . . . . . . . . . . 11 84 7.2.2. EPP Command . . . . . . . . . . . . . . . . 12 85 7.2.3. EPP Command . . . . . . . . . . . . . . . . . 13 86 7.2.4. EPP Command . . . . . . . . . . . . . . . 14 87 7.2.5. EPP Command . . . . . . . . . . . . . . . . 14 88 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 89 9. Internationalization Considerations . . . . . . . . . . . . . 16 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 93 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 94 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 18 95 14.1. draft-kong-epp-bundle-mapping: Version 00 . . . . . . . 18 96 14.2. draft-kong-epp-bundle-mapping: Version 01 . . . . . . . 18 97 14.3. draft-kong-epp-bundle-mapping: Version 02 . . . . . . . 18 98 14.4. draft-ietf-regext-bundle-mapping: Version 00 . . . . . . 18 99 14.5. draft-ietf-regext-bundle-mapping: Version 01 . . . . . . 18 100 14.6. draft-ietf-regext-bundle-mapping: Version 02 . . . . . . 18 101 14.7. draft-ietf-regext-bundle-mapping: Version 03 . . . . . . 18 102 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 103 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 104 15.2. Informative References . . . . . . . . . . . . . . . . . 20 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 107 1. Introduction 109 Bundled domain names are those which share the same TLD but whose 110 second level labels are variants, or those which has identical second 111 level labels for which certain parameters are shared in different 112 TLDs. For example, Public Interest Registry, request to implement 113 technical bundling of second level domains for .NGO and .ONG. So we 114 have two kinds of bundled domain names. First one is in the form of 115 "V-label.TLD" in which the second level labels (V-label) are variants 116 sharing the same TLD; Second one is in the form of "LABEL.V-tld" in 117 which the second level labels(LABEL) are same ending with the 118 different TLDs (V-tld); 120 Bundled domain names normally share some attributes. There are three 121 types of bundling. First one is strict bundling, which requires all 122 bundled names to share many same attributes. When creating, 123 updating, or transferring of any of the bundled domain names, all 124 bundled domain names will be created, updated or transferred. Second 125 one is partial bundling, which requires that at least the bundled 126 domain names if registered should be registered by the same 127 registrant. Third one is relax bundling, which has not specific 128 requirements to the domain registration. This document mainly focus 129 on strict bundling names registration. 131 For the name variants, some registries adopt the policy that variant 132 IDNs which are identified as equivalent are allocated or delegated to 133 the same registrant. For example, the specified registration policy 134 of Chinese Domain Name (CDN) is that a registrant can apply an 135 original CDN in any forms: Simplified Chinese (SC) form, Traditional 136 Chinese (TC) form, or other variant forms, then the corresponding 137 variant CDN in SC form and that in TC form will also be delegated to 138 the same registrant. All variant names in the same TLD contain same 139 attributes. 141 The basic Extensible Provisioning Protocol (EPP) domain name mapping 142 [RFC5731] provides the domain name registration one by one. It does 143 not specify how to register the strict bundled names which share many 144 same attributes. 146 In order to meet above requirements of the strict bundled names 147 registration, this document describes an extension of the EPP domain 148 name mapping [RFC5731] for the provisioning and management of bundled 149 names.This document is specified using the Extensible Markup Language 150 (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema 151 notation as described in [W3C.REC-xmlschema-1-20041028] and 152 [W3C.REC-xmlschema-2-20041028]. 154 The EPP core protocol specification [RFC5730] provides a complete 155 description of EPP command and response structures. A thorough 156 understanding of the base protocol specification is necessary to 157 understand the extension of mapping described in this document. 159 This document uses lots of the concepts of the IDN, so a thorough 160 understanding of the IDNs for Application (IDNA, described in 161 [RFC5890], [RFC5891], and [RFC5892]) and a thorough understanding of 162 variant approach discussed in [RFC4290] are both required. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 uLable is defined in [RFC 5890]. uLabel is expressed in this document 171 as a number of characters with the format of U+XXXX where XXXX is a 172 UNICODE point. 174 "b-dn-1.0" in this document is used as an abbreviation for 175 urn:ietf:params:xml:ns:b-dn-1.0. 177 In examples, "C:" represents lines sent by a protocol client and "S:" 178 represents lines returned by a protocol server. Indentation and 179 white space in examples are provided only to illustrate element 180 relationships and are not a REQUIRED feature of this specification. 182 XML is case sensitive. Unless stated otherwise, XML specifications 183 and examples provided in this document MUST be interpreted in the 184 character case presented to develop a conforming implementation. 186 3. Definitions 188 The following definitions are used in this document: 190 o Registered Domain Name (RDN), represents the valid domain name 191 that users submitted for registration by the first time. 193 o Bundled Domain Name (BDN), represents the bundled domain name 194 produced according to the bundled domain name registration policy. 196 4. Overview 198 Domain registries have traditionally adopted a registration model 199 whereby metadata relating to a domain name, such as its expiration 200 date and sponsoring registrar, are stored as properties of the domain 201 object. The domain object is then considered an atomic unit of 202 registration, on which operations such as update, renewal and 203 deletion may be performed. 205 Bundled names, brought about the need for multiple domain names to be 206 registered and managed as a single package. In this model, the 207 registry typically accepts a domain registration request (i.e. EPP 208 domain command) containing the domain name to be registered. 209 This domain name is referred to as the RDN in this document. As part 210 of the processing of the registration request, the registry generates 211 a set of bundled names that are related to the RDN, either 212 programmatically or with the guidance of registration policies, and 213 place them in the registration package together with the RDN. 215 The bundled names share many same properties, such as expiration date 216 and sponsoring registrar, by sharing one domain object. So when 217 users update any property of a domain object within a bundle package, 218 that property of all other domain objects in the bundle package will 219 be updated at the same time. 221 5. Requirement for Bundling Registration of Names 223 The bundled names whether they are in the form of "V-label.TLD" or in 224 the form of "LABEL.V-tld" should share some parameter or attributes 225 assoicated with domain names. Typically, Bundled names will share 226 the following parameters or attributes: 227 o Registrar Ownership 228 o Registration and Expiry Dates 229 o Registrant, Admin, Billing, and Technical Contacts 230 o Name Server Association 231 o Domain Status 232 o Applicable grace periods (Add Grace Period, Renewal Grace Period, 233 Auto-Renewal Grace Period, Transfer Grace Period, and Redemption 234 Grace Period) 235 Because the domain names are bundled and share the same parameters or 236 attributes, the EPP command should do some processing for these 237 requirements: 238 o When performing a domain check, either BDN or RDN can be queried 239 for the EPP command, and will return the same response. 240 o When performing a domain info, either BDN or RDN can be queried, 241 the same response will include both BDN and RDN information with the 242 same attributes. 243 o When performing a domain Create, either BDN or RDN will be 244 accepted. If the domain name is available, both BDN and RDN will be 245 registered. 246 o When performing a domain Delete, either BDN or RDN will be 247 accepted. If the domain name is available, both BDN and RDN will be 248 deleted. 249 o When performing a domain renew, either BDN or RDN will be accepted. 250 Upon a successful domain renewal,both BDN and RDN will have their 251 expiry date extended by the requested term. Upon a successful domain 252 renewal, both BDN and RDN will conform to the same renew grace 253 period. 254 o When performing a domain transfer, either BDN or RDN will be 255 accepted. Upon successful completion of a domain transfer request, 256 both BDN and RDN will enter a pendingTransfer status. Upon approval 257 of the transfer request, both BDN and RDN will be owned and managed 258 by the same new registrant. 259 o When performing a domain update, either BDN or RDN will be 260 accepted. Any modifications to contact associations, name server 261 associations, domain status values and authorization information will 262 be applied to both BDN and RDN. 264 6. Object Attributes 266 This extension defines following additional elements to the EPP 267 domain name mapping [RFC5731]. All of these additional elements can 268 be got from command. 270 6.1. RDN 272 The RDN is an ASCII name or an IDN with the A-label [RFC5890] form. 273 In this document, its corresponding element is . An 274 optional attribute "uLabel" associated with is used to 275 represent the U-label [RFC5890] form. An optional boolean 276 "activated" attribute, with a default true value, is used to indicate 277 the presence of the label in the zone file. 279 For example: xn-- 280 fsq270a.example 282 6.2. BDN 284 The BDN is an ASCII name or an IDN with the A-label [RFC5890] form 285 which is converted from the corresponding BDN. In this document, its 286 corresponding element is . An optional attribute "uLabel" 287 associated with is used to represent the U-label [RFC5890] 288 form. 290 For example: xn-- 291 fsqz41a.example 293 7. EPP Command Mapping 295 A detailed description of the EPP syntax and semantics can be found 296 in the EPP core protocol specification [RFC5730]. The command 297 mappings described here are specifically for use in provisioning and 298 managing bundled names via EPP. 300 7.1. EPP Query Commands 302 EPP provides three commands to retrieve domain information: 303 to determine if a domain object can be provisioned within a 304 repository, to retrieve detailed information associated with a 305 domain object, and to retrieve domain-object transfer 306 status information. 308 7.1.1. EPP Command 310 This extension does not add any element to the EPP command or 311 response described in the EPP domain name mapping [RFC5731]. 312 However, when either RDN or BDN is sent for check, response SHOULD 313 contain both RDN and BDN information, which may also give some 314 explanation in the reason field to tell the user that the associated 315 domain name is a produced name according to some bundle domain name 316 policy. 318 Example Response for an authorized client: 320 S: 321 S: 322 S: 323 S: 324 S: Command completed successfully 325 S: 326 S: 327 S: 329 S: 330 S: 331 xn--fsq270a.example 332 S: 333 S: 334 S: 335 xn--fsqz41a.example 336 S: This associated domain name is 337 a produced name 338 based on bundle name policy. 339 S: 340 S: 341 S: 342 S: 343 S: ABC-12345 344 S: 54322-XYZ 345 S: 346 S: 347 S: 349 7.1.2. EPP Command 351 This extension does not add any element to the EPP command 352 described in the EPP domain mapping [RFC5731]. However, additional 353 elements are defined for the response. 355 When an command has been processed successfully, the EPP 356 element MUST contain child elements as described in the EPP 357 domain mapping [RFC5731]. In addition, the EPP element 358 SHOULD contain a child element that identifies the 359 extension namespace if the domain object has data associated with 360 this extension and based on its service policy. The 361 element contains the which has the following child 362 elements: 364 o An element that contains the RDN, along with the 365 attributes described below. 367 o An OPTIONAL element that contains the BDN, along with 368 the attributes described below. 370 The above elements contain the following attributes: 372 o An optional "uLabel" attribute represents the U-label of the 373 element. 375 Example Response for an authorized client: 377 S: 378 S: 379 S: 380 S: 381 S: Command completed successfully 382 S: 383 S: 384 S: 386 S: xn--fsq270a.example 387 S: 58812678-domain 388 S: 389 S: 123 390 S: 123 391 S: 123 392 S: 393 S: ns1.example.cn 394 395 S: 396 S: ClientX 397 S: ClientY 398 S: 2011-04-03T22:00:00.0Z 399 400 S: 2012-04-03T22:00:00.0Z 401 402 S: 403 S: 2fooBAR 404 S: 405 S: 406 S: 407 S: 408 S: 410 S: 411 S: xn--fsq270a.example 413 S: xn--fsqz41a.example 415 S: 416 S: 417 S: 418 S: 419 S: ABC-12345 420 S: 54322-XYZ 421 S: 422 S: 423 S: 425 Response for the unauthorized client has not been changed,see 426 [RFC5731] for detail. 428 An EPP error response MUST be returned if an command cannot be 429 processed for any reason. 431 7.1.3. EPP Query Command 433 This extension does not add any element to the EPP command 434 or reponse described in the EPP domain mapping [RFC5731]. 436 7.2. EPP Transform Commands 438 EPP provides five commands to transform domain objects: to 439 create an instance of a domain object, to delete an instance 440 of a domain object, to extend the validity period of a domain 441 object, to manage domain object sponsorship changes, and 442 to change information associated with a domain object. 444 When theses commands have been processed successfully, the EPP 445 element MUST contain child elements as described in the EPP 446 domain mapping [RFC5731]. This EPP element SHOULD 447 contain the which has the following child elements: 449 o An element that contains the RDN, along with the 450 attributes described below. 452 o An OPTIONAL element that contains the BDN, along with 453 the attributes described below. 455 The above elements contain the following attribute: 457 o An optional "uLabel" attribute represents the U-label of the 458 element. 460 7.2.1. EPP Command 462 This extension defines additional elements to extend the EPP 463 command described in the EPP domain name mapping [RFC5731] for 464 bundled names registration. 466 In addition to the EPP command elements described in the EPP domain 467 mapping [RFC5731], the command SHALL contain an 468 element. The element SHOULD contain a child 469 element that identifies the bundle namespace and the 470 location of the bundle name schema. 472 Example command: 474 C: 475 C: 476 C: 477 C: 478 C: 480 C: xn--fsq270a.example 481 C: 2 482 C: 123 483 C: 123 484 C: 123 485 C: 486 C: 2fooBAR 487 C: 488 C: 489 C: 490 C: 491 C: 493 C: 494 C: xn--fsq270a.example 495 C: 496 C: 497 C: ABC-12345 498 C: 499 C: 501 When an command has been processed successfully, the EPP 502 element MUST contain child elements as described in the EPP 503 domain mapping [RFC5731]. In addition, the EPP element 504 SHOULD contain a child element that identifies the 505 extension namespace if the domain object has data associated with 506 this extension and based on its service policy. The 507 element contains the element. 509 Example Response for an authorized client: 511 S: 512 S: 513 S: 514 S: 515 S: Command completed successfully 516 S: 517 S: 518 S: 520 S: xn--fsq270a.example 521 S: 1999-04-03T22:00:00.0Z 522 S: 2001-04-03T22:00:00.0Z 523 S: 524 S: 525 S: 526 S: 528 S: 529 S: xn--fsq270a.example 531 S: xn--fsqz41a.example 533 S: 534 S: 535 S: 536 S: 537 S: ABC-12345 538 S: 54322-XYZ 539 S: 540 S: 541 S: 543 Response for the unauthorized client has not been 544 changed,see [RFC5731] for detail. 546 An EPP error response MUST be returned if an command cannot 547 be processed for any reason. 549 7.2.2. EPP Command 551 This extension does not add any element to the EPP command 552 described in the EPP domain mapping [RFC5731]. However, additional 553 elements are defined for the response. 555 When a command has been processed successfully, the EPP 556 element MUST contain child elements as described in the EPP 557 domain mapping [RFC5731]. In addition, the EPP element 558 SHOULD contain a child element that identifies the 559 extension namespace if the domain object has data associated with 560 this extension and based on its service policy. The 561 element SHOULD contain the element. 563 Example response: 565 S: 566 S: 567 S: 568 S: 569 S: Command completed successfully 570 S: 571 S: 572 S: 574 S: 575 S: xn--fsq270a.example 576 S: xn--fsqz41a.example 577 S: 578 S: 579 S: 580 S: 581 S: ABC-12345 582 S: 54321-XYZ 583 S: 584 S: 585 S: 587 An EPP error response MUST be returned if a command cannot 588 be processed for any reason. 590 7.2.3. EPP Command 592 This extension does not add any element to the EPP command 593 described in the EPP domain name mapping [RFC5731]. However, when 594 either RDN or BDN is sent for renew, response SHOULD contain both RDN 595 and BDN information. When the command has been processed 596 successfully, the EPP element MUST contain child elements 597 as described in the EPP domain mapping [RFC5731]. This EPP 598 element SHOULD contain the which contains 599 element. 601 7.2.4. EPP Command 603 This extension does not add any element to the EPP command 604 described in the EPP domain name mapping [RFC5731]. When the command 605 has been processed successfully, the EPP element MUST 606 contain child elements as described in the EPP domain mapping 607 [RFC5731]. This EPP element SHOULD contain the 608 which contains element. 610 7.2.5. EPP Command 612 This extension does not add any element to the EPP command 613 described in the EPP domain name mapping [RFC5731]. When the command 614 has been processed successfully, the EPP element MUST 615 contain child elements as described in the EPP domain mapping 616 [RFC5731]. This EPP element SHOULD contain the 617 which contains element. 619 8. Formal Syntax 621 An EPP object name mapping extension for bundled names is specified 622 in XML Schema notation. The formal syntax presented here is a 623 complete schema representation of the object mapping suitable for 624 automated validation of EPP XML instances. The BEGIN and END tags 625 are not part of the schema; they are used to note the beginning and 626 ending of the schema for URI registration purposes. 628 BEGIN 629 631 638 641 643 645 646 647 Extensible Provisioning Protocol v1.0 648 Bundle Domain Extension Schema v1.0 650 651 653 656 658 662 663 664 666 667 669 674 677 678 679 680 681 682 684 685 686 687 688 690 694 695 696 697 700 701 703 704 705 706 708 709 710 712 715 717 END 719 9. Internationalization Considerations 721 EPP is represented in XML, which provides native support for encoding 722 information using the Unicode character set and its more compact 723 representations including UTF-8. Conformant XML processors recognize 724 both UTF-8 and UTF-16. Though XML includes provisions to identify 725 and use other character encodings through use of an "encoding" 726 attribute in an declaration, use of UTF-8 is RECOMMENDED. 728 As an extension of the EPP domain name mapping, the elements, element 729 content described in this document MUST inherit the 730 internationalization conventions used to represent higher-layer 731 domain and core protocol structures present in an XML instance that 732 includes this extension. 734 10. IANA Considerations 736 This document uses URNs to describe XML namespaces and XML schemas 737 conforming to a registry mechanism described in [RFC3688]. IANA is 738 requested to assignment the following two URIs. 740 Registration request for the IDN namespace: 742 o URI: urn:ietf:params:xml:ns:b-dn-1.0 743 o Registrant Contact: See the "Author's Address" section of this 744 document. 746 o XML: None. Namespace URI does not represent an XML specification. 748 Registration request for the IDN XML schema: 750 o URI: urn:ietf:params:xml:schema:b-dn-1.0 752 o Registrant Contact: See the "Author's Address" section of this 753 document. 755 o XML: See the "Formal Syntax" section of this document. 757 11. Security Considerations 759 The object mapping extension described in this document does not 760 provide any other security services or introduce any additional 761 considerations beyond those described by [RFC5730] or those caused by 762 the protocol layers used by EPP. 764 12. Implementation Status 766 Note to RFC Editor: Please remove this section before publication. 768 o The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, 769 HKIRC, MONIC, SGNIC and more have followed the principles defined 770 in this document for many years. 772 o CNNIC and TELEINFO have implemented this extension in their EPP 773 based Chinese domain name registration system. 775 o Public Interest Registry, has requested to implement technical 776 bundling of second level domains for .NGO and .ONG. This means 777 that by registering and purchasing a domain in the .ngo TLD, for 778 example, the NGO registrant is also registering and purchasing the 779 corresponding name in the .ong TLD (and vice-versa for 780 registrations in .ong). 782 13. Acknowledgements 784 The authors especially thank the authors of [RFC5730] and [RFC5731] 785 and the following ones of CNNIC: Weiping Yang, Chao Qi. This draft 786 extends the draft draft-kong-epp-idn-variants-mapping to support both 787 forms of bundled names: V-label.TLD and LABEL.V-tld. 789 Useful comments were made by John Klensin, Scott Hollenbeck, Patrick 790 Mevzek and Edward Lewis. 792 14. Change History 794 RFC Editor: Please remove this section. 796 14.1. draft-kong-epp-bundle-mapping: Version 00 798 o EPP extensiton for bundled domain name registrations. 800 14.2. draft-kong-epp-bundle-mapping: Version 01 802 o Change the proposed category from EXP to STD. 804 o Add the section of Implementation Status. 806 o Refine the text, and update the examples. 808 14.3. draft-kong-epp-bundle-mapping: Version 02 810 o Refine the texts. 812 14.4. draft-ietf-regext-bundle-mapping: Version 00 814 o accepted as WG document. 816 14.5. draft-ietf-regext-bundle-mapping: Version 01 818 o make this document to focus on the restrict bundled domain name 819 registration. 821 14.6. draft-ietf-regext-bundle-mapping: Version 02 823 o Update the section of implementation status. 825 14.7. draft-ietf-regext-bundle-mapping: Version 03 827 o This document is changed to informational category. 829 o Refine the text. 831 15. References 833 15.1. Normative References 835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels", BCP 14, RFC 2119, 837 DOI 10.17487/RFC2119, March 1997, 838 . 840 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 841 DOI 10.17487/RFC3688, January 2004, 842 . 844 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 845 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 846 . 848 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 849 Domain Name Mapping", STD 69, RFC 5731, 850 DOI 10.17487/RFC5731, August 2009, 851 . 853 [RFC5890] Klensin, J., "Internationalized Domain Names for 854 Applications (IDNA): Definitions and Document Framework", 855 RFC 5890, DOI 10.17487/RFC5890, August 2010, 856 . 858 [RFC5891] Klensin, J., "Internationalized Domain Names in 859 Applications (IDNA): Protocol", RFC 5891, 860 DOI 10.17487/RFC5891, August 2010, 861 . 863 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 864 Internationalized Domain Names for Applications (IDNA)", 865 RFC 5892, DOI 10.17487/RFC5892, August 2010, 866 . 868 [W3C.REC-xml-20040204] 869 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 870 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 871 Edition)", World Wide Web Consortium FirstEdition REC-xml- 872 20040204", February 2004, 873 . 875 [W3C.REC-xmlschema-1-20041028] 876 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 877 ""XML Schema Part 1: Structures Second Edition", World 878 Wide Web Consortium Recommendation REC-xmlschema- 879 1-20041028", October 2004, 880 . 882 [W3C.REC-xmlschema-2-20041028] 883 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 884 Second Edition", World Wide Web Consortium Recommendation 885 REC-xmlschema-2-20041028", October 2004, 886 . 888 15.2. Informative References 890 [bundle.name] 891 ICANN, "Registry Services Technical Evaluation Panel 892 (RSTEP) Report on Public Interest Registry's Request to 893 Implement Technical Bundling in .NGO and .ONG", July 2014, 894 . 897 [Final.Integrated.Issues.Report] 898 ICANN, "The IDN Variant Issues Project: A Study of Issues 899 Related to the Management of IDN Variant TLDs", February 900 2012, . 903 [RFC4290] Klensin, J., "Suggested Practices for Registration of 904 Internationalized Domain Names (IDN)", RFC 4290, 905 DOI 10.17487/RFC4290, December 2005, 906 . 908 Authors' Addresses 910 Ning Kong 911 CNNIC 912 4 South 4th Street,Zhongguancun,Haidian District 913 Beijing, Beijing 100190 914 China 916 Phone: +86 10 5881 3147 917 Email: nkong@cnnic.cn 919 Jiankang Yao (editor) 920 CNNIC 921 4 South 4th Street,Zhongguancun,Haidian District 922 Beijing, Beijing 100190 923 China 925 Phone: +86 10 5881 3007 926 Email: yaojk@cnnic.cn 927 Xiaodong Li 928 CNNIC 929 4 South 4th Street,Zhongguancun,Haidian District 930 Beijing, Beijing 100190 931 China 933 Phone: +86 10 5881 3020 934 Email: xl@cnnic.cn 936 Wil Tan 937 Cloud Registry 938 Suite 32 Seabridge House, 377 Kent St 939 Sydney, NSW 2000 940 Australia 942 Phone: +61 414 710899 943 Email: wil@cloudregistry.net 945 Jiagui Xie 947 Email: jiagui1984@163.com