idnits 2.17.1 draft-kong-eppext-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 13, 2015) is 3117 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 157, 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 15, 2016 CNNIC 6 J. Xie 7 CONAC 8 W. Tan 9 Cloud Registry 10 October 13, 2015 12 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for 13 Bundling Registration 14 draft-kong-eppext-bundling-registration-02 16 Abstract 18 This document describes an extension of Extensible Provisioning 19 Protocol (EPP) domain name mapping for the provisioning and 20 management of bundling registration of domain names. Specified in 21 XML, this mapping extends the EPP domain name mapping to provide 22 additional features required for the provisioning of bundled domain 23 names. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 15, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 5. Requirement for Bundling Registration of Names . . . . . . . 5 76 6. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6 77 6.1. RDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 6.2. BDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 80 7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 81 7.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 82 7.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 83 7.1.3. EPP Query Command . . . . . . . . . . . . 9 84 7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 9 85 7.2.1. EPP Command . . . . . . . . . . . . . . . . 10 86 7.2.2. EPP Command . . . . . . . . . . . . . . . . 12 87 7.2.3. EPP Command . . . . . . . . . . . . . . . . . 13 88 7.2.4. EPP Command . . . . . . . . . . . . . . . 14 89 7.2.5. EPP Command . . . . . . . . . . . . . . . . 14 90 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 91 9. Internationalization Considerations . . . . . . . . . . . . . 16 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 94 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 95 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 96 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 18 97 14.1. draft-kong-epp-bundle-mapping: Version 00 . . . . . . . 18 98 14.2. draft-kong-epp-bundle-mapping: Version 01 . . . . . . . 18 99 14.3. draft-kong-epp-bundle-mapping: Version 02 . . . . . . . 18 100 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 102 15.2. Informative References . . . . . . . . . . . . . . . . . 19 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 105 1. Introduction 107 Bundled domain names are those who share the same TLD but whose 108 second level labels are variants, or those who has identical second 109 level labels for which certain parameters are shared in different 110 TLDs. For example, Public Interest Registry, request to implement 111 technical bundling of second level domains for .NGO and .ONG. So we 112 have two kinds of bundled domain names. First one is in the form of 113 "V-label.TLD" in which the second level labels (V-label) are variants 114 sharing the same TLD; Second one is in the form of "LABEL.V-tld" in 115 which the second level labels(LABEL) are same with the different TLDs 116 (V-tld); 118 For the name variants, some registries adopt the policy that variant 119 IDNs which are identified as equivalent are allocated or delegated to 120 the same registrant. For example, the specified registration policy 121 of Chinese Domain Name (CDN) is that a registrant can apply an 122 original CDN in any forms: Simplified Chinese (SC) form, Traditional 123 Chinese (TC) form, or other variant forms, then the corresponding 124 variant CDN in SC form and that in TC form will also be delegated to 125 the same registrant. All variant names in the same TLD contain same 126 attributes. 128 The basic Extensible Provisioning Protocol (EPP) domain name mapping 129 [RFC5731] provides the domain name registration one by one. It does 130 not specify how to register the bindled names which share the same 131 attributes. 133 In order to meet above requirements of the bundled names 134 registration, this document describes an extension of the EPP domain 135 name mapping [RFC5731] for the provisioning and management of bundled 136 names.This document is specified using the Extensible Markup Language 137 (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema 138 notation as described in [W3C.REC-xmlschema-1-20041028] and 139 [W3C.REC-xmlschema-2-20041028]. 141 The EPP core protocol specification [RFC5730] provides a complete 142 description of EPP command and response structures. A thorough 143 understanding of the base protocol specification is necessary to 144 understand the extension of mapping described in this document. 146 This document uses lots of the concepts of the IDN, so a thorough 147 understanding of the IDNs for Application (IDNA, described in 148 [RFC5890], [RFC5891], and [RFC5892]) and a thorough understanding of 149 variant approach discussed in [RFC4290] are both required. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 uLable is defined in [RFC 5890]. uLabel is expressed in this document 158 as a number of characters with the format of U+XXXX where XXXX is a 159 UNICODE point. 161 "b-dn-1.0" in this document is used as an abbreviation for 162 urn:ietf:params:xml:ns:b-dn-1.0. 164 In examples, "C:" represents lines sent by a protocol client and "S:" 165 represents lines returned by a protocol server. Indentation and 166 white space in examples are provided only to illustrate element 167 relationships and are not a REQUIRED feature of this specification. 169 XML is case sensitive. Unless stated otherwise, XML specifications 170 and examples provided in this document MUST be interpreted in the 171 character case presented to develop a conforming implementation. 173 3. Definitions 175 The following definitions are used in this document: 177 o Registered Domain Name (RDN), represents the valid domain name 178 that users submitted for registration by the first time. 180 o Bundled Domain Name (BDN), represents the bundled domain name 181 produced according to the bundled domain name registration policy. 183 4. Overview 185 Domain registries have traditionally adopted a registration model 186 whereby metadata relating to a domain name, such as its expiration 187 date and sponsoring registrar, are stored as properties of the domain 188 object. The domain object is then considered an atomic unit of 189 registration, on which operations such as update, renewal and 190 deletion may be performed. 192 Bundled names, brought about the need for multiple domain names to be 193 registered and managed as a single package. In this model, the 194 registry typically accepts a domain registration request (i.e. EPP 195 domain command) containing the domain name to be registered. 196 This domain name is referred to as the RDN in this document. As part 197 of the processing of the registration request, the registry generates 198 a set of bundled names that are related to the RDN, either 199 programmatically or with the guidance of registration policies, and 200 place them in the registration package together with the RDN. 202 The bundled names have the same properties, such as expiration date 203 and sponsoring registrar, by sharing one domain object. So when 204 users update any property of a domain object within a bundle package, 205 that property of all other domain objects in the bundle package will 206 be updated at the same time. 208 5. Requirement for Bundling Registration of Names 210 The bundled names whether they are in the form of "V-label.TLD" or in 211 the form of "LABEL.V-tld" should share some parameter or attributes 212 assoicated with domain names. Typically, Bundled names will share 213 the following parameters or attributes: 214 o Registrar Ownership 215 o Registration and Expiry Dates 216 o Registrant, Admin, Billing, and Technical Contacts 217 o Name Server Association 218 o Domain Status 219 o Applicable grace periods (Add Grace Period, Renewal Grace Period, 220 Auto-Renewal Grace Period, Transfer Grace Period, and Redemption 221 Grace Period) 223 Because the domain names are bundled and share the same parameters or 224 attributes, the EPP command should do some processing for these 225 requirements: 226 o When performing a domain check, either BDN or RDN can be queried 227 for the EPP command, and will return the same response. 228 o When performing a domain info, either BDN or RDN can be queried, 229 the same response will include both BDN and RDN information with the 230 same attributes. 231 o When performing a domain Create, either BDN or RDN will be 232 accepted. If the domain name is available, both BDN and RDN will be 233 registered. 234 o When performing a domain Delete, either BDN or RDN will be 235 accepted. If the domain name is available, both BDN and RDN will be 236 deleted. 237 o When performing a domain renew, either BDN or RDN will be accepted. 238 Upon a successful domain renewal,both BDN and RDN will have their 239 expiry date extended by the requested term. Upon a successful domain 240 renewal, both BDN and RDN will conform to the same renew grace 241 period. 243 o When performing a domain transfer, either BDN or RDN will be 244 accepted. Upon successful completion of a domain transfer request, 245 both BDN and RDN will enter a pendingTransfer status. Upon approval 246 of the transfer request, both BDN and RDN will be owned and managed 247 by the same new registrant. 248 o When performing a domain update, either BDN or RDN will be 249 accepted. Any modifications to contact associations, name server 250 associations, domain status values and authorization information will 251 be applied to both BDN and RDN. 253 6. Object Attributes 255 This extension defines following additional elements to the EPP 256 domain name mapping [RFC5731]. All of these additional elements can 257 be got from command. 259 6.1. RDN 261 The RDN is an ASCII name or an IDN with the A-label [RFC5890] form. 262 In this document, its corresponding element is . An 263 optional attribute "uLabel" associated with is used to 264 represent the U-label [RFC5890] form. An optional boolean 265 "activated" attribute, with a default true value, is used to indicate 266 the presence of the label in the zone file. 268 For example: xn-- 269 fsq270a.example 271 6.2. BDN 273 The BDN is an ASCII name or an IDN with the A-label [RFC5890] form 274 which is converted from the corresponding BDN. In this document, its 275 corresponding element is . An optional attribute "uLabel" 276 associated with is used to represent the U-label [RFC5890] 277 form. 279 For example: xn-- 280 fsqz41a.example 282 7. EPP Command Mapping 284 A detailed description of the EPP syntax and semantics can be found 285 in the EPP core protocol specification [RFC5730]. The command 286 mappings described here are specifically for use in provisioning and 287 managing bundled names via EPP. 289 7.1. EPP Query Commands 291 EPP provides three commands to retrieve domain information: 292 to determine if a domain object can be provisioned within a 293 repository, to retrieve detailed information associated with a 294 domain object, and to retrieve domain-object transfer 295 status information. 297 7.1.1. EPP Command 299 This extension does not add any element to the EPP command or 300 response described in the EPP domain name mapping [RFC5731]. 301 However, when either RDN or BDN is sent for check, response SHOULD 302 contain both RDN and BDN information, which may also give some 303 explanation in the reason field to tell the user that the associated 304 domain name is a produced name according to some bundle domain name 305 policy. 307 Example Response for an authorized client: 309 S: 310 S: 311 S: 312 S: 313 S: Command completed successfully 314 S: 315 S: 316 S: 318 S: 319 S: 320 xn--fsq270a.example 321 S: 322 S: 323 S: 324 xn--fsqz41a.example 325 S: This associated domain name is 326 a produced name 327 based on bundle name policy. 328 S: 329 S: 330 S: 331 S: 332 S: ABC-12345 333 S: 54322-XYZ 334 S: 335 S: 336 S: 338 7.1.2. EPP Command 340 This extension does not add any element to the EPP command 341 described in the EPP domain mapping [RFC5731]. However, additional 342 elements are defined for the response. 344 When an command has been processed successfully, the EPP 345 element MUST contain child elements as described in the EPP 346 domain mapping [RFC5731]. In addition, the EPP element 347 SHOULD contain a child element that identifies the 348 extension namespace if the domain object has data associated with 349 this extension and based on its service policy. The 350 element contains the which has the following child 351 elements: 353 o An element that contains the RDN, along with the 354 attributes described below. 356 o An OPTIONAL element that contains the BDN, along with 357 the attributes described below. 359 The above elements contain the following attributes: 361 o An optional "uLabel" attribute represents the U-label of the 362 element. 364 Example Response for an authorized client: 366 S: 367 S: 368 S: 369 S: 370 S: Command completed successfully 371 S: 372 S: 373 S: 375 S: xn--fsq270a.example 376 S: 58812678-domain 377 S: 378 S: 123 379 S: 123 380 S: 123 381 S: 382 S: ns1.example.cn 383 384 S: 385 S: ClientX 386 S: ClientY 387 S: 2011-04-03T22:00:00.0Z 388 389 S: 2012-04-03T22:00:00.0Z 390 391 S: 392 S: 2fooBAR 393 S: 394 S: 395 S: 396 S: 397 S: 399 S: 400 S: xn--fsq270a.example 402 S: xn--fsqz41a.example 404 S: 405 S: 406 S: 407 S: 408 S: ABC-12345 409 S: 54322-XYZ 410 S: 411 S: 412 S: 414 Response for the unauthorized client has not been changed,see 415 [RFC5731] for detail. 417 An EPP error response MUST be returned if an command cannot be 418 processed for any reason. 420 7.1.3. EPP Query Command 422 This extension does not add any element to the EPP command 423 or reponse described in the EPP domain mapping [RFC5731]. 425 7.2. EPP Transform Commands 427 EPP provides five commands to transform domain objects: to 428 create an instance of a domain object, to delete an instance 429 of a domain object, to extend the validity period of a domain 430 object, to manage domain object sponsorship changes, and 431 to change information associated with a domain object. 433 When theses commands have been processed successfully, the EPP 434 element MUST contain child elements as described in the EPP 435 domain mapping [RFC5731]. This EPP element SHOULD 436 contain the which has the following child elements: 438 o An element that contains the RDN, along with the 439 attributes described below. 441 o An OPTIONAL element that contains the BDN, along with 442 the attributes described below. 444 The above elements contain the following attribute: 446 o An optional "uLabel" attribute represents the U-label of the 447 element. 449 7.2.1. EPP Command 451 This extension defines additional elements to extend the EPP 452 command described in the EPP domain name mapping [RFC5731] for 453 bundled names registration. 455 In addition to the EPP command elements described in the EPP domain 456 mapping [RFC5731], the command SHALL contain an 457 element. The element SHOULD contain a child 458 element that identifies the bundle namespace and the 459 location of the bundle name schema. 461 Example command: 463 C: 464 C: 465 C: 466 C: 467 C: 469 C: xn--fsq270a.example 470 C: 2 471 C: 123 472 C: 123 473 C: 123 474 C: 475 C: 2fooBAR 476 C: 477 C: 478 C: 479 C: 480 C: 482 C: 483 C: xn--fsq270a.example 484 C: 485 C: 486 C: ABC-12345 487 C: 488 C: 490 When an command has been processed successfully, the EPP 491 element MUST contain child elements as described in the EPP 492 domain mapping [RFC5731]. In addition, the EPP element 493 SHOULD contain a child element that identifies the 494 extension namespace if the domain object has data associated with 495 this extension and based on its service policy. The 496 element contains the element. 498 Example Response for an authorized client: 500 S: 501 S: 502 S: 503 S: 504 S: Command completed successfully 505 S: 506 S: 507 S: 509 S: xn--fsq270a.example 510 S: 1999-04-03T22:00:00.0Z 511 S: 2001-04-03T22:00:00.0Z 512 S: 513 S: 514 S: 515 S: 517 S: 518 S: xn--fsq270a.example 520 S: xn--fsqz41a.example 522 S: 523 S: 524 S: 525 S: 526 S: ABC-12345 527 S: 54322-XYZ 528 S: 529 S: 530 S: 532 Response for the unauthorized client has not been 533 changed,see [RFC5731] for detail. 535 An EPP error response MUST be returned if an command cannot 536 be processed for any reason. 538 7.2.2. EPP Command 540 This extension does not add any element to the EPP command 541 described in the EPP domain mapping [RFC5731]. However, additional 542 elements are defined for the response. 544 When a command has been processed successfully, the EPP 545 element MUST contain child elements as described in the EPP 546 domain mapping [RFC5731]. In addition, the EPP element 547 SHOULD contain a child element that identifies the 548 extension namespace if the domain object has data associated with 549 this extension and based on its service policy. The 550 element SHOULD contain the element. 552 Example response: 554 S: 555 S: 556 S: 557 S: 558 S: Command completed successfully 559 S: 560 S: 561 S: 563 S: 564 S: xn--fsq270a.example 565 S: xn--fsqz41a.example 566 S: 567 S: 568 S: 569 S: 570 S: ABC-12345 571 S: 54321-XYZ 572 S: 573 S: 574 S: 576 An EPP error response MUST be returned if a command cannot 577 be processed for any reason. 579 7.2.3. EPP Command 581 This extension does not add any element to the EPP command 582 described in the EPP domain name mapping [RFC5731]. However, when 583 either RDN or BDN is sent for renew, response SHOULD contain both RDN 584 and BDN information. When the command has been processed 585 successfully, the EPP element MUST contain child elements 586 as described in the EPP domain mapping [RFC5731]. This EPP 587 element SHOULD contain the which contains 588 element. 590 7.2.4. EPP Command 592 This extension does not add any element to the EPP command 593 described in the EPP domain name mapping [RFC5731]. When the command 594 has been processed successfully, the EPP element MUST 595 contain child elements as described in the EPP domain mapping 596 [RFC5731]. This EPP element SHOULD contain the 597 which contains element. 599 7.2.5. EPP Command 601 This extension does not add any element to the EPP command 602 described in the EPP domain name mapping [RFC5731]. When the command 603 has been processed successfully, the EPP element MUST 604 contain child elements as described in the EPP domain mapping 605 [RFC5731]. This EPP element SHOULD contain the 606 which contains element. 608 8. Formal Syntax 610 An EPP object name mapping extension for bundled names is specified 611 in XML Schema notation. The formal syntax presented here is a 612 complete schema representation of the object mapping suitable for 613 automated validation of EPP XML instances. The BEGIN and END tags 614 are not part of the schema; they are used to note the beginning and 615 ending of the schema for URI registration purposes. 617 BEGIN 618 620 627 630 632 634 635 636 Extensible Provisioning Protocol v1.0 637 Bundle Domain Extension Schema v1.0 639 640 642 645 647 651 652 653 655 656 658 663 666 667 668 669 670 671 673 674 675 676 677 679 683 684 685 686 689 690 692 693 694 695 697 698 699 701 704 706 END 708 9. Internationalization Considerations 710 EPP is represented in XML, which provides native support for encoding 711 information using the Unicode character set and its more compact 712 representations including UTF-8. Conformant XML processors recognize 713 both UTF-8 and UTF-16. Though XML includes provisions to identify 714 and use other character encodings through use of an "encoding" 715 attribute in an declaration, use of UTF-8 is RECOMMENDED. 717 As an extension of the EPP domain name mapping, the elements, element 718 content described in this document MUST inherit the 719 internationalization conventions used to represent higher-layer 720 domain and core protocol structures present in an XML instance that 721 includes this extension. 723 10. IANA Considerations 725 This document uses URNs to describe XML namespaces and XML schemas 726 conforming to a registry mechanism described in [RFC3688]. IANA is 727 requested to assignment the following two URIs. 729 Registration request for the IDN namespace: 731 o URI: urn:ietf:params:xml:ns:b-dn-1.0 732 o Registrant Contact: See the "Author's Address" section of this 733 document. 735 o XML: None. Namespace URI does not represent an XML specification. 737 Registration request for the IDN XML schema: 739 o URI: urn:ietf:params:xml:schema:b-dn-1.0 741 o Registrant Contact: See the "Author's Address" section of this 742 document. 744 o XML: See the "Formal Syntax" section of this document. 746 11. Security Considerations 748 The object mapping extension described in this document does not 749 provide any other security services or introduce any additional 750 considerations beyond those described by [RFC5730] or those caused by 751 the protocol layers used by EPP. 753 12. Implementation Status 755 Note to RFC Editor: Please remove this section before publication. 757 o CNNIC has implemented this extension in his EPP based Chinese 758 domain name registration system. 760 o Public Interest Registry, has requested to implement technical 761 bundling of second level domains for .NGO and .ONG. This means 762 that by registering and purchasing a domain in the .ngo TLD, for 763 example, the NGO registrant is also registering and purchasing the 764 corresponding name in the .ong TLD (and vice-versa for 765 registrations in .ong). 767 13. Acknowledgements 769 The authors especially thank the authors of [RFC5730] and [RFC5731] 770 and the following ones of CNNIC: Weiping Yang, Chao Qi. This draft 771 extends the draft draft-kong-epp-idn-variants-mapping to support both 772 forms of bundled names: V-label.TLD and LABEL.V-tld. 774 Useful comments were made by John Klensin, Scott Hollenbeck, Patrick 775 Mevzek and Edward Lewis. 777 14. Change History 779 RFC Editor: Please remove this section. 781 14.1. draft-kong-epp-bundle-mapping: Version 00 783 o EPP extensiton for bundled domain name registrations. 785 14.2. draft-kong-epp-bundle-mapping: Version 01 787 o Change the proposed category from EXP to STD. 789 o Add the section of Implementation Status. 791 o Refine the text, and update the examples. 793 14.3. draft-kong-epp-bundle-mapping: Version 02 795 o Refine the texts. 797 15. References 799 15.1. Normative References 801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, 803 DOI 10.17487/RFC2119, March 1997, 804 . 806 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 807 DOI 10.17487/RFC3688, January 2004, 808 . 810 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 811 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 812 . 814 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 815 Domain Name Mapping", STD 69, RFC 5731, 816 DOI 10.17487/RFC5731, August 2009, 817 . 819 [RFC5890] Klensin, J., "Internationalized Domain Names for 820 Applications (IDNA): Definitions and Document Framework", 821 RFC 5890, DOI 10.17487/RFC5890, August 2010, 822 . 824 [RFC5891] Klensin, J., "Internationalized Domain Names in 825 Applications (IDNA): Protocol", RFC 5891, 826 DOI 10.17487/RFC5891, August 2010, 827 . 829 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 830 Internationalized Domain Names for Applications (IDNA)", 831 RFC 5892, DOI 10.17487/RFC5892, August 2010, 832 . 834 [W3C.REC-xml-20040204] 835 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 836 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 837 Edition)", World Wide Web Consortium FirstEdition REC-xml- 838 20040204", February 2004, 839 . 841 [W3C.REC-xmlschema-1-20041028] 842 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 843 ""XML Schema Part 1: Structures Second Edition", World 844 Wide Web Consortium Recommendation REC-xmlschema- 845 1-20041028", October 2004, 846 . 848 [W3C.REC-xmlschema-2-20041028] 849 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 850 Second Edition", World Wide Web Consortium Recommendation 851 REC-xmlschema-2-20041028", October 2004, 852 . 854 15.2. Informative References 856 [bundle.name] 857 ICANN, "Registry Services Technical Evaluation Panel 858 (RSTEP) Report on Public Interest Registry's Request to 859 Implement Technical Bundling in .NGO and .ONG", July 2014, 860 . 863 [Final.Integrated.Issues.Report] 864 ICANN, "The IDN Variant Issues Project: A Study of Issues 865 Related to the Management of IDN Variant TLDs", February 866 2012, . 869 [RFC4290] Klensin, J., "Suggested Practices for Registration of 870 Internationalized Domain Names (IDN)", RFC 4290, 871 DOI 10.17487/RFC4290, December 2005, 872 . 874 Authors' Addresses 876 Ning Kong 877 CNNIC 878 4 South 4th Street,Zhongguancun,Haidian District 879 Beijing, Beijing 100190 880 China 882 Phone: +86 10 5881 3147 883 Email: nkong@cnnic.cn 885 Jiankang Yao (editor) 886 CNNIC 887 4 South 4th Street,Zhongguancun,Haidian District 888 Beijing, Beijing 100190 889 China 891 Phone: +86 10 5881 3007 892 Email: yaojk@cnnic.cn 894 Xiaodong Li 895 CNNIC 896 4 South 4th Street,Zhongguancun,Haidian District 897 Beijing, Beijing 100190 898 China 900 Phone: +86 10 5881 3020 901 Email: xl@cnnic.cn 903 Jiagui Xie 904 CONAC 905 Jia 31,North Guangximen, Xibahe, Chaoyang District 906 Beijing, Beijing 100028 907 China 909 Phone: +86 10 10 5203 5025 910 Email: xiejg@conac.cn 911 Wil Tan 912 Cloud Registry 913 Suite 32 Seabridge House, 377 Kent St 914 Sydney, NSW 2000 915 Australia 917 Phone: +61 414 710899 918 Email: wil@cloudregistry.net