idnits 2.17.1 draft-zhou-eppext-reseller-mapping-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 : ---------------------------------------------------------------------------- No issues found here. 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 2968 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: 1 error (**), 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 G. Zhou 5 Expires: September 10, 2016 X. Lee 6 CNNIC 7 J. Gould 8 VeriSign, Inc. 9 March 9, 2016 11 Extensible Provisioning Protocol (EPP) Reseller Mapping 12 draft-zhou-eppext-reseller-mapping-03 14 Abstract 16 This document describes an Extensible Provisioning Protocol (EPP) 17 mapping for provisioning and management of reseller object stored in 18 a shared central repository. Specified in Extensible Markup Language 19 (XML), this extended mapping is applied to provide additional 20 features required for the provisioning of resellers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 70 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 71 3.1. Reseller Identifier . . . . . . . . . . . . . . . . . . . 4 72 3.2. Contact and Client Identifiers . . . . . . . . . . . . . 4 73 3.3. Reseller State . . . . . . . . . . . . . . . . . . . . . 4 74 3.4. Parent Identifier . . . . . . . . . . . . . . . . . . . . 4 75 3.5. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.6. Disclosure of Data Elements and Attributes . . . . . . . 5 77 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 78 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 79 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 80 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 7 81 4.1.3. EPP Command . . . . . . . . . . . . . . . 13 82 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 13 83 4.2.1. EPP Command . . . . . . . . . . . . . . . . 13 84 4.2.2. EPP Command . . . . . . . . . . . . . . . . 16 85 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 18 86 4.2.4. EPP Command . . . . . . . . . . . . . . . 18 87 4.2.5. EPP Command . . . . . . . . . . . . . . . . 18 88 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 89 6. Internationalization Considerations . . . . . . . . . . . . . 26 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 91 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 26 92 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 27 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 95 10. Normative References . . . . . . . . . . . . . . . . . . . . 27 96 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 99 1. Introduction 101 Domain resellers are the individuals or companies that act as agents 102 for domain name registrars. A domain name registrar is a direct 103 customer of the domain name registry, is represented as the 104 sponsoring client to the server in [RFC5730], and may have several 105 resellers to help them sell domain names to end users. 107 This document describes an extension mapping for version 1.0 of the 108 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 109 specifies the reseller object mapping. 111 This document is specified using the XML 1.0 as described in 112 [W3C.REC-xml-20040204] and XML Schema notation as described in 113 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 115 2. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 In examples, "C:" represents lines sent by a protocol client and "S:" 122 represents lines returned by a protocol server. Indentation and 123 white space in examples are provided only to illustrate element 124 relationships and are not a REQUIRED feature of this specification. 126 XML is case sensitive. Unless stated otherwise, XML specifications 127 and examples provided in this document MUST be interpreted in the 128 character case presented to develop a conforming implementation. 130 "reseller-1.0" in is used as an abbreviation for 131 "urn:ietf:params:xml:ns:reseller-1.0". The XML namespace prefix 132 "reseller" is used, but implementations MUST NOT depend on it and 133 instead employ a proper namespace-aware XML parser and serializer to 134 interpret and output the XML documents. 136 3. Object Attributes 138 An EPP reseller object has attributes and associated values that can 139 be viewed and modified by the sponsoring client or the server. This 140 section describes each attribute type in detail. The formal syntax 141 for the attribute values described here can be found in the "Formal 142 Syntax" section of this document and in the appropriate normative 143 references. 145 3.1. Reseller Identifier 147 Reseller identifier provides the ID of the reseller of a sponsoring 148 registrar. Its corresponding element is defined in 149 this document. All reseller objects are identified by a server- 150 unique identifier. 152 3.2. Contact and Client Identifiers 154 All EPP contacts are identified by a server-unique identifier. 155 Contact identifiers are character strings with a specific minimum 156 length, a specified maximum length, and a specified format. Contact 157 identifiers use the "clIDType" client identifier syntax described in 158 [RFC5730]. 160 3.3. Reseller State 162 A reseller object MUST always have at least one associated state 163 value. Valid values include "ok", "readonly" and "terminated". 165 State Value Descriptions: 167 o ok: the normal status value for the reseller object. 169 o readonly: transform commands submitted with the reseller 170 identifier in the reseller extension would not be allowed. 172 o terminated: query and transform commands submitted with the 173 reseller identifier in the reseller extension would not be 174 allowed. 176 3.4. Parent Identifier 178 There can be more than one layer of resellers. The parent 179 identifier, as defined with the element, 180 represents the parent reseller identifier in a child reseller. The 181 parent identifier is not defined for the top level reseller, namely 182 the registrar of the registry. An N-tier reseller has a parent 183 reseller and at least one child reseller. A reseller customer has a 184 parent reseller and no child resellers. 186 Loops SHOULD be prohibited. If reseller A has B as parent 187 identifier, reseller B must not have reseller A as parent identifier. 189 3.5. URL 191 The URL represents the reseller web home page, as defined with the 192 element. 194 3.6. Disclosure of Data Elements and Attributes 196 This document supports the same disclosure features described in 197 Section 2.9 of with the use of the element. 198 [RFC5733]. 200 The element MUST contain at least one of the 201 following child elements: 203 205 207 209 211 213 215 217 219 221 4. EPP Command Mapping 223 A detailed description of the EPP syntax and semantics can be found 224 in the EPP core protocol specification [RFC5730]. The command 225 mappings described here are specifically for use in provisioning and 226 managing reseller information via EPP. 228 4.1. EPP Query Commands 230 EPP provides two commands to retrieve domain information: to 231 determine if a reseller object can be provisioned within a 232 repository, and to retrieve detailed information associated 233 with a reseller object. This document does not define a mapping for 234 the EPP command. 236 4.1.1. EPP Command 238 The EPP command is used to determine if an object can be 239 provisioned within a repository. It provides a hint that allows a 240 client to anticipate the success or failure of provisioning an object 241 using the command, as object-provisioning requirements are 242 ultimately a matter of server policy. 244 In addition to the standard EPP command elements, the command 245 MUST contain a element that identifies the reseller 246 namespace. The element contains the following child 247 elements: 249 o One or more elements that contain the server-unique 250 identifier of the reseller objects to be queried. 252 Example command: 254 C: 255 C: 256 C: 257 C: 258 C: 260 C: res1523 261 C: re1523 262 C: 1523res 263 C: 264 C: 265 C: ABC-12345 266 C: 267 C: 269 When a command has been processed successfully, the EPP 270 element MUST contain a child element 271 that identifies the reseller namespace. The 272 element contains one or more elements that contain the 273 following child elements: 275 o A element that identifies the queried object. This 276 element MUST contain an "avail" attribute whose value indicates 277 object availability (can it be provisioned or not) at the moment 278 the command was completed. A value of "1" or "true" means 279 that the object can be provisioned. A value of "0" or "false" 280 means that the object cannot be provisioned. 282 o An OPTIONAL element that MAY be provided when an 283 object cannot be provisioned. If present, this element contains 284 server-specific text to help explain why the object cannot be 285 provisioned. This text MUST be represented in the response 286 language previously negotiated with the client; an OPTIONAL "lang" 287 attribute MAY be present to identify the language if the 288 negotiated value is something other than the default value of 289 "en"(English). 291 Example response: 293 S: 294 S: 295 S: 296 S: 297 S: Command completed successfully 298 S: 299 S: 300 S: 302 S: 303 S: res1523 304 S: 305 S: 306 S: re1523 307 S: In use 308 S: 309 S: 310 S: 1523res 311 S: 312 S: 313 S: 314 S: 315 S: ABC-12345 316 S: 54322-XYZ 317 S: 318 S: 319 S: 321 An EPP error response MUST be returned if a command cannot be 322 processed for any reason. 324 4.1.2. EPP Command 326 The EPP command is used to retrieve information associated 327 with a reseller object. In addition to the standard EPP command 328 elements, the command MUST contain a element 329 that identifies the reseller namespace. The element 330 contains the following child elements: 332 o A element that contains the server-unique identifier 333 of the reseller object to be queried. 335 Example command: 337 C: 338 C: 339 C: 340 C: 341 C: 343 C: res1523 344 C: 345 C: 346 C: ABC-12345 347 C: 348 C: 350 When an command has been processed successfully, the EPP 351 element MUST contain a child element 352 that identifies the reseller namespace. The 353 element contains the following child elements: 355 o A element that contains the server-unique identifier 356 of the reseller object, as defined in Section 3.1. 358 o A element that contains the Repository Object 359 IDentifier assigned to the reseller object when the object was 360 created. 362 o A element that contains the operational state of 363 the reseller, as defined in Section 3.3. 365 o An OPTIONAL element that contains the 366 identifier of the parent object, as defined in Section 3.4. 368 o One or two elements that contain postal- 369 address information. Two elements are provided so that address 370 information can be provided in both internationalized and 371 localized forms; a "type" attribute is used to identify the two 372 forms. If an internationalized form (type="int") is provided, 373 element content MUST be represented in a subset of UTF-8 that can 374 be represented in the 7-bit US-ASCII character set. If a 375 localized form (type="loc") is provided, element content MAY be 376 represented in unrestricted UTF-8. The 377 element contains the following child elements: 379 * A element that contains the name of the 380 reseller, which SHOULD be the name of the organization. 382 * A element that contains address information 383 associated with the reseller. A element 384 contains the following child elements: 386 + One, two, or three OPTIONAL elements that 387 contain the reseller's street address. 389 + A element that contains the reseller's city. 391 + An OPTIONAL element that contains the 392 reseller's state or province. 394 + An OPTIONAL element that contains the 395 reseller's postal code. 397 + A element that contains the reseller's country 398 code. 400 o An OPTIONAL element that contains the reseller's 401 voice telephone number. 403 o An OPTIONAL element that contains the reseller's 404 facsimile telephone number. 406 o A element that contains the reseller's email 407 address. 409 o A element that contains the URL to the website of 410 the reseller. 412 o Zero or more OPTIONAL elements that contain 413 identifiers for the contact objects to be associated with the 414 reseller object. Contact object identifiers MUST be known to the 415 server before the contact object can be associated with the 416 reseller object. An attribute "type" associated with 417 is used to represent contact types. The type 418 values include admin, tech and billing. 420 o A element that contains the identifier of the 421 sponsoring client, who is the domain name registrar. 423 o A element that contains the identifier of the 424 client that created the reseller object. 426 o A element that contains the date and time of 427 reseller-object creation. 429 o A element that contains the identifier of the 430 client that last updated the reseller object. This element MUST 431 NOT be present if the reseller has never been modified. 433 o A element that contains the date and time of the 434 most recent reseller-object modification. This element MUST NOT 435 be present if the reseller object has never been modified. 437 o An OPTIONAL element that identifies elements 438 that require exceptional server-operator handling to allow or 439 restrict disclosure to third parties. See Section 3.6 for a 440 description of the child elements contained within the 441 element. 443 Example response for the sponsoring client: 445 S: 446 S: 447 S: 448 S: 449 S: Command completed successfully 450 S: 451 S: 452 S: 454 S: res1523 455 S: res1523-REP 456 S: ok 457 S: 1523res 458 S: 459 S: Example Reseller Inc. 460 S: 461 S: 123 Example Dr. 462 S: Suite 100 463 S: Dulles 464 S: VA 465 S: 20166-6503 466 S: US 467 S: 468 S: 469 S: +1.7035555555 470 S: +1.7035555556 471 S: contact@reseller.example 472 S: http://reseller.example 473 S: sh8013 474 S: sh8013 475 S: ClientY 476 S: ClientX 477 S: 1999-04-03T22:00:00.0Z 478 S: ClientX 479 S: 1999-12-03T09:00:00.0Z 480 S: 481 S: 482 S: 483 S: 484 S: 485 S: 486 S: 487 S: ABC-12345 488 S: 54322-XYZ 489 S: 490 S: 491 S: 492 Example for the non-sponsoring client, according to the 493 disclosure policy: 495 S: 496 S: 497 S: 498 S: 499 S: Command completed successfully 500 S: 501 S: 502 S: 504 S: res1523 505 S: res1523-REP 506 S: ok 507 S: 1523res 508 S: 509 S: Example Reseller Inc. 510 S: 511 S: 123 Example Dr. 512 S: Suite 100 513 S: Dulles 514 S: VA 515 S: 20166-6503 516 S: US 517 S: 518 S: 519 S: +1.7035555556 520 S: http://reseller.example 521 S: ClientY 522 S: ClientX 523 S: 1999-04-03T22:00:00.0Z 524 S: ClientX 525 S: 1999-12-03T09:00:00.0Z 526 S: 527 S: 528 S: 529 S: ABC-12345 530 S: 54322-XYZ 531 S: 532 S: 533 S: 535 An EPP error response MUST be returned if an command cannot be 536 processed for any reason. 538 4.1.3. EPP Command 540 The transfer semantics does not apply to reseller object. No EPP 541 command is defined in this document. 543 4.2. EPP Transform Commands 545 EPP provides four commands to transform reseller-object information: 546 to create an instance of a reseller object, to 547 delete an instance of a reseller object, to manage 548 reseller-object sponsorship changes, and to change 549 information associated with a reseller object. This document does 550 not define a mapping for the EPP and command. 552 Transform commands are typically processed and completed in real 553 time. Server operators MAY receive and process transform commands 554 but defer completing the requested action if human or third-party 555 review is required before the requested action can be completed. In 556 such situations, the server MUST return a 1001 response code to the 557 client to note that the command has been received and processed but 558 that the requested action is pending. The server MUST also manage 559 the status of the object that is the subject of the command to 560 reflect the initiation and completion of the requested action. Once 561 the action has been completed, all clients involved in the 562 transaction MUST be notified using a service message that the action 563 has been completed and that the status of the object has changed. 564 Other notification methods MAY be used in addition to the required 565 service message. 567 4.2.1. EPP Command 569 The EPP command provides a transform operation that allows a 570 client to create a reseller object. In addition to the standard EPP 571 command elements, the command MUST contain a 572 element that identifies the reseller namespace. 573 The element contains the following child elements: 575 o A element that contains the desired server-unique 576 identifier for the reseller to be created, as defined in 577 Section 3.1. 579 o A element that contains the operational status of 580 the reseller, as defined in Section 3.3. 582 o An OPTIONAL element that contains the 583 identifier of the parent object, as defined in Section 3.4. 585 o One or two elements that contain postal- 586 address information. Two elements are provided so that address 587 information can be provided in both internationalized and 588 localized forms; a "type" attribute is used to identify the two 589 forms. If an internationalized form (type="int") is provided, 590 element content MUST be represented in a subset of UTF-8 that can 591 be represented in the 7-bit US-ASCII character set. If a 592 localized form (type="loc") is provided, element content MAY be 593 represented in unrestricted UTF-8. The 594 element contains the following child elements: 596 * A element that contains the name of the 597 reseller, which SHOULD be the name of the organization. 599 * A element that contains address information 600 associated with the reseller. A element 601 contains the following child elements: 603 + One, two, or three OPTIONAL elements that 604 contain the reseller's street address. 606 + A element that contains the reseller's city. 608 + An OPTIONAL element that contains the 609 reseller's state or province. 611 + An OPTIONAL element that contains the 612 reseller's postal code. 614 + A element that contains the reseller's country 615 code. 617 o An OPTIONAL element that contains the reseller's 618 voice telephone number. 620 o An OPTIONAL element that contains the reseller's 621 facsimile telephone number. 623 o A element that contains the reseller's email 624 address. 626 o A element that contains the URL to the website of 627 the reseller. 629 o Zero or more OPTIONAL elements that contain 630 identifiers for the human or organizational social information 631 objects associated with the reseller object. 633 o An OPTIONAL element that identifies elements 634 that require exceptional server-operator handling to allow or 635 restrict disclosure to third parties. See Section 3.6 for a 636 description of the child elements contained within the 637 element. 639 Example command: 641 C: 642 C: 643 C: 644 C: 645 C: 647 C: res1523 648 C: ok 649 C: 1523res 650 C: 651 C: Example Reseller Inc. 652 C: 653 C: 123 Example Dr. 654 C: Suite 100 655 C: Dulles 656 C: VA 657 C: 20166-6503 658 C: US 659 C: 660 C: 661 C: +1.7035555555 662 C: +1.7035555556 663 C: contact@reseller.example 664 C: http://reseller.example 665 C: sh8013 666 C: sh8013 667 C: 668 C: 669 C: 670 C: 671 C: 672 C: 673 C: ABC-12345 674 C: 675 C: 677 When a command has been processed successfully, the EPP 678 element MUST contain a child element 679 that identifies the reseller namespace. The 680 element contains the following child elements: 682 o A element that contains the server-unique identifier 683 for the created reseller, as defined in Section 3.1. 685 o A element that contains the date and time of 686 reseller-object creation. 688 Example response: 690 S: 691 S: 692 S: 693 S: 694 S: Command completed successfully 695 S: 696 S: 697 S: 699 S: res1523 700 S: 1999-04-03T22:00:00.0Z 701 S: 702 S: 703 S: 704 S: ABC-12345 705 S: 54321-XYZ 706 S: 707 S: 708 S: 710 An EPP error response MUST be returned if a command cannot 711 be processed for any reason. 713 4.2.2. EPP Command 715 The EPP command provides a transform operation that allows a 716 client to delete a reseller object. In addition to the standard EPP 717 command elements, the command MUST contain a 718 element that identifies the reseller namespace. 719 The element MUST contain the following child 720 element: 722 o A element that contains the server-unique identifier 723 of the reseller object, as defined in Section 3.1, to be deleted. 725 A reseller object SHOULD NOT be deleted if it is associated with 726 other known objects. An associated reseller SHOULD NOT be deleted 727 until associations with other known objects have been broken. A 728 server SHOULD notify clients that object relationships exist by 729 sending a 2305 error response code when a command is 730 attempted and fails due to existing object relationships. 732 Example command: 734 C: 735 C: 736 C: 737 C: 738 C: 740 C: res1523 741 C: 742 C: 743 C: ABC-12345 744 C: 745 C: 747 When a command has been processed successfully, a server 748 MUST respond with an EPP response with no element. 750 Example response: 752 S: 753 S: 754 S: 755 S: 756 S: Command completed successfully 757 S: 758 S: 759 S: ABC-12345 760 S: 54321-XYZ 761 S: 762 S: 763 S: 765 An EPP error response MUST be returned if a command cannot 766 be processed for any reason. 768 4.2.3. EPP Command 770 Renewal semantics do not apply to reseller objects, so there is no 771 mapping defined for the EPP command. 773 4.2.4. EPP Command 775 Transfer semantics do not apply to reseller objects, so there is no 776 mapping defined for the EPP command. 778 4.2.5. EPP Command 780 The EPP command provides a transform operation that allows a 781 client to modify the attributes of a reseller object. In addition to 782 the standard EPP command elements, the command MUST contain 783 a element that identifies the reseller namespace. 784 The element contains the following child elements: 786 o A element that contains the server-unique identifier 787 of the reseller object to be updated, as defined in Section 3.1. 789 o An OPTIONAL element that contains attribute values 790 to be added to the object. 792 o An OPTIONAL element that contains attribute values 793 to be removed from the object. 795 o An OPTIONAL element that contains attribute values 796 to be changed. 798 At least one , or element 799 MUST be provided if the command is not being extended. All of these 800 elements MAY be omitted if an extension is present. The 801 and elements contain the following 802 child element: 804 o Zero or more elements that contain the 805 identifiers for contact objects to be associated with or removed 806 from the reseller object. Contact object identifiers MUST be 807 known to the server before the contact object can be associated 808 with the reseller object. 810 A element contains the following OPTIONAL child 811 elements. At least one child element MUST be present: 813 o A element that contains the operational status of 814 the reseller. 816 o A element that contains the identifier of the 817 parent object. 819 o One or two elements that contain postal- 820 address information. Two elements are provided so that address 821 information can be provided in both internationalized and 822 localized forms; a "type" attribute is used to identify the two 823 forms. If an internationalized form (type="int") is provided, 824 element content MUST be represented in a subset of UTF-8 that can 825 be represented in the 7-bit US-ASCII character set. If a 826 localized form (type="loc") is provided, element content MAY be 827 represented in unrestricted UTF-8. The 828 element contains the following child elements: 830 * A element that contains the name of the 831 reseller, which SHOULD be the name of the organization. 833 * A element that contains address information 834 associated with the reseller. A element 835 contains the following child elements: 837 + One, two, or three OPTIONAL elements that 838 contain the reseller's street address. 840 + A element that contains the reseller's city. 842 + An OPTIONAL element that contains the 843 reseller's state or province. 845 + An OPTIONAL element that contains the 846 reseller's postal code. 848 + A element that contains the reseller's country 849 code. 851 o An element that contains the reseller's voice 852 telephone number. 854 o An element that contains the reseller's facsimile 855 telephone number. 857 o A element that contains the reseller's email 858 address. 860 o A element that contains the URL to the website of 861 the reseller. 863 o An element that identifies elements that 864 require exceptional server-operator handling to allow or restrict 865 disclosure to third parties. See Section 2.9 in [RFC5733] for a 866 description of the child elements contained within the 867 element. 869 Example command: 871 C: 872 C: 873 C: 874 C: 875 C: 877 C: res1523 878 C: 879 C: sh8013 880 C: 881 C: 882 C: readonly 883 C: 884 C: 885 C: 124 Example Dr. 886 C: Suite 200 887 C: Dulles 888 C: VA 889 C: 20166-6503 890 C: US 891 C: 892 C: 893 C: +1.7034444444 894 C: 895 C: 896 C: 897 C: 898 C: 899 C: 900 C: 901 C: 902 C: ABC-12345 903 C: 904 C: 906 When an command has been processed successfully, a server 907 MUST respond with an EPP response with no element. 909 Example response: 911 S: 912 S: 913 S: 914 S: 915 S: Command completed successfully 916 S: 917 S: 918 S: ABC-12345 919 S: 54321-XYZ 920 S: 921 S: 922 S: 924 An EPP error response MUST be returned if an command cannot 925 be processed for any reason. 927 5. Formal Syntax 929 An EPP object mapping is specified in XML Schema notation. The 930 formal syntax presented here is a complete schema representation of 931 the object mapping suitable for automated validation of EPP XML 932 instances. The BEGIN and END tags are not part of the schema; they 933 are used to note the beginning and ending of the schema for URI 934 registration purposes. 936 BEGIN 937 939 947 950 951 952 953 955 956 957 Extensible Provisioning Protocol v1.0 958 reseller provisioning schema. 959 960 962 965 966 967 968 969 971 974 975 976 977 978 979 980 982 983 984 985 986 987 989 991 992 993 995 997 998 999 1000 1001 1002 1003 1004 1005 1008 1009 1010 1011 1013 1015 1017 1019 1021 1022 1024 1026 1028 1029 1031 1034 1035 1036 1037 1038 1040 1043 1044 1045 1047 1048 1050 1053 1054 1055 1056 1057 1059 1062 1063 1064 1065 1067 1069 1071 1072 1074 1077 1078 1079 1081 1082 1084 1087 1088 1089 1091 1093 1095 1097 1099 1102 1104 1106 1107 1109 1110 1111 1113 1115 1116 1118 1120 1123 1124 1125 1127 1130 1131 1132 1133 1134 1135 1137 1139 1141 1143 1144 1146 1148 1149 1150 1151 1153 1155 1157 1158 1160 1163 1164 END 1166 6. Internationalization Considerations 1168 EPP is represented in XML, which provides native support for encoding 1169 information using the Unicode character set and its more compact 1170 representations including UTF-8. Conformant XML processors recognize 1171 both UTF-8 and UTF-16. Though XML includes provisions to identify 1172 and use other character encodings through use of an "encoding" 1173 attribute in an declaration, use of UTF-8 is RECOMMENDED. 1175 As an extension of the EPP reseller object mapping, the elements and 1176 element content described in this document MUST inherit the 1177 internationalization conventions used to represent higher-layer 1178 domain and core protocol structures present in an XML instance that 1179 includes this extension. 1181 7. IANA Considerations 1183 7.1. XML Namespace 1185 This document uses URNs to describe XML namespaces and XML schemas 1186 conforming to a registry mechanism described in [RFC3688]. IANA is 1187 requested to assignment the following URI. 1189 Registration request for the reseller namespace: 1191 o URI: urn:ietf:params:xml:ns:reseller-1.0 1193 o Registrant Contact: See the "Author's Address" section of this 1194 document. 1196 o XML: See the "Formal Syntax" section of this document. 1198 7.2. EPP Extension Registry 1200 The EPP extension described in this document should be registered by 1201 the IANA in the EPP Extension Registry described in [RFC7451]. The 1202 details of the registration are as follows: 1204 Name of Extension: Domain Reseller Object Extension 1206 Document status: Standards Track 1208 Reference: (insert reference to RFC version of this document) 1210 Registrant Name and Email Address: See the "Author's Address" section 1211 of this document. 1213 TLDs: any 1215 IPR Disclosure: none 1217 Status: active 1219 Notes: none 1221 8. Security Considerations 1223 Authorization information described in [RFC5733] is not supported in 1224 this document. If the querying client is not the sponsoring 1225 registrar of the reseller, not all the object information is 1226 accessible. The disclose element defined in [RFC5733] is used to 1227 allow or restrict disclosure of object elements to third parties. 1228 Other mechanism, such as defining a registry customized authorization 1229 information list according to their local policies and regulations, 1230 is also possible. 1232 9. Acknowledgement 1234 The authors would like to thank Rik Ribbers, Marc Groeneweg and 1235 Patrick Mevzek for their careful review and valuable comments. 1237 10. Normative References 1239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1240 Requirement Levels", BCP 14, RFC 2119, 1241 DOI 10.17487/RFC2119, March 1997, 1242 . 1244 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1245 DOI 10.17487/RFC3688, January 2004, 1246 . 1248 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1249 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1250 . 1252 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1253 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 1254 August 2009, . 1256 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1257 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1258 February 2015, . 1260 [W3C.REC-xml-20040204] 1261 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1262 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 1263 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1264 20040204", February 2004, 1265 . 1267 [W3C.REC-xmlschema-1-20041028] 1268 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1269 ""XML Schema Part 1: Structures Second Edition", World 1270 Wide Web Consortium Recommendation REC-xmlschema- 1271 1-20041028", October 2004, 1272 . 1274 [W3C.REC-xmlschema-2-20041028] 1275 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 1276 Second Edition", World Wide Web Consortium Recommendation 1277 REC-xmlschema-2-20041028", October 2004, 1278 . 1280 Appendix A. Change Log 1282 Initial -00: Individual document submitted. 1284 -01: 1286 * Updated abstract text. 1288 * Added sentences to avoid loop of parent identifiers in section 1289 3.4. 1291 * Revised typos in section 3.6. 1293 * Added explanation of contact type attribute in section 4.1.2. 1295 * Updated responses. 1297 * Deleted description of command in section 4.1 and 1298 4.2. 1300 * Deleted whoisInfo disclose type in XML schema. 1302 * Deleted maxOccurs of addRemType. 1304 * Deleted extra "OPTIONAL" in section 4.2.5. 1306 * Updated typos in response. 1308 -02: 1310 * Changed author information. 1312 * Updated url definition. 1314 * Updated XML schema. 1316 -03: 1318 * Changed author information. 1320 * Updated section 3.1. 1322 * Refactored the XSD file. Added element. 1324 * Added acknowledgement. 1326 Authors' Addresses 1328 Linlin Zhou 1329 CNNIC 1330 4 South 4th Street, Zhongguancun, Haidian District 1331 Beijing, Beijing 100190 1332 China 1334 Phone: +86 10 5881 2677 1335 Email: zhoulinlin@cnnic.cn 1336 Ning Kong 1337 CNNIC 1338 4 South 4th Street, Zhongguancun, Haidian District 1339 Beijing, Beijing 100190 1340 China 1342 Phone: +86 10 5881 3147 1343 Email: nkong@cnnic.cn 1345 Guiqing Zhou 1346 CNNIC 1347 4 South 4th Street, Zhongguancun, Haidian District 1348 Beijing, Beijing 100190 1349 China 1351 Phone: +86 10 5881 2692 1352 Email: zhouguiqing@cnnic.cn 1354 Xiaodong Lee 1355 CNNIC 1356 4 South 4th Street, Zhongguancun, Haidian District 1357 Beijing, Beijing 100190 1358 China 1360 Phone: +86 10 5881 3020 1361 Email: xl@cnnic.cn 1363 James Gould 1364 VeriSign, Inc. 1365 12061 Bluemont Way 1366 Reston, VA 20190 1367 US 1369 Email: jgould@verisign.com