diff options
Diffstat (limited to 'doc/rfc/rfc8544.txt')
| -rw-r--r-- | doc/rfc/rfc8544.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc8544.txt b/doc/rfc/rfc8544.txt new file mode 100644 index 0000000..d3bec94 --- /dev/null +++ b/doc/rfc/rfc8544.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Zhou +Request for Comments: 8544 CNNIC +Category: Standards Track N. Kong +ISSN: 2070-1721 Consultant + J. Wei + J. Yao + CNNIC + J. Gould + VeriSign, Inc. + April 2019 + + + Organization Extension for the Extensible Provisioning Protocol (EPP) + +Abstract + + This document describes an extension to Extensible Provisioning + Protocol (EPP) object mappings that is designed to support assigning + an organization to any existing object (domain, host, contact) as + well as any future objects. + +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/rfc8544. + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 1] + +RFC 8544 Organization Extension for the EPP April 2019 + + +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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4 + 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 + 4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 4 + 4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 4 + 4.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 8 + 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8 + 4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 8 + 4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 10 + 4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 10 + 4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 11 + 4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 11 + 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6. Internationalization Considerations . . . . . . . . . . . . . 18 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 18 + 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 19 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 9.2. Informative References . . . . . . . . . . . . . . . . . 21 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + + + + + + + + +Zhou, et al. Standards Track [Page 2] + +RFC 8544 Organization Extension for the EPP April 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 are supported in the Extensible + Provisioning Protocol (EPP) by the "organization" entities in + [RFC8543]. This document provides a way to associate any EPP object + such as domain names in [RFC5731], hosts in [RFC5732], and contacts + in [RFC5733] to "organization" entities in [RFC8543]. The examples + provided in this document are used for the domain object for + illustration purposes. The host and contact object could be extended + in the same way as the domain object. + + Organization object identifiers, defined in [RFC8543], MUST be known + to the server before the organization object can be associated with + the EPP object. + + This document 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 "orgext" is used for the namespace + "urn:ietf:params:xml:ns:epp:orgext-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 + + This extension adds additional elements to EPP object mappings such + as the EPP domain name mapping [RFC5731]. Only the new elements are + described here. + + + +Zhou, et al. Standards Track [Page 3] + +RFC 8544 Organization Extension for the EPP April 2019 + + +3.1. Organization Identifier + + The organization identifier provides the ID of an organization. Its + corresponding element is <orgext:id>, which refers to the <org:id> + element defined in [RFC8543]. All organization objects are + identified by a server-unique identifier. A "role" attribute is used + to represent the relationship that the organization has to the EPP + object. Any given object MUST have at most one associated + organization ID for any given role value. + +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 assigning organizations + to EPP objects. + +4.1. EPP Query Commands + + EPP provides three commands to retrieve EPP object information: + <check> to determine if an object can be provisioned within a + repository, <info> to retrieve detailed information associated with + an object, and <transfer> to retrieve object transfer status + information. + +4.1.1. EPP <check> Command + + This extension does not add any elements to the EPP <check> command + or <check> response described in the EPP object mapping. + +4.1.2. EPP <info> Command + + This extension does not add any elements to the EPP <info> command + described in the EPP object mapping. However, additional elements + are defined for the <info> response in the EPP object mapping. + + When an <info> command has been processed successfully, the EPP + <resData> element MUST contain child elements as described in the EPP + object extensions. In addition, the EPP <extension> element SHOULD + contain a child <orgext:infData> element. This element is returned + if the object has data that is associated with this extension and + that is based on server policy. This element or its ancestor element + + + + + + + + + +Zhou, et al. Standards Track [Page 4] + +RFC 8544 Organization Extension for the EPP April 2019 + + + MUST identify the extension namespace + "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:infData> + element contains the following child elements: + + o Zero or more <orgext:id> elements are allowed that contain the + identifier of the organization, as defined in Section 3.1. The + "role" attribute is used to represent the relationship that the + organization has to the object. See Section 7.3 of [RFC8543] for + a list of values. + + Example <info> response for an authorized client with multiple + organizations: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 5] + +RFC 8544 Organization Extension for the EPP April 2019 + + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1000"> + S: <msg lang="en-US">Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:infData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:roid>EXAMPLE1-REP</domain:roid> + S: <domain:status s="ok"/> + S: <domain:registrant>jd1234</domain:registrant> + S: <domain:contact type="admin">sh8013</domain:contact> + S: <domain:contact type="billing">sh8013</domain:contact> + S: <domain:contact type="tech">sh8013</domain:contact> + S: <domain:ns> + S: <domain:hostObj>ns1.example.com</domain:hostObj> + S: </domain:ns> + S: <domain:clID>ClientX</domain:clID> + S: <domain:crID>ClientY</domain:crID> + S: <domain:crDate>2015-02-06T04:01:21.0Z</domain:crDate> + S: <domain:exDate>2018-02-06T04:01:21.0Z</domain:exDate> + S: <domain:authInfo> + S: <domain:pw>2fooBAR</domain:pw> + S: </domain:authInfo> + S: </domain:infData> + S: </resData> + S: <extension> + S: <orgext:infData + S: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + S: <orgext:id role="reseller">reseller1523</orgext:id> + S: <orgext:id role="privacyproxy">proxy2935</orgext:id> + S: </orgext:infData> + S: </extension> + S: <trID> + S: <clTRID>ngcl-IvJjzMZc</clTRID> + S: <svTRID>test142AWQONJZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + + + + + + + + + +Zhou, et al. Standards Track [Page 6] + +RFC 8544 Organization Extension for the EPP April 2019 + + + Example <info> response for an authorized client with no + organization: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1000"> + S: <msg lang="en-US">Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:infData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:roid>EXAMPLE1-REP</domain:roid> + S: <domain:status s="ok"/> + S: <domain:registrant>jd1234</domain:registrant> + S: <domain:contact type="admin">sh8013</domain:contact> + S: <domain:contact type="billing">sh8013</domain:contact> + S: <domain:contact type="tech">sh8013</domain:contact> + S: <domain:ns> + S: <domain:hostObj>ns1.example.com</domain:hostObj> + S: </domain:ns> + S: <domain:clID>ClientX</domain:clID> + S: <domain:crID>ClientY</domain:crID> + S: <domain:crDate>2015-02-06T04:01:21.0Z</domain:crDate> + S: <domain:exDate>2018-02-06T04:01:21.0Z</domain:exDate> + S: <domain:authInfo> + S: <domain:pw>2fooBAR</domain:pw> + S: </domain:authInfo> + S: </domain:infData> + S: </resData> + S: <extension> + S: <orgext:infData + S: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"/> + S: </extension> + S: <trID> + S: <clTRID>ngcl-IvJjzMZc</clTRID> + S: <svTRID>test142AWQONJZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + An EPP error response MUST be returned if an <info> command cannot be + processed for any reason. + + + + + + + +Zhou, et al. Standards Track [Page 7] + +RFC 8544 Organization Extension for the EPP April 2019 + + +4.1.3. EPP <transfer> Query Command + + This extension does not add any elements to the EPP <transfer> query + command or <transfer> query response described in the EPP object + mapping. + +4.2. EPP Transform Commands + + EPP provides five commands to transform EPP objects: <create> to + create an instance of an object, <delete> to delete an instance of an + object, <renew> to extend the validity period of an object, + <transfer> to manage the object sponsorship changes, and <update> to + change information associated with an object. + +4.2.1. EPP <create> Command + + This extension defines additional elements for the EPP <create> + command described in the EPP object extensions. No additional + elements are defined for the EPP <create> response. + + The EPP <create> command provides a transform operation that allows a + client to create an object. In addition to the EPP command elements + described in the EPP object extensions, the command MUST contain an + <extension> element, and the <extension> element MUST contain a child + <orgext:create> element. This element is used if the client wants to + associate data defined in this extension to the object. This element + or its ancestor element MUST identify the extension namespace + "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:create> element + contains the following child elements: + + o One or more <orgext:id> elements that contain the identifier of + the organization, as defined in Section 3.1. The "role" attribute + is used to represent the relationship that the organization has to + the object. See Section 7.3 of [RFC8543] for a list of values. + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 8] + +RFC 8544 Organization Extension for the EPP April 2019 + + + Example <create> command with only one organization: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <create> + C: <domain:create + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: <domain:period unit="y">3</domain:period> + C: <domain:ns> + C: <domain:hostObj>ns1.example.com</domain:hostObj> + C: </domain:ns> + C: <domain:registrant>jd1234</domain:registrant> + C: <domain:contact type="tech">sh8013</domain:contact> + C: <domain:contact type="billing">sh8013</domain:contact> + C: <domain:contact type="admin">sh8013</domain:contact> + C: <domain:authInfo> + C: <domain:pw>fooBAR</domain:pw> + C: </domain:authInfo> + C: </domain:create> + C: </create> + C: <extension> + C: <orgext:create + C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + C: <orgext:id role="reseller">reseller1523</orgext:id> + C: </orgext:create> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 9] + +RFC 8544 Organization Extension for the EPP April 2019 + + + Example <create> command with multiple organizations: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <create> + C: <domain:create + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: <domain:period unit="y">3</domain:period> + C: <domain:ns> + C: <domain:hostObj>ns1.example.com</domain:hostObj> + C: </domain:ns> + C: <domain:registrant>jd1234</domain:registrant> + C: <domain:contact type="tech">sh8013</domain:contact> + C: <domain:contact type="billing">sh8013</domain:contact> + C: <domain:contact type="admin">sh8013</domain:contact> + C: <domain:authInfo> + C: <domain:pw>fooBAR</domain:pw> + C: </domain:authInfo> + C: </domain:create> + C: </create> + C: <extension> + C: <orgext:create + C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + C: <orgext:id role="reseller">reseller1523</orgext:id> + C: <orgext:id role="privacyproxy">proxy2935</orgext:id> + C: </orgext:create> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + When a <create> command has been processed successfully, the EPP + response is as described in the EPP object extension. + + An EPP error response MUST be returned if a <create> command cannot + be processed for any reason. + +4.2.2. EPP <delete> Command + + This extension does not add any elements to the EPP <delete> command + or <delete> response described in the EPP object mapping. + +4.2.3. EPP <renew> Command + + This extension does not add any elements to the EPP <renew> command + or <renew> response described in the EPP object mapping. + + + +Zhou, et al. Standards Track [Page 10] + +RFC 8544 Organization Extension for the EPP April 2019 + + +4.2.4. EPP <transfer> Command + + This extension does not add any elements to the EPP <transfer> + command or <transfer> response described in the EPP object mapping, + but after a successful transfer of an object with an assigned + organization, the handling of the assigned organization is dependent + on the organization roles and server policy. + +4.2.5. EPP <update> Command + + This extension defines additional elements for the EPP <update> + command described in the EPP domain mapping [RFC5731], host mapping + [RFC5732], and contact mapping [RFC5733]. No additional elements are + defined for the EPP <update> response. + + The EPP <update> command provides a transform operation that allows a + client to modify the attributes of an object. In addition to the EPP + <update> command elements, the command MUST contain an <extension> + element, and the <extension> element MUST contain a child + <orgext:update> element. This element is used if the client wants to + update the object with data defined in this extension. This element + or its ancestor element MUST identify the extension namespace + "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:update> element + contains the following child elements: + + o An OPTIONAL <orgext:add> element that contains one or more + <orgext:id> elements, as defined in Section 3.1, that add + nonexistent organization roles to the object. The <orgext:id> + element MUST have a non-empty organization identifier value. The + server SHOULD validate that the <orgext:id> element role does not + exist. + + o An OPTIONAL <orgext:rem> element that contains one or more + <orgext:id> elements, as defined in Section 3.1, that remove + organization roles from the object. The <orgext:id> element MAY + have an empty organization identifier value. The server SHOULD + validate the existence of the <orgext:id> element role and the + organization identifier if provided. + + o An OPTIONAL <orgext:chg> element that contains one or more + <orgext:id> elements, as defined in Section 3.1, that change + organization role identifiers for the object. The existing + organization identifier value will be replaced for the defined + role. The server SHOULD validate the existence of the <orgext:id> + element role. + + At least one <orgext:add>, <orgext:rem>, or <orgext:chg> element MUST + be provided. + + + +Zhou, et al. Standards Track [Page 11] + +RFC 8544 Organization Extension for the EPP April 2019 + + + Example <update> command, adding a reseller: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <orgext:update + C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + C: <orgext:add> + C: <orgext:id role="reseller">reseller1523</orgext:id> + C: </orgext:add> + C: </orgext:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + Example <update> command, adding multiple organizations: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <orgext:update + C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + C: <orgext:add> + C: <orgext:id role="reseller">reseller1523</orgext:id> + C: <orgext:id role="privacyproxy">proxy2935</orgext:id> + C: </orgext:add> + C: </orgext:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + +Zhou, et al. Standards Track [Page 12] + +RFC 8544 Organization Extension for the EPP April 2019 + + + Example <update> command, removing a reseller: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <orgext:update + C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + C: <orgext:rem> + C: <orgext:id role="reseller"/> + C: </orgext:rem> + C: </orgext:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + Example <update> command, removing multiple organizations: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <orgext:update + C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + C: <orgext:rem> + C: <orgext:id role="reseller"/> + C: <orgext:id role="privacyproxy"/> + C: </orgext:rem> + C: </orgext:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + +Zhou, et al. Standards Track [Page 13] + +RFC 8544 Organization Extension for the EPP April 2019 + + + Example <update> command, updating reseller identifier: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <orgext:update + C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + C: <orgext:chg> + C: <orgext:id role="reseller">reseller1523</orgext:id> + C: </orgext:chg> + C: </orgext:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + Example <update> command, updating multiple organization identifiers: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <orgext:update + C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"> + C: <orgext:chg> + C: <orgext:id role="reseller">reseller1523</orgext:id> + C: <orgext:id role="privacyproxy">proxy2935</orgext:id> + C: </orgext:chg> + C: </orgext:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + +Zhou, et al. Standards Track [Page 14] + +RFC 8544 Organization Extension for the EPP April 2019 + + + When an extended <update> command has been processed successfully, + the EPP response is as described in the EPP object extension. + + An EPP error response MUST be returned if an <update> command cannot + be processed for any reason. An attempt to add one organization ID + or multiple organization IDs with a particular role value when at + least one of them already exists does not change the object at all. + A server SHOULD notify clients that object relationships exist by + sending a 2305 error response code. An attempt to remove an + organization ID or multiple organization IDs with a particular role + value when at least one of them does not exist does not change the + object at all. A server SHOULD notify clients that object + relationships do not exist by sending a 2305 error response code. An + attempt to change an organization ID or multiple organization IDs + with a particular role value when at least one of them does not exist + does not change the object at all. A server SHOULD notify clients + that object relationships do not exist by sending a 2305 error + response code. Response format with error value elements is defined + in Section 2.6 of [RFC5730]. + +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 + <?xml version="1.0" encoding="UTF-8"?> + + <schema + targetNamespace="urn:ietf:params:xml:ns:epp:orgext-1.0" + xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0" + xmlns="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" + > + + <annotation> + <documentation> + Extensible Provisioning Protocol v1.0 + Organization Extension Schema v1.0 + </documentation> + </annotation> + + + + + + +Zhou, et al. Standards Track [Page 15] + +RFC 8544 Organization Extension for the EPP April 2019 + + + <!-- Child elements found in EPP commands --> + <element + name="create" + type="orgext:createType"/> + <element + name="update" + type="orgext:updateType"/> + + <!-- + Organization identifier with required role + --> + <complexType name="orgIdType"> + <simpleContent> + <extension base="token"> + <attribute + name="role" + type="token" + use="required"/> + </extension> + </simpleContent> + </complexType> + + <!-- + Child elements of the <orgext:create> command. + All elements must be present at time of creation. + --> + <complexType name="createType"> + <sequence> + <!-- Agent identifier or the organization, + e.g., registrar, reseller, privacy proxy, etc. --> + <element + name="id" + type="orgext:orgIdType" + maxOccurs="unbounded"/> + </sequence> + </complexType> + + <!-- + Child elements of <orgext:update> command + --> + <complexType name="updateType"> + <sequence> + <element + name="add" + type="orgext:addRemChgType" + minOccurs="0" + /> + + + + +Zhou, et al. Standards Track [Page 16] + +RFC 8544 Organization Extension for the EPP April 2019 + + + <element + name="rem" + type="orgext:addRemChgType" + minOccurs="0" + /> + <element + name="chg" + type="orgext:addRemChgType" + minOccurs="0" + /> + </sequence> + </complexType> + + <complexType name="addRemChgType"> + <sequence> + <!-- Agent identifier of the organization, + e.g., registrar, reseller, privacy proxy, etc. --> + <element + name="id" + type="orgext:orgIdType" + maxOccurs="unbounded"/> + </sequence> + </complexType> + + <!-- Child response element --> + <element + name="infData" + type="orgext:infDataType"/> + + <!-- <orgext:infData> response elements --> + <complexType name="infDataType"> + <sequence> + <!-- Agent identifier the organization, + e.g., registrar, reseller, privacy proxy, etc. --> + <element + name="id" + type="orgext:orgIdType" + minOccurs="0" + maxOccurs="unbounded"/> + </sequence> + </complexType> + + <!-- End of schema --> + </schema> + END + + + + + + +Zhou, et al. Standards Track [Page 17] + +RFC 8544 Organization Extension for the EPP April 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 <?xml?> declaration, use + of UTF-8 is RECOMMENDED. + + As an extension of the EPP 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 extension namespace: + + URI: urn:ietf:params:xml:ns:epp:orgext-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:orgext-1.0 + + Registrant Contact: IESG + + XML: See the "Formal Syntax" section of RFC 8544 (this document). + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 18] + +RFC 8544 Organization Extension for the EPP April 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: Organization Extension for the Extensible + Provisioning Protocol (EPP) + + Document Status: Standards Track + + Reference: RFC 8544 + + Registrant Name and Email Address: IESG, iesg@ietf.org + + TLDs: Any + + IPR Disclosure: None + + Status: Active + + Notes: None + +8. Security Considerations + + The object mapping extension described in this document does not + provide any other security services or introduce any additional + considerations beyond those described by [RFC5730], [RFC5731], + [RFC5732], and [RFC5733] or those caused by the protocol layers used + by EPP. + +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, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, <https://www.rfc-editor.org/info/rfc3629>. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + <https://www.rfc-editor.org/info/rfc3688>. + + + +Zhou, et al. Standards Track [Page 19] + +RFC 8544 Organization Extension for the EPP April 2019 + + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + <https://www.rfc-editor.org/info/rfc5730>. + + [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Domain Name Mapping", STD 69, RFC 5731, + DOI 10.17487/RFC5731, August 2009, + <https://www.rfc-editor.org/info/rfc5731>. + + [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, + August 2009, <https://www.rfc-editor.org/info/rfc5732>. + + [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, + August 2009, <https://www.rfc-editor.org/info/rfc5733>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [UNICODE] The Unicode Consortium, "The Unicode Standard", + <http://www.unicode.org/versions/latest/>. + + [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, + <https://www.w3.org/TR/xml/>. + + [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, + <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. + + [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, + <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. + + + + + + + + +Zhou, et al. Standards Track [Page 20] + +RFC 8544 Organization Extension for the EPP April 2019 + + +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, + <https://www.rfc-editor.org/info/rfc2781>. + + [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible + Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, + February 2015, <https://www.rfc-editor.org/info/rfc7451>. + + [RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou, + "Extensible Provisioning Protocol (EPP) Organization + Mapping", RFC 8543, DOI 10.17487/RFC8543, March 2019, + <https://www.rfc-editor.org/info/rfc8543>. + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 21] + +RFC 8544 Organization Extension for the EPP April 2019 + + +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 + + + Junkai Wei + CNNIC + 4 South 4th Street, Zhongguancun, Haidian District + Beijing, Beijing 100190 + China + + Email: weijunkai@cnnic.cn + + + 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 + + + + + + + + +Zhou, et al. Standards Track [Page 22] + |