0% found this document useful (0 votes)
146 views28 pages

Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated: November 3, 2004

This document contains proprietary information that is owned by VeriSign. This document may only be used by the recipient for the purpose for which it was transmitted. Nothing herein grants the reader any license to make, use, or sell equipment or products constructed in accordance with this document.

Uploaded by

Ansh Batra
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
146 views28 pages

Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated: November 3, 2004

This document contains proprietary information that is owned by VeriSign. This document may only be used by the recipient for the purpose for which it was transmitted. Nothing herein grants the reader any license to make, use, or sell equipment or products constructed in accordance with this document.

Uploaded by

Ansh Batra
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 28

Protocol Variance Document: EPP .

5,
1.0, 1.0 Consolidated
Version 1.3
November 3, 2004

Copyright © 2004 VeriSign, Inc. All rights reserved.

VeriSign, Inc.
VeriSign Naming and Directory Services
VNDS Proprietary and Confidential
COPYRIGHT NOTIFICATION

Copyright © 2004 VeriSign, Inc. All rights reserved.

This document contains proprietary information that is owned by VeriSign. This document may only
be used by the recipient for the purpose for which it was transmitted. This document must be
returned upon request or when no longer needed by recipient. It may not be copied or its contents
communicated without the written consent of VeriSign.

DISCLAIMER AND LIMITATION OF LIABILITY

VeriSign, Inc. has made efforts to ensure the accuracy and completeness of the information in this
document. However, VeriSign, Inc. makes no warranties of any kind (whether express, implied or
statutory) with respect to the information contained herein. VeriSign, Inc. assumes no liability to any
party for any loss or damage (whether direct or indirect) caused by any errors, omissions or
statements of any kind contained in this document. Further, VeriSign, Inc. assumes no liability
arising from the application or use of the product or service described herein and specifically
disclaims any representation that the products or services described herein do not infringe upon any
existing or future intellectual property rights. Nothing herein grants the reader any license to make,
use, or sell equipment or products constructed in accordance with this document. Finally, all rights
and privileges related to any intellectual property right described herein 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.
VeriSign Inc. reserves the right to make changes to any information herein without further notice.

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.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • ii
Contents
1. INTRODUCTION ....................................................................................................................... 1
1.1 Terms and Acronyms.......................................................................................... 1
1.2 Conventions ........................................................................................................ 1
1.3 References........................................................................................................... 2
1.4 Purpose................................................................................................................ 4
1.5 Audience ............................................................................................................. 4
2. HIGH-LEVEL VARIANCE ANALYSIS ........................................................................................ 5
2.1 Introduction......................................................................................................... 5
2.2 Highlights of Protocol Changes .......................................................................... 5
2.3 High-Level Variances of Underlying Platforms ................................................. 6
2.3.1 IP Address Variances.................................................................................. 6
2.3.2 IDN Provisioning ........................................................................................ 7
2.3.3 Domain Transfer ......................................................................................... 7
2.3.4 Domain Auto-Renewal ............................................................................... 7
2.3.5 Variable Pricing For Domains .................................................................... 7
2.3.6 New Domain Statuses ................................................................................. 8
2.3.7 Grace and Pending Periods ......................................................................... 8
3. EPP COMMAND/RESPONSE VARIANCE................................................................................... 9
3.1 EPP General Command/Response Variance ...................................................... 9
3.1.1 <greeting>................................................................................................... 9
3.1.2 <login> Command .................................................................................... 10
3.1.3 <logout> Command .................................................................................. 11
3.1.4 Error <response>....................................................................................... 11
3.1.5 <poll> Command/Response...................................................................... 12
3.1.6 <hello> Command .................................................................................... 13
3.2 EPP Namestore Extension Variance................................................................. 13
3.3 EPP Domain Command/Response Variance .................................................... 14
3.3.1 Domain <check>....................................................................................... 14
3.3.2 Domain <info>.......................................................................................... 14
3.4 EPP Host Command/Response Variance.......................................................... 20
3.5 RCCDomain Variance ...................................................................................... 20
3.6 RCCHost Variance............................................................................................ 21
3.7 RCCJob Variance .......................................................................................... 21

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • iii
Figures
Table 1: Terms and Acronyms Used in This Document..................................................... 1
Table 2 - Documentation References.................................................................................. 2
Table 3: Matrix of support for IP address functionality across platforms .......................... 7
Table 4: Transfer functionality across platforms ................................................................ 7
Table 5: New RGP Statuses in EPP 1.0 Consolidated........................................................ 8
Table 6 - <login> Command Variance ............................................................................. 10
Table 7 - Error <response> Variance................................................................................ 11
Table 8 - Poll <response> Variance.................................................................................. 12
Table 9 - <namestoreExt> Variance ................................................................................ 13
Table 10 - Possible subProduct Values............................................................................. 14
Table 11 - Domain <info> Response Variance ................................................................ 15
Table 12 - Domain <create> Command Variance ............................................................ 16
Table 13 - Domain <update> Command Variance ........................................................... 17
Table 14 - Domain <transfer> Request Command Variance ........................................... 19

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • iv
1. Introduction
1.1 Terms and Acronyms
VNDS VeriSign Naming and Directory Services
CTLD Consolidated Top-Level Domain, a platform being launched by VNDS to
support provisioning of many TLDs through a common interface.
ccTLD Country Code Top-Level Domain: top-level domain assigned to a country, e.g.
.TV.
gTLD Global Top-Level Domain: top-level domain without regional assignment, e.g.
.COM.
TLD Top-level domain, encompassing both gTLDs and ccTLDs.
SDK Software Development Kit, likely including various language SDKs,
documentation and example code.
API Application Programming Interface, a component of an SDK that
provides compiled or source libraries for integration to specific
programming language platforms.
EPP Extensible Provisioning Protocol, an IETF standard protocol for object
provisioning.
EPP SDK A software package that includes a easy to use interface for
implementing an EPP client along with a EPP Server Stub for testing.
CORE Existing platform offered by VNDS for provisioning .COM and .NET
domains.
IDN Internationalized Domain Namenames provisioned or resolved using
character sets other than traditional ASCII.
SSL Secure Sockets Layer – a scheme for encrypting and authentication two-
party network communications.
Table 1: Terms and Acronyms Used in This Document

