| J. Gould | |
| N. Chigurupati | |
| S. Veeramachaneni | |
| VeriSign, Inc. | |
| January 2, 2014 |
Related Domain Extension for the Extensible Provisioning Protocol (EPP)
verisign_epp-extension_idn-lang_v01
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for managing client-side and server-side domain name relationships.
COPYRIGHT NOTIFICATION
Copyright 2013 VeriSign, Inc. All rights reserved. VERISIGN; the Verisign logo; and other trademarks, service marks and Verisign designs are registered or unregistered trademarks of VeriSign Inc. and its subsidiaries in the United States and foreign countries. Copyright laws and international treaties protect this document, and any Verisign product to which it relates.
VERISIGN PROPRIETARY INFORMATION
This document is the property of VeriSign, Inc. and its subsidiaries (together "Verisign") It may be used by recipient only for the purpose for which it was transmitted and must be returned upon request or when no longer needed by recipient. It may not be copied or communicated without the prior written consent of Verisign.
NOTICE AND CAUTION
Concerning U.S. Patent or Trademark Rights
Verisign and other trademarks, service marks and logos are registered or unregistered trademarks of Verisign and its subsidiaries in the United States and in foreign countries. The inclusion in this document, the associated on-line file or the associated software of any information covered by any other patent, trademark or service mark rights does not constitute nor imply a grant of or authority to exercise, any right or privilege protected by such patent, trademark or service mark. All such rights and privileges are vested in the patent, trademark or service mark owner and no other person may exercise such rights without express permission, authority or license secured from the patent, trademark or service mark owner.
This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an extension of the domain name mapping described in [RFC5731], for managing client-side and server-side domain name relationships. A client-side domain name relationship can be managed by using the extension to the transform commands that enable transforming more than one domain name in a single transform command. A server-side domain name relationship (across top-level domains "tld" or variants within a top-level domain "variant") is reflected in the extension to the info response, and can be managed by using the extension to the transform commands.
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 RFC 2119 [RFC2119].
XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.
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 protocol.
"relDom-1.0" is used as an abbreviation for "http://www.verisign-grs.com/epp/relatedDomain-1.0". The XML namespace prefix "relDom" 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.
This extension adds additional elements to the EPP domain name mapping [RFC5731]. Only those new elements are described here.
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730].
EPP provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.
This extension does not add any elements to the EPP <check> command or <check> response described in the EPP domain name mapping [RFC5731].
This extension defines additional elements to extend the EPP <info> command described in EPP domain name mapping [RFC5731].
There are two forms of the extension to the EPP <info> command based on the "type" attribute: The Domain Info Form and the Related Info Form.
The <relDom:infData> element is returned to a successfully processed <info> command for both the Domain Info Form [domainInfoForm] and the Related Info Form [relatedInfoForm]. The <relDom:infData> element contains the following child elements:
The Domain Info Form, defined with the <relDom:info> "type" attribute value of "domain", is used to get the domain information of an existing domain along with the related domain information. This is the default form when the <relDom:info> "type" attribute is not explicitly defined. With the Domain Info Form, in addition to the EPP info command elements described in [RFC5731], the command MUST contain an <extension> element. The <extension> element MUST contain a child <relDom:info> element, with the "type" attribute value of "domain" explicitly or by default, to indicate to the server to include the related domain information in an extension to the EPP info response described in [RFC5731].
Example <info> command for a domain with the <relDom:info> extension using the Domain Info Form:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>xn--test.tld1</domain:name> C: </domain:info> C: </info> C: <extension> C: <relDom:info C: xmlns:relDom= C: "http://www.verisign.com/epp/relatedDomain-1.0" C: type="domain"/> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in [RFC5731]. In addition, the EPP <extension> element SHOULD contain a child <relDom:infData> element that identifies the extension namespace if the object has one or more related domains associated with it and based on server policy. The <relDom:infData> element contains the child elements defined in Section 3.1.2.1.
Example <info> response for a domain with both "tld" and "variant" related domain information using the Domain Info Form:
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>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData xmlns:domain= S: "urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>xn--test.tld1</domain:name> S: <domain:roid>TEST1-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>sh8013</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:contact type="billing">sh8013</domain:contact> S: <domain:ns> S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns2.example.com</domain:hostObj> S: </domain:ns> S: <domain:host>ns1.example.com</domain:host> S: <domain:host>ns2.example.com</domain:host> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:upID>ClientX</domain:upID> S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <extension> S: <relDom:infData S: xmlns:relDom= S: "http://www.verisign-grs.com/epp/relatedDomain-1.0"> S: <relDom:group type="tld"> S: <relDom:fields inSync="false"> S: <relDom:field name="clID" inSync="false"> S: <relDom:field name="registrant" inSync="true"> S: <relDom:field name="ns" inSync="false"> S: </relDom:fields> S: <relDom:registered> S: <relDom:name>xn--test.tld1</relDom:name> S: <relDom:name>xn--test.tld2</relDom:name> S: </relDom:registered> S: <relDom:available> S: <relDom:name>xn--test.tld3</relDom:name> S: </relDom:available> S: </relDom:group> S: <relDom:group type="variant"> S: <relDom:fields inSync="true"> S: <relDom:field name="clID" inSync="true"> S: <relDom:field name="registrant" inSync="true"> S: <relDom:field name="ns" inSync="true"> S: </relDom:fields> S: <relDom:registered> S: <relDom:name>xn--test-variant1.tld1</relDom:name> S: <relDom:name>xn--test-variant2.tld1</relDom:name> S: <relDom:name>xn--test-variant3.tld1</relDom:name> S: </relDom:registered> S: <relDom:available> S: <relDom:name>xn--test-variant4.tld1</relDom:name> S: <relDom:name>xn--test-variant5.tld1</relDom:name> S: <relDom:name>xn--test-variant6.tld1</relDom:name> S: </relDom:available> S: </relDom:group> S: </relDom:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
The Related Info Form, defined with the <relDom:info> "type" attribute value of "related", is a new command called the Related Domain Info Command. The command gets the related domain information of the <domain:name> info command element defined in [RFC5731], independent of the existence of the domain name. With the Related Info Form, in addition to the EPP info command elements defined in [RFC5731], the command MUST contain an <extension> element. The <extension> element MUST contain a child <relDom:info> element, with the "type" attribute value of "related", to indicate to the server to include the related domain information in an extension to the EPP response described in [RFC5730].
Example <info> command for a domain with the <relDom:info> extension using the Related Info Form:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>xn--test.tld3</domain:name> C: </domain:info> C: </info> C: <extension> C: <relDom:info C: xmlns:relDom= C: "http://www.verisign.com/epp/relatedDomain-1.0" C: type="related"/> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When an <info> command has been processed successfully, the EPP <response> element MUST contain an <extension> element. In addition, the EPP <extension> element SHOULD contain a child <relDom:infData> element that identifies the extension namespace if at least one related domain exists and based on server policy. The <relDom:infData> element contains the child elements defined in section Section 3.1.2.1.
Example <info> response for both "tld" and "variant" related domain information using the Related Info Form:
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: <relDom:infData S: xmlns:relDom= S: "http://www.verisign.com/epp/relatedDomain-1.0"> S: <relDom:group type="tld"> S: <relDom:fields inSync="false"> S: <relDom:field name="clID" inSync="false"/> S: <relDom:field name="registrant" inSync="true"/> S: <relDom:field name="ns" inSync="false"/> S: </relDom:fields> S: <relDom:registered> S: <relDom:name>xn--test.tld1</relDom:name> S: <relDom:name>xn--test.tld2</relDom:name> S: </relDom:registered> S: <relDom:available> S: <relDom:name>xn--test.tld3</relDom:name> S: </relDom:available> S: </relDom:group> S: <relDom:group type="variant"> S: <relDom:fields inSync="true"> S: <relDom:field name="clID" inSync="true"/> S: <relDom:field name="registrant" inSync="true"/> S: <relDom:field name="ns" inSync="true"/> S: </relDom:fields> S: <relDom:registered> S: <relDom:name>xn--test-variant1.tld1</relDom:name> S: <relDom:name>xn--test-variant1.tld2</relDom:name> S: <relDom:name>xn--test-variant1.tld3</relDom:name> S: </relDom:registered> S: <relDom:available> S: <relDom:name>xn--test-variant2.tld1</relDom:name> S: <relDom:name>xn--test-variant2.tld2</relDom:name> S: <relDom:name>xn--test-variant2.tld3</relDom:name> S: </relDom:available> S: </relDom:group> S: </relDom:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
This extension defines additional elements for the EPP <transfer> command described in [RFC5731]. The extension to the EPP <transfer> query command is defined in Section 3.2.4 where the <transfer> command MUST contain an "op" attribute with value "query". The extension to the EPP <transfer> query response is defined in Section 3.2.4.
EPP provides five commands to transform 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 object sponsorship changes, and <update> to change information associated with an object.
This extension defines additional elements to extend the EPP <create> command described in EPP domain name mapping [RFC5731].
In addition to the EPP command elements described in [RFC5731], the command MUST contain an <extension> element. The <extension> element MUST contain a child <relDom:create> element to create more than one related domain name in the <create> command. The <relDom:create> element contains the following child elements:
Example <create> command for three related domain names ("example1.tld", "example2.tld", and "example3.tld") with the <relDom:create> extension:
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>example1.tld</domain:name> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <extension> C: <relDom:create C: xmlns:relDom= C: "http://www.verisign.com/epp/relatedDomain-1.0"> C: <relDom:domain> C: <relDom:name>example2.tld</relDom:name> C: <relDom:authInfo> C: <relDom:pw>relDom123!</relDom:pw> C: </relDom:authInfo> C: <relDom:period unit="y">5</relDom:period> C: </relDom:domain> C: <relDom:domain> C: <relDom:name>example3.tld</relDom:name> C: <relDom:authInfo> C: <relDom:pw>relDom456!</relDom:pw> C: </relDom:authInfo> C: <relDom:period unit="y">5</relDom:period> C: </relDom:domain> C: </relDom:create> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When an <create> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in [RFC5731]. In addition, the EPP <extension> element MUST contain a child <relDom:creData> element. The <relDom:creData> element contains the following child elements:
Example <create> response for three related domain names ("example1.tld", "example2.tld", and "example3.tld") created with the <relDom:create> extension:
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>Command completed successfully</msg> S: </result> S: <resData> S: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example1.tld</domain:name> S: <domain:crDate> S: 2013-07-10T00:00:00.0000Z</domain:crDate> S: <domain:exDate> S: 2018-07-10T00:00:00.0000Z</domain:exDate> S: </domain:creData> S: </resData> S: <extension> S: <relDom:creData S: xmlns:relDom= S: "http://www.verisign.com/epp/relatedDomain-1.0"> S: <relDom:domain> S: <relDom:name>example2.tld</relDom:name> S: <relDom:crDate> S: 2013-07-10T00:00:00.0000Z</relDom:crDate> S: <relDom:exDate> S: 2018-07-10T00:00:00.0000Z</relDom:exDate> S: </relDom:domain> S: <relDom:domain> S: <relDom:name>example3.tld</relDom:name> S: <relDom:crDate> S: 2013-07-10T00:00:00.0000Z</relDom:crDate> S: <relDom:exDate> S: 2018-07-10T00:00:00.0000Z</relDom:exDate> S: </relDom:domain> S: </relDom:creData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
This extension defines additional elements to extend the EPP <delete> command described in EPP domain name mapping [RFC5731].
In addition to the EPP command elements described in [RFC5731], the command MUST contain an <extension> element. The <extension> element MUST contain a child <relDom:delete> element to delete more than one related domain name in the <delete> command. The <relDom:delete> element contains the following child elements:
Example <delete> command for three related domain names ("example1.tld", "example2.tld", and "example3.tld") with the <relDom:delete> extension:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <delete> C: <domain:delete C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example1.tld</domain:name> C: </domain:delete> C: </delete> C: <extension> C: <relDom:delete C: xmlns:relDom= C: "http://www.verisign.com/epp/relatedDomain-1.0"> C: <relDom:name>example2.tld</relDom:name> C: <relDom:name>example3.tld</relDom:name> C: </relDom:delete> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When an <delete> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in [RFC5731]. In addition, the EPP <extension> element MUST contain a child <relDom:delData> element. The <relDom:delData> element contains the following child elements:
Example <delete> response for three related domain names ("example1.tld", "example2.tld", and "example3.tld") deleted with the <relDom:delete> extension:
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="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <extension> S: <relDom:delData S: xmlns:relDom= S: "http://www.verisign.com/epp/relatedDomain-1.0"> S: <relDom:domain> S: <relDom:name>domain1.com</relDom:name> S: <relDom:result>deleted</relDom:result> S: </relDom:domain> S: <relDom:domain> S: <relDom:name>domain2.com</relDom:name> S: <relDom:result>pendingDelete</relDom:result> S: </relDom:domain> S: </relDom:delData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
This extension defines additional elements to extend the EPP <renew> command described in EPP domain name mapping [RFC5731].
In addition to the EPP command elements described in [RFC5731], the command MUST contain an <extension> element. The <extension> element MUST contain a child <relDom:renew> element to renew more than one related domain name in the <renew> command. The <relDom:renew> element contains the following child elements:
Example <renew> command for three related domain names ("example1.tld", "example2.tld", and "example3.tld") with the <relDom:renew> extension:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <renew> C: <domain:renew C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example1.tld</domain:name> C: <domain:curExpDate>2013-07-10</domain:curExpDate> C: <domain:period unit="y">5</domain:period> C: </domain:renew> C: </renew> C: <extension> C: <relDom:renew C: xmlns:relDom= C: "http://www.verisign.com/epp/relatedDomain-1.0"> C: <relDom:domain> C: <relDom:name>example2.tld</relDom:name> C: <relDom:curExpDate>2013-07-10</relDom:curExpDate> C: <relDom:period unit="y">5</relDom:period> C: </relDom:domain> C: <relDom:domain> C: <relDom:name>example3.tld</relDom:name> C: <relDom:curExpDate>2013-07-10</relDom:curExpDate> C: <relDom:period unit="y">5</relDom:period> C: </relDom:domain> C: </relDom:renew> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When an <renew> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in [RFC5731]. In addition, the EPP <extension> element MUST contain a child <relDom:renData> element. The <relDom:renData> element contains the following child elements:
Example <renew> response for three related domain names ("example1.tld", "example2.tld", and "example3.tld") renewed with the <relDom:renew> extension:
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>Command completed successfully</msg> S: </result> S: <resData> S: <domain:renData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example1.com</domain:name> S: <domain:exDate>2018-07-10T00:00:00.0000Z S: </domain:exDate> S: </domain:renData> S: </resData> S: <extension> S: <relDom:renData S: xmlns:relDom= S: "http://www.verisign.com/epp/relatedDomain-1.0"> S: <relDom:domain> S: <relDom:name>example2.com</relDom:name> S: <relDom:exDate>2018-07-10T00:00:00.0000Z S: </relDom:exDate> S: </relDom:domain> S: <relDom:domain> S: <relDom:name>example3.com</relDom:name> S: <relDom:exDate>2018-07-10T00:00:00.0000Z S: </relDom:exDate> S: </relDom:domain> S: </relDom:renData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
This extension defines additional elements to extend the EPP <transfer> command described in EPP domain name mapping [RFC5731].
In addition to the EPP command elements described in [RFC5731], the command MUST contain an <extension> element. The <extension> element MUST contain a child <relDom:transfer> element to transfer more than one related domain name in the <transfer> command. The <relDom:transfer> element contains the following child elements:
Example <transfer> command for three related domain names ("example1.tld", "example2.tld", and "example3.tld") with the <relDom:transfer> extension:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="request"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example1.tld</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <extension> C: <relDom:transfer C: xmlns:relDom= C: "http://www.verisign.com/epp/relatedDomain-1.0"> C: <relDom:domain> C: <relDom:name>example2.tld</relDom:name> C: <relDom:authInfo> C: <relDom:pw>relDom123!</relDom:pw> C: </relDom:authInfo> C: <relDom:period unit="y">1</relDom:period> C: </relDom:domain> C: <relDom:domain> C: <relDom:name>example3.tld</relDom:name> C: <relDom:authInfo> C: <relDom:pw>relDom123!</relDom:pw> C: </relDom:authInfo> C: </relDom:domain> C: </relDom:transfer> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When an <transfer> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in [RFC5731]. In addition, the EPP <extension> element MUST contain a child <relDom:trnData> element. The <relDom:trnData> element contains the following child elements:
Example <transfer> response for three related domain names ("example1.tld", "example2.tld", and "example3.tld"):
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>Command completed successfully</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example1.tld</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>ClientX</domain:reID> S: <domain:reDate>2013-07-10T00:00:00.0000Z</domain:reDate> S: <domain:acID>ClientY</domain:acID> S: <domain:acDate>2013-07-10T00:00:00.0000Z</domain:acDate> S: <domain:exDate>2014-07-10T00:00:00.0000Z</domain:exDate> S: </domain:trnData> S: </resData> S: <extension> S: <relDom:trnData S: xmlns:relDom= S: "http://www.verisign.com/epp/relatedDomain-1.0"> S: <relDom:domain> S: <relDom:name>example2.tld</relDom:name> S: <relDom:trStatus>pending</relDom:trStatus> S: <relDom:reID>ClientX</relDom:reID> S: <relDom:reDate>2013-07-10T00:00:00.0000Z S: </relDom:reDate> S: <relDom:acID>ClientY</relDom:acID> S: <relDom:acDate>2013-07-10T00:00:00.0000Z S: </relDom:acDate> S: <relDom:exDate>2014-07-10T00:00:00.0000Z S: </relDom:exDate> S: </relDom:domain> S: <relDom:domain> S: <relDom:name>example3.tld</relDom:name> S: <relDom:trStatus>pending</relDom:trStatus> S: <relDom:reID>ClientX</relDom:reID> S: <relDom:reDate>2013-07-10T00:00:00.0000Z S: </relDom:reDate> S: <relDom:acID>ClientY</relDom:acID> S: <relDom:acDate>2013-07-10T00:00:00.0000Z S: </relDom:acDate> S: <relDom:exDate>2014-07-10T00:00:00.0000Z S: </relDom:exDate> S: </relDom:domain> S: </relDom:trnData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
This extension defines additional elements to extend the EPP <update> command described in EPP domain name mapping [RFC5731].
In addition to the EPP command elements described in [RFC5731], the command MUST contain an <extension> element. The <extension> element MUST contain a child <relDom:update> element to update more than one related domain name in the <update> command. The <relDom:update> element contains the following child elements:
Example <update> command for three related domain names ("example1.tld", "example2.tld", and "example3.tld") with the <relDom:update> extension:
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>example1.tld</domain:name> C: <domain:add> C: <domain:ns> C: <domain:hostObj>ns1.example.com C: </domain:hostObj> C: </domain:ns> C: <domain:status s="clientHold"/> C: </domain:add> C: <domain:rem> C: <domain:ns> C: <domain:hostObj>ns2.example.com C: </domain:hostObj> C: </domain:ns> C: <domain:status s="clientDeleteProhibited"/> C: </domain:rem> C: <domain:chg> C: <domain:registrant>jd1234</domain:registrant> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:chg> C: </domain:update> C: </update> C: <extension> C: <relDom:update C: xmlns:relDom= C: "http://www.verisign.com/epp/relatedDomain-1.0"> C: <relDom:name>example2.tld</relDom:name> C: <relDom:name>example3.tld</relDom:name> C: </relDom:update> C: </extension> C: <clTRID>ABC-12345-XYZ</clTRID> C: </command> C:</epp>
This extension does not define any extension to the response of an <update> domain command. After processing the command, the server replies with a standard EPP response as defined in [RFC5731].
One schema is presented here that is the EPP Related Domain Extension schema.
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 xmlns:relDom=
"http://www.verisign.com/epp/relatedDomain-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
targetNamespace="http://www.verisign.com/epp/relatedDomain-1.0"
elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
Related Domain extension
</documentation>
</annotation>
<!--
Import common element types.
-->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>
<!--
Related Domain info command extension root element
-->
<element name="info" type="relDom:infoType"/>
<!--
Info type attribute values
-->
<simpleType name="infoTypeType">
<restriction base="string">
<enumeration value="domain"/>
<enumeration value="related"/>
</restriction>
</simpleType>
<!--
Related Domain Info type
-->
<complexType name="infoType">
<attribute name="type" type="relDom:infoTypeType"
default="domain"/>
</complexType>
<!--
Related Domain info response extension root element
-->
<element name="infData" type="relDom:infDataType"/>
<complexType name="infDataType">
<sequence>
<element name="group"
type="relDom:relatedDomainGroupType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<simpleType name="fieldNameType">
<restriction base="normalizedString">
<minLength value="1"/>
<maxLength value="64"/>
</restriction>
</simpleType>
<!--
Field that needs to be synchronized.
-->
<complexType name="fieldType">
<attribute name="name" type="relDom:fieldNameType"
use="required"/>
<attribute name="inSync" type="boolean"
use="required"/>
</complexType>
<!--
Related Domain group types
-->
<simpleType name="groupType">
<restriction base="string">
<enumeration value="tld"/>
<enumeration value="variant"/>
</restriction>
</simpleType>
<!--
Fields that need to be synchronized
-->
<complexType name="fieldsType">
<sequence>
<element name="field" type="relDom:fieldType"
maxOccurs="unbounded"/>
</sequence>
<attribute name="inSync" use="required"/>
</complexType>
<!--
Domain names that are registered or available.
-->
<complexType name="domainListType">
<sequence>
<element name="name" type="eppcom:labelType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
Related Domain Group
-->
<complexType name="relatedDomainGroupType">
<sequence>
<element name="fields" type="relDom:fieldsType"/>
<element name="registered"
type="relDom:domainListType"
minOccurs="0"/>
<element name="available"
type="relDom:domainListType"
minOccurs="0"/>
</sequence>
<attribute name="type" type="relDom:groupType"
use="required"/>
</complexType>
<!--
Related Domain Auth Info Type
-->
<complexType name="authInfoType">
<choice>
<element name="pw"
type="eppcom:pwAuthInfoType"/>
<element name="ext"
type="eppcom:extAuthInfoType"/>
</choice>
</complexType>
<!--
Related Domain Period Type
-->
<complexType name="periodType">
<simpleContent>
<extension base="relDom:pLimitType">
<attribute name="unit"
type="relDom:pUnitType"
use="required"/>
</extension>
</simpleContent>
</complexType>
<!--
Related Domain Period Limit Type
-->
<simpleType name="pLimitType">
<restriction base="unsignedShort">
<minInclusive value="1"/>
<maxInclusive value="99"/>
</restriction>
</simpleType>
<!--
Related Domain Period Unit Type
-->
<simpleType name="pUnitType">
<restriction base="token">
<enumeration value="y"/>
<enumeration value="m"/>
</restriction>
</simpleType>
<!--
Related Domain Create Request Type
-->
<complexType name="createRequestType">
<sequence>
<element name="name"
type="eppcom:labelType"/>
<element name="authInfo"
type="relDom:authInfoType"/>
<element name="period"
type="relDom:periodType"
minOccurs="0"/>
<element name="lang"
type="language"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Related Domain Create Request element
-->
<element name="create">
<complexType>
<sequence>
<element name="domain"
type="relDom:createRequestType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!--
Related Domain Create Response type
-->
<complexType name="creDataType">
<sequence>
<element name="name"
type="eppcom:labelType"/>
<element name="crDate"
type="dateTime"/>
<element name="exDate"
type="dateTime"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Related Domain Create Request element
-->
<element name="creData">
<complexType>
<sequence>
<element name="domain"
type="relDom:creDataType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!--
Related Domain Delete Request element
-->
<element name="delete"
type="relDom:domainListType"/>
<simpleType name="deleteResultType">
<restriction base="string">
<enumeration value="deleted"/>
<enumeration value="pendingDelete"/>
</restriction>
</simpleType>
<!--
Related Domain Delete Response type
-->
<complexType name="delDataType">
<sequence>
<element name="name"
type="eppcom:labelType"/>
<element name="result"
type="relDom:deleteResultType"/>
</sequence>
</complexType>
<!--
Related Domain Delete Response element
-->
<element name="delData">
<complexType>
<sequence>
<element name="domain"
type="relDom:delDataType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!--
Related Domain Update Request element
-->
<element name="update" type="relDom:domainListType"/>
<!--
Related Domain Renew type
-->
<complexType name="renewType">
<sequence>
<element name="name"
type="eppcom:labelType"/>
<element name="curExpDate"
type="date"/>
<element name="period"
type="relDom:periodType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Related Domain Renew element
-->
<element name="renew">
<complexType>
<sequence>
<element name="domain"
type="relDom:renewType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!--
Related Domain Renew Data type
-->
<complexType name="renDataType">
<sequence>
<element name="name"
type="eppcom:labelType"/>
<element name="exDate"
type="dateTime"/>
</sequence>
</complexType>
<!--
Related Domain Renew Data element
-->
<element name="renData">
<complexType>
<sequence>
<element name="domain"
type="relDom:renDataType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!--
Related Domain Transfer type
-->
<complexType name="transferType">
<sequence>
<element name="name"
type="eppcom:labelType"/>
<element name="authInfo"
type="relDom:authInfoType"
minOccurs="0"/>
<element name="period"
type="relDom:periodType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Related Domain Transfer element
-->
<element name="transfer">
<complexType>
<sequence>
<element name="domain"
type="relDom:transferType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!--
Related Domain Transfer Data Type
-->
<complexType name="trnDataType">
<sequence>
<element name="name"
type="eppcom:labelType"/>
<element name="trStatus"
type="eppcom:trStatusType"/>
<element name="reID"
type="eppcom:clIDType"/>
<element name="reDate"
type="dateTime"/>
<element name="acID"
type="eppcom:clIDType"/>
<element name="acDate"
type="dateTime"/>
<element name="exDate"
type="dateTime" minOccurs="0"/>
</sequence>
</complexType>
<!--
Related Domain Transfer Data element
-->
<element name="trnData">
<complexType>
<sequence>
<element name="domain"
type="relDom:trnDataType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
</schema>
END
The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730] and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5730] | Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009. |
| [RFC5731] | Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009. |