EPP 1.0 FAQ

When will the ccTLD SRS be upgraded to EPP v.1.0?
What are the differences in the old EPP system (v.07/05) versus the new EPP v.1.0 system?
Will my v.07/05 client work with EPP V1.0?
What is the <dcp> element referenced in RFC 3730 and what is PIR?s policy?
What is the <disclose> element provided for in RFC 3733?
Is a new OT&E test mandatory for current .ORG registrars who are in the live Production system?
When will the new EPP v.1.0 OT&E environment and RTK be available?
If I am currently completing my registrar requirements to go live, will I be able to pass my OT&E test with the old (version 07/05) RTK and still transact with the registry?
Will the new EPP v.1.0 RTK work with the old EPP v.07/05 system?
Will the old EPP v.07/05 RTK work with the new EPP v.1.0 EPP system?
Will Afilias provide assistance to registrars who need to modify their existing clients?
Where can I find examples for DomainCreate and DomainUpdate commands in the EPP v.1.0 RTK?
Is the OT&E now running with EPP v.1.0?
Will a new DomainInfo Command be deployed in the ccTLD complex? What will be the difference between the new DomainInfo Command and the current DomainInfo Command?
When will the new DomainInfo Command be available for testing in OT&E?
Will I be required to modify my EPP client to function with the new DomainInfo Command changes?

1. When will the ccTLD SRS be upgraded to EPP v.1.0?

Afilias will upgrade the ccTLD SRS to be compliant with EPP v.1.0, RFCs 3730 through 3735, on 25 June 2005. The OT&E environment has already been upgraded.

2. What are the differences in the old EPP system (v.07/05) versus the new EPP v.1.0 system?

The differences are minor. RFC 3730 requires the transmittal of a <dcp> (Data Collection Policy) and RFC 3733 introduces an optional <disclose> element as a privacy mechanism for contacts.

The new EPP RFC also introduces several changes in the way host objects are handled within certain domain operations that will require registrars to modify their EPP client.

The registrar must submit host information in the following syntax within the DomainCreate and DomainUpdate command and parse response to DomainInfo command.

<domain:ns>

<domain:hostObj>ns1.afilias.org</domain:hostObj>

<domain:hostObj>ns2.afilias.org</domain:hostObj>

</domain:ns>

These new items will impact existing v.07/05 clients. It is therefore suggested that registrars utilize the Operational Testing & Evaluation (OT&E) environment to test their clients' functionality.

3. Will my v.07/05 client work with EPP V1.0?

Possibly not. All registrars will need to modify their client code to work with the new EPP V1.0 SRS. The ccTLD OT&E environment has been upgraded to EPP 1.0 for your testing use.

The .ORG system that Afilias operates is an EPP 1.0 system, so if you are a .ORG registrar you can use the same client to intract with our ccTLD SRS. If you like, you can manage your domains by using our Web admin tool only.

4. What is the <dcp> element referenced in RFC 3730 and what is the policy?

The <dcp> element described in RC 3730 requires the transmittal of a Data Collection Policy to be part of the initial greeting message when a registrar connects to the registry. Therefore the <dcp> element is intended to describe the individual policy for data collection and management by the registry in question. An optional <expiry> element may also be sent to describe the lifetime of that privacy policy.

Since Afilias does not maintain a specific privacy policy in the EPP system, the new RFC-compliant production system will send a non-blank <dcp> tag to registrars to ensure that future non-blank <dcp> tags will work correctly.

If v.07/05 clients currently include robust exception handling, the addition of the <dcp> element will not impact the registrar?s login process.

5. What is the <disclose> element provided for in RFC 3733?

In RFC 3733 (Contact Mapping) the <disclose> element is introduced as the privacy mechanism for contacts. Under the RFC, the registry will disclose the default disclosure policy on contacts when establishing a session with a client. If the registry?s Data Collection Policy allows, when an object is created or updated, the client can specify contact attributes that require exceptional disclosure handling using the optional <disclosure> element. This must be in conformance with the announced policy in the <dcp> element or it will be rejected by the registry.

The v.07/05 ccTLD system does not support the <disclose> element; however the new EPP v.1.0 system will introduce support for this optional element in contact mapping. Clients that do not implement this feature should work as is, since this element is optional.

6. Is a new OT&E test mandatory for current ccTLD registrars who are in the live production system?