1.2 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
contained in this document are to be interpreted as described in [RFC 2119]. Bolded
items indicate updates/additions to syntax.

In protocol examples, "C:" represents lines sent by the registrar client and "S:" represents
lines sent by the registry server.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 1
1.3 References
The following documents are referenced herein and provide supporting documentation of
the systems we are comparing.
Table 2 - Documentation References
Author(s) Title Revision Date

Scott Hollenbeck Extensible Provisioning Protocol 3/2004


Scott Hollenbeck Extensible Provisioning Protocol (EPP) Transport 3/2004
Over TCP
Scott Hollenbeck Extensible Provisioning Protocol (EPP) Domain 3/2004
Name Mapping
Scott Hollenbeck Extensible Provisioning Protocol (EPP) Host 3/2004
Mapping
Scott Hollenbeck Extensible Provisioning Protocol (EPP) Transport 3/2004
Over TCP
Extensible Provisioning Protocol Extension Mapping: 1.1
Namestore Extension
Extensible Provisioning Protocol Extension Mapping: 1.0
Customer Contact DRAFT
0.1
Extensible Provisioning Protocol Extension Mapping: 1.0
Literal IT DRAFT
0.1
Karthik EPP Name Store RCC Contact Mapping Guide 2.0 02/24/2004
Shyamsunder
Karthik EPP Name Store RCC Domain Mapping Guide 2.0 03/04/2004
Shyamsunder
Karthik EPP Name Store RCC Host Mapping Guide 2.0 02/26/2004
Shyamsunder
Karthik EPP Name Store RCC Job Mapping Guide 1.0 2/24/2003
Shyamsunder
Scott Hollenbeck Domain Registry Grace Period Mapping for the 9/2004
Extensible Provisioning Protocol (EPP)
Scott Hollenbeck ConsoliDate Mapping for the Extensible Provisioning 00 12/23/2003
Protocol
Mahendra Jain EPP RGP Poll Mapping Guide 1.1 5/23/2004

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 2
Mahendra Jain EPP Low Balance Mapping Guide 1.1 5/23/2004

Venkat Munuswamy Extensible Provisioning Protocol Extension Mapping: 1.1


IDN Language Tag
Extensible Provisioning Protocol Extension Mapping: 1.0
Namestore Domain Billing DRAFT
0.1

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 3
1.4 Purpose

The purpose of this document is to analyze the protocol differences between EPP .5, EPP
1.0 and EPP 1.0 Consolidated, clarifying the upgrade path for registrars and internal users
from the NameStore .5 and NameStore 1.0 to NameStore Consolidated. NameStore
Consolidated is an EPP 1.0 system that includes additional features that are not included
with the NameStore 1.0 system. The NameStore .5 and the NameStore 1.0 systems are
being replaced by NameStore Consolidated.

1.5 Audience
The audience for this document is software developers and support personnel planning to
upgrade their software from using NameStore .5 or NameStore 1.0 to NameStore
Consolidated.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 4
2. High-Level Variance Analysis
2.1 Introduction
This section analyzes each command offered in EPP and examines the differences in
syntax and business rules associated with each. Full documentation of the EPP syntax and
business rules is provided in the various documents listed in the

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 5
References section of this document. This document does not attempt to enumerate all
business rules or protocol variations, only to highlight important differences that may
prove to be stumbling blocks in the upgrade process.

2.2 Highlights of Protocol Changes


The following is an overview of the protocol changes between EPP .5/1.0
implementations and EPP 1.0 Consolidated implementation.

1. IDN Support - EPP 1.0 Consolidated supports provisioning of ASCII-encoded


IDN names with the new “Extensible Provisioning Protocol: IDN Language Tag”
extension.
2. Restore command - EPP 1.0 Consolidated supports the restore command with
the new “Domain Registry Grace Period Mapping for the Extensible Provisioning
Protocol” extension. This command allows a registrar to undo a delete domain
request in some situations. The extension includes support for both the restore
request and the restore report. The extension adds an additional status to the
domain info response.
3. Sync command - EPP 1.0 Consolidated supports the sync command with the new
“ConsoliDate Mapping for the Extensible Provisioning Protocol” extension. This
command allows a registrar to modify the month and day of a domain’s
registration period for the purpose of synchronizing domain expirations and
renewals.
4. Removal of premium pricing extension from EPP .5 - The “Extensible
Provisioning Protocol Extension Mapping: Namestore Domain Billing” is not
supported in either EPP 1.0 or EPP 1.0 Consolidated.
5. Registry Grace Period (RGP) Poll Notification - EPP 1.0 Consolidated added
support for a new poll message with the “EPP RGP Poll Mapping” to indicate that
an RGP report is required. The “Domain Registry Grace Period Mapping for the
Extensible Provisioning Protocol” extension requires both a restore request and a
restore report to fully execute an RGP, so the poll message is required to notify
that a restore report has not been received.
6. Low Balance Poll Notification - EPP 1.0 Consolidated added support for a new
poll message with the “EPP Low Balance Mapping” to indicate that an account’s
available credit is below the credit threshold.
7. Transfer Poll Notification - EPP 1.0 Consolidated added the use of the domain
transfer poll notification as defined in “Extensible Provisioning Protocol (EPP)
Domain Name Mapping”. The transfer poll notification is sent with each transfer
transform operation including
8. Multiple Extension Support - Support for multiple extensions in the “Extensible
Provisioning Protocol Extension Mapping: Namestore Extension” is not
supported in EPP 1.0 and EPP 1.0 Consolidated and is replaced for the native EPP
1.0 support for multiple extensions. In EPP 1.0 a command and response can not
contains multiple extensions, which is needed when passing both the Namestore
Extension along with the IDN Language Tag, RGP extension, or ConsoliDate
(Sync) extension.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 6
9. Use of <extValue> instead of <value> tag with Error Results - EPP .5 used free-form text
in the <value> element of error results to provide additional error information. In EPP 1.0 and
EPP 1.0 Consolidated, the <extValue> element is used to in place of <value>, where the free-
form text is contained in the <reason> sub element and the <epp:undef> element is used in
the <value> sub element.
10. EPP 1.0 Syntax Changes - Some of the core EPP syntax changed from EPP .5 to EPP 1.0
including the <login> command, the poll <msgQ> element, the requirement for the greeting
<dcp> element, and the <result> elements.
11. RCC Mapping (RCCDomain, RCCHost, RCCContact) Changes - The RCC mappings
had significant updates from EPP .5 to EPP 1.0 to make them closer to the IETF mappings
(Domain, Host, Contact). RCC defined a new EPP poll message with EPP 1.0 which used
XML in place of delimited data.
12. NameStore Handling of client Statuses – NameStore .5 and 1.0 provides a passthrough
interface to RRP based servers, which means that EPP has to be mapped to RRP. NameStore
Consolidated provides full EPP behavior, so a client using NameStore .5 and 1.0 needs to
account for the different behavior when setting client statuses. For example, in NameStore .5
and 1.0 setting the clientHold status winds up mapping to RRP REGISTRAR-HOLD statuses,
which has the effect of automatically setting the clientUpdateProhited, clientDeleteProhibited,
and clientTransferProhibited statuses. With NameStore Consolidated, a client must set all sta-
tuses to get the same result.

