idnits 2.17.1 draft-ietf-regext-bundling-registration-02.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 (October 26, 2017) is 2373 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 5890' is mentioned on line 169, 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. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Kong 3 Internet-Draft J. Yao, Ed. 4 Intended status: Standards Track X. Li 5 Expires: April 29, 2018 CNNIC 6 W. Tan 7 Cloud Registry 8 J. Xie 9 October 26, 2017 11 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for 12 Strict Bundling Registration 13 draft-ietf-regext-bundling-registration-02 15 Abstract 17 This document describes an extension of Extensible Provisioning 18 Protocol (EPP) domain name mapping for the provisioning and 19 management of strict bundling registration of domain names. 20 Specified in XML, this mapping extends the EPP domain name mapping to 21 provide additional features required for the provisioning of bundled 22 domain names. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 29, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5. Requirement for Bundling Registration of Names . . . . . . . 5 75 6. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6 76 6.1. RDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 6.2. BDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 79 7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 80 7.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 81 7.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 82 7.1.3. EPP Query Command . . . . . . . . . . . . 10 83 7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 84 7.2.1. EPP Command . . . . . . . . . . . . . . . . 11 85 7.2.2. EPP Command . . . . . . . . . . . . . . . . 12 86 7.2.3. EPP Command . . . . . . . . . . . . . . . . . 13 87 7.2.4. EPP Command . . . . . . . . . . . . . . . 14 88 7.2.5. EPP Command . . . . . . . . . . . . . . . . 14 89 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 90 9. Internationalization Considerations . . . . . . . . . . . . . 16 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 95 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 18 96 14.1. draft-kong-epp-bundle-mapping: Version 00 . . . . . . . 18 97 14.2. draft-kong-epp-bundle-mapping: Version 01 . . . . . . . 18 98 14.3. draft-kong-epp-bundle-mapping: Version 02 . . . . . . . 18 99 14.4. draft-ietf-regext-bundle-mapping: Version 00 . . . . . . 18 100 14.5. draft-ietf-regext-bundle-mapping: Version 01 . . . . . . 18 101 14.6. draft-ietf-regext-bundle-mapping: Version 02 . . . . . . 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 There are several kinds of bundling. First one is strict bundling, 121 which requires all bundled names to share many same attributes. When 122 creating, updating, or transfering of any of the bundled domain 123 names, all bundled domain names will be created, updated or 124 transferred. Second one is partial bundling, which requires that at 125 least the bundled domain names if registered should be registered by 126 the same registrant. Third one is relax bundling, which has not 127 specific requirements to the domain registration. This document 128 mainly focus on strict bundling names registration. 130 For the name variants, some registries adopt the policy that variant 131 IDNs which are identified as equivalent are allocated or delegated to 132 the same registrant. For example, the specified registration policy 133 of Chinese Domain Name (CDN) is that a registrant can apply an 134 original CDN in any forms: Simplified Chinese (SC) form, Traditional 135 Chinese (TC) form, or other variant forms, then the corresponding 136 variant CDN in SC form and that in TC form will also be delegated to 137 the same registrant. All variant names in the same TLD contain same 138 attributes. 140 The basic Extensible Provisioning Protocol (EPP) domain name mapping 141 [RFC5731] provides the domain name registration one by one. It does 142 not specify how to register the strict bundled names which share many 143 same attributes. 145 In order to meet above requirements of the strict bundled names 146 registration, this document describes an extension of the EPP domain 147 name mapping [RFC5731] for the provisioning and management of bundled 148 names.This document is specified using the Extensible Markup Language 149 (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema 150 notation as described in [W3C.REC-xmlschema-1-20041028] and 151 [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 of mapping described in this document. 158 This document uses lots of the concepts of the IDN, so a thorough 159 understanding of the IDNs for Application (IDNA, described in 160 [RFC5890], [RFC5891], and [RFC5892]) and a thorough understanding of 161 variant approach discussed in [RFC4290] are both required. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 uLable is defined in [RFC 5890]. uLabel is expressed in this document 170 as a number of characters with the format of U+XXXX where XXXX is a 171 UNICODE point. 173 "b-dn-1.0" in this document is used as an abbreviation for 174 urn:ietf:params:xml:ns:b-dn-1.0. 176 In examples, "C:" represents lines sent by a protocol client and "S:" 177 represents lines returned by a protocol server. Indentation and 178 white space in examples are provided only to illustrate element 179 relationships and are not a REQUIRED feature of this specification. 181 XML is case sensitive. Unless stated otherwise, XML specifications 182 and examples provided in this document MUST be interpreted in the 183 character case presented to develop a conforming implementation. 185 3. Definitions 187 The following definitions are used in this document: 189 o Registered Domain Name (RDN), represents the valid domain name 190 that users submitted for registration by the first time. 192 o Bundled Domain Name (BDN), represents the bundled domain name 193 produced according to the bundled domain name registration policy. 195 4. Overview 197 Domain registries have traditionally adopted a registration model 198 whereby metadata relating to a domain name, such as its expiration 199 date and sponsoring registrar, are stored as properties of the domain 200 object. The domain object is then considered an atomic unit of 201 registration, on which operations such as update, renewal and 202 deletion may be performed. 204 Bundled names, brought about the need for multiple domain names to be 205 registered and managed as a single package. In this model, the 206 registry typically accepts a domain registration request (i.e. EPP 207 domain command) containing the domain name to be registered. 208 This domain name is referred to as the RDN in this document. As part 209 of the processing of the registration request, the registry generates 210 a set of bundled names that are related to the RDN, either 211 programmatically or with the guidance of registration policies, and 212 place them in the registration package together with the RDN. 214 The bundled names share many same properties, such as expiration date 215 and sponsoring registrar, by sharing one domain object. So when 216 users update any property of a domain object within a bundle package, 217 that property of all other domain objects in the bundle package will 218 be updated at the same time. 220 5. Requirement for Bundling Registration of Names 222 The bundled names whether they are in the form of "V-label.TLD" or in 223 the form of "LABEL.V-tld" should share some parameter or attributes 224 assoicated with domain names. Typically, Bundled names will share 225 the following parameters or attributes: 226 o Registrar Ownership 227 o Registration and Expiry Dates 228 o Registrant, Admin, Billing, and Technical Contacts 229 o Name Server Association 230 o Domain Status 231 o Applicable grace periods (Add Grace Period, Renewal Grace Period, 232 Auto-Renewal Grace Period, Transfer Grace Period, and Redemption 233 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. 241 o When performing a domain info, either BDN or RDN can be queried, 242 the same response will include both BDN and RDN information with the 243 same attributes. 244 o When performing a domain Create, either BDN or RDN will be 245 accepted. If the domain name is available, both BDN and RDN will be 246 registered. 247 o When performing a domain Delete, either BDN or RDN will be 248 accepted. If the domain name is available, both BDN and RDN will be 249 deleted. 250 o When performing a domain renew, either BDN or RDN will be accepted. 251 Upon a successful domain renewal,both BDN and RDN will have their 252 expiry date extended by the requested term. Upon a successful domain 253 renewal, both BDN and RDN will conform to the same renew grace 254 period. 255 o When performing a domain transfer, either BDN or RDN will be 256 accepted. Upon successful completion of a domain transfer request, 257 both BDN and RDN will enter a pendingTransfer status. Upon approval 258 of the transfer request, both BDN and RDN will be owned and managed 259 by the same new registrant. 260 o When performing a domain update, either BDN or RDN will be 261 accepted. Any modifications to contact associations, name server 262 associations, domain status values and authorization information will 263 be applied to both BDN and RDN. 265 6. Object Attributes 267 This extension defines following additional elements to the EPP 268 domain name mapping [RFC5731]. All of these additional elements can 269 be got from command. 271 6.1. RDN 273 The RDN is an ASCII name or an IDN with the A-label [RFC5890] form. 274 In this document, its corresponding element is . An 275 optional attribute "uLabel" associated with is used to 276 represent the U-label [RFC5890] form. An optional boolean 277 "activated" attribute, with a default true value, is used to indicate 278 the presence of the label in the zone file. 280 For example: xn-- 281 fsq270a.example 283 6.2. BDN 285 The BDN is an ASCII name or an IDN with the A-label [RFC5890] form 286 which is converted from the corresponding BDN. In this document, its 287 corresponding element is . An optional attribute "uLabel" 288 associated with is used to represent the U-label [RFC5890] 289 form. 291 For example: xn-- 292 fsqz41a.example 294 7. EPP Command Mapping 296 A detailed description of the EPP syntax and semantics can be found 297 in the EPP core protocol specification [RFC5730]. The command 298 mappings described here are specifically for use in provisioning and 299 managing bundled names via EPP. 301 7.1. EPP Query Commands 303 EPP provides three commands to retrieve domain information: 304 to determine if a domain object can be provisioned within a 305 repository, to retrieve detailed information associated with a 306 domain object, and to retrieve domain-object transfer 307 status information. 309 7.1.1. EPP Command 311 This extension does not add any element to the EPP command or 312 response described in the EPP domain name mapping [RFC5731]. 313 However, when either RDN or BDN is sent for check, response SHOULD 314 contain both RDN and BDN information, which may also give some 315 explanation in the reason field to tell the user that the associated 316 domain name is a produced name according to some bundle domain name 317 policy. 319 Example Response for an authorized client: 321 S: 322 S: 323 S: 324 S: 325 S: Command completed successfully 326 S: 327 S: 328 S: 330 S: 331 S: 332 xn--fsq270a.example 333 S: 334 S: 335 S: 336 xn--fsqz41a.example 337 S: This associated domain name is 338 a produced name 339 based on bundle name policy. 340 S: 341 S: 342 S: 343 S: 344 S: ABC-12345 345 S: 54322-XYZ 346 S: 347 S: 348 S: 350 7.1.2. EPP Command 352 This extension does not add any element to the EPP command 353 described in the EPP domain mapping [RFC5731]. However, additional 354 elements are defined for the response. 356 When an command has been processed successfully, the EPP 357 element MUST contain child elements as described in the EPP 358 domain mapping [RFC5731]. In addition, the EPP element 359 SHOULD contain a child element that identifies the 360 extension namespace if the domain object has data associated with 361 this extension and based on its service policy. The 362 element contains the which has the following child 363 elements: 365 o An element that contains the RDN, along with the 366 attributes described below. 368 o An OPTIONAL element that contains the BDN, along with 369 the attributes described below. 371 The above elements contain the following attributes: 373 o An optional "uLabel" attribute represents the U-label of the 374 element. 376 Example Response for an authorized client: 378 S: 379 S: 380 S: 381 S: 382 S: Command completed successfully 383 S: 384 S: 385 S: 387 S: xn--fsq270a.example 388 S: 58812678-domain 389 S: 390 S: 123 391 S: 123 392 S: 123 393 S: 394 S: ns1.example.cn 395 396 S: 397 S: ClientX 398 S: ClientY 399 S: 2011-04-03T22:00:00.0Z 400 401 S: 2012-04-03T22:00:00.0Z 402 403 S: 404 S: 2fooBAR 405 S: 406 S: 407 S: 408 S: 409 S: 411 S: 412 S: xn--fsq270a.example 414 S: xn--fsqz41a.example 416 S: 417 S: 418 S: 419 S: 420 S: ABC-12345 421 S: 54322-XYZ 422 S: 423 S: 424 S: 426 Response for the unauthorized client has not been changed,see 427 [RFC5731] for detail. 429 An EPP error response MUST be returned if an command cannot be 430 processed for any reason. 432 7.1.3. EPP Query Command 434 This extension does not add any element to the EPP command 435 or reponse described in the EPP domain mapping [RFC5731]. 437 7.2. EPP Transform Commands 439 EPP provides five commands to transform domain objects: to 440 create an instance of a domain object, to delete an instance 441 of a domain object, to extend the validity period of a domain 442 object, to manage domain object sponsorship changes, and 443 to change information associated with a domain object. 445 When theses commands have been processed successfully, the EPP 446 element MUST contain child elements as described in the EPP 447 domain mapping [RFC5731]. This EPP element SHOULD 448 contain the which has the following child elements: 450 o An element that contains the RDN, along with the 451 attributes described below. 453 o An OPTIONAL element that contains the BDN, along with 454 the attributes described below. 456 The above elements contain the following attribute: 458 o An optional "uLabel" attribute represents the U-label of the 459 element. 461 7.2.1. EPP Command 463 This extension defines additional elements to extend the EPP 464 command described in the EPP domain name mapping [RFC5731] for 465 bundled names registration. 467 In addition to the EPP command elements described in the EPP domain 468 mapping [RFC5731], the command SHALL contain an 469 element. The element SHOULD contain a child 470 element that identifies the bundle namespace and the 471 location of the bundle name schema. 473 Example command: 475 C: 476 C: 477 C: 478 C: 479 C: 481 C: xn--fsq270a.example 482 C: 2 483 C: 123 484 C: 123 485 C: 123 486 C: 487 C: 2fooBAR 488 C: 489 C: 490 C: 491 C: 492 C: 494 C: 495 C: xn--fsq270a.example 496 C: 497 C: 498 C: ABC-12345 499 C: 500 C: 502 When an command has been processed successfully, the EPP 503 element MUST contain child elements as described in the EPP 504 domain mapping [RFC5731]. In addition, the EPP element 505 SHOULD contain a child element that identifies the 506 extension namespace if the domain object has data associated with 507 this extension and based on its service policy. The 508 element contains the element. 510 Example Response for an authorized client: 512 S: 513 S: 514 S: 515 S: 516 S: Command completed successfully 517 S: 518 S: 519 S: 521 S: xn--fsq270a.example 522 S: 1999-04-03T22:00:00.0Z 523 S: 2001-04-03T22:00:00.0Z 524 S: 525 S: 526 S: 527 S: 529 S: 530 S: xn--fsq270a.example 532 S: xn--fsqz41a.example 534 S: 535 S: 536 S: 537 S: 538 S: ABC-12345 539 S: 54322-XYZ 540 S: 541 S: 542 S: 544 Response for the unauthorized client has not been 545 changed,see [RFC5731] for detail. 547 An EPP error response MUST be returned if an command cannot 548 be processed for any reason. 550 7.2.2. EPP Command 552 This extension does not add any element to the EPP command 553 described in the EPP domain mapping [RFC5731]. However, additional 554 elements are defined for the response. 556 When a command has been processed successfully, the EPP 557 element MUST contain child elements as described in the EPP 558 domain mapping [RFC5731]. In addition, the EPP element 559 SHOULD contain a child element that identifies the 560 extension namespace if the domain object has data associated with 561 this extension and based on its service policy. The 562 element SHOULD contain the element. 564 Example response: 566 S: 567 S: 568 S: 569 S: 570 S: Command completed successfully 571 S: 572 S: 573 S: 575 S: 576 S: xn--fsq270a.example 577 S: xn--fsqz41a.example 578 S: 579 S: 580 S: 581 S: 582 S: ABC-12345 583 S: 54321-XYZ 584 S: 585 S: 586 S: 588 An EPP error response MUST be returned if a command cannot 589 be processed for any reason. 591 7.2.3. EPP Command 593 This extension does not add any element to the EPP command 594 described in the EPP domain name mapping [RFC5731]. However, when 595 either RDN or BDN is sent for renew, response SHOULD contain both RDN 596 and BDN information. When the command has been processed 597 successfully, the EPP element MUST contain child elements 598 as described in the EPP domain mapping [RFC5731]. This EPP 599 element SHOULD contain the which contains 600 element. 602 7.2.4. EPP Command 604 This extension does not add any element to the EPP command 605 described in the EPP domain name mapping [RFC5731]. When the command 606 has been processed successfully, the EPP element MUST 607 contain child elements as described in the EPP domain mapping 608 [RFC5731]. This EPP element SHOULD contain the 609 which contains element. 611 7.2.5. EPP Command 613 This extension does not add any element to the EPP command 614 described in the EPP domain name mapping [RFC5731]. When the command 615 has been processed successfully, the EPP element MUST 616 contain child elements as described in the EPP domain mapping 617 [RFC5731]. This EPP element SHOULD contain the 618 which contains element. 620 8. Formal Syntax 622 An EPP object name mapping extension for bundled names is specified 623 in XML Schema notation. The formal syntax presented here is a 624 complete schema representation of the object mapping suitable for 625 automated validation of EPP XML instances. The BEGIN and END tags 626 are not part of the schema; they are used to note the beginning and 627 ending of the schema for URI registration purposes. 629 BEGIN 630 632 639 642 644 646 647 648 Extensible Provisioning Protocol v1.0 649 Bundle Domain Extension Schema v1.0 651 652 654 657 659 663 664 665 667 668 670 675 678 679 680 681 682 683 685 686 687 688 689 691 695 696 697 698 701 702 704 705 706 707 709 710 711 713 716 718 END 720 9. Internationalization Considerations 722 EPP is represented in XML, which provides native support for encoding 723 information using the Unicode character set and its more compact 724 representations including UTF-8. Conformant XML processors recognize 725 both UTF-8 and UTF-16. Though XML includes provisions to identify 726 and use other character encodings through use of an "encoding" 727 attribute in an declaration, use of UTF-8 is RECOMMENDED. 729 As an extension of the EPP domain name mapping, the elements, element 730 content described in this document MUST inherit the 731 internationalization conventions used to represent higher-layer 732 domain and core protocol structures present in an XML instance that 733 includes this extension. 735 10. IANA Considerations 737 This document uses URNs to describe XML namespaces and XML schemas 738 conforming to a registry mechanism described in [RFC3688]. IANA is 739 requested to assignment the following two URIs. 741 Registration request for the IDN namespace: 743 o URI: urn:ietf:params:xml:ns:b-dn-1.0 744 o Registrant Contact: See the "Author's Address" section of this 745 document. 747 o XML: None. Namespace URI does not represent an XML specification. 749 Registration request for the IDN XML schema: 751 o URI: urn:ietf:params:xml:schema:b-dn-1.0 753 o Registrant Contact: See the "Author's Address" section of this 754 document. 756 o XML: See the "Formal Syntax" section of this document. 758 11. Security Considerations 760 The object mapping extension described in this document does not 761 provide any other security services or introduce any additional 762 considerations beyond those described by [RFC5730] or those caused by 763 the protocol layers used by EPP. 765 12. Implementation Status 767 Note to RFC Editor: Please remove this section before publication. 769 o The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, 770 HKIRC, MONIC, SGNIC and more have followed the principles defined 771 in this document for many years. 773 o CNNIC and TELEINFO have implemented this extension in their EPP 774 based Chinese domain name registration system. 776 o Public Interest Registry, has requested to implement technical 777 bundling of second level domains for .NGO and .ONG. This means 778 that by registering and purchasing a domain in the .ngo TLD, for 779 example, the NGO registrant is also registering and purchasing the 780 corresponding name in the .ong TLD (and vice-versa for 781 registrations in .ong). 783 13. Acknowledgements 785 The authors especially thank the authors of [RFC5730] and [RFC5731] 786 and the following ones of CNNIC: Weiping Yang, Chao Qi. This draft 787 extends the draft draft-kong-epp-idn-variants-mapping to support both 788 forms of bundled names: V-label.TLD and LABEL.V-tld. 790 Useful comments were made by John Klensin, Scott Hollenbeck, Patrick 791 Mevzek and Edward Lewis. 793 14. Change History 795 RFC Editor: Please remove this section. 797 14.1. draft-kong-epp-bundle-mapping: Version 00 799 o EPP extensiton for bundled domain name registrations. 801 14.2. draft-kong-epp-bundle-mapping: Version 01 803 o Change the proposed category from EXP to STD. 805 o Add the section of Implementation Status. 807 o Refine the text, and update the examples. 809 14.3. draft-kong-epp-bundle-mapping: Version 02 811 o Refine the texts. 813 14.4. draft-ietf-regext-bundle-mapping: Version 00 815 o accepted as WG document. 817 14.5. draft-ietf-regext-bundle-mapping: Version 01 819 o make this document to focus on the restrict bundled domain name 820 registration. 822 14.6. draft-ietf-regext-bundle-mapping: Version 02 824 o Update the section of implementation status. 826 15. References 828 15.1. Normative References 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, 832 DOI 10.17487/RFC2119, March 1997, 833 . 835 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 836 DOI 10.17487/RFC3688, January 2004, 837 . 839 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 840 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 841 . 843 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 844 Domain Name Mapping", STD 69, RFC 5731, 845 DOI 10.17487/RFC5731, August 2009, 846 . 848 [RFC5890] Klensin, J., "Internationalized Domain Names for 849 Applications (IDNA): Definitions and Document Framework", 850 RFC 5890, DOI 10.17487/RFC5890, August 2010, 851 . 853 [RFC5891] Klensin, J., "Internationalized Domain Names in 854 Applications (IDNA): Protocol", RFC 5891, 855 DOI 10.17487/RFC5891, August 2010, 856 . 858 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 859 Internationalized Domain Names for Applications (IDNA)", 860 RFC 5892, DOI 10.17487/RFC5892, August 2010, 861 . 863 [W3C.REC-xml-20040204] 864 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 865 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 866 Edition)", World Wide Web Consortium FirstEdition REC-xml- 867 20040204", February 2004, 868 . 870 [W3C.REC-xmlschema-1-20041028] 871 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 872 ""XML Schema Part 1: Structures Second Edition", World 873 Wide Web Consortium Recommendation REC-xmlschema- 874 1-20041028", October 2004, 875 . 877 [W3C.REC-xmlschema-2-20041028] 878 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 879 Second Edition", World Wide Web Consortium Recommendation 880 REC-xmlschema-2-20041028", October 2004, 881 . 883 15.2. Informative References 885 [bundle.name] 886 ICANN, "Registry Services Technical Evaluation Panel 887 (RSTEP) Report on Public Interest Registry's Request to 888 Implement Technical Bundling in .NGO and .ONG", July 2014, 889 . 892 [Final.Integrated.Issues.Report] 893 ICANN, "The IDN Variant Issues Project: A Study of Issues 894 Related to the Management of IDN Variant TLDs", February 895 2012, . 898 [RFC4290] Klensin, J., "Suggested Practices for Registration of 899 Internationalized Domain Names (IDN)", RFC 4290, 900 DOI 10.17487/RFC4290, December 2005, 901 . 903 Authors' Addresses 905 Ning Kong 906 CNNIC 907 4 South 4th Street,Zhongguancun,Haidian District 908 Beijing, Beijing 100190 909 China 911 Phone: +86 10 5881 3147 912 Email: nkong@cnnic.cn 914 Jiankang Yao (editor) 915 CNNIC 916 4 South 4th Street,Zhongguancun,Haidian District 917 Beijing, Beijing 100190 918 China 920 Phone: +86 10 5881 3007 921 Email: yaojk@cnnic.cn 922 Xiaodong Li 923 CNNIC 924 4 South 4th Street,Zhongguancun,Haidian District 925 Beijing, Beijing 100190 926 China 928 Phone: +86 10 5881 3020 929 Email: xl@cnnic.cn 931 Wil Tan 932 Cloud Registry 933 Suite 32 Seabridge House, 377 Kent St 934 Sydney, NSW 2000 935 Australia 937 Phone: +61 414 710899 938 Email: wil@cloudregistry.net 940 Jiagui Xie 942 Email: jiagui1984@163.com