Generic Top-Level Domain (gTLD) Registry Agreements
Unsponsored TLD Agreement: Appendix C, Section B (.info)
 |
Unsponsored TLD Agreement: Appendix C, Section B (.info) (11 May 2001) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Functional Specifications Section B—Database Services The Registry database will serve as the authoritative source of data for all aspects of the Registry Service. Authorized Registrars will be permitted to interact with this data according to the EPP specifications using the commands specified in Transactional Services, below. The Registry database will also serve as the authoritative source of data for all other aspects of the Registry Service including Whois, xWhois, Domain Name Service and billing. The following sections describe the objects stored within the database, the transactional services that can be applied to these objects and the billing services that are triggered because of these transactions. Object Store Overview The Database system will support the following object stores: Contact objects, Host Objects, Domain Name objects, and Registrar Objects. The set of these objects defines a "thick" registry, as all the information associated with registered entities, including technical and social information, is stored within the registry repository. Definitions of attributes for Contact, Host and Domain Name objects can be found in the EPP Mapping drafts, which have been included as attachments to this appendix. The object stores are described below. Contact Objects The system will support the mapping, provisioning and management of identifiers representing individuals or organizations (known as "contacts") stored in a shared central repository. The contact mapping is specified in XML, and follows EPP command syntax and semantics as applied to contacts. The attributes, associated values, and formal syntax are described in Extensible Provisioning Protocol Contact Mapping [EPP-C], in sections 2 and 4. The contact object has attributes and associated values that may be viewed and modified by the sponsoring client or the server. Host Objects The system will support the mapping, provisioning and management of Internet host names stored in a shared central repository. The host mapping is specified in XML, and follows EPP command syntax and semantics as applied to host names. The attributes, associated values, and formal syntax are described in Extensible Provisioning Protocol Host Mapping [EPP-H], in sections 2 and 4. The Internet host names object has attributes and associated values that may be viewed and modified by the sponsoring client or the server. Domain Name Objects The system will support the mapping, provisioning and management of Internet domain names stored in a shared central repository. The mapping is specified in XML, and follows EPP command syntax and semantics as applied to domain names. The attributes, associated values, and formal syntax are described in Extensible Provisioning Protocol Domain Name Mapping [EPP-D], in sections 2 and 4. The Internet domain names object has attributes and associated values that may be viewed and modified by the sponsoring client or the server. Registrar Objects The system shall support the mapping, provisioning and management of Registrars stored in a shared central repository. The Registrar object has attributes and associated values that may be viewed and modified by the sponsoring client or by the Registry. The Registrar object cannot be manipulated directly via EPP. The Registry/Registrar Administrative Interfaces are used to create, update, delete and otherwise manage these objects. Database Structure This section describes the database schema and rules for the objects supported by the registry. BNF Definitions The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [RFC2234].
Domain Object The epp_domain table stores information about a domain object. The following field definitions are based on the EPP Domain Mapping schema described in [EPP-D].
Host Object The epp_host table stores information about a host object. The following field definitions are based on the EPP Host Mapping schema described in [EPP-H].
The epp_domain_host table associates a domain object with one or more host objects:
The epp_ip table stores information about an IP addresses. The following field definitions are based on the EPP Host Mapping schema described in [EPP-H].
The epp_host_ip table associates a host with one or more IP addresses.
Contact Object The epp_contact table stores information about a contact object. The following field definitions are based on the EPP Contact Mapping schema described in [EPP-C].
The epp_domain_contact table associates a domain object with one or more contact objects. The following field definitions are based on the EPP Contact Mapping schema described in [EPP-C].
Registrar Object The epp_registrar table stores information about a registrar object.
The epp_registrar_contact table associates a registrar object with one or more contact objects.
Authorized Registrars can interact with the objects in the database via the SRS using the following transactional services.
The Billing Services will handle billing events associated with the above transactions. This is described in "Billing Services Overview". Command Set The following command set will allow Authorized Registrars to interact with the data in the object store. Examples of the EPP commands and responses can be found in the EPP drafts, which have been included as attachments to this appendix. Add Domain Registrars use the Add Domain command to create a new domain object in the Registry. The creation of a new domain is a billable operation. Domains can be created with associated nameservers and contacts. The EPP specification permits from 0 to 13 nameservers, however Afilias policy only permits domains with two or more nameservers to be resolvable. The EPP specification permits from 0 to 4 contact handles, however Afilias policy requires all four contact handles. The Add Domain command can be specified with an optional registration period, with minimum and maximum values of one and ten years, respectively. If the registration period is not specified, the initial registration period will be the minimum required by the Registry. Afilias policy restricts the maximum outstanding expiration period to ten years, which the Registry System enforces. Add Domain uses the EPP Domain Mapping <create> command. An example of an Add Domain command can be found in the EPP Domain Mapping [EPP-D] draft in section 3.2.1. Modify Domain A registrar uses the Modify Domain command to change attributes of a domain for which it is the sponsoring registrar. Attributes that can be changed include: contact information, nameservers and domain status. The EPP specification permits from 0 to 13 nameservers, however Afilias policy only permits domains with two or more nameservers to be resolvable. The EPP specification permits from 0 to 4 contact handles, however Afilias policy requires all four contact handles. Modification of domain attributes is a non-billable operation. Modify Domain uses the EPP Domain Mapping <update> command. An example of a Modify Domain command can be found in the EPP Domain Mapping [EPP-D] draft in section 3.2.5. Delete Domain Registrars use the Delete Domain command to remove a domain object from the Registry. A registrar can only delete domains for which it is the sponsoring registrar. The deletion of a domain may trigger a billing operation if the deletion is performed within certain grace periods. When a domain is deleted, all Host objects for which this domain is the parent domain will also be deleted. As a result of this requirement, a domain can only be deleted if these nameservers are not associated with any domains in the Registry. Delete Domain uses the EPP Domain Mapping <delete> command. An example of a Delete Domain command can be found in the EPP Domain Mapping [EPP-D] draft in section 3.2.2. Renew Domain Registrars use the Renew Domain command to extend the expiration year for a domain object. A registrar can only renew domains for which it is the sponsoring registrar. The renewal of a domain is a billable operation. The Renew Domain command must be specified with a registration period, from one to ten years. Afilias policy restricts the maximum outstanding expiration period to ten years. A domain renewal with an extension period that exceeds this limit will be rejected. Renew Domain uses the EPP Domain Mapping <renew> command. An example of a Renew Domain command can be found in the EPP Domain Mapping [EPP-D] draft in section 3.2.3. Auto-Renew Domain When a domain reaches its expiration date the Registry will automatically renew the domain for one additional year. The automatic renewal of a domain is a billable operation. A registrar has the duration of the auto-renewal grace period to delete the domain and receive a refund for the automatic renewal. Afilias policy restricts the maximum outstanding expiration period to ten years. Transfer Domain Registrars use the Transfer Domain command to change a domain's sponsoring registrar. The transfer request is issued by the gaining registrar, after which the Registry will notify the current registrar of the request to transfer the domain. The current registrar may choose to accept or deny the transfer request. If the current registrar takes no action, the Registry will automatically accept the transfer after a pre-determined number of days. A domain that is transferred will have its expiration date extended by at least one year. The expiration extension is a billable operation. When a domain is transferred, all Host objects for which this domain is the parent domain will also be transferred to the gaining registrar. Transfer Domain uses the EPP Domain Mapping <transfer> transform command. Please note that this is different from the EPP <transfer> query command. An example of a Transfer Domain command can be found in the EPP Domain Mapping [EPP-D] draft in section 3.2.4. Bulk Transfer Per Appendix F, Exhibit D, Part B, ICANN may request Afilias to perform a bulk transfer of all registered objects from one registrar to another registrar. The bulk transfer will not be performed with the use of EPP commands. Instead it will be performed as a bulk database update of the Owned By field for all objects currently sponsored by the losing registrar. Check Domain Registrars use the Check Domain command to find out if a domain exists as a valid object in the Registry. The Registry will return a result of "known" or "unknown" to the Check Domain request. The checking of a domain is a non-billable operation. Check Domain uses the EPP Domain Mapping <check> command. An example of a Check Domain command can be found in the EPP Domain Mapping [EPP-D] draft in section 3.1.2. Query Domain Registrars use the Query Domain command to retrieve the domain information of a domain object in the Registry. Only the sponsoring registrar of a domain can retrieve its domain information. The query for domain information is a non-billable operation. Query Domain uses the EPP Domain Mapping <info> command. An example of a Query Domain command can be found in the EPP Domain Mapping [EPP-D] draft in section 3.1.1. Query Domain Transfer Status Registrars use the Query Domain Transfer Status command to find out the status of a domain transfer. The query for domain transfer status information is a non-billable operation. Query Domain Transfer Status uses the EPP Domain Mapping <transfer> query command. Please note that this is different from the EPP <transfer> transform command. An example of a Query Domain Transfer Status command can be found in the EPP Domain Mapping [EPP-D] draft in section 3.1.3. Add Nameserver Registrars use the Add Nameserver command to create a new host object in the Registry. The creation of a new nameserver is a non-billable operation. Nameservers can only be created by the sponsoring registrar of the parent domain object. A nameserver can be created with up to 13 IP addresses. Add Nameserver uses the EPP Host Mapping <create> command. An example of an Add Nameserver command can be found in the EPP Host Mapping [EPP-H] draft in section 3.2.1. Modify Nameserver Registrars use the Modify Nameserver command to change the IP addresses associated with a nameserver. The modification of a nameserver is a non-billable operation and can only be performed by the sponsoring registrar of the nameserver. Modify Nameserver uses the EPP Host Mapping <update> command. An example of a Modify Nameserver command can be found in the EPP Host Mapping [EPP-H] draft in section 3.2.5. Delete Nameserver Registrars use the Delete Nameserver command to remove a host object from the Registry. A registrar can only delete a nameserver for which it is the sponsoring registrar. The deletion of a nameserver is a non-billable operation. A nameserver can only be deleted if is not associated with any domains in the Registry. Delete Nameserver uses the EPP Host Mapping <delete> command. An example of a Delete Nameserver command can be found in the EPP Host Mapping [EPP-H] draft in section 3.2.2. Check Nameserver Registrars use the Check Nameserver command to check to see if a nameserver object exists in the Registry. The Registry will return a result of "known" or "unknown" for the nameserver requested. Checking nameserver existence is a non-billable operation. Check Nameserver uses the EPP Host Mapping <check> command. An example of a Check Nameserver command can be found in the EPP Host Mapping [EPP-H] draft in section 3.1.2. Query Nameserver Registrars use the Query Nameserver command to retrieve the host object's information for a nameserver. Only the sponsoring registrar of the nameserver can query for a nameserver's information. Querying for a nameserver's information is a non-billable operation. Query Nameserver uses the EPP Host Mapping <info> command. An example of a Query Nameserver command can be found in the EPP Host Mapping [EPP-H] draft in section 3.1.1. Add Contact Registrars use the Add Contact command to create a new contact object in the Registry. The creation of a new contact is a non-billable operation. Add Contact uses the EPP Contact Mapping <create> command. An example of an Add Contact command can be found in the EPP Contact Mapping [EPP-C] draft in section 3.2.1. Modify Contact Registrars use the Modify Contact command to change the attributes of a contact object. The modification of a contact is a non-billable operation and can only be performed by the sponsoring registrar of the contact. Modify Contact uses the EPP Contact Mapping <update> command. An example of a Modify Contact command can be found in the EPP Contact Mapping [EPP-C] draft in section 3.2.5. Delete Contact Registrars use the Delete Contact command to remove a contact object from the Registry. A registrar can only delete a contact for which it is the sponsoring registrar. The deletion of a contact is a non-billable operation. A contact can only be deleted if is not associated with any domains in the Registry. Delete Contact uses the EPP Contact Mapping <delete> command. An example of a Delete Contact command can be found in the EPP Contact Mapping [EPP-C] draft in section 3.2.2. Transfer Contact Registrars use the Transfer Contact command to change a domain's sponsoring registrar. Transfer Contact uses the EPP Contact Mapping <transfer> transform command. Please note that this is different from the EPP <transfer> query command. An example of a Transfer Contact command can be found in the EPP Contact Mapping [EPP-C] draft in section 3.2.4. Check Contact Registrars use the Check Contact command to check to see if a contact object exists in the Registry. The Registry will return a result of "known" or "unknown" for the contact requested. Checking contact existence is a non-billable operation. Check Contact uses the EPP Contact Mapping <check> command. An example of a Check Contact command can be found in the EPP Contact Mapping [EPP-C] draft in section 3.1.2. Query Contact Registrars use the Query Contact command to retrieve the contact object's information for a contact. Querying for a contact's information is a non-billable operation. Query Contact uses the EPP Contact Mapping <info> command. An example of a Query Contact command can be found in the EPP Contact Mapping [EPP-C] draft in section 3.1.1. Query Contact Transfer Status Registrars use the Query Contact Transfer Status command to find out the status of a contact transfer. The query for contact transfer status information is a non-billable operation. Query Contact Transfer Status uses the EPP Contact Mapping <transfer> query command. Please note that this is different from the EPP <transfer> transform command. An example of a Query Contact Transfer Status command can be found in the EPP Contact Mapping [EPP-C] draft in section 3.1.3. Billing Services Overview The Billing subsystem handles all billing events from the Registry that are created as part of normal registry operations. This mechanism also handles requests from the Registrar Administration facility as well as from the Registry Administration facility. The Billing mechanism interfaces with the Afilias Financial system by way of a database interface. The billing subsystem is composed of:
XRS Billing Subsystem The "XRS Billing" subsystem executes as a part of the same subsystem that controls base registry transactions. This ensures transactional integrity between the billing server and the registry server. Examples for billing events handled by the API are
The Billing Process The main premise of the Billing subsystem is that the Registry sends billing events, which require an immediate response enabling the registration process to take place. The billing implementation reflects a pre-paid billing model where a balance is debited for each bill event presented. A negative response is returned by the Billing subsystem if there are not sufficient funds available to complete the requested event. An EPP operation that receives a negative response from the billing subsystem will return an "operation failed" response to the Registrar that initiated the operation. Each Billing subsystem event has a dependency on the Registry Administrator having done the following:
The Billing Events must contain the "Transaction Id" as outlined in the EPP specification. This enables registry events to be traced in terms of their billing consequences. The Billing subsystem operates in US dollars only. Registrar Administration Interface Each registrar will be provided with a username/password to access a secured web site where it can perform certain functions.
Registry Administration Interface The Registry Administrative interface is designed for an administrator of the Afilias Registry. This interface provides the same functions as the Registrar Administration interface except administrator staff will be able to perform the operation on any registrar's account. In addition, there are some Registry-only functions. This includes:
Afilias management will also be able to use this interface to manage accounts for administration staff and define roles to restrict the functionality available to a particular staff. Earlier draft: Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org. Page Updated 24-Dec-2002 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||