2.3 High-Level Variances of Underlying Platforms

There are many differences between the platforms under which the legacy ccTLD (.TV, .CC) imple-
mentations and the NameStore Consolidated implementation is run. Highlights of these differences
include:

2.3.1 IP Address Variances


The .TV implementation only supports one IP address per host, the .CC implementation supports up
to 13 IP addresses per host. Additionally, all legacy implementations have a unique constraint on IP
addresses, such that only one unique IP may be used for any hosts within the registry. Additionally,
the legacy registries do not support IPv6 IP addresses. EPP 1.0 Consolidated does support IPv6. The
following table shows supported functionality with respect to IP addresses:

functionality .CC .TV CTLD


Multiple IP addresses per nameserver YES NO YES
IP address must be unique within registry YES YES NO
Support of IPv6 NO NO YES
Table 3: Matrix of support for IP address functionality across platforms

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated •7
VNDS Proprietary and Confidential
2.3.2 IDN Provisioning
The EPP 1.0 Consolidated implementation supports provisioning of punicode-encoded
ASCII domains with the “Extensible Provisioning Protocol: IDN Language Tag”
extension. EPP .5 and 1.0 do not support IDN provisioning. Details of the IDN Language
Tag extension syntax “Extensible Provisioning Protocol: IDN Language Tag” document
and details of the registry policy can be found in the Registrar Reference Manual. I

2.3.3 Domain Transfer


EPP .5 and 1.0 do not support registrar-to-registrar transfers for .TV and do not support
transfer query or transfer EPP poll messages for .CC. Details of domain transfer syntax
and business rules can be found in the Registrar Reference Manual, cited in the

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated •8
VNDS Proprietary and Confidential
References section of this document.

functionality .CC .TV CTLD


Transfers YES NO YES
Transfer EPP Poll Messages NO NO YES
Table 4: Transfer functionality across platforms

2.3.4 Domain Auto-Renewal


All platforms auto-renew domain names when their existing registration period expires.
Details of domain auto-renewal business rules within the CTLD and .TV Registry
systems can be found below, in the Grace and Pending Periods section, as well as in
supporting documents cited in the

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 9
References section of this document.

2.3.5 Variable Pricing For Domains


The .TV Registry and the EPP .5 implementation supports variable pricing for domains,
or “premium names”. This support was implemented with the “Extensible Provisioning
Protocol Extension Mapping: Namestore Domain Billing “ extension in EPP .5, but was
removed in EPP 1.0. EPP 1.0 Consolidated does not support this extension and will be
rejected with a 2001 error response “Command syntax error”. Each registrar has a single
price for a domain.

2.3.6 New Domain Statuses


Domains and associated domain status codes exist in a one-to-many relationship. That is,
a domain name may have more than one associated status at any given time. The Registry
may change the status of all registered domain names, while registrars may only change
the status of domain names that they have registered. EPP 1.0 Consolidated adds support
for the “Domain Registry Grace Period Mapping for the Extensible Provisioning
Protocol”, which will include three new RGP statuses defined in Table 5: New RGP
Statuses in EPP 1.0 Consolidated that are applied when the EPP domain pendingDelete
status is set.

redemptionPeriod This status value is used to describe a domain for which a


<delete> command has been received, but the domain has
not yet been purged because an opportunity exists to restore
the domain and abort the deletion process.
pendingRestore This status value is used to describe a domain that is in the
process of being restored after being in the
redemptionPeriod state.
pendingDelete This status value is used to describe a domain that has
entered the purge processing state after completing the
redemptionPeriod state. A domain in this status MUST also
be in the pendingDelete status described in the EPP domain
mapping.
Table 5: New RGP Statuses in EPP 1.0 Consolidated

The following is an example

For complete documentation on domain statuses within CTLD and EPP, consult the
Registrar Reference Manual, cited in the

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 10
References section.

2.3.7 Grace and Pending Periods


Operational “Grace” and “Pending” periods are business-rule time windows in which
registry objects are subject to special conditions or business rules that do not apply to
those objects in typical situations. An example of a grace or pending period is the “Add
Grace Period”, a span of time after creating a domain during which that domain may be
immediately deleted with a full financial credit to the provisioning registrar.

With the exception of the added functionality of restore and transfer with CTLD EPP, all
grace periods are consistent between legacy and CTLD implementations.

3. EPP Command/Response Variance


