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.

Proposed Unsponsored TLD Agreement: Appendix C, Part 6 (.name)

ICANN | Proposed Unsponsored TLD Agreement: Appendix C, Part 6 (.name)
  ICANN Logo

Proposed Unsponsored TLD Agreement: Appendix C,
Part 6 (.name)

(2 July 2001)


Functional Specifications

Part 6 - Object Transfers

This section describes the technical process surrounding transfers of objects between Registrars, other than transfers approved by ICANN under Appendix F (Registry-Registrar Agreement), Exhibit D, Part B, which are performed by batch processes manually initiated by Registry Operator personnel.

The EPP <transfer> command is used to manage changes in Registrar sponsorship of a known object. Registrars 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, Emailforwarding and Contact objects. Nameserver (host) objects are implicitly transferred when a domain is transferred between registrars.

Initiation of Transfers

A Registrar that wishes to assume sponsorship of a known object from another registrar 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.

Approval/Rejection

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 put in the message queue of the affected Registrar and be retrieved when the Registrar later uses the EPP <poll> command. The current status of a pending <transfer> command for any object may be found by the losing and gaining registrar 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".

Authorization

Every <transfer> request command must include an authorization identifier to confirm transfer authority. This element contains authorization information associated with the object, or alternatively for domain and emailforwarding objects, authorization information associated with the registrant or associated contacts, as specified in the EPP drafts.

The Authorization identifier information must not be disclosed to any other Registrar or third party. A Registrar that 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.

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.

Transfer notification

Transfer notifications will be put in a message queue in the Registry System. These notifications can be retrieved and acknowledged through the EPP <poll> command at any time. Information about the request can also 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 emailforwarding objects, the fully qualified email address of the object should be specified, and for contact objects the contact ID that serves as a unique identifier should be specified.

For domain objects and emailforwarding objects, the Registrar may also provide an element that contains the number of years to be added to the registration period of the object if the transfer is successful. The minimum and maximum allowable values for the extension is one year and ten years, respectively, and the default value is one year. Registry operator policy restricts the maximum outstanding expiration period for domain objects and emailforwarding objects to ten years. A transfer with an extension period that exceeds this limit will be rejected. Exception: If the addition of the minimum allowable value of extension would extend the registration period past the maximum outstanding expiration years, the transfer will go through, but with no registration extension.

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].


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

Page Updated 03-Jul-2001

(c) 2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.