No. Though current ccTLD registrars in the live production system will not be required to complete a new OT&E test in order to transact with the new ccTLD production system, Afilias recommends that all registrars utilize the OT&E environment to verify the functionality of its client. Current Production registrars only need to test the new elements contained in EPP v.1.0, which are the following sections of the new EPP Acceptance Criteria:

Section 1. Introduction
Subsections 1.1 through 1.6

Section 2. EPP Communications

Subsection 2.1 Session Management

Subsection 2.1.1

Subsection 2.1.2

Subsection 2.2 Domain Name Operations

Subsection 2.2.1

Subsection 2.2.10

Subsection 2.2.17

Subsection 2.3 Name Server Operations

Subsection 2.3.1

Subsection 2.4 Contact Operations

Subsection 2.4.1

Subsection 2.6 Empty Element Commands

Subsection 2.6.1

Subsection 2.7 End Session

7. When will the new EPP v.1.0 OT&E environment and RTK be available?

The are available now. Registrars can access EPP v.1.0 OT&E using their existing username and password. The RTK and OT&E Acceptance Criteria are available for download.

8. If I am currently completing my registrar requirements to go live, will I be able to pass my OT&E test with the old (version 07/05) RTK and still transact with the registry?

No. Registrars who complete the business and technical requirements after May 25, 2005 will be required to pass the new EPP v.1.0 OT&E test.

9. Will the new EPP v.1.0 RTK work with the old EPP v.07/05 system?

No. The new EPP v.1.0 introduces several changes that will require registrars to modify their client to properly connect to the new EPP v.1.0 system.

The RFC 3731 requires registrars to submit host information within the DomainCreate and DomainUpdate commands. The registrar must submit host information in the following syntax within the DomainCreate and DomainUpdate command and parse response to DomainInfo command.

<domain:ns>

<domain:hostObj>ns1.afilias.org</domain:hostObj>

<domain:hostObj>ns2.afilias.org</domain:hostObj>

</domain:ns>

10. Will the old EPP v.07/05 RTK work with the new EPP v.1.0 EPP system?

No. EPP v.1.0 system requires changes regarding the handling of host objects within certain domain operations which are not recognized in EPP v.07/05. The registrars will be required to modify their current EPP v.07/05 to include these changes. Also, registrars will need to verify that their client meets the <dcp> requirements of RFC 3730, which are detailed above.

11. Will Afilias provide assistance to registrars who need to modify their existing clients?

Technical Support may provide assistance regarding templates for clarification on changes necessary for Java, C++, or Perl RTK implementations.

12. Where can I find examples for DomainCreate and DomainUpdate commands in the EPP v.1.0 RTK?

Please download the EPP v1.0 RTK package from the following URL:

href="http://www.afilias-grs.info/public/registrars/">http://www.afilias-grs.info/public/registrars/

For specifics on passing the syntax within the DomainCreate and DomainUpdate command, the registrar must look at the examples in the RTK in the following directory:

/epp-rtk-java-0.9.1/java/src/com/tucows/oxrs/epp0705/rtk/example

13. Is the OT&E now running with EPP v.1.0?

Yes.

14. Will a new DomainInfo Command be deployed in the ccTLD complex? What will be the difference between the new DomainInfo Command and the current DomainInfo Command?

Effective June 25, 2005, the ccTLD registry will respond with a thin reply (rather than a thick reply) to the DomainInfo command for domains not under sponsorship by the registrar. This response is already implemented in the .ORG registry that Afilias operates.

The thin reply will contain the following:

Domain name

Domain Registry id

Sponsoring Registrar code

list of status values ()

A thick reply will be provided when the DomainInfo command is submitted on domains that either the registrar is an owner of (sponsoring registrar), or for domains when the registrar includes a valid authinfo code.

15. When will the new DomainInfo Command be available for testing in OT&E?

The new DomainInfo Command is deployed for testing in OT&E.

16. Will I be required to modify my EPP client to function with the new DomainInfo Command changes?

Yes, but only if you parse the server's response looking for specific XML tags, you may have to adjust your client accordingly.

For example; The DomainInfo response to non-sponsoring registrars will be different from the current DomainInfo response. Therefore if your EPP client expects certain fields in the response, you will have to adjust it to anticipate the appropriate fields in the response.