This section describes the syntax variances between EPP .5, 1.0, and 1.0 Consolidated.

3.1 EPP General Command/Response Variance


3.1.1 <greeting>
EPP 1.0 added the requirement for the <greeting> to contain the <dcp> element. In
additional to the <dcp> requirement, the <dcp> sub-elements changed between EPP .5
and 1.0.

EPP .5 EPP 1.0


<?xml version="1.0" encoding="UTF-8" <?xml version="1.0" encoding="UTF-8"
standalone="no"?> standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema- xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:epp- xsi:schemaLocation="urn:ietf:params:xml:ns:epp-
1.0 1.0
epp-1.0.xsd"> epp-1.0.xsd">
<greeting> <greeting>
<svID>Example Company EPP server <svID>Example EPP server
epp.example.com</svID> epp.example.com</svID>
<svDate>2000-06-08T22:00:00.0Z</svDate> <svDate>2000-06-08T22:00:00.0Z</svDate>
<svcMenu> <svcMenu>
<version>1.0</version> <version>1.0</version>
<lang>en</lang> <lang>en</lang>
<lang>fr</lang> <lang>fr</lang>
<objURI>urn:ietf:params:xml:ns:contact-
1.0</objURI> <objURI>urn:ietf:params:xml:ns:obj1</objURI>
<objURI>urn:ietf:params:xml:ns:domain-
1.0</objURI> <objURI>urn:ietf:params:xml:ns:obj2</objURI>
<objURI>urn:ietf:params:xml:ns:host-
1.0</objURI> <objURI>urn:ietf:params:xml:ns:obj3</objURI>
<svcExtension> <svcExtension>
<extURI>http://custom/obj1ext- <extURI>http://custom/obj1ext-
1.0</extURI> 1.0</extURI>
</svcExtension> </svcExtension>
</svcMenu> </svcMenu>

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 11
<dcp> <dcp>
<access><all/></access> <access><all/></access>
<statement> <statement>
<purpose><dnReg/><contact/></purpose> <purpose><admin/><prov/></purpose>

<recipient><ours/><public/></recipient> <recipient><ours/><public/></recipient>
<retention><business/></retention> <retention><stated/></retention>
</statement> </statement>
</dcp> </dcp>
</greeting> </greeting>
</epp> </epp>

The <greeting> for EPP 1.0 Consolidated should look like the following:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>


<epp
xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"
>
<greeting>
<svID>Verisign NADS EPP HTTP Server: Current Thread ID : 718579226</svID>
<svDate>2004-09-13T20:03:00.0718Z</svDate>
<svcMenu>
<version>1.0</version>
<lang>en</lang>
<objURI>http://www.verisign-grs.com/epp/rcccontact-1.1</objURI>
<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
<objURI>urn:ietf:params:xml:ns:host-1.0</objURI>
<objURI>http://www.verisign-grs.com/epp/rccjob-1.0</objURI>
<objURI>http://www.verisign-grs.com/epp/rcchost-1.1</objURI>
<objURI>http://www.verisign-grs.com/epp/rccdomain-1.1</objURI>
<objURI>http://www.verisign.com/epp/lowbalance-poll-1.0</objURI>
<svcExtension>
<extURI>http://www.verisign-grs.com/epp/namestoreExt-1.1</extURI>
<extURI>http://www.verisign-grs.com/epp/rccLiteralIT-1.0</extURI>
<extURI>http://www.verisign-grs.com/epp/rccCustContact-1.0</extURI>
<extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI>
<extURI>http://www.verisign.com/epp/sync-1.0</extURI>
<extURI> http://www.verisign.com/epp/idnLang-1.0</extURI>
</svcExtension>
</svcMenu>
<dcp>
<access>
<all/>
</access>
<statement>
<purpose>
<admin/>
<prov/>
</purpose>
<recipient>
<ours/>
<public/>
</recipient>
<retention>
<stated/>
</retention>
</statement>
</dcp>
</greeting>
</epp>

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 12
3.1.2 <login> Command
All of the EPP .5 <creds> elements have been moved directly into the <login> command.
The <creds> has been removed in EPP 1.0.

Table 6 - <login> Command Variance


EPP .5 EPP 1.0
<?xml version="1.0" encoding="UTF-8" <?xml version="1.0" encoding="UTF-8"
standalone="no"?> standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema- xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:epp- xsi:schemaLocation="urn:ietf:params:xml:ns:epp-
1.0 1.0
epp-1.0.xsd"> epp-1.0.xsd">
<command> <command>
<creds> <login>
<clID>ClientX</clID> <clID>ClientX</clID>
<pw>foo-BAR2</pw> <pw>foo-BAR2</pw>
<newPW>bar-FOO2</newPW> <newPW>bar-FOO2</newPW>
<options> <options>
<version>1.0</version> <version>1.0</version>
<lang>en</lang> <lang>en</lang>
</options> </options>
</creds> <svcs>
<login>
<svcs> <objURI>urn:ietf:params:xml:ns:obj1</objURI>

<objURI>urn:ietf:params:xml:ns:contact- <objURI>urn:ietf:params:xml:ns:obj2</objURI>
1.0</objURI>
<objURI>urn:ietf:params:xml:ns:obj3</objURI>
<objURI>urn:ietf:params:xml:ns:domain- <svcExtension>
1.0</objURI> <extURI>http://custom/obj1ext-
<objURI>urn:ietf:params:xml:ns:host- 1.0</extURI>
1.0</objURI> </svcExtension>
<svcExtension> </svcs>
<extURI>http://custom/obj1ext- </login>
1.0</extURI> <clTRID>ABC-12345</clTRID>
</svcExtension> </command>
</svcs> </epp>
</login>
<clTRID>ABC-12345</clTRID>
</command>
</epp>

3.1.3 <logout> Command


No variance between EPP .5 and EPP 1.0.

3.1.4 Error <response>


