From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8543.txt | 2299 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2299 insertions(+) create mode 100644 doc/rfc/rfc8543.txt (limited to 'doc/rfc/rfc8543.txt') diff --git a/doc/rfc/rfc8543.txt b/doc/rfc/rfc8543.txt new file mode 100644 index 0000000..4ed5ce7 --- /dev/null +++ b/doc/rfc/rfc8543.txt @@ -0,0 +1,2299 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Zhou +Request for Comments: 8543 CNNIC +Category: Standards Track N. Kong +ISSN: 2070-1721 Consultant + J. Yao + CNNIC + J. Gould + VeriSign, Inc. + G. Zhou + March 2019 + + + Extensible Provisioning Protocol (EPP) Organization Mapping + +Abstract + + This document describes an Extensible Provisioning Protocol (EPP) + mapping for provisioning and management of organization objects + stored in a shared central repository. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8543. + +Copyright Notice + + Copyright (c) 2019 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 + (https://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 + 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. + + + +Zhou, et al. Standards Track [Page 1] + +RFC 8543 EPP Organization Mapping March 2019 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4 + 3.2. Organization Roles . . . . . . . . . . . . . . . . . . . 4 + 3.2.1. Role Type . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2.2. Role Status . . . . . . . . . . . . . . . . . . . . . 4 + 3.2.3. Role Identifier . . . . . . . . . . . . . . . . . . . 4 + 3.3. Contact and Client Identifiers . . . . . . . . . . . . . 5 + 3.4. Organization Status Values . . . . . . . . . . . . . . . 5 + 3.5. Role Status Values . . . . . . . . . . . . . . . . . . . 7 + 3.6. Parent Identifier . . . . . . . . . . . . . . . . . . . . 7 + 3.7. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.8. Dates and Times . . . . . . . . . . . . . . . . . . . . . 8 + 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 8 + 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 8 + 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 10 + 4.1.3. EPP Query Command . . . . . . . . . . . . 15 + 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 16 + 4.2.1. EPP Command . . . . . . . . . . . . . . . . 16 + 4.2.2. EPP Command . . . . . . . . . . . . . . . . 20 + 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 21 + 4.2.4. EPP Command . . . . . . . . . . . . . . . 21 + 4.2.5. EPP Command . . . . . . . . . . . . . . . . 21 + 4.3. Offline Review of Requested Actions . . . . . . . . . . . 25 + 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 + 6. Internationalization Considerations . . . . . . . . . . . . . 36 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 36 + 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 37 + 7.3. Role Type Values Registry . . . . . . . . . . . . . . . . 37 + 7.3.1. Registration Template . . . . . . . . . . . . . . . . 37 + 7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 38 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 9.2. Informative References . . . . . . . . . . . . . . . . . 40 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 + + + + + + + + + +Zhou, et al. Standards Track [Page 2] + +RFC 8543 EPP Organization Mapping March 2019 + + +1. Introduction + + There are many entities, such as registrars, resellers, DNS service + operators, and privacy proxies, involved in the domain registration + business. These kinds of entities have not been formally defined as + having an object in Extensible Provisioning Protocol (EPP). This + document provides a way to specify them as "organization" entities. + + This document describes an organization object mapping for version + 1.0 of the EPP [RFC5730]. This mapping is specified using XML 1.0 as + described in [W3C.REC-xml-20081126] 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", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + 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. + + The XML namespace prefix "org" is used for the namespace + "urn:ietf:params:xml:ns:epp:org-1.0", but implementations MUST NOT + depend on it; instead, they should employ a proper namespace-aware + XML parser and serializer to interpret and output the XML documents. + +3. Object Attributes + + An EPP organization 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. Standards Track [Page 3] + +RFC 8543 EPP Organization Mapping March 2019 + + +3.1. Organization Identifier + + All EPP organizations are identified by a server-unique identifier. + Organization identifiers are character strings with a specified + minimum length, a specified maximum length, and a specified format. + Organization identifiers use the "clIDType" client identifier syntax + described in [RFC5730]. The corresponding element is . + +3.2. Organization Roles + + The organization roles are used to represent the relationship an + organization could have. The corresponding element is . + An organization object MUST always have at least one associated role. + Roles can be set only by the client that sponsors an organization + object. A client can change the role of an organization object using + the EPP command (see Section 4.2.5). + +3.2.1. Role Type + + An organization role MUST have a type field, which may have any of + the values listed in Section 7.3. The corresponding element is + . An organization could have multiple roles with different + role types. + +3.2.2. Role Status + + A role of an organization object MAY have its own statuses. The + corresponding element is . The possible values for the + role status are defined in Section 3.5. + +3.2.3. Role Identifier + + A role MAY have a third-party-assigned identifier such as the IANA ID + for registrars. The corresponding element is . + + Example of organization role identifier: + + + registrar + ok + linked + 1362 + + + + + + + + + +Zhou, et al. Standards Track [Page 4] + +RFC 8543 EPP Organization Mapping March 2019 + + +3.3. Contact and Client Identifiers + + All EPP contacts are identified by server-unique identifiers. + Contact identifiers are character strings with a specified minimum + length, a specified maximum length, and a specified format. Contact + identifiers use the "clIDType" client identifier syntax described in + [RFC5730]. + +3.4. Organization Status Values + + An organization object MUST always have at least one associated + status value. Status values can be set only by the client that + sponsors an organization object and by the server on which the object + resides. A client can change the status of an organization object + using the EPP command. Each status value MAY be accompanied + by a string of human-readable text that describes the rationale for + the status applied to the object. + + A client MUST NOT alter server status values set by the server. A + server MAY alter or override status values set by a client, subject + to local server policies. The status of an object MAY change as a + result of either a client-initiated transform command or an action + performed by a server operator. + + Status values that can be added or removed by a client are prefixed + with "client". Corresponding server status values that can be added + or removed by a server are prefixed with "server". The "hold" and + "terminated" status values are server managed when the organization + has no parent identifier (Section 3.6) and otherwise MAY be client + managed based on server policy. Other status values that do not + begin with either "client" or "server" are server managed. + + Status Value Descriptions: + + o ok: This is the normal status value for an object that has no + operations pending or active prohibitions. This value is set and + removed by the server as other status values are added or removed. + + o hold: Organization transform commands and new links MUST be + rejected. + + o terminated: The organization that has been terminated MUST NOT be + linked. Organization transform commands and new links MUST be + rejected. + + + + + + + +Zhou, et al. Standards Track [Page 5] + +RFC 8543 EPP Organization Mapping March 2019 + + + o linked: The organization object has at least one active + association with another object. The "linked" status is not + explicitly set by the client. Servers should provide services to + determine existing object associations. + + o clientLinkProhibited, serverLinkProhibited: Requests to add new + links to the organization MUST be rejected. + + o clientUpdateProhibited, serverUpdateProhibited: Requests to update + the object (other than to remove this status) MUST be rejected. + + o clientDeleteProhibited, serverDeleteProhibited: Requests to delete + the object MUST be rejected. + + o pendingCreate, pendingUpdate, pendingDelete: A transform command + has been processed for the object, but the action has not been + completed by the server. Server operators can delay action + completion for a variety of reasons, such as to allow for human + review or third-party action. A transform command that is + processed, but whose requested action is pending, is noted with + response code 1001. + + "pendingCreate", "ok", "hold", and "terminated" are mutually + exclusive statuses. An organization MUST have exactly one of these + statuses set. + + "ok" status MAY only be combined with "linked" status. + + A client or server MAY combine "linked" with either + "clientLinkProhibited" or "serverLinkProhibited" if new links must be + prohibited. + + "pendingDelete" status MUST NOT be combined with either + "clientDeleteProhibited" or "serverDeleteProhibited" status. + + The "pendingCreate", "pendingDelete", and "pendingUpdate" status + values MUST NOT be combined with each other. + + If "clientUpdateProhibited" or "serverUpdateProhibited" is set, the + client will not be able to update the object. For + "clientUpdateProhibited", the client will first need to remove + "clientUpdateProhibited" prior to attempting to update the object. + The server can modify the object at any time. + + + + + + + + +Zhou, et al. Standards Track [Page 6] + +RFC 8543 EPP Organization Mapping March 2019 + + +3.5. Role Status Values + + A role SHOULD have at least one associated status value. Valid + values include "ok", "linked", "clientLinkProhibited", and + "serverLinkProhibited". + + Status Value Descriptions: + + o ok: This is the normal status value for a role that has no + operations pending or active prohibitions. This value is set and + removed by the server as other status values are added or removed. + + o linked: The role of an organization object has at least one active + association with another object. The "linked" status is not + explicitly set by the client. Servers SHOULD provide services to + determine existing object associations. + + o clientLinkProhibited, serverLinkProhibited: Requests to add new + links to the role MUST be rejected. + +3.6. Parent Identifier + + Organizations can have more than one layer. The parent identifier, + as defined with the element, represents the parent + organization identifier in a child organization. + + The case of reseller organizations provides an example. 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 MUST be prohibited. For example: if organization A has + organization B as its parent identifier, organization B cannot have + organization A as its parent identifier. The same is true for larger + loops involving three or more organizations. + +3.7. URL + + The URL represents the organization web home page, as defined with + the element. + + + + + + + + + + +Zhou, et al. Standards Track [Page 7] + +RFC 8543 EPP Organization Mapping March 2019 + + +3.8. Dates and Times + + Date and time attribute values MUST be represented in Coordinated + Universal Time (UTC) using the Gregorian calendar. The extended + date-time form using uppercase "T" and "Z" characters defined in + [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time + values, as XML Schema does not support truncated date-time forms or + lowercase "T" and "Z" characters. + +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 organization information via EPP. + +4.1. EPP Query Commands + + EPP provides two commands to retrieve organization information: + to determine if an organization object can be provisioned + within a repository and to retrieve detailed information + associated with an organization object. This document does not + define a mapping for the EPP command to retrieve + organization-object transfer status information. + +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 an element. This element or its ancestor + element MUST identify the organization namespace + "urn:ietf:params:xml:ns:epp:org-1.0". The element + contains the following child elements: + + o One or more elements that contain the server-unique + identifier of the organization objects to be queried. + + + + + + + + + + +Zhou, et al. Standards Track [Page 8] + +RFC 8543 EPP Organization Mapping March 2019 + + + 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. This + element or its ancestor element MUST identify the organization + namespace "urn:ietf:params:xml:ns:epp:org-1.0". The + element contains one or more elements that contain the + following child elements: + + o An 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. + + 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 as defined in [RFC5646] may be present to identify the + language if the negotiated value is something other than the + default value of "en"(English). + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 9] + +RFC 8543 EPP Organization Mapping March 2019 + + + 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 an organization object. In addition to the standard EPP command + elements, the command MUST contain an element. + This element or its ancestor element MUST identify the organization + namespace "urn:ietf:params:xml:ns:epp:org-1.0". The + element contains the following child element: + + o An element that contains the server-unique identifier of + the organization object to be queried. + + + + + + + +Zhou, et al. Standards Track [Page 10] + +RFC 8543 EPP Organization Mapping March 2019 + + + 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. This + element or its ancestor element MUST identify the organization + namespace "urn:ietf:params:xml:ns:epp:org-1.0". The + element contains the following child elements: + + o An element that contains the server-unique identifier of + the organization object, as defined in Section 3.1. + + o An element that contains the Repository Object + Identifier assigned to the organization object when the object was + created. + + o One or more elements that contain the role type, role + statuses, and optional role ID of the organization. + + * An element that contains the type of the + organization, as defined in Section 3.2. + + * One or more elements that contain the role + statuses. The values of the role status are defined in + Section 3.5. + + * An OPTIONAL element that contains a third-party- + assigned identifier, such as IANA ID for registrars, as defined + in Section 3.2.3. + + o One or more elements that contain the operational + status of the organization, as defined in Section 3.4. + + o An OPTIONAL element that contains the identifier of + the parent object, as defined in Section 3.6. + + + + +Zhou, et al. Standards Track [Page 11] + +RFC 8543 EPP Organization Mapping March 2019 + + + o Zero to 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 Unicode + [UNICODE] in the range U+0020 - U+007E. If a localized form + (type="loc") is provided, element content MAY be represented in + unrestricted UTF-8. The element contains the + following child elements: + + * An element that contains the name of the + organization. + + * An OPTIONAL element that contains address + information associated with the organization. An + element contains the following child elements: + + + One, two, or three elements that contain the + organization's street address. + + + An element that contains the organization's city. + + + An OPTIONAL element that contains the + organization's state or province. + + + An OPTIONAL element that contains the + organization's postal code. + + + An element that contains the alpha-2 organization's + country code. The detailed format of this element is + described in Section 2.4.3 of [RFC5733]. + + o An OPTIONAL element that contains the organization's + voice telephone number. The detailed format of this element is + described in Section 2.5 of [RFC5733]. + + o An OPTIONAL element that contains the organization's + facsimile telephone number. The detailed format of this element + is described in Section 2.5 of [RFC5733]. + + o An OPTIONAL element that contains the organization's + email address. The detailed format of this element is described + in [RFC5322]. + + o An OPTIONAL element that contains the URL to the website + of the organization. The detailed format of this element is + described in [RFC3986]. + + + +Zhou, et al. Standards Track [Page 12] + +RFC 8543 EPP Organization Mapping March 2019 + + + o Zero or more elements that contain identifiers for + the contact objects to be associated with the organization object. + Contact object identifiers MUST be known to the server before the + contact object can be associated with the organization object. + The required "type" is used to represent contact types. The type + values include "admin", "tech", "billing", "abuse", and "custom". + The OPTIONAL "typeName" attribute is used to define the name of a + "custom" type. + + o An OPTIONAL element that contains the organization + identifier of the sponsoring client. There is no + element if the organization is managed by the registry. + + o An element that contains the identifier of the client + that created the organization object. + + o An element that contains the date and time of + organization object creation. + + o An element that contains the identifier of the client + that last updated the organization object. This element MUST NOT + be present if the organization has never been modified. + + o An element that contains the date and time of the + most recent organization object modification. This element MUST + NOT be present if the organization object has never been modified. + + Example response for "Example Registrar Inc." organization + object with identifier "registrar1362": + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: registrar1362 + S: registrar1362-REP + S: + S: registrar + S: ok + S: linked + S: 1362 + S: + S: ok + + + +Zhou, et al. Standards Track [Page 13] + +RFC 8543 EPP Organization Mapping March 2019 + + + S: + S: Example Registrar 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@organization.example + S: https://organization.example + S: sh8013 + S: sh8013 + S: sh8013 + S: ClientX + S: 2018-04-03T22:00:00.0Z + S: ClientX + S: 2018-12-03T09:00:00.0Z + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + Example response for "Example Reseller Inc." organization + object of reseller type managed by identifier "registrar1362": + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: reseller1523 + S: reseller1523-REP + S: + S: reseller + + + +Zhou, et al. Standards Track [Page 14] + +RFC 8543 EPP Organization Mapping March 2019 + + + S: ok + S: linked + S: + S: ok + S: registrar1362 + 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: https://organization.example + S: sh8013 + S: 1362 + S: ClientX + S: 2018-04-03T22:00:00.0Z + S: ClientX + S: 2018-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. + +4.1.3. EPP Query Command + + The transfer semantics do not apply to organization objects. No EPP + query command is defined in this document. + + + + + + + + + + + +Zhou, et al. Standards Track [Page 15] + +RFC 8543 EPP Organization Mapping March 2019 + + +4.2. EPP Transform Commands + + This document provides three commands to transform organization + object information: to create an instance of an organization + object, to delete an instance of an organization object, and + to change information associated with an organization + 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, the client MUST be notified using a + service message that the action has been completed and 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 an organization object. In addition to the standard + EPP command elements, the command MUST contain an + element. This element or its ancestor element MUST + identify the organization namespace "urn:ietf:params:xml:ns:epp:org- + 1.0". The element contains the following child + elements: + + o An element that contains the desired server-unique + identifier for the organization to be created, as defined in + Section 3.1. + + o One or more elements that contain the role type, role + statuses, and optional role ID of the organization. + + * An element that contains the type of the + organization, as defined in Section 3.2. + + * Zero or more elements that contain the role + statuses. The possible values of the role statuses are defined + in Section 3.5. + + + + + +Zhou, et al. Standards Track [Page 16] + +RFC 8543 EPP Organization Mapping March 2019 + + + * An OPTIONAL element that contains a third-party- + assigned identifier, such as IANA ID for registrars, as defined + in Section 3.2.3. + + o Zero or more elements that contain the operational + status of the organization, as defined in Section 3.4. + + o An OPTIONAL element that contains the identifier of + the parent object, as defined in Section 3.6. + + o Zero to 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 Unicode + [UNICODE] in the range U+0020 - U+007E. If a localized form + (type="loc") is provided, element content MAY be represented in + unrestricted UTF-8. The element contains the + following child elements: + + * An element that contains the name of the + organization. + + * An OPTIONAL element that contains address + information associated with the organization. An + element contains the following child elements: + + + One, two, or three elements that contain the + organization's street address. + + + An element that contains the organization's city. + + + An OPTIONAL element that contains the + organization's state or province. + + + An OPTIONAL element that contains the + organization's postal code. + + + An element that contains the alpha-2 organization's + country code. The detailed format of this element is + described in Section 2.4.3 of [RFC5733]. + + o An OPTIONAL element that contains the organization's + voice telephone number. The detailed format of this element is + described in Section 2.5 of [RFC5733]. + + + + + +Zhou, et al. Standards Track [Page 17] + +RFC 8543 EPP Organization Mapping March 2019 + + + o An OPTIONAL element that contains the organization's + facsimile telephone number. The detailed format of this element + is described in Section 2.5 of [RFC5733]. + + o An OPTIONAL element that contains the organization's + email address. The detailed format of this element is described + of [RFC5322]. + + o An OPTIONAL element that contains the URL to the website + of the organization. The detailed format of this element is + described in [RFC3986]. + + o Zero or more elements that contain identifiers for + the contact objects associated with the organization object. + + Example command: + + C: + C: + C: + C: + C: + C: res1523 + C: + C: reseller + C: + C: 1523res + C: + C: Example Organization 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@organization.example + C: https://organization.example + C: sh8013 + C: sh8013 + C: + C: + C: ABC-12345 + + + +Zhou, et al. Standards Track [Page 18] + +RFC 8543 EPP Organization Mapping March 2019 + + + C: + C: + + When a command has been processed successfully, the EPP + element MUST contain a child element. This + element or its ancestor element MUST identify the organization + namespace "urn:ietf:params:xml:ns:epp:org-1.0". The + element contains the following child elements: + + o An element that contains the server-unique identifier for + the created organization, as defined in Section 3.1. + + o An element that contains the date and time of + organization-object creation. + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: res1523 + S: 2018-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. + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 19] + +RFC 8543 EPP Organization Mapping March 2019 + + +4.2.2. EPP Command + + The EPP command provides a transform operation that allows a + client to delete an organization object. In addition to the standard + EPP command elements, the command MUST contain an + element. This element or its ancestor element MUST + identify the organization namespace "urn:ietf:params:xml:ns:epp:org- + 1.0". The element MUST contain the following child + element: + + o An element that contains the server-unique identifier of + the organization object to be deleted, as defined in Section 3.1. + + An organization object MUST NOT be deleted if it is associated with + other known objects. An associated organization MUST NOT be deleted + until associations with other known objects have been broken. A + server MUST 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. + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 20] + +RFC 8543 EPP Organization Mapping March 2019 + + + 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. + +4.2.3. EPP Command + + Renewal semantics do not apply to organization objects, so there is + no mapping defined for the EPP command. + +4.2.4. EPP Command + + Transfer semantics do not apply to organization 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 an organization object. In + addition to the standard EPP command elements, the command + MUST contain an element. This element or its ancestor + element MUST identify the organization namespace + "urn:ietf:params:xml:ns:epp:org-1.0". The element + contains the following child elements: + + o An element that contains the server-unique identifier of + the organization 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. + + + + + +Zhou, et al. Standards Track [Page 21] + +RFC 8543 EPP Organization Mapping March 2019 + + + 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 OPTIONAL + and elements contain the following child + elements: + + o Zero or more elements that contain the identifiers + for contact objects to be associated with or removed from the + organization object. Contact object identifiers MUST be known to + the server before the contact object can be associated with the + organization object. + + o Zero or more elements that contain the role type, role + statuses, and optional role ID of the organization. + + * An element that contains the role type of the + organization, as defined in Section 3.2. The role type + uniquely identifies the role to update. + + * Zero or more elements that contain the role + statuses. The values of the role status are defined in + Section 3.5. + + * An OPTIONAL element that contains a third-party- + assigned identifier, such as IANA ID for registrars, as defined + in Section 3.2.3. + + o Zero or more elements that contain the operational + status of the organization. + + An OPTIONAL element contains the following child elements, + where at least one child element MUST be present: + + o An OPTIONAL element that contains the identifier of + the parent object. + + o Zero to 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 Unicode + [UNICODE] in the range U+0020 - U+007E. If a localized form + (type="loc") is provided, element content MAY be represented in + unrestricted UTF-8. The change of the postal info is defined as a + + + +Zhou, et al. Standards Track [Page 22] + +RFC 8543 EPP Organization Mapping March 2019 + + + replacement of that postal info element with the contents of the + sub-elements included in the command. An empty + element is supported to allow a type of postal + info to be removed. The element contains the + following child elements: + + * An element that contains the name of the + organization. + + * An OPTIONAL element that contains address + information associated with the organization. An + element contains the following child elements: + + + One, two, or three elements that contain the + organization's street address. + + + An element that contains the organization's city. + + + An OPTIONAL element that contains the + organization's state or province. + + + An OPTIONAL element that contains the + organization's postal code. + + + An element that contains the alpha-2 organization's + country code. The detailed format of this element is + described in Section 2.4.3 of [RFC5733]. + + o An OPTIONAL element that contains the organization's + voice telephone number. The detailed format of this element is + described in Section 2.5 of [RFC5733]. + + o An OPTIONAL element that contains the organization's + facsimile telephone number. The detailed format of this element + is described in Section 2.5 of [RFC5733]. + + o An OPTIONAL element that contains the organization's + email address. The detailed format of this element is described + in [RFC5322]. + + o An OPTIONAL element that contains the URL to the website + of the organization. The detailed format of this element is + described in [RFC3986]. + + + + + + + + +Zhou, et al. Standards Track [Page 23] + +RFC 8543 EPP Organization Mapping March 2019 + + + Example command: + + C: + C: + C: + C: + C: + C: res1523 + C: + C: sh8013 + C: + C: privacyproxy + C: clientLinkProhibited + C: + C: clientLinkProhibited + C: + C: + C: sh8014 + C: + C: reseller + C: + C: + C: + 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: ABC-12345 + C: + C: + + When an command has been processed successfully, a server + MUST respond with an EPP response with no element. + + + + + + +Zhou, et al. Standards Track [Page 24] + +RFC 8543 EPP Organization Mapping March 2019 + + + 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 an command cannot + be processed for any reason. + +4.3. Offline Review of Requested Actions + + Commands are processed by a server in the order they are received + from a client. Though an immediate response confirming receipt and + processing of the command is produced by the server, a server + operator MAY perform an offline review of requested transform + commands before completing the requested action. In such situations, + the response from the server MUST clearly note that the transform + command has been received and processed, but the requested action is + pending. The status in the response of the corresponding object MUST + clearly reflect processing of the pending action. The server MUST + notify the client when offline processing of the action has been + completed. + + Examples describing a command that requires offline review + are included here. Note the result code and message returned in + response to the command. + + S: + S: + S: + S: + S: Command completed successfully; + S: action pending + S: + S: + S: + S: res1523 + S: 2018-04-03T22:00:00.0Z + + + +Zhou, et al. Standards Track [Page 25] + +RFC 8543 EPP Organization Mapping March 2019 + + + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + The status of the organization object after returning this response + MUST include "pendingCreate". The server operator reviews the + request offline and informs the client of the outcome of the review + by queuing a service message for retrieval via the command; it + MAY additionally use an out-of-band mechanism to inform the client of + the outcome. + + The service message MUST contain text that describes the notification + in the child element of the response element. In + addition, the EPP element MUST contain a child + element. This element or its ancestor element MUST + identify the organization namespace "urn:ietf:params:xml:ns:epp:org- + 1.0". The element contains the following child + elements: + + o An element that contains the server-unique identifier of + the organization object. The element contains a REQUIRED + "paResult" attribute. A positive boolean value indicates that the + request has been approved and completed. A negative boolean value + indicates that the request has been denied and the requested + action has not been taken. + + o An element that contains the client transaction + identifier and server transaction identifier returned with the + original response to process the command. The client transaction + identifier is OPTIONAL and will only be returned if the client + provided an identifier with the original command. + + o An element that contains the date and time describing + when review of the requested action was completed. + + Example "review completed" service message: + + S: + S: + S: + S: + S: Command completed successfully; + S: ack to dequeue + + + +Zhou, et al. Standards Track [Page 26] + +RFC 8543 EPP Organization Mapping March 2019 + + + S: + S: + S: 2018-04-04T22:01:00.0Z + S: Pending action completed successfully. + S: + S: + S: + S: res1523 + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: 2018-04-04T22:00:00.0Z + S: + S: + S: + S: BCD-23456 + S: 65432-WXY + S: + S: + S: + +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 + + + + + + + + + + + +Zhou, et al. Standards Track [Page 27] + +RFC 8543 EPP Organization Mapping March 2019 + + + + + Extensible Provisioning Protocol v1.0 + organization provisioning schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 28] + +RFC 8543 EPP Organization Mapping March 2019 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 29] + +RFC 8543 EPP Organization Mapping March 2019 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 30] + +RFC 8543 EPP Organization Mapping March 2019 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 31] + +RFC 8543 EPP Organization Mapping March 2019 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 32] + +RFC 8543 EPP Organization Mapping March 2019 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 33] + +RFC 8543 EPP Organization Mapping March 2019 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 34] + +RFC 8543 EPP Organization Mapping March 2019 + + + + + + + + + + + + + + + + + + + + + + + + + + + END + + + + + + + + +Zhou, et al. Standards Track [Page 35] + +RFC 8543 EPP Organization Mapping March 2019 + + +6. Internationalization Considerations + + EPP is represented in XML, which provides native support for encoding + information using the Unicode character set [UNICODE] and its more + compact representations, including UTF-8. Conformant XML processors + recognize both UTF-8 [RFC3629] and UTF-16 [RFC2781]. 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 organization 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 has + assigned the following URI. + + The organization namespace: + + URI: urn:ietf:params:xml:ns:epp:org-1.0 + + Registrant Contact: IESG + + XML: None. Namespace URIs do not represent an XML specification. + + The organization XML schema: + + URI: urn:ietf:params:xml:schema:epp:org-1.0 + + Registrant Contact: IESG + + XML: See the "Formal Syntax" section of RFC 8543 (this document). + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 36] + +RFC 8543 EPP Organization Mapping March 2019 + + +7.2. EPP Extension Registry + + The EPP extension described in this document has been registered by + IANA in the "Extensions for the Extensible Provisioning Protocol + (EPP)" registry described in [RFC7451]. The details of the + registration are as follows: + + Name of Extension: Extensible Provisioning Protocol (EPP) + Organization Mapping + + Document status: Standards Track + + Reference: RFC 8543 + + Registrant Name and Email Address: IESG, iesg@ietf.org + + TLDs: Any + + IPR Disclosure: None + + Status: Active + + Notes: None + +7.3. Role Type Values Registry + + IANA has created a new category of protocol registry for values of + the organization roles. The name of this registry is "EPP + Organization Role Values". The registration policy for this registry + is "Expert Review" [RFC8126]. + +7.3.1. Registration Template + + Value: The string value being registered. + + Description: Brief description of the organization role values. + + Registrant Name: For RFC specifications, state "IESG". For other + specifications, give the name of the responsible party. + + Registrant Contact Information: An email address, postal address, or + some other information to be used to contact the registrant. + + + + + + + + + +Zhou, et al. Standards Track [Page 37] + +RFC 8543 EPP Organization Mapping March 2019 + + +7.3.2. Initial Registry Contents + + The following are the initial registry contents: + + Value: registrar + + Description: The entity object instance represents the authority + responsible for the registration in the registry. + + Registrant: IESG, iesg@ietf.org + + Value: reseller + + Description: The entity object instance represents a third party + through which the registration was conducted (i.e., not the + registry or registrar). + + Registrant: IESG, iesg@ietf.org + + Value: privacyproxy + + Description: The entity object instance represents a third party + who could help to register a domain without exposing the + registrants' private information. + + Registrant: IESG, iesg@ietf.org + + Value: dns-operator + + Description: The entity object instance represents a third-party + DNS operator that maintains the name servers and zone data on + behalf of a registrant. + + Registrant: IESG, iesg@ietf.org + +8. Security Considerations + + The organization object may have personally identifiable information, + such as . This information is not a required element in + this document that can be provided on a voluntary basis. If it is + provided, both client and server MUST ensure that authorization + information is stored and exchanged with high-grade encryption + mechanisms to provide privacy services, which are specified in + [RFC5733]. The security considerations described in [RFC5730] or + those caused by the protocol layers used by EPP will apply to this + specification as well. + + + + + +Zhou, et al. Standards Track [Page 38] + +RFC 8543 EPP Organization Mapping March 2019 + + +9. References + +9.1. 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, + . + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, . + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + . + + [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying + Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, + September 2009, . + + [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, . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + + + + +Zhou, et al. Standards Track [Page 39] + +RFC 8543 EPP Organization Mapping March 2019 + + + [UNICODE] The Unicode Consortium, "The Unicode Standard", + . + + [W3C.REC-xml-20081126] + Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and + F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth + Edition)", World Wide Web Consortium Recommendation + REC-xml-20081126, November 2008, + . + + [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, + . + +9.2. Informative References + + [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO + 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, + . + + [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible + Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, + February 2015, . + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 40] + +RFC 8543 EPP Organization Mapping March 2019 + + +Acknowledgments + + The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick + Mevzek, Antoin Verschuren, and Scott Hollenbeck for their careful + review and valuable comments. + +Authors' Addresses + + Linlin Zhou + CNNIC + 4 South 4th Street, Zhongguancun, Haidian District + Beijing, Beijing 100190 + China + + Email: zhoulinlin@cnnic.cn + + + Ning Kong + Consultant + + Email: ietfing@gmail.com + + + Jiankang Yao + CNNIC + 4 South 4th Street, Zhongguancun, Haidian District + Beijing, Beijing 100190 + China + + Email: yaojk@cnnic.cn + + + James Gould + VeriSign, Inc. + 12061 Bluemont Way + Reston, VA 20190 + United States of America + + Email: jgould@verisign.com + URI: http://www.verisign.com + + + Guiqing Zhou + + Email: qing.joe@gmail.com + + + + + + +Zhou, et al. Standards Track [Page 41] + -- cgit v1.2.3