Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

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

ICANN | Unsponsored TLD Agreement: Appendix C, Section H (.info)
  ICANN Logo

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

(26 April 2001)


Functional Specifications

Section H—Object Transfers

This section describes the technical process surrounding transfers of objects between Registrars.

The EPP <transfer> command is used to manage changes in Registrar sponsorship of a known object. Registrar's may initiate a transfer request, cancel a transfer request, approve a transfer request, and reject a transfer request using the "op" command attribute of the <transfer> command.

The EPP <transfer> command can only be used to explicitly transfer Domain and Contact objects. Nameserver (host) objects are implicitly transferred when a domain is transferred between registrars.

Authorization

Every <transfer> command must include an authorization identifier to confirm transfer authority. This identifier is a copy of the transaction identifier associated with the most recent command causing a change of sponsorship, such as the most recently successful command or the original command (e.g. that created the object). The identifier associated with the original command must be used to authorize the first transfer of an object. After an object has been successfully transferred at least once, the identifier associated with the most recent successful command must be used to authorize transfer of an object. Registrars performing a <transfer> command on behalf of a third party must provide the third party with a copy of the transaction identifier used to request the transfer.

The Authorization identifier information must not be disclosed to any other Registrar or third party. A Registrar who wishes to transfer an object on behalf of a third party must receive authorization identifier information from the third party before a command can be executed.

Procedure

A Registrar who wishes to assume sponsorship of a known object from another client uses the <transfer> command with the value of the "op" attribute set to "request". Once a transfer has been requested, the same Registrar may cancel the request using a command with the value of the "op" attribute set to "cancel". A request to cancel the transfer must be sent to the Registry before the current sponsoring Registrar either approves or rejects the transfer request and before the Registry automatically processes the request due to inactivity on the part of the current sponsoring Registrar.

Once a transfer request has been received by the Registry, the Registry will notify the current sponsoring Registrar of the requested transfer. This notification will be done using an out-of-band communication method, specifically, via e-mail. The current status of a pending <transfer> command for any object may be found using the <transfer> query command.

The current sponsoring Registrar may explicitly approve or reject the transfer request. The Registrar may approve the request using a <transfer> command with the value of the "op" attribute set to "approve". The Registrar may reject the request using a <transfer> command with the value of the "op" attribute set to "reject".

Automatic Transfer

The Registry will automatically approve all transfer requests that are not explicitly approved or rejected by the current sponsoring Registrar within five calendar days of the transfer request. The losing registrar will be notified via e-mail of the automatic transfer.

Out of Band Communication

The Registry will use an out-of-band service, specifically e-mail, to inform Registrars of a transfer for which a response is expected. Once a Registrar is aware of a requested transfer, information about the request may be found using the <transfer> query command.

Protocol Details

When using the EPP <transfer> command for domain objects, the Registrar will specify the fully qualified domain name of the object for which a transfer request is to be created, approved, rejected, or cancelled. For contact objects, the contact ID that serves as a unique identifier should be specified.

For domain objects, the Registrar must also provide an element that contains the number of years to be added to the registration period of the domain if the transfer is successful. The minimum and maximum allowable values for the domain extension is one year and ten years, respectively. Afilias policy restricts the maximum outstanding expiration period to ten years. A transfer with an extension period that exceeds this limit will be rejected. This element must be consistently present for all associated request, approval, rejection, or cancellation operations.

Every EPP <transfer> command issued by a Registrar must contain an "op" attribute that specifically identifies the transfer operation to be performed. Valid values, definitions, and authorizations for all attribute values are defined in [EPP].

In addition, every EPP <transfer> command must also contain an authorization identifier as described in [EPP]. The transaction identifier associated with a successful transfer of a domain object becomes the authorization identifier required to authorize subsequent transfers of sponsorship of the domain object. A Registrar must retain all transaction identifiers associated with successful domain object transfers and protect them from disclosure. A Registrar must provide a copy of the transaction identifier information to the domain registrant, who will need this information to request a domain transfer through a different Registrar.


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 24-Dec-2002

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