Internet Engineering Task Force L. Zhou Internet-Draft N. Kong Intended status: Standards Track G. Zhou Expires: December 9, 2016 X. Lee CNNIC J. Gould VeriSign, Inc. June 7, 2016 Extensible Provisioning Protocol (EPP) Reseller Mapping draft-ietf-regext-reseller-00 Abstract This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of reseller object stored in a shared central repository. Specified in Extensible Markup Language (XML), this extended mapping is applied to provide additional features required for the provisioning of resellers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 9, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Zhou, et al. Expires December 9, 2016 [Page 1] Internet-Draft EPP Reseller Mapping June 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Reseller Identifier . . . . . . . . . . . . . . . . . . . 4 3.2. Contact and Client Identifiers . . . . . . . . . . . . . 4 3.3. Reseller State . . . . . . . . . . . . . . . . . . . . . 4 3.4. Parent Identifier . . . . . . . . . . . . . . . . . . . . 4 3.5. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6. Disclosure of Data Elements and Attributes . . . . . . . 5 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 7 4.1.3. EPP Command . . . . . . . . . . . . . . . 13 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 13 4.2.1. EPP Command . . . . . . . . . . . . . . . . 13 4.2.2. EPP Command . . . . . . . . . . . . . . . . 16 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 18 4.2.4. EPP Command . . . . . . . . . . . . . . . 18 4.2.5. EPP Command . . . . . . . . . . . . . . . . 18 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Internationalization Considerations . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 26 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 10. Normative References . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 Zhou, et al. Expires December 9, 2016 [Page 2] Internet-Draft EPP Reseller Mapping June 2016 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Domain resellers are the individuals or companies that act as agents for domain name registrars. A domain name registrar is a direct customer of the domain name registry, is represented as the sponsoring client to the server in [RFC5730], and may have several resellers to help them sell domain names to end users. This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping specifies the reseller object mapping. This document is specified using the XML 1.0 as described in [W3C.REC-xml-20040204] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this specification. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation. "reseller-1.0" in is used as an abbreviation for "urn:ietf:params:xml:ns:reseller-1.0". The XML namespace prefix "reseller" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. 3. Object Attributes An EPP reseller object has attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references. Zhou, et al. Expires December 9, 2016 [Page 3] Internet-Draft EPP Reseller Mapping June 2016 3.1. Reseller Identifier Reseller identifier provides the ID of the reseller of a sponsoring registrar. Its corresponding element is defined in this document. All reseller objects are identified by a server- unique identifier. 3.2. Contact and Client Identifiers All EPP contacts are identified by a server-unique identifier. Contact identifiers are character strings with a specific minimum length, a specified maximum length, and a specified format. Contact identifiers use the "clIDType" client identifier syntax described in [RFC5730]. 3.3. Reseller State A reseller object MUST always have at least one associated state value. Valid values include "ok", "readonly" and "terminated". State Value Descriptions: o ok: the normal status value for the reseller object. o readonly: transform commands submitted with the reseller identifier in the reseller extension would not be allowed. o terminated: query and transform commands submitted with the reseller identifier in the reseller extension would not be allowed. 3.4. Parent Identifier There can be more than one layer of resellers. The parent identifier, as defined with the element, represents the parent reseller identifier in a child reseller. The parent identifier is not defined for the top level reseller, namely the registrar of the registry. An N-tier reseller has a parent reseller and at least one child reseller. A reseller customer has a parent reseller and no child resellers. Loops SHOULD be prohibited. If reseller A has B as parent identifier, reseller B must not have reseller A as parent identifier. Zhou, et al. Expires December 9, 2016 [Page 4] Internet-Draft EPP Reseller Mapping June 2016 3.5. URL The URL represents the reseller web home page, as defined with the element. 3.6. Disclosure of Data Elements and Attributes This document supports the same disclosure features described in Section 2.9 of with the use of the element. [RFC5733]. The element MUST contain at least one of the following child elements: 4. EPP Command Mapping A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for use in provisioning and managing reseller information via EPP. 4.1. EPP Query Commands EPP provides two commands to retrieve domain information: to determine if a reseller object can be provisioned within a repository, and to retrieve detailed information associated with a reseller object. This document does not define a mapping for the EPP command. Zhou, et al. Expires December 9, 2016 [Page 5] Internet-Draft EPP Reseller Mapping June 2016 4.1.1. EPP Command The EPP command is used to determine if an object can be provisioned within a repository. It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the command, as object-provisioning requirements are ultimately a matter of server policy. In addition to the standard EPP command elements, the command MUST contain a element that identifies the reseller namespace. The element contains the following child elements: o One or more elements that contain the server-unique identifier of the reseller objects to be queried. Example command: C: C: C: C: C: C: res1523 C: re1523 C: 1523res C: C: C: ABC-12345 C: C: When a command has been processed successfully, the EPP element MUST contain a child element that identifies the reseller namespace. The element contains one or more elements that contain the following child elements: o A element that identifies the queried object. This element MUST contain an "avail" attribute whose value indicates object availability (can it be provisioned or not) at the moment the command was completed. A value of "1" or "true" means that the object can be provisioned. A value of "0" or "false" means that the object cannot be provisioned. Zhou, et al. Expires December 9, 2016 [Page 6] Internet-Draft EPP Reseller Mapping June 2016 o An OPTIONAL element that MAY be provided when an object cannot be provisioned. If present, this element contains server-specific text to help explain why the object cannot be provisioned. This text MUST be represented in the response language previously negotiated with the client; an OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en"(English). Example response: S: S: S: S: S: Command completed successfully S: S: S: S: S: res1523 S: S: S: re1523 S: In use S: S: S: 1523res S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if a command cannot be processed for any reason. 4.1.2. EPP Command The EPP command is used to retrieve information associated with a reseller object. In addition to the standard EPP command elements, the command MUST contain a element Zhou, et al. Expires December 9, 2016 [Page 7] Internet-Draft EPP Reseller Mapping June 2016 that identifies the reseller namespace. The element contains the following child elements: o A element that contains the server-unique identifier of the reseller object to be queried. Example command: C: C: C: C: C: C: res1523 C: C: C: ABC-12345 C: C: When an command has been processed successfully, the EPP element MUST contain a child element that identifies the reseller namespace. The element contains the following child elements: o A element that contains the server-unique identifier of the reseller object, as defined in Section 3.1. o A element that contains the Repository Object IDentifier assigned to the reseller object when the object was created. o A element that contains the operational state of the reseller, as defined in Section 3.3. o An OPTIONAL element that contains the identifier of the parent object, as defined in Section 3.4. o One or two elements that contain postal- address information. Two elements are provided so that address information can be provided in both internationalized and localized forms; a "type" attribute is used to identify the two forms. If an internationalized form (type="int") is provided, element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. If a localized form (type="loc") is provided, element content MAY be Zhou, et al. Expires December 9, 2016 [Page 8] Internet-Draft EPP Reseller Mapping June 2016 represented in unrestricted UTF-8. The element contains the following child elements: * A element that contains the name of the reseller, which SHOULD be the name of the organization. * A element that contains address information associated with the reseller. A element contains the following child elements: + One, two, or three OPTIONAL elements that contain the reseller's street address. + A element that contains the reseller's city. + An OPTIONAL element that contains the reseller's state or province. + An OPTIONAL element that contains the reseller's postal code. + A element that contains the reseller's country code. o An OPTIONAL element that contains the reseller's voice telephone number. o An OPTIONAL element that contains the reseller's facsimile telephone number. o A element that contains the reseller's email address. o A element that contains the URL to the website of the reseller. o Zero or more OPTIONAL elements that contain identifiers for the contact objects to be associated with the reseller object. Contact object identifiers MUST be known to the server before the contact object can be associated with the reseller object. An attribute "type" associated with is used to represent contact types. The type values include admin, tech and billing. o A element that contains the identifier of the sponsoring client, who is the domain name registrar. Zhou, et al. Expires December 9, 2016 [Page 9] Internet-Draft EPP Reseller Mapping June 2016 o A element that contains the identifier of the client that created the reseller object. o A element that contains the date and time of reseller-object creation. o A element that contains the identifier of the client that last updated the reseller object. This element MUST NOT be present if the reseller has never been modified. o A element that contains the date and time of the most recent reseller-object modification. This element MUST NOT be present if the reseller object has never been modified. o An OPTIONAL element that identifies elements that require exceptional server-operator handling to allow or restrict disclosure to third parties. See Section 3.6 for a description of the child elements contained within the element. Example response for the sponsoring client: Zhou, et al. Expires December 9, 2016 [Page 10] Internet-Draft EPP Reseller Mapping June 2016 S: S: S: S: S: Command completed successfully S: S: S: S: res1523 S: res1523-REP S: ok S: 1523res S: S: Example Reseller Inc. S: S: 123 Example Dr. S: Suite 100 S: Dulles S: VA S: 20166-6503 S: US S: S: S: +1.7035555555 S: +1.7035555556 S: contact@reseller.example S: http://reseller.example S: sh8013 S: sh8013 S: ClientY S: ClientX S: 1999-04-03T22:00:00.0Z S: ClientX S: 1999-12-03T09:00:00.0Z S: S: S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: Zhou, et al. Expires December 9, 2016 [Page 11] Internet-Draft EPP Reseller Mapping June 2016 Example for the non-sponsoring client, according to the disclosure policy: S: S: S: S: S: Command completed successfully S: S: S: S: res1523 S: res1523-REP S: ok S: 1523res S: S: Example Reseller Inc. S: S: 123 Example Dr. S: Suite 100 S: Dulles S: VA S: 20166-6503 S: US S: S: S: +1.7035555556 S: http://reseller.example S: ClientY S: ClientX S: 1999-04-03T22:00:00.0Z S: ClientX S: 1999-12-03T09:00:00.0Z S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if an command cannot be processed for any reason. Zhou, et al. Expires December 9, 2016 [Page 12] Internet-Draft EPP Reseller Mapping June 2016 4.1.3. EPP Command The transfer semantics does not apply to reseller object. No EPP command is defined in this document. 4.2. EPP Transform Commands EPP provides four commands to transform reseller-object information: to create an instance of a reseller object, to delete an instance of a reseller object, to manage reseller-object sponsorship changes, and to change information associated with a reseller object. This document does not define a mapping for the EPP and command. Transform commands are typically processed and completed in real time. Server operators MAY receive and process transform commands but defer completing the requested action if human or third-party review is required before the requested action can be completed. In such situations, the server MUST return a 1001 response code to the client to note that the command has been received and processed but that the requested action is pending. The server MUST also manage the status of the object that is the subject of the command to reflect the initiation and completion of the requested action. Once the action has been completed, all clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed. Other notification methods MAY be used in addition to the required service message. 4.2.1. EPP Command The EPP command provides a transform operation that allows a client to create a reseller object. In addition to the standard EPP command elements, the command MUST contain a element that identifies the reseller namespace. The element contains the following child elements: o A element that contains the desired server-unique identifier for the reseller to be created, as defined in Section 3.1. o A element that contains the operational status of the reseller, as defined in Section 3.3. o An OPTIONAL element that contains the identifier of the parent object, as defined in Section 3.4. Zhou, et al. Expires December 9, 2016 [Page 13] Internet-Draft EPP Reseller Mapping June 2016 o One or two elements that contain postal- address information. Two elements are provided so that address information can be provided in both internationalized and localized forms; a "type" attribute is used to identify the two forms. If an internationalized form (type="int") is provided, element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. If a localized form (type="loc") is provided, element content MAY be represented in unrestricted UTF-8. The element contains the following child elements: * A element that contains the name of the reseller, which SHOULD be the name of the organization. * A element that contains address information associated with the reseller. A element contains the following child elements: + One, two, or three OPTIONAL elements that contain the reseller's street address. + A element that contains the reseller's city. + An OPTIONAL element that contains the reseller's state or province. + An OPTIONAL element that contains the reseller's postal code. + A element that contains the reseller's country code. o An OPTIONAL element that contains the reseller's voice telephone number. o An OPTIONAL element that contains the reseller's facsimile telephone number. o A element that contains the reseller's email address. o A element that contains the URL to the website of the reseller. o Zero or more OPTIONAL elements that contain identifiers for the human or organizational social information objects associated with the reseller object. Zhou, et al. Expires December 9, 2016 [Page 14] Internet-Draft EPP Reseller Mapping June 2016 o An OPTIONAL element that identifies elements that require exceptional server-operator handling to allow or restrict disclosure to third parties. See Section 3.6 for a description of the child elements contained within the element. Example command: C: C: C: C: C: C: res1523 C: ok C: 1523res C: C: Example Reseller Inc. C: C: 123 Example Dr. C: Suite 100 C: Dulles C: VA C: 20166-6503 C: US C: C: C: +1.7035555555 C: +1.7035555556 C: contact@reseller.example C: http://reseller.example C: sh8013 C: sh8013 C: C: C: C: C: C: C: ABC-12345 C: C: When a command has been processed successfully, the EPP element MUST contain a child element Zhou, et al. Expires December 9, 2016 [Page 15] Internet-Draft EPP Reseller Mapping June 2016 that identifies the reseller namespace. The element contains the following child elements: o A element that contains the server-unique identifier for the created reseller, as defined in Section 3.1. o A element that contains the date and time of reseller-object creation. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: res1523 S: 1999-04-03T22:00:00.0Z S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: An EPP error response MUST be returned if a command cannot be processed for any reason. 4.2.2. EPP Command The EPP command provides a transform operation that allows a client to delete a reseller object. In addition to the standard EPP command elements, the command MUST contain a element that identifies the reseller namespace. The element MUST contain the following child element: o A element that contains the server-unique identifier of the reseller object, as defined in Section 3.1, to be deleted. Zhou, et al. Expires December 9, 2016 [Page 16] Internet-Draft EPP Reseller Mapping June 2016 A reseller object SHOULD NOT be deleted if it is associated with other known objects. An associated reseller SHOULD NOT be deleted until associations with other known objects have been broken. A server SHOULD notify clients that object relationships exist by sending a 2305 error response code when a command is attempted and fails due to existing object relationships. Example command: C: C: C: C: C: C: res1523 C: C: C: ABC-12345 C: C: When a command has been processed successfully, a server MUST respond with an EPP response with no element. Example response: S: S: S: S: S: Command completed successfully S: S: S: ABC-12345 S: 54321-XYZ S: S: S: An EPP error response MUST be returned if a command cannot be processed for any reason. Zhou, et al. Expires December 9, 2016 [Page 17] Internet-Draft EPP Reseller Mapping June 2016 4.2.3. EPP Command Renewal semantics do not apply to reseller objects, so there is no mapping defined for the EPP command. 4.2.4. EPP Command Transfer semantics do not apply to reseller objects, so there is no mapping defined for the EPP command. 4.2.5. EPP Command The EPP command provides a transform operation that allows a client to modify the attributes of a reseller object. In addition to the standard EPP command elements, the command MUST contain a element that identifies the reseller namespace. The element contains the following child elements: o A element that contains the server-unique identifier of the reseller object to be updated, as defined in Section 3.1. o An OPTIONAL element that contains attribute values to be added to the object. o An OPTIONAL element that contains attribute values to be removed from the object. o An OPTIONAL element that contains attribute values to be changed. At least one , or element MUST be provided if the command is not being extended. All of these elements MAY be omitted if an extension is present. The and elements contain the following child element: o Zero or more elements that contain the identifiers for contact objects to be associated with or removed from the reseller object. Contact object identifiers MUST be known to the server before the contact object can be associated with the reseller object. A element contains the following OPTIONAL child elements. At least one child element MUST be present: o A element that contains the operational status of the reseller. Zhou, et al. Expires December 9, 2016 [Page 18] Internet-Draft EPP Reseller Mapping June 2016 o A element that contains the identifier of the parent object. o One or two elements that contain postal- address information. Two elements are provided so that address information can be provided in both internationalized and localized forms; a "type" attribute is used to identify the two forms. If an internationalized form (type="int") is provided, element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. If a localized form (type="loc") is provided, element content MAY be represented in unrestricted UTF-8. The element contains the following child elements: * A element that contains the name of the reseller, which SHOULD be the name of the organization. * A element that contains address information associated with the reseller. A element contains the following child elements: + One, two, or three OPTIONAL elements that contain the reseller's street address. + A element that contains the reseller's city. + An OPTIONAL element that contains the reseller's state or province. + An OPTIONAL element that contains the reseller's postal code. + A element that contains the reseller's country code. o An element that contains the reseller's voice telephone number. o An element that contains the reseller's facsimile telephone number. o A element that contains the reseller's email address. o A element that contains the URL to the website of the reseller. Zhou, et al. Expires December 9, 2016 [Page 19] Internet-Draft EPP Reseller Mapping June 2016 o An element that identifies elements that require exceptional server-operator handling to allow or restrict disclosure to third parties. See Section 2.9 in [RFC5733] for a description of the child elements contained within the element. Example command: C: C: C: C: C: C: res1523 C: C: sh8013 C: C: C: readonly C: C: C: 124 Example Dr. C: Suite 200 C: Dulles C: VA C: 20166-6503 C: US C: C: C: +1.7034444444 C: C: C: C: C: C: C: C: C: ABC-12345 C: C: When an command has been processed successfully, a server MUST respond with an EPP response with no element. Example response: Zhou, et al. Expires December 9, 2016 [Page 20] Internet-Draft EPP Reseller Mapping June 2016 S: S: S: S: S: Command completed successfully S: S: S: ABC-12345 S: 54321-XYZ S: S: S: An EPP error response MUST be returned if an command cannot be processed for any reason. 5. Formal Syntax An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. BEGIN Extensible Provisioning Protocol v1.0 Zhou, et al. Expires December 9, 2016 [Page 21] Internet-Draft EPP Reseller Mapping June 2016 reseller provisioning schema. Zhou, et al. Expires December 9, 2016 [Page 22] Internet-Draft EPP Reseller Mapping June 2016 Zhou, et al. Expires December 9, 2016 [Page 23] Internet-Draft EPP Reseller Mapping June 2016 Zhou, et al. Expires December 9, 2016 [Page 24] Internet-Draft EPP Reseller Mapping June 2016 Zhou, et al. Expires December 9, 2016 [Page 25] Internet-Draft EPP Reseller Mapping June 2016 END 6. Internationalization Considerations EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an declaration, use of UTF-8 is RECOMMENDED. As an extension of the EPP reseller object mapping, the elements and element content described in this document MUST inherit the internationalization conventions used to represent higher-layer domain and core protocol structures present in an XML instance that includes this extension. 7. IANA Considerations 7.1. XML Namespace This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. IANA is requested to assignment the following URI. Registration request for the reseller namespace: o URI: urn:ietf:params:xml:ns:reseller-1.0 o Registrant Contact: See the "Author's Address" section of this document. o XML: See the "Formal Syntax" section of this document. Zhou, et al. Expires December 9, 2016 [Page 26] Internet-Draft EPP Reseller Mapping June 2016 7.2. EPP Extension Registry The EPP extension described in this document should be registered by the IANA in the EPP Extension Registry described in [RFC7451]. The details of the registration are as follows: Name of Extension: Domain Reseller Object Extension Document status: Standards Track Reference: (insert reference to RFC version of this document) Registrant Name and Email Address: See the "Author's Address" section of this document. TLDs: any IPR Disclosure: none Status: active Notes: none 8. Security Considerations Authorization information described in [RFC5733] is not supported in this document. If the querying client is not the sponsoring registrar of the reseller, not all the object information is accessible. The disclose element defined in [RFC5733] is used to allow or restrict disclosure of object elements to third parties. Other mechanism, such as defining a registry customized authorization information list according to their local policies and regulations, is also possible. 9. Acknowledgement The authors would like to thank Rik Ribbers, Marc Groeneweg and Patrick Mevzek for their careful review and valuable comments. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Zhou, et al. Expires December 9, 2016 [Page 27] Internet-Draft EPP Reseller Mapping June 2016 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, . [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, . [W3C.REC-xml-20040204] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml- 20040204", February 2004, . [W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, ""XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema- 1-20041028", October 2004, . [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028", October 2004, . Appendix A. Change Log Initial -00: Individual document submitted. -01: * Updated abstract text. * Added sentences to avoid loop of parent identifiers in section 3.4. * Revised typos in section 3.6. Zhou, et al. Expires December 9, 2016 [Page 28] Internet-Draft EPP Reseller Mapping June 2016 * Added explanation of contact type attribute in section 4.1.2. * Updated responses. * Deleted description of command in section 4.1 and 4.2. * Deleted whoisInfo disclose type in XML schema. * Deleted maxOccurs of addRemType. * Deleted extra "OPTIONAL" in section 4.2.5. * Updated typos in response. -02: * Changed author information. * Updated url definition. * Updated XML schema. -03: * Changed author information. * Updated section 3.1. * Refactored the XSD file. Added element. * Added acknowledgement. Authors' Addresses Linlin Zhou CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 2677 Email: zhoulinlin@cnnic.cn Zhou, et al. Expires December 9, 2016 [Page 29] Internet-Draft EPP Reseller Mapping June 2016 Ning Kong CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3147 Email: nkong@cnnic.cn Guiqing Zhou CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 2692 Email: zhouguiqing@cnnic.cn Xiaodong Lee CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3020 Email: xl@cnnic.cn James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com Zhou, et al. Expires December 9, 2016 [Page 30]