idnits 2.17.1 draft-ietf-regext-bundling-registration-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (May 3, 2017) is 2544 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 168, 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: November 4, 2017 CNNIC 6 W. Tan 7 Cloud Registry 8 J. Xie 9 May 3, 2017 11 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for 12 Strict Bundling Registration 13 draft-ietf-regext-bundling-registration-01 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 http://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 November 4, 2017. 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 (http://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 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 103 15.2. Informative References . . . . . . . . . . . . . . . . . 19 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 106 1. Introduction 108 Bundled domain names are those who share the same TLD but whose 109 second level labels are variants, or those who has identical second 110 level labels for which certain parameters are shared in different 111 TLDs. For example, Public Interest Registry, request to implement 112 technical bundling of second level domains for .NGO and .ONG. So we 113 have two kinds of bundled domain names. First one is in the form of 114 "V-label.TLD" in which the second level labels (V-label) are variants 115 sharing the same TLD; Second one is in the form of "LABEL.V-tld" in 116 which the second level labels(LABEL) are same with the different TLDs 117 (V-tld); 119 There are several kinds of bundling. First one is strict bundling, 120 which requires all bundled names to share many same attributes. When 121 creating, updating, or transfering of any of the bundled domain 122 names, all bundled domain names will be created, updated or 123 transferred. Second one is partial bundling, which requires that at 124 least the bundled domain names if registered should be registered by 125 the same registrant. Third one is relax bundling, which has not 126 specific requirements to the domain registration. This document 127 mainly focus on strict bundling names registration. 129 For the name variants, some registries adopt the policy that variant 130 IDNs which are identified as equivalent are allocated or delegated to 131 the same registrant. For example, the specified registration policy 132 of Chinese Domain Name (CDN) is that a registrant can apply an 133 original CDN in any forms: Simplified Chinese (SC) form, Traditional 134 Chinese (TC) form, or other variant forms, then the corresponding 135 variant CDN in SC form and that in TC form will also be delegated to 136 the same registrant. All variant names in the same TLD contain same 137 attributes. 139 The basic Extensible Provisioning Protocol (EPP) domain name mapping 140 [RFC5731] provides the domain name registration one by one. It does 141 not specify how to register the strict bundled names which share many 142 same attributes. 144 In order to meet above requirements of the strict bundled names 145 registration, this document describes an extension of the EPP domain 146 name mapping [RFC5731] for the provisioning and management of bundled 147 names.This document is specified using the Extensible Markup Language 148 (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema 149 notation as described in [W3C.REC-xmlschema-1-20041028] and 150 [W3C.REC-xmlschema-2-20041028]. 152 The EPP core protocol specification [RFC5730] provides a complete 153 description of EPP command and response structures. A thorough 154 understanding of the base protocol specification is necessary to 155 understand the extension of mapping described in this document. 157 This document uses lots of the concepts of the IDN, so a thorough 158 understanding of the IDNs for Application (IDNA, described in 159 [RFC5890], [RFC5891], and [RFC5892]) and a thorough understanding of 160 variant approach discussed in [RFC4290] are both required. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 uLable is defined in [RFC 5890]. uLabel is expressed in this document 169 as a number of characters with the format of U+XXXX where XXXX is a 170 UNICODE point. 172 "b-dn-1.0" in this document is used as an abbreviation for 173 urn:ietf:params:xml:ns:b-dn-1.0. 175 In examples, "C:" represents lines sent by a protocol client and "S:" 176 represents lines returned by a protocol server. Indentation and 177 white space in examples are provided only to illustrate element 178 relationships and are not a REQUIRED feature of this specification. 180 XML is case sensitive. Unless stated otherwise, XML specifications 181 and examples provided in this document MUST be interpreted in the 182 character case presented to develop a conforming implementation. 184 3. Definitions 186 The following definitions are used in this document: 188 o Registered Domain Name (RDN), represents the valid domain name 189 that users submitted for registration by the first time. 191 o Bundled Domain Name (BDN), represents the bundled domain name 192 produced according to the bundled domain name registration policy. 194 4. Overview 196 Domain registries have traditionally adopted a registration model 197 whereby metadata relating to a domain name, such as its expiration 198 date and sponsoring registrar, are stored as properties of the domain 199 object. The domain object is then considered an atomic unit of 200 registration, on which operations such as update, renewal and 201 deletion may be performed. 203 Bundled names, brought about the need for multiple domain names to be 204 registered and managed as a single package. In this model, the 205 registry typically accepts a domain registration request (i.e. EPP 206 domain command) containing the domain name to be registered. 207 This domain name is referred to as the RDN in this document. As part 208 of the processing of the registration request, the registry generates 209 a set of bundled names that are related to the RDN, either 210 programmatically or with the guidance of registration policies, and 211 place them in the registration package together with the RDN. 213 The bundled names have the same properties, such as expiration date 214 and sponsoring registrar, by sharing one domain object. So when 215 users update any property of a domain object within a bundle package, 216 that property of all other domain objects in the bundle package will 217 be updated at the same time. 219 5. Requirement for Bundling Registration of Names 221 The bundled names whether they are in the form of "V-label.TLD" or in 222 the form of "LABEL.V-tld" should share some parameter or attributes 223 assoicated with domain names. Typically, Bundled names will share 224 the following parameters or attributes: 225 o Registrar Ownership 226 o Registration and Expiry Dates 227 o Registrant, Admin, Billing, and Technical Contacts 228 o Name Server Association 229 o Domain Status 230 o Applicable grace periods (Add Grace Period, Renewal Grace Period, 231 Auto-Renewal Grace Period, Transfer Grace Period, and Redemption 232 Grace Period) 234 Because the domain names are bundled and share the same parameters or 235 attributes, the EPP command should do some processing for these 236 requirements: 237 o When performing a domain check, either BDN or RDN can be queried 238 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 CNNIC has implemented this extension in his EPP based Chinese 769 domain name registration system. 771 o Public Interest Registry, has requested to implement technical 772 bundling of second level domains for .NGO and .ONG. This means 773 that by registering and purchasing a domain in the .ngo TLD, for 774 example, the NGO registrant is also registering and purchasing the 775 corresponding name in the .ong TLD (and vice-versa for 776 registrations in .ong). 778 13. Acknowledgements 780 The authors especially thank the authors of [RFC5730] and [RFC5731] 781 and the following ones of CNNIC: Weiping Yang, Chao Qi. This draft 782 extends the draft draft-kong-epp-idn-variants-mapping to support both 783 forms of bundled names: V-label.TLD and LABEL.V-tld. 785 Useful comments were made by John Klensin, Scott Hollenbeck, Patrick 786 Mevzek and Edward Lewis. 788 14. Change History 790 RFC Editor: Please remove this section. 792 14.1. draft-kong-epp-bundle-mapping: Version 00 794 o EPP extensiton for bundled domain name registrations. 796 14.2. draft-kong-epp-bundle-mapping: Version 01 798 o Change the proposed category from EXP to STD. 800 o Add the section of Implementation Status. 802 o Refine the text, and update the examples. 804 14.3. draft-kong-epp-bundle-mapping: Version 02 806 o Refine the texts. 808 14.4. draft-ietf-regext-bundle-mapping: Version 00 810 o accepted as WG document. 812 14.5. draft-ietf-regext-bundle-mapping: Version 01 814 o make this document to focus on the restrict bundled domain name 815 registration. 817 15. References 819 15.1. Normative References 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, 823 DOI 10.17487/RFC2119, March 1997, 824 . 826 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 827 DOI 10.17487/RFC3688, January 2004, 828 . 830 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 831 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 832 . 834 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 835 Domain Name Mapping", STD 69, RFC 5731, 836 DOI 10.17487/RFC5731, August 2009, 837 . 839 [RFC5890] Klensin, J., "Internationalized Domain Names for 840 Applications (IDNA): Definitions and Document Framework", 841 RFC 5890, DOI 10.17487/RFC5890, August 2010, 842 . 844 [RFC5891] Klensin, J., "Internationalized Domain Names in 845 Applications (IDNA): Protocol", RFC 5891, 846 DOI 10.17487/RFC5891, August 2010, 847 . 849 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 850 Internationalized Domain Names for Applications (IDNA)", 851 RFC 5892, DOI 10.17487/RFC5892, August 2010, 852 . 854 [W3C.REC-xml-20040204] 855 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 856 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 857 Edition)", World Wide Web Consortium FirstEdition REC-xml- 858 20040204", February 2004, 859 . 861 [W3C.REC-xmlschema-1-20041028] 862 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 863 ""XML Schema Part 1: Structures Second Edition", World 864 Wide Web Consortium Recommendation REC-xmlschema- 865 1-20041028", October 2004, 866 . 868 [W3C.REC-xmlschema-2-20041028] 869 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 870 Second Edition", World Wide Web Consortium Recommendation 871 REC-xmlschema-2-20041028", October 2004, 872 . 874 15.2. Informative References 876 [bundle.name] 877 ICANN, "Registry Services Technical Evaluation Panel 878 (RSTEP) Report on Public Interest Registry's Request to 879 Implement Technical Bundling in .NGO and .ONG", July 2014, 880 . 883 [Final.Integrated.Issues.Report] 884 ICANN, "The IDN Variant Issues Project: A Study of Issues 885 Related to the Management of IDN Variant TLDs", February 886 2012, . 889 [RFC4290] Klensin, J., "Suggested Practices for Registration of 890 Internationalized Domain Names (IDN)", RFC 4290, 891 DOI 10.17487/RFC4290, December 2005, 892 . 894 Authors' Addresses 896 Ning Kong 897 CNNIC 898 4 South 4th Street,Zhongguancun,Haidian District 899 Beijing, Beijing 100190 900 China 902 Phone: +86 10 5881 3147 903 Email: nkong@cnnic.cn 905 Jiankang Yao (editor) 906 CNNIC 907 4 South 4th Street,Zhongguancun,Haidian District 908 Beijing, Beijing 100190 909 China 911 Phone: +86 10 5881 3007 912 Email: yaojk@cnnic.cn 914 Xiaodong Li 915 CNNIC 916 4 South 4th Street,Zhongguancun,Haidian District 917 Beijing, Beijing 100190 918 China 920 Phone: +86 10 5881 3020 921 Email: xl@cnnic.cn 922 Wil Tan 923 Cloud Registry 924 Suite 32 Seabridge House, 377 Kent St 925 Sydney, NSW 2000 926 Australia 928 Phone: +61 414 710899 929 Email: wil@cloudregistry.net 931 Jiagui Xie 933 Email: jiagui1984@163.com