Unsponsored TLD Agreement: Appendix C, Section A (.info)

Unsponsored TLD Agreement: Appendix C, Section A (.info)

(26 April 2001)

Functional Specifications

Section A—The SRS Protocol (Extensible Provisioning Protocol)

Overview

The .info registry implementation for Afilias LLC by Liberty Registry Management Services will feature a "thick" model as typified by the rich object store managed by the centralized Registry. This object store can be managed by accredited registrars via the SRS interface that will be using the interface protocol specified by the November 2000 IETF Hollenbeck Extensible Provisioning Protocol (EPP) drafts. As these drafts progress through the standard process, the Registry will, where appropriate, manage towards ensuring that the most current version of the standard is supported as outlined in the "Protocol Development/Change Management" section below.

It is the intent of this portion of the document to provide Registrar operations development support staff with an overview of the protocol by which they can guide their integration efforts.

The EPP specification is broken up into an extensible object design with each of the primary objects given an individual but consistent interface that meet the base EPP framework as described below:

Registry Protocol Highlights (EPP)

Base EPP Framework
Reference: [EPP]

This document describes the foundation upon which all of the specific objects (Domains, Hosts, Contacts) must adhere to in order to maintain a consistent interface. In order to support this foundation a base XML/XSD framework will be designed and developed. The Registry is using the (Xerces-J) XML package from http://xml.apache.org as a foundation, as is it the standard XML parser for JAVA and also supports XML Schema. This package is also available in Perl and C++.

EPP TCP Server
Reference: [EPP-TCP]

This document dictates the TCP connection strategies to use and is almost identical to the existing NSI RRP implementation. Therefore, the EPP Server implementation structure will mirror the existing RRP Server design using TCP/IP and SSL to secure transport.

Domains
Reference: [EPP-D]

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.

Nameservers (Hosts)
Reference: [EPP-H]

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.

Contacts
Reference: [EPP-C]

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of identifiers representing individuals or organizations (known as "contacts") stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to contacts.

Supported Command Set

The Registry will provide the following command sets to support the Registry Service.

• Greeting
• Session management
• Object Query
• Object Transform

The command sets are described in more detail below.

Greeting

An EPP server shall respond to a successful connection by returning a greeting to the client. The greeting response includes information such as:

• The name of the server
• The server's current date and time in UTC
• The features supported by this server, which may include:
  • One or more protocol versions supported by the server
  • One or more languages for the text response supported by the server
  • One or more elements which identify the objects that the server is capable of managing

Session Management Commands

EPP provides two commands for session management: <login> to establish a session with a server, and <logout> to end a session with a server.

Login

The EPP <login> command is used to establish a session with an EPP server in response to a greeting issued by the server. A <login> command MUST be sent to a server before any other EPP command.

Logout

The EPP <logout> command is used to end a session with an EPP server.

Object Query Commands

EPP provides three commands to retrieve object information: <info> to retrieve detailed information associated with a known object, <check> to determine if an object is known to the server, and <transfer> to retrieve known object transfer status information.
These are described below.

Info

The EPP <info> command is used to retrieve information associated with a known object. The elements needed to identify an object and the type of information associated with an object are both object-specific, so the child elements of the <info> command are specified using the EPP extension framework.

Check

The EPP <check> command is used to determine if an object is known to the server. The elements needed to identify an object are object-specific, so the child elements of the <check> command are specified using the EPP extension framework.

Transfer (Query)

The EPP <transfer> command provides a query operation that allows a client to determine real-time status of pending and completed transfer requests. The elements needed to identify an object that is the subject of a transfer request are object-specific, so the child elements of the <transfer> query command are specified using the EPP extension framework.

Object Transform Commands

EPP provides five commands to transform objects: <create> to create an instance of an object with a server, <delete> to remove an instance of an object from a server, <renew> to extend the validity period of an object, <update> to change information associated with an object, and <transfer> to manage changes in client sponsorship of a known object.

These are described below.

Create

The EPP <create> command is used to create an instance of an object. An object may be created for an indefinite period of time, or an object may be created for a specific validity period. The EPP mapping for an object MUST describe the status of an object with respect to time, to include expected client and server behavior if a validity period is used.

Delete

The EPP <delete> command is used to remove an instance of a known object. The elements needed to identify an object are object-specific, so the child elements of the <delete> command are specified using the EPP extension framework.

Renew

The EPP <renew> command is used to extend the validity period of an object. The elements needed to identify and extend the validity period of an object are object-specific, so the child elements of the <renew> command are specified using the EPP extension framework.

Transfer

The EPP <transfer> command is used to manage changes in client sponsorship of a known object. Clients may initiate a transfer request, cancel a transfer request, approve a transfer request, and reject a transfer request.

Update

The EPP <update> command is used to change information associated with a known object. The elements needed to identify and modify an object are object-specific, so the child elements of the <update> command are specified using the EPP extension framework.

Examples

Implementation of these commands with specific examples can be found in Section B - Transactional Services Overview.

Protocol Development/Change Management

The IETF Provisioning Registry Protocol "provreg" working group [PROVREG] has been chartered to develop a specification for the requirements and limitations for a protocol that enables a registrar to access multiple registries. The working group will also develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications. The EPP has been proposed as a candidate for this purpose. The working group's target is to have a draft for a standards track protocol by September 2001.

Afilias expects the activities in the working group to have significant impacts on both Registry and Registrar systems. As such, Afilias will take the following steps to ensure that it will be able to migrate to a protocol that has been accepted as an IETF standard.

1. Key technical staff will actively participate in the IETF process though the provreg mailing list as well as attend IETF meetings. Afilias believes that its early adoption of the EPP protocol will allow it to provide valuable feedback to the Internet community with regards to the suitability of the EPP for Registrar-Registry interaction.

2. Within 135 days of the IESG's adoption of a preliminary standard [RFC2026] based on the "provreg" working group's protocol specification, Afilias will implement support for the protocol in the OT&E environment. Registrars will be notified of any proposed changes at least 30 days prior to their introduction into the OT&E test environment. Once the new features are available in OT&E, Afilias will provide at least 30 days for Registrars to upgrade their client systems before introducing the features into the live environment. In connection with these changes to the live environment, Afilias will give Registrars the notice required by Section 2.4 of the Registry-Registrar Agreement, Appendix F.

If technically possible, Afilias will provide backwards compatibility for older versions of the protocol to ease the migration to the new standard. If the accepted protocol is EPP, it will be supported as follows: When a Registrar connects to the Registry using the EPP <greeting> command, the Registry will announce what Schemas it supports for the various EPP mappings (domains, hosts, contacts). In this way, the Registrar will be able to determine if the Registry supports the EPP protocol it is using. If modifications are made to the protocol, such that the Schema mappings change, the Registry will continue to offer backward compatibility for the previous Schema(s) for some period of time (at least 30 days). During that overlap period, both the new and old Schemas will be supported. This will allow a Registrar to perform Registry transactions using the old Schemas, until they have completed their conversion to the new Schemas.

3. If necessary, Afilias will update the Registrar Tool Kit to support changes to the protocol.

Page Updated 24-Dec-2002

©2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.