EPP 1.0 added the <extValue> element to the <response> to allow the server to specify a
free-form text <reason>. In EPP .5, NameStore used the <value> element to include free-
form text error information, but EPP 1.0 requires XML data in the <value> element.
NameStore EPP 1.0 now uses the <extValue> element for returning free-form text error

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 13
information to the client. Where a command element can not be identified, the element
<epp:undef/> is used as the value of the <value> element of <extValue>.

Table 7 - Error <response> Variance


EPP .5 EPP 1.0
<?xml version="1.0" encoding="UTF-8" <?xml version="1.0" encoding="UTF-8"
standalone="no"?> standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema- xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:epp- xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
1.0 epp-1.0.xsd">
epp-1.0.xsd"> <response>
<response> <result code="2005">
<result code="2005"> <msg>Parameter value syntax error</msg>
<msg>Parameter value range error</msg> <extValue>
<value>Invalid character found.</value> <value
</result> xmlns:epp="urn:ietf:params:xml:ns:epp-1.0">
<trID> <epp:undef/>
<clTRID>ABC-12345</clTRID> </value>
<svTRID>54321-XYZ</svTRID> <reason>Invalid character
</trID> found.</reason>
</response> </extValue>
</epp> </result>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>

3.1.5 <poll> Command/Response


The poll response format greatly changed between EPP .5 and EPP 1.0.

3.1.5.1 <poll> Command


No variance in this command between EPP .5 and EPP 1.0.

3.1.5.2 <poll> Response


The poll response elements were moved out of the generic <result> element and moved
under the <msgQ> element. Specifically, The result code 1301 will always return a
<msg> value of “Command completed successfully; ack to dequeue” in EPP 1.0, and the
<msgQ> will contain the generic poll queue <msg> element associated with the poll
message. Additionally, the message id has moved to an attribute of the <msgQ> element
instead of an attribute of the <result> <msg> element.

Table 8 - Poll <response> Variance


EPP .5 EPP 1.0
<?xml version="1.0" encoding="UTF-8" <?xml version="1.0" encoding="UTF-8"
standalone="no"?> standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 14
xmlns:xsi="http://www.w3.org/2001/XMLSchema- xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:epp- xsi:schemaLocation="urn:ietf:params:xml:ns:epp-
1.0 1.0
epp-1.0.xsd"> epp-1.0.xsd">
<response> <response>
<result code="1301"> <result code="1301">
<msg id="12345">Transfer <msg>Command completed successfully;
requested.</msg> ack to dequeue</msg>
</result> </result>
<msgQ count="5"> <msgQ count="5" id="12345">
<qDate>2000-06-08T22:00:00.0Z</qDate> <qDate>2000-06-08T22:00:00.0Z</qDate>
</msgQ> <msg>Transfer requested.</msg>
<resData> </msgQ>
<obj:trnData <resData>
xmlns:obj="urn:ietf:params:xml:ns:obj" <obj:trnData
xmlns:obj="urn:ietf:params:xml:ns:obj-
xsi:schemaLocation="urn:ietf:params:xml:ns:obj 1.0"
obj.xsd">
<obj:name>example</obj:name> xsi:schemaLocation="urn:ietf:params:xml:ns:obj-
<obj:trStatus>pending</obj:trStatus> 1.0
<obj:reID>ClientX</obj:reID> obj-1.0.xsd">
<obj:reDate>2000-06- <obj:name>example.com</obj:name>
08T22:00:00.0Z</obj:reDate> <obj:trStatus>pending</obj:trStatus>
<obj:acID>ClientY</obj:acID> <obj:reID>ClientX</obj:reID>
<obj:acDate>2000-06- <obj:reDate>2000-06-
13T22:00:00.0Z</obj:acDate> 08T22:00:00.0Z</obj:reDate>
<obj:exDate>2002-09- <obj:acID>ClientY</obj:acID>
08T22:00:00.0Z</obj:exDate> <obj:acDate>2000-06-
</obj:trnData> 13T22:00:00.0Z</obj:acDate>
</resData> <obj:exDate>2002-09-
<trID> 08T22:00:00.0Z</obj:exDate>
<clTRID>ABC-12345</clTRID> </obj:trnData>
<svTRID>54321-XYZ</svTRID> </resData>
</trID> <trID>
</response> <clTRID>ABC-12345</clTRID>
</epp> <svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>

EPP 1.0 Consolidated includes support for the following types of poll messages:
1. Transfer Poll Notification – This is a standard EPP poll notification for transfer
operation (request, cancel, approve, reject) that will be supported for the first
time with EPP 1.0 Consolidated.
2. Low Balance Poll Notification – New poll message, defined in the “EPP Low
Balance Mapping Guide”, that is used to notify a customer that there available
credit is below a specified threshold.
3. RGP Poll Notification – New poll message, defined in “EPP RGP Poll Mapping
Guide”, that is used to notify a customer that a RGP restore command was
received without the required RGP restore report command.
4. RCCTLD Pending Action Notification – EPP 1.0 poll notification, defined in the
“EPP Name Store RCC Domain Mapping Guide”, that is used to provide the
status of a domain pending action.

3.1.6 <hello> Command


No variance between EPP .5 and EPP 1.0.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 15
3.2 EPP Namestore Extension Variance
The EPP Namestore Extension is used with all Domain Commands/Responses and Host
Commands/Responses to specify the logical NameStore Registry. For EPP .5, the
extension is version 1.0 and for EPP 1.0, the extension is version 1.1. The primary
difference between version 1.0 and 1.1 is the removal of the support for the
<namestoreExt:extensions> element. EPP 1.0 supports multiple extensions, so there is
no need for <namestoreExt:extensions> in EPP 1.0. The list of possible subProduct
values is defined in Table 10 - Possible subProduct Values.

Table 9 - <namestoreExt> Variance


