idnits 2.17.1 draft-zhou-eppext-reseller-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([RFC5731]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 9, 2016) is 2969 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) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Zhou 3 Internet-Draft N. Kong 4 Intended status: Standards Track J. Wei 5 Expires: September 10, 2016 X. Lee 6 CNNIC 7 J. Gould 8 VeriSign, Inc. 9 March 9, 2016 11 Reseller Extension for the Extensible Provisioning Protocol (EPP) 12 draft-zhou-eppext-reseller-03 14 Abstract 16 This mapping, an extension to EPP object mappings like the EPP domain 17 name mapping [RFC5731], to support assigning a reseller to any 18 existing object (domain, host, contact) as well as any future 19 objects. Specified in Extensible Markup Language (XML), this 20 extended mapping is applied to provide additional features required 21 for the provisioning of resellers. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 10, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 71 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Reseller Identifier . . . . . . . . . . . . . . . . . . . 4 73 3.2. Reseller Name . . . . . . . . . . . . . . . . . . . . . . 4 74 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 75 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 76 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 4 77 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 4 78 4.1.3. EPP Command . . . . . . . . . . . . . . . 7 79 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 7 80 4.2.1. EPP Command . . . . . . . . . . . . . . . . 7 81 4.2.2. EPP Command . . . . . . . . . . . . . . . . 8 82 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 8 83 4.2.4. EPP Command . . . . . . . . . . . . . . . 9 84 4.2.5. EPP Command . . . . . . . . . . . . . . . . 9 85 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6. Internationalization Considerations . . . . . . . . . . . . . 13 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13 89 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 14 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 10.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Introduction 100 Domain resellers are the individuals or companies act as agents for 101 ICANN accredited registrars. A domain name registrar may have 102 several resellers to help them sell domain names to end users. 104 Generally speaking, resellers provide domain registration information 105 via registrar's EPP client without reseller information. On one 106 hand, registrars are concerned about how to identify resellers. On 107 the other hand, end users would also be confused by the WHOIS service 108 without corresponding reseller information. This requirement imposes 109 a challenge for the domain registries since there is no definition of 110 resellers in the existing EPP domain name mapping. Out of band 111 method could solve this problem but may increase extra cost. 113 In order to facilitate provisioning and management of reseller 114 information in a shared central repository, this document proposes a 115 reseller extension of [RFC5731], [RFC5732] and [RFC5733]. The 116 examples provided in this document are used for the domain object for 117 illustration purposes. The host and contact object could be extended 118 in the same way with the domain object. 120 A reseller mapping object defined in 121 [ID.draft-zhou-eppext-reseller-mapping] SHOULD be created first. The 122 reseller information specified in this document SHOULD reference the 123 existing reseller identifier and reseller name. 125 This document is specified using the XML 1.0 as described in 126 [W3C.REC-xml-20040204] and XML Schema notation as described in 127 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 129 2. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 In examples, "C:" represents lines sent by a protocol client and "S:" 136 represents lines returned by a protocol server. Indentation and 137 white space in examples are provided only to illustrate element 138 relationships and are not a REQUIRED feature of this specification. 140 XML is case sensitive. Unless stated otherwise, XML specifications 141 and examples provided in this document MUST be interpreted in the 142 character case presented to develop a conforming implementation. 144 resellerext-1.0 in this document is used as an abbreviation for 145 urn:ietf:params:xml:ns:resellerext-1.0. 147 3. Object Attributes 149 This extension adds additional elements to the EPP domain name 150 mapping [RFC5731]. Only the new elements are described here. 152 3.1. Reseller Identifier 154 Reseller identifier provides the ID of the reseller of a sponsoring 155 registrar. Its corresponding element is which 156 refers to the element defined in 157 [ID.draft-zhou-eppext-reseller-mapping]. All reseller objects are 158 identified by a server-unique identifier 160 3.2. Reseller Name 162 Reseller name provides the name of the reseller of a sponsoring 163 registrar. Its corresponding element is which 164 refers to the element defined in 165 [ID.draft-zhou-eppext-reseller-mapping]. 167 4. EPP Command Mapping 169 A detailed description of the EPP syntax and semantics can be found 170 in the EPP core protocol specification [RFC5730]. The command 171 mappings described here are specifically for use in provisioning and 172 managing reseller information via EPP. 174 4.1. EPP Query Commands 176 EPP provides three commands to retrieve domain information: 177 to determine if a domain object can be provisioned within a 178 repository, to retrieve detailed information associated with a 179 domain object, and to retrieve domain-object transfer 180 status information. 182 4.1.1. EPP Command 184 This extension does not add any elements to the EPP command 185 or response described in the EPP domain name mapping 186 [RFC5731], host mapping [RFC5732] and contact mapping [RFC5733]. 188 4.1.2. EPP Command 190 This extension does not add any element to the EPP command 191 described in the EPP domain mapping [RFC5731], host mapping [RFC5732] 192 and contact mapping [RFC5733]. However, additional elements are 193 defined for the response. 195 Example command: 197 C: 198 C: 199 C: 200 C: 201 C: 202 C: example.com 203 C: 204 C: fooBAR 205 C: 206 C: 207 C: 208 C: ngcl-mIFICBNP 209 C: 210 C: 212 When an command has been processed successfully, the EPP 213 element MUST contain child elements as described in the EPP 214 domain mapping [RFC5731], host mapping [RFC5732] and contact mapping 215 [RFC5733]. In addition, the EPP element SHOULD contain a 216 child element that identifies the extension 217 namespace if the domain object has data associated with this 218 extension and based on its service policy. The 219 element contains the following child elements: 221 o A element that contains the identifier of the 222 reseller of a sponsoring registrar. 224 Example response for an authorized client: 226 S: 227 S: 228 S: 229 S: 230 S: Command completed successfully 231 S: 232 S: 233 S: 234 S: example.com 235 S: EXAMPLE1-REP 236 S: 237 S: jd1234 238 S: sh8013 239 S: sh8013 240 S: sh8013 241 S: 242 S: ns1.example.com 243 S: 244 S: ClientX 245 S: ClientY 246 S: 2015-02-06T04:01:21.0Z 247 S: 2018-02-06T04:01:21.0Z 248 S: 249 S: 2fooBAR 250 S: 251 S: 252 S: 253 S: 254 S: 255 S: 256 S: 257 S: 258 S: myreseller 259 S: 260 S: 261 S: 262 S: ngcl-IvJjzMZc 263 S: test142AWQONJZ 264 S: 265 S: 266 S: 268 response for the unauthorized client has not been changed, see 269 [RFC5731], [RFC5732] and [RFC5733]for detail. 271 An EPP error response MUST be returned if an command cannot be 272 processed for any reason. 274 4.1.3. EPP Command 276 This extension does not add any elements to the EPP 277 command or response described in the EPP domain name 278 mapping [RFC5731], host mapping [RFC5732] and contact mapping 279 [RFC5733]. 281 4.2. EPP Transform Commands 283 EPP provides five commands to transform domain objects: to 284 create an instance of a domain object, to delete an instance 285 of a domain object, to extend the validity period of a domain 286 object, to manage domain object sponsorship changes, and 287 to change information associated with a domain object. 289 4.2.1. EPP Command 291 This extension defines additional elements for the EPP 292 command described in the EPP domain mapping [RFC5731], host mapping 293 [RFC5732] and contact mapping [RFC5733]. No additional elements are 294 defined for the EPP response. 296 The EPP command provides a transform operation that allows a 297 client to create a domain object. In addition to the EPP command 298 elements described in the EPP domain mapping [RFC5731], host mapping 299 [RFC5732] and contact mapping [RFC5733], the command MUST contain an 300 element, and the element MUST contain a child 301 element that identifies the extension namespace 302 if the client wants to associate data defined in this extension to 303 the domain object. The element contains the 304 following child elements: 306 o A element that contains the identifier of the 307 reseller of a sponsoring registrar. 309 Example Command: 311 C: 312 C: 313 C: 314 C: 315 C: 316 C: example.com 317 C: 3 318 C: 319 C: ns1.example.com 320 C: 321 C: jd1234 322 C: sh8013 323 C: sh8013 324 C: sh8013 325 C: 326 C: fooBAR 327 C: 328 C: 329 C: 330 C: 331 C: 332 C: myreseller 333 C: 334 C: 335 C: ABC-12345 336 C: 337 C: 339 When a command has been processed successfully, the EPP 340 response is as described in the EPP domain mapping [RFC5731], host 341 mapping [RFC5732] and contact mapping [RFC5733]. 343 An EPP error response MUST be returned if a command cannot 344 be processed for any reason. 346 4.2.2. EPP Command 348 This extension does not add any elements to the EPP command 349 or response described in the EPP domain mapping [RFC5731], 350 host mapping [RFC5732] and contact mapping [RFC5733]. 352 4.2.3. EPP Command 354 This extension does not add any elements to the EPP command 355 or response described in the EPP domain mapping [RFC5731], 356 host mapping [RFC5732] and contact mapping [RFC5733]. 358 4.2.4. EPP Command 360 This extension does not add any elements to the EPP 361 command or response described in the EPP domain mapping 362 [RFC5731], host mapping [RFC5732] and contact mapping [RFC5733], but 363 after a successful transfer of an object with an assigned reseller, 364 the server SHOULD clear the assigned reseller value. 366 4.2.5. EPP Command 368 This extension defines additional elements for the EPP 369 command described in the EPP domain mapping [RFC5731], host mapping 370 [RFC5732] and contact mapping [RFC5733]. No additional elements are 371 defined for the EPP response. 373 The EPP command provides a transform operation that allows a 374 client to modify the attributes of a domain object. In addition to 375 the EPP command elements described in the EPP domain mapping, the 376 command MUST contain an element, and the 377 element MUST contain a child element that 378 identifies the extension namespace if the client wants to update the 379 domain object with data defined in this extension. The 380 element contains the following child elements: 382 o An OPTIONAL element that contains attribute 383 values to be added to the object. 385 o An OPTIONAL element that contains attribute 386 values to be removed from the object. 388 o An OPTIONAL element that contains attribute 389 values to be changed. 391 At least one and only one , or 392 element MUST be provided. The , 393 and elements contain the 394 following child element: 396 o A element that contains the identifier of the 397 reseller of a sponsoring registrar. 399 Example command, adding a reseller: 401 C: 402 C: 403 C: 404 C: 405 C: 406 C: example.com 407 C: 408 C: 409 C: 410 C: 411 C: 412 C: myreseller 413 C: 414 C: 415 C: 416 C: ABC-12345 417 C: 418 C: 420 Example command, removing a reseller: 422 C: 423 C: 424 C: 425 C: 426 C: 427 C: example.com 428 C: 429 C: 430 C: 431 C: 432 C: 433 C: myreseller 434 C: 435 C: 436 C: 437 C: ABC-12345 438 C: 439 C: 441 Example command, updating reseller identifier: 443 C: 444 C: 445 C: 446 C: 447 C: 448 C: example.com 449 C: 450 C: 451 C: 452 C: 453 C: 454 C: myreseller 455 C: 456 C: 457 C: 458 C: ABC-12345 459 C: 460 C: 462 When an extended command has been processed successfully, 463 the EPP response is as described in the EPP domain name mapping 464 [RFC5731], host mapping [RFC5732] and contact mapping [RFC5733]. 466 5. Formal Syntax 468 An EPP object mapping is specified in XML Schema notation. The 469 formal syntax presented here is a complete schema representation of 470 the object mapping suitable for automated validation of EPP XML 471 instances. The BEGIN and END tags are not part of the schema; they 472 are used to note the beginning and ending of the schema for URI 473 registration purposes. 475 BEGIN 476 478 485 488 490 493 494 495 Extensible Provisioning Protocol v1.0 496 Domain Reseller Extension Schema v1.0 497 498 500 501 502 504 507 508 509 510 511 512 514 518 519 520 521 522 523 524 526 527 528 529 530 531 533 535 537 539 540 541 542 543 544 546 547 548 END 550 6. Internationalization Considerations 552 EPP is represented in XML, which provides native support for encoding 553 information using the Unicode character set and its more compact 554 representations including UTF-8. Conformant XML processors recognize 555 both UTF-8 and UTF-16. Though XML includes provisions to identify 556 and use other character encodings through use of an "encoding" 557 attribute in an declaration, use of UTF-8 is RECOMMENDED. 559 As an extension of the EPP domain name mapping, the elements, element 560 content described in this document MUST inherit the 561 internationalization conventions used to represent higher-layer 562 domain and core protocol structures present in an XML instance that 563 includes this extension. 565 7. IANA Considerations 567 7.1. XML Namespace 569 This document uses URNs to describe XML namespaces and XML schemas 570 conforming to a registry mechanism described in [RFC3688]. IANA is 571 requested to assignment the following URI. 573 Registration request for the reseller namespace: 575 o URI: urn:ietf:params:xml:ns:reseller-1.0 577 o Registrant Contact: See the "Author's Address" section of this 578 document. 580 o XML: See the "Formal Syntax" section of this document. 582 7.2. EPP Extension Registry 584 The EPP extension described in this document should be registered by 585 the IANA in the EPP Extension Registry described in [RFC7451]. The 586 details of the registration are as follows: 588 Name of Extension: Domain Reseller Extension 590 Document status: Standards Track 592 Reference: (insert reference to RFC version of this document) 594 Registrant Name and Email Address: See the "Author's Address" section 595 of this document. 597 TLDs: any 599 IPR Disclosure: none 601 Status: active 603 Notes: none 605 8. Security Considerations 607 The object mapping extension described in this document does not 608 provide any other security services or introduce any additional 609 considerations beyond those described by [RFC5730], [RFC5731], 610 [RFC5732] and [RFC5733] or those caused by the protocol layers used 611 by EPP. 613 9. Acknowledgement 615 The authors would like to thank Rik Ribbers, Marc Groeneweg and 616 Patrick Mevzek for their careful review and valuable comments. 618 10. References 620 10.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 628 DOI 10.17487/RFC3688, January 2004, 629 . 631 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 632 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 633 . 635 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 636 Domain Name Mapping", STD 69, RFC 5731, 637 DOI 10.17487/RFC5731, August 2009, 638 . 640 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 641 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 642 August 2009, . 644 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 645 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 646 August 2009, . 648 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 649 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 650 February 2015, . 652 [W3C.REC-xml-20040204] 653 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 654 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 655 Edition)", World Wide Web Consortium FirstEdition REC-xml- 656 20040204", February 2004, 657 . 659 [W3C.REC-xmlschema-1-20041028] 660 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 661 ""XML Schema Part 1: Structures Second Edition", World 662 Wide Web Consortium Recommendation REC-xmlschema- 663 1-20041028", October 2004, 664 . 666 [W3C.REC-xmlschema-2-20041028] 667 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 668 Second Edition", World Wide Web Consortium Recommendation 669 REC-xmlschema-2-20041028", October 2004, 670 . 672 10.2. Informative References 674 [ID.draft-zhou-eppext-reseller-mapping] 675 Zhou, L., Kong, N., Qi, C., Lee, X., and J. Gould, 676 "Extensible Provisioning Protocol (EPP) Reseller Mapping", 677 Oct 2015, . 680 Appendix A. Change Log 682 Initial -00: Individual document submitted. 684 -01: 686 * Updated abstract and introduction. 688 * Revised typos in info response. 690 * Added explanations on how to process reseller extension after 691 successful transfer operation. 693 * Modified explanation. 695 * Deleted reseller name element in and 696 commands. 698 * Removed some inaccurate comments from xml schema. 700 * Modified the element name of reseller id and reseller name. 702 -02: 704 * Changed author information. 706 * Updated xml typos to 707 in response. 709 -03: 711 * Changed author information. 713 * Updated section 3.1. 715 * Removed reseller name element in response. 717 * Added acknowledgement. 719 * Revised the typo "resellerr" to "resellerext". 721 Authors' Addresses 722 Linlin Zhou 723 CNNIC 724 4 South 4th Street, Zhongguancun, Haidian District 725 Beijing, Beijing 100190 726 China 728 Phone: +86 10 5881 2677 729 Email: zhoulinlin@cnnic.cn 731 Ning Kong 732 CNNIC 733 4 South 4th Street, Zhongguancun, Haidian District 734 Beijing, Beijing 100190 735 China 737 Phone: +86 10 5881 3147 738 Email: nkong@cnnic.cn 740 Junkai Wei 741 CNNIC 742 4 South 4th Street, Zhongguancun, Haidian District 743 Beijing, Beijing 100190 744 China 746 Phone: +86 10 5881 3494 747 Email: weijunkai@cnnic.cn 749 Xiaodong Lee 750 CNNIC 751 4 South 4th Street, Zhongguancun, Haidian District 752 Beijing, Beijing 100190 753 China 755 Phone: +86 10 5881 3020 756 Email: xl@cnnic.cn 758 James Gould 759 VeriSign, Inc. 760 12061 Bluemont Way 761 Reston, VA 20190 762 US 764 Email: jgould@verisign.com