EPP .5 EPP 1.0
<namestoreExt:namestoreExt <namestoreExt:namestoreExt
xmlns:namestoreExt="http://www.verisign- xmlns:namestoreExt="http://www.verisign-
grs.com/epp/namestoreExt-1.0" grs.com/epp/namestoreExt-1.1"
xsi:schemaLocation="http://www.verisign- xsi:schemaLocation="http://www.verisign-
grs.com/epp/namestoreExt-1.0 namestoreExt-1.0.xsd" grs.com/epp/namestoreExt-1.1 namestoreExt-1.1.xsd"
> >
<namestoreExt:subProduct>dotCC</namestoreExt:subProduct> <namestoreExt:subProduct>dotCC</namestoreExt:subPro
<namestoreExt:extensions> </namestoreExt:namestoreExt>

</namestoreExt:extensions>
</namestoreExt:namestoreExt>

Table 10 - Possible subProduct Values


Environment EPP .5 EPP 1.0 Consolidated EPP 1.0
OT&E dotCC, dotTV dotCC, dotTV dotBZ, dotCC, dotCOM, dotNET dotTV
Production dotCC, dotTV dotCC, dotTV dotBZ, dotCC, dotTV

3.3 EPP Domain Command/Response Variance


3.3.1 Domain <check>
All systems allow a registrar to check availability of a domain in the registry.

3.3.1.1 Domain <check> Command Variance


No variance between EPP .5 and EPP 1.0.

3.3.1.2 Domain <check> Response Variance


As of EPP 1.0, NameStore does not support the use of the “Extensible Provisioning
Protocol Extension Mapping: Namestore Domain Billing “extension which was a
requirement for Domain <check> responses in EPP .5. The variance for error responses
is described in section 3.1.4.

3.3.2 Domain <info>


All systems allow a registrar to check availability of a domain in the registry.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 16
3.3.2.1 Domain <info> Command Variance
EPP 1.0 defines the option to use <domain:authInfo> for a <info> command, which is not
supported by NameStore so the syntax for <info> command does not change between
EPP .5 and EPP 1.0.

3.3.2.2 Domain <info> Response Variance


The format of the <domain:ns> and the <domain:authInfo> elements changed between
EPP .5 and EPP 1.0 as well as the error responses as described in section 3.1.4.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 17
Table 11 - Domain <info> Response Variance

EPP .5 EPP 1.0


<?xml version="1.0" encoding="UTF-8" <?xml version="1.0" encoding="UTF-8"
standalone="no"?> standalone="no"?>
<epp <epp
xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-
xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance"
instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"
xsi:schemaLocation="urn:ietf:params:xml:ns:ep >
p-1.0 epp-1.0.xsd" <response>
> <result code="1000">
<response> <msg>Command completed successfully</msg>
<result code="1000"> </result>
<msg>Command completed <resData>
successfully</msg> <domain:infData
</result> xmlns:domain="urn:ietf:params:xml:ns:domain-
<resData> 1.0"
<domain:infData
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-
xmlns:domain="urn:ietf:params:xml:ns:domain- 1.0 domain-1.0.xsd"
1.0" >
<domain:name>TEST.CC</domain:name>
xsi:schemaLocation="urn:ietf:params:xml:ns:do <domain:roid>86377203DOMAIN-
main-1.0 domain-1.0.xsd" NAME</domain:roid>
> <domain:status s="ok"/>
<domain:name>TEST.CC</domain:name> <domain:ns>
<domain:roid>86377203DOMAIN-
NAME</domain:roid> <domain:hostObj>NS1.TEST.CC</domain:hostObj>
<domain:status s="ok"/> </domain:ns>
<domain:ns>NS1.TEST.CC</domain:ns> <domain:host>NS1.TEST.CC</domain:host>
<domain:clID>TEST</domain:clID>
<domain:host>NS1.TEST.CC</domain:host> <domain:crID>TEST-ADMIN</domain:crID>
<domain:clID>TEST</domain:clID> <domain:crDate>2004-09-
<domain:crID>nccmaster</domain:crID> 20T14:23:48.0000Z</domain:crDate>
<domain:crDate>2004-09- <domain:upID>TEST-ADMIN</domain:upID>
20T14:23:48.0000Z</domain:crDate> <domain:upDate>2004-09-
<domain:upID>TEST-ADMIN</domain:upID> 21T15:26:34.0000Z</domain:upDate>
<domain:upDate>2004-09- <domain:exDate>2005-09-
21T15:26:34.0000Z</domain:upDate> 20T14:23:48.0000Z</domain:exDate>
<domain:exDate>2005-09- <domain:authInfo>
20T14:23:48.0000Z</domain:exDate> <domain:pw>password</domain:pw>
<domain:authInfo </domain:authInfo>
type=”pw”>ctldpw</domain:authInfo> </domain:infData>
</domain:infData> </resData>
</resData> <trID>
<trID> <clTRID>ABC-12345</clTRID>
<clTRID>ABC-12345</clTRID> <svTRID>1095780334978-13525</svTRID>
<svTRID>1095780334978-13525</svTRID> </trID>
</trID> </response>
</response> </epp>
</epp>

3.3.2.3 Domain <create>


All systems allow a registrar to create or add a domain (on behalf of a registrant) to the
registry.

3.3.2.3.1 Domain <create> Command Variance


EPP 1.0 changed the way domain name servers are referenced and changed the
formatting of the <authInfo> element. NameStore supports the fully qualified name
server host object through the use of the <domain:hostObj> elements. As of EPP 1.0,
VeriSign® Naming and Directory Services
Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 18
NameStore does not support the use of the “Extensible Provisioning Protocol Extension
Mapping: Namestore Domain Billing “extension, which was a required for Domain
<create> commands in EPP .5.

Table 12 - Domain <create> Command Variance


EPP .5 EPP 1.0
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <?xml version="1.0" encoding="UTF-8" standalone="no
<epp <epp
xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-insta
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.
epp-1.0.xsd" epp-1.0.xsd"
> >
<command> <command>
<create> <create>
<domain:create <domain:create
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain

xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1
domain-1.0.xsd" domain-1.0.xsd"
> >
<domain:name>test.cc</domain:name> <domain:name>test.cc</domain:name>
<domain:period unit="y">2</domain:period> <domain:period unit="y">2</domain:period>
<domain:ns>pri.domainnames.com</domain:ns> <domain:ns>
<domain:ns>ns1.example.cc</domain:ns>
<domain:authInfo <domain:hostObj>pri.domainnames.com</domain:hostObj
type=”pw”>ctldpw</domain:authInfo>
</domain:create> <domain:hostObj>ns1.example.cc</domain:hostObj>
</create> </domain:ns>
<extension> <domain:authInfo>
<namestoreExt:namestoreExt <domain:pw>ctldpw</domain:pw>
xmlns:namestoreExt="http://www.verisign- </domain:authInfo>
grs.com/epp/namestoreExt-1.0" </domain:create>
xsi:schemaLocation="http://www.verisign- </create>
grs.com/epp/namestoreExt-1.0 namestoreExt-1.0.xsd" <extension>
> <namestoreExt:namestoreExt
<namestoreExt:subProduct>dotCC</namestoreExt:subProduct> xmlns:namestoreExt="http://www.verisign-
</namestoreExt:namestoreExt> grs.com/epp/namestoreExt-1.1"
</extension> xsi:schemaLocation="http://www.verisign-
<clTRID>ABC-12345</clTRID> grs.com/epp/namestoreExt-1.1 namestoreExt-1.1.xsd"
</command> >
</epp> <namestoreExt:subProduct>dotCC</namestoreExt:subPro
</namestoreExt:namestoreExt>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>

3.3.2.3.2 Domain <create> Response Variance


No variance between EPP .5 and EPP 1.0 other than for errors as described in section
3.1.4.

3.3.2.4 Domain <update>


All systems allow a registrar to modify or update a domain (on behalf of a registrant)
within the registry.

3.3.2.4.1 Domain <update> Command Variance

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 19
EPP 1.0 changed the way domain name servers are referenced and changed the
formatting of the <authInfo> element. NameStore supports the fully qualified name
server host object through the use of the <domain:hostObj> elements.

Table 13 - Domain <update> Command Variance

EPP .5 EPP 1.0


<?xml version="1.0" encoding="UTF-8" <?xml version="1.0" encoding="UTF-8"
standalone="no"?> standalone="no"?>
<epp <epp
xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema- xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-
1.0 epp-1.0.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-
> 1.0 epp-1.0.xsd"
<command> >
<update> <command>
<domain:update <update>
<domain:update
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-
1.0 domain-1.0.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:domai
> n-1.0 domain-1.0.xsd"
<domain:name>test.cc</domain:name> >
<domain:rem> <domain:name>test.cc</domain:name>
<domain:ns>ns1.example.cc</domain:ns> <domain:rem>
</domain:rem> <domain:ns>
<domain:add>
<domain:ns>ns1.examples.cc</domain:ns> <domain:hostObj>ns1.example.cc</domain:hostObj>
</domain:add> </domain:ns>
</domain:update> </domain:rem>
</update> <domain:add>
<extension> <domain:ns>
<namestoreExt:namestoreExt
xmlns:namestoreExt="http://www.verisign- <domain:hostObj>ns1.examples.cc</domain:hostObj>
grs.com/epp/namestoreExt-1.1" </domain:ns>
xsi:schemaLocation="http://www.verisign- </domain:add>
grs.com/epp/namestoreExt-1.1 namestoreExt-1.1.xsd" </domain:update>
> </update>
<namestoreExt:subProduct>dotCC</namestoreExt:subPro <extension>
duct> <namestoreExt:namestoreExt
</namestoreExt:namestoreExt> xmlns:namestoreExt="http://www.verisign-
</extension> grs.com/epp/namestoreExt-1.1"
<clTRID>ABC-12345</clTRID> xsi:schemaLocation="http://www.verisign-
</command> grs.com/epp/namestoreExt-1.1 namestoreExt-
</epp> 1.1.xsd"
>

<namestoreExt:subProduct>dotCC</namestoreExt:sub
Product>
</namestoreExt:namestoreExt>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>

3.3.2.4.2 Domain <update> Response Variance


No variance between EPP .5 and EPP 1.0 other than for errors as described in section
3.1.4.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 20
3.3.2.5 Domain <renew>
3.3.2.5.1 Domain <renew> Command Variance
As of EPP 1.0, NameStore does not support the use of the “Extensible Provisioning
Protocol Extension Mapping: Namestore Domain Billing “extension, which was a
required for Domain <renew> commands in EPP .5.

3.3.2.5.2 Domain <renew> Response Variance


No variance between EPP .5 and EPP 1.0 other than for errors as described in section
3.1.4.

3.3.2.6 Domain <delete>


All systems allow a registrar to delete availability a domain (on behalf of a registrant)
attributed to them in the registry.

3.3.2.6.1 Domain <delete> Command Variance


No variance between EPP .5 and EPP 1.0.

3.3.2.6.2 Domain <delete> Response Variance


No variance between EPP .5 and EPP 1.0 other than for errors as described in section
3.1.4.

3.3.2.7 Domain <transfer>


Refer to section 2.3.3 for detail on transfer support across EPP .5, EPP 1.0, and
Consolidated EPP 1.0.

3.3.2.7.1 Domain <transfer> Command Variance


EPP 1.0 defines the option to use <domain:authInfo> for a <transfer> query, which is not
supported by NameStore so the syntax for <transfer> query does not change between
EPP .5 and EPP 1.0. The format of the <domain:authInfo> has changed from EPP .5 and
EPP 1.0, which is required for <transfer> requests.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 21
Table 14 - Domain <transfer> Request Command Variance

EPP .5 EPP 1.0


<?xml version="1.0" encoding="UTF-8" standalone="no"?> <?xml version="1.0" encoding="UTF-8"
<epp standalone="no"?>
xmlns="urn:ietf:params:xml:ns:epp-1.0" <epp
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:ietf:params:xml:ns:epp-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 xmlns:xsi="http://www.w3.org/2001/XMLSchema-
epp-1.0.xsd" instance"
> xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
<command> epp-1.0.xsd"
<transfer op="request"> >
<domain:transfer <command>
xmlns:domain="urn:ietf:params:xml:ns:domain- <transfer op="request">
1.0" <domain:transfer
xmlns:domain="urn:ietf:params:xml:ns:domain-
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 1.0"
domain-1.0.xsd"
> xsi:schemaLocation="urn:ietf:params:xml:ns:domain-
<domain:name>test.cc</domain:name> 1.0 domain-1.0.xsd"
<domain:period unit="y">1</domain:period> >
<domain:authInfo> <domain:name>test.cc</domain:name>
<domain:pw roid="JD1234- <domain:period unit="y">1</domain:period>
REP">ctldpw</domain:pw> <domain:authInfo>
</domain:authInfo> <domain:pw roid="JD1234-
</domain:transfer> REP">ctldpw</domain:pw>
</transfer> </domain:authInfo>
<extension> </domain:transfer>
<namestoreExt:namestoreExt </transfer>
xmlns:namestoreExt="http://www.verisign- <extension>
grs.com/epp/namestoreExt-1.1" <namestoreExt:namestoreExt
xsi:schemaLocation="http://www.verisign- xmlns:namestoreExt="http://www.verisign-
grs.com/epp/namestoreExt-1.1 namestoreExt-1.1.xsd" grs.com/epp/namestoreExt-1.1"
> xsi:schemaLocation="http://www.verisign-
grs.com/epp/namestoreExt-1.1 namestoreExt-1.1.xsd"
<namestoreExt:subProduct>dotCC</namestoreExt:subProduct >
>
</namestoreExt:namestoreExt> <namestoreExt:subProduct>dotCC</namestoreExt:subProd
</extension> uct>
<clTRID>ABC-12345</clTRID> </namestoreExt:namestoreExt>
</command> </extension>
</epp> <clTRID>ABC-12345</clTRID>
</command>
</epp>

3.3.2.7.2 Domain <transfer> Response Variance


No variance between EPP .5 and EPP 1.0 other than for errors as described in section
3.1.4.

3.3.2.8 Domain <Restore>


Support of the Domain Registry Grace Period Mapping for the Extensible Provisioning
Protocol extension is newly supported in NameStore Consolidated. The grace period
statuses addPeriod, autoRenewPeriod, renewPeriod, and transferPeriod are not supported.
The redemptionPeriod, pendingDelete, and pendingRestore statuses for supporting the
restore request command. Restore command and restore report commands are new
commands defined in the RGP specification. The restore request/report commands allow
a registrar to undo a delete domain request in some situations.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 22
3.3.2.9 Domain <sync>
Support of the ConsoliDate Mapping for the Extensible Provisioning Protocol extension
is newly supported in NameStore Consolidated. ConsoliDate is used to synchronize a
domain name registration period expiration date, and is specified by including an
<sync:update> extension to an empty domain <update> command..

3.4 EPP Host Command/Response Variance


There are no EPP .5 to EPP 1.0 variances for EPP Host in NameStore since NameStore
does not use the new pending statuses (pendingCreate and pendingUpdate).

3.5 RCCDomain Variance


RCCDomain has the following XML schema changes from EPP .5 to EPP 1.0:
1. The requirement to use a NamestoreExt extension to contain any other extension
has been removed. This was previously required for create operations involving
the RCCLiteralIT and RCCCustContact extensions.
2. The <check> element has had an optional <quality> element added. This
will be used to specify a requested quality for the check responses.
3. The <cd> element has had an optional “quality” attribute added. This will
be used to specify the estimated quality of the check result.
4. The <info>, <update> and <delete> elements can now take either <id> or
<name> to determine the object to operate upon. Use of the <name>
element has the possibility of returning multiple matches in certain cases.
In the case of <info>, the most probable match will be returned, with the
alternatives specified in the <infData> response. For other operations,
multiple matches will cause the operation to operate upon the single
active domain. If there is no active domain, the operation will fail.
5. The <registrantcontact> element has been renamed to <registrant> in all
the locations where it is used.
6. The <admincontact> element has been renamed to <contact
type=”admin”> in all the locations where it is used.
7. The <techcontact> element has been renamed to <contact type=”tech”>
in all the locations where it is used.
8. The <host1> through <host4> elements have been renamed to <ns1>
through <ns4> in all the locations where they are used.
9. New <ns5> though <ns13> elements have been added wherever <ns1>
through <ns4> are used. These will allow more than 4 nameservers to be
used for a domain.
10. The <infData> element has been extended to support zero or more new
<status> elements that specify the currently applied statuses of the
object.
11. The <infData> element has been extended to support zero or more new
<alternativeId> elements that specify other possible domain id’s when the
info request has multiple matches.
12. The <infData> element has been extended to support zero or more new
<host> elements that specify the subsidiary hosts of the domain object.
VeriSign® Naming and Directory Services
Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 23
13. The <infData> element has been extended to include a new <delDate>
element that specifies the date by which the domain must be deleted in
order to avoid auto-renewal.
14. The <update> element has been extended to support the adding or
removing of new <status> elements that specify the required
modifications to the statuses of the object.
15. A new poll message format has been defined. This is documented in the
RCCDomain Mapping Document as the <panData> element.

3.6 RCCHost Variance


RCCHost has the following XML schema changes from EPP .5 to EPP 1.0:
1. The <infData> element has been extended to support zero or more new
<status> elements that specify the currently applied statuses of the object.
2. The <update> element has been extended to support the adding or
removing of new <status> elements that specify the required modifications
to the statuses of the object.

3.7 RCCJob Variance


No variance between EPP .5 and EPP 1.0.

VeriSign® Naming and Directory Services


Protocol Variance Document: EPP .5, 1.0, 1.0 Consolidated
VNDS Proprietary and Confidential • 24

You might also like