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.

.MOBI Appendix 5

Appendix 5
  icann logo
Appendix 5




Whois Specifications

Public Whois Specification



Public Whois for the Sponsored TLD will be provided according to the specification described in Appendix S.



Whois Provider Data Specification



Registry Operator shall ensure the provision of bulk access to up-to-date data concerning domain name and nameserver registrations maintained on behalf of

Registry Operator in connection with the Sponsored TLD on a daily schedule, only for purposes of providing free public query-based access to up-to-date data concerning domain name and nameserver registrations in multiple TLDs, to a party designated from time to time in writing by ICANN (the "Designated Recipient"). Any agreement between ICANN and a Designated Recipient for the license of such data (a "Whois License Agreement") will provide Registry Operator with the right to enforce the Designated Recipient's obligations under this Appendix and the Whois License Agreement directly against the Designated

Recipient, whether through being made a party to or third-party beneficiary of such agreement or through such other means as may be appropriate. In addition, any Whois License Agreement will include the following provisions governing the use of such data by the Designated Recipient:



1. The Designated Recipient shall only use the data provided by the Registry Operator for the purpose of providing free public query-based Whois access as described in Section 3.1(c)(v) of the Sponsored TLD Registry Agreement. The Designated Recipient may not use such data for any other purpose.



2. The Designated Recipient shall use best efforts to implement any corrections to the data provided by the Registry Operator as soon as practicable.



3. The Designated Recipient must take such technical and organizational security measures as are, at a minimum, equivalent to those implemented by the Registry Operator with respect to such data.



4. Except for providing free public query-based access according to item 1 above, the Designated Recipient shall not transfer the data to any third party for any purpose except in the event that such third party becomes bound in the same manner as a Designated Recipient by the provisions of this Appendix and the Whois License Agreement.



The procedures for providing access, and the specification of the content and format of this data, will be as stated below, until changed according to the

Sponsored TLD Registry Agreement. This Appendix is subject to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. In addition, Registry Operator agrees to ensure the implementation of changes to this Appendix specified by ICANN to conform to the IETF provreg working group's protocol specification no later than

135 days after the IETF specification is adopted as a Proposed Standard [RFC

2026, section 4.1.1]. Accordingly, the following provides the target architecture and initial functionality.



A. Procedures for Providing Access



Registry Operator shall ensure the preparation of (i) full data sets for one day of each week (the day to be designated by ICANN) and (ii) incremental data sets for all seven days of each week. Full and incremental data sets shall be up-to-date and coherent as of 1200 UTC on the day to which they relate. Until a different day is designated by ICANN, the full data sets will be prepared for Sundays.

(Note that on the ICANN-designated day both an incremental and a full data set are prepared.)



1. Preparation of Files Containing Data Sets. Each full and incremental data set consists of an XML document meeting the content and format requirements of Parts B and C of this document. Once the XML document is generated, the following preparation steps will be performed:



a. The XML document will be placed in a file named according to the following convention: For full data sets: "wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two digits of year; MM=number of month; DD=day; in all cases a single digit number should be left-padded with a zero). For incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format.



b. The Registry Operator may optionally specify to split the document using the Unix SPLIT command (or equivalent) to produce files no less than 1GB each (except the final file). If files are split, an MD5 file (produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors in case of transfer fault. The Registry Operator may optionally specify to compress the document using the Unix GZIP command (or equivalent) to reduce the file size.



c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the escrow file in addition to encrypting it.) The Data Recipient's public key will be used for the encryption and the Registry Operator's private key will be used for the signature. Public keys will be exchanged between the Registry Operator and the Designated Recipient by e-mail, physical delivery of floppy diskettes, or other agreed means.



2. Transmission of Full Data Sets. Once prepared, full data sets will be provided either by the procedures for incremental data sets described in item A (3) below or, at the option of either the Registry Operator or the Designated

Recipient, by writing the full data set to DAT tape (or other media mutually agreed by Registry Operator and the Designated Recipient) and sending it to the

Designated Recipient by expedited delivery service (such as FedEx or DHL). If sent by expedited delivery service, the full data set will be scheduled for arrival no later than the second calendar day following the day to which the full backup relates.



3. Transmission of Incremental Data Sets. To permit the transmission of incremental data sets, Registry Operator shall specify to make them available for download by the Designated Recipient by Internet File Transfer Protocol.

Incremental data sets will be made available for download no later than 2000 UTC on the day to which they relate.



B. Content



The data sets (whether full or incremental) will consist of four types of objects:



1. Domain Objects. One type of object is the domain object, which corresponds to a single Registered Name. Each domain object includes the following data:



Domain ID

Domain Name

Sponsoring Registrar (IANA-assigned identifier)

Domain Status

ENS_AuthId

Registrant, Administrative, Technical and Billing Contact Information (references to appropriate contact objects)

Maintainer URL

Names of Nameservers associated with this domain

Created by Registrar (IANA-assigned identifier)

Last Updated by Registrar (IANA-assigned identifier)

Last Transferred Date

Additional fields (Registry Operator specified)

Domain Registration Date

Domain Expiration Date

Domain Last Updated Date



2. Nameserver Objects. A second type of object is the nameserver object, which corresponds to a single registered nameserver. The nameserver object includes the following data:



Nameserver ID

Nameserver Name

IP Addresses associated

Sponsoring Registrar (IANA-assigned identifier)

Created by Registrar (IANA-assigned identifier)

Nameserver Last Updated by Registrar (IANA-assigned identifier)

Created Date

Last Updated Date

Last Transferred Date



3. Contact Objects. A third type of object is the contact object, which corresponds to a single contact (whether registrant, administrative, technical, or billing contact). The contact object includes the following data:



Contact ID

Contact Name

Contact Organization

Contact Address, City, State/Province, Country

Contact Postal Code

Contact Phone, Fax, E-mail

Contact Registration Date

Contact Last Updated Date

Currently Associated

Contact Status

Additional fields (Registry Operator specified)

Sponsoring Registrar (IANA-assigned identifier)

Created Registrar (IANA-assigned identifier)

Last Transferred Date



4. Registrar Object. The final type of object corresponds to a single registrar. It includes the following data:



Registrar ID (conforming to the IANA registrar-ids registry)

Registrar Name

Registrar Status

Registrar Address, City, State/Province, Country

Registrar Postal Code

Registrar Phone, Fax, E-mail

Registrar Administrative Contacts

Registrar Technical Contacts

Registrar Billing Contacts



5. Objects Contained in Full and Incremental Data Sets. Full data sets include one domain object for each Registered Name within the Sponsored TLD; and nameserver, contact, and registrar objects for each nameserver, contact, and registrar referred to in any domain object. Incremental data sets consist of (a) those of the objects constituting a full data set that have been added or updated since the last incremental data set and (b) notations of deletion of any objects since the last incremental data set.



C. Format



Full and incremental data sets will be XML version 1.0, UTF-8 encoded documents conforming to the following document type definition:



<! DOCTYPE whois-data [<! ELEMENT whois-data (domain*, del-domain*, nameserver*, del-nameserver*, contact*, del-contact*, registrar*, del-registrar*) >

<! -- Del-domain, del-nameserver, del-contact, and del-registrar child elements are only meaningful where the attribute type= "Incremental" -->

<!ATTLIST whois-data

tld NMTOKEN #FIXED "jobs"

date CDATA #REQUIRED

type (Full | Incremental)

version CDATA #FIXED "1.0" >

<!ELEMENT domain (name, url)>

<!ATTLIST domain

dom-id ID #REQUIRED

registrar-id IDREF #REQUIRED

registrant-id IDREF #REQUIRED

ENS_AuthId IDREF #REQUIRED

admin-id IDREF #REQUIRED

tech-id IDREF #REQUIRED

billing-id IDREF #REQUIRED

nameserver-id IDREFS #IMPLIED

status (NEW | ACTIVE | INACTIVE | HOLD | LOCK | CLIENT-HOLD | CLIENTLOCK| PENDING-TRANSFER | PENDING-DELETE)

created-by IDREF #REQUIRED

updated-by IDREF #REQUIRED

cre-date CDATA #REQUIRED

exp-date CDATA #REQUIRED

upd-date CDATA #REQUIRED

xfer-date CDATA #REQUIRED>

<!ELEMENT del-domain EMPTY >

<!-the presence of this element in an incremental data set indicates that the

domain has been deleted since the last incremental data set -->

<!ATTLIST del-domain

dom-id ID #REQUIRED >

<!ELEMENT nameserver (name, ip, ip+) >

<!ATTLIST nameserver

nameserver-id ID #REQUIRED

registrar-id IDREF #REQUIRED

created-by IDREF #REQUIRED

updated-by IDREF #REQUIRED

cre-date CDATA #REQUIRED

upd-date CDATA #REQUIRED

xfer-date CDATA #REQUIRED >

<!ELEMENT del-nameserver EMPTY >

<!-the presence of this element in an incremental data set indicates that the

nameserver has been deleted since the last incremental data set -->

<!ATTLIST del-nameserver

nameserver-id ID #REQUIRED >

<!ELEMENT contact (name, org, address, post-code, country, phone, fax-, email)

>

<!ATTLIST contact

contact-id ID #REQUIRED

registrar-id IDREF #REQUIRED

created-by IDREF #REQUIRED

updated-by IDREF #REQUIRED

cre-date CDATA #REQUIRED

upd-date CDATA #REQUIRED

xfer-date CDATA #REQUIRED >

<!ELEMENT del-contact EMPTY >

<!-the presence of this element in an incremental data set indicates that the

contact has been deleted since the last incremental data set -->

<!ATTLIST del-contact

contact-id ID #REQUIRED >

<!ELEMENT registrar (reg-status, url) >

<!ATTLIST registrar

registrar-id ID #REQUIRED

contact-id IDREF #REQUIRED

admin-id IDREFS #REQUIRED

tech-id IDREFS #REQUIRED

billing-id IDREFS #REQUIRED

cre-date CDATA #REQUIRED

upd-date CDATA #REQUIRED>

<!ELEMENT del-registrar EMPTY >

<!-the presence of this element in an incremental data set indicates that the

registrar has been deleted since the last incremental data set -->

<!ATTLIST del-registrar

registrar-id ID #REQUIRED >

<!ELEMENT name (#PCDATA) >

<!ELEMENT ip (#PCDATA) >

<!ELEMENT org (#PCDATA) >

<!ELEMENT address (#PCDATA) >

<!ELEMENT post-code (#PCDATA) >

<!ELEMENT country EMPTY >

<!ATTLIST country cc (AF | AL | DZ | AS | AD | AO | AI | AQ | AG | AR | AM |

AW | AU | AT | AZ | BS | BH | BD | BB | BY | BE | BZ | BJ | BM | BT | BO | BA |

BW | BV | BR | IO | BN | BG | BF | BI | KH | CM | CA | CV | KY | CF | TD | CL | CN

| CX | CC | CO | KM | CG | CD | CK | CR | CI | HR | CU | CY | CZ | DK | DJ | DM |

DO | TP | EC | EG | SV | GQ | ER | EE | ET | FK | FO | FJ | FI | FR | GF | PF | TF |

GA | GM | GE | DE | GH | GI | GR | GL | GD | GP | GU | GT | GN | GW | GY | HT |

HM | VA | HN | HK | HU | IS | IN | ID | IR | IQ | IE | IL | IT | JM | JP | JO | KZ | KE |

KI | KP | KR | KW | KG | LA | LV | LB | LS | LR | LY | LI | LT | LU | MO | MK | MG |

MW | MY | MV | ML | MT | MH | MQ | MR | MU | YT | MX | FM | MD | MC | MN |

MS | MA | MZ | MM | NA | NR | NP | NL | AN | NC | NZ | NI | NE | NG | NU | NF |

MP | NO | OM | PK | PW | PS | PA | PG | PY | PE | PH | PN | PL | PT | PR | QA |

RE | RO | RU | RW | SH | KN | LC | PM | VC | WS | SM | ST | SA | SN | SC | SL |

SG | SK | SI | SB | SO | ZA | GS | ES | LK | SD | SR | SJ | SZ | SE | CH | SY | TW

| TJ | TZ | TH | TG | TK | TO | TT | TN | TR | TM | TC | TV | UG | UA | AE | GB |

US | UM | UY | UZ | VU | VE | VN | VG | VI | WF | EH | YE | YU | ZM | ZW | AC |

GG | IM | JE | UK ) >

<!ELEMENT phone (#PCDATA) >

<!ELEMENT fax (#PCDATA) >

<!ELEMENT e-mail (#PCDATA) >

<!ELEMENT reg-status (#PCDATA) >

<!ELEMENT url (#PCDATA) >



Whois Data Specification – ICANN



Registry Operator shall ensure the provision of bulk access by ICANN to up-to date data concerning domain name and nameserver registrations maintained by Registry Operator in connection with the Sponsored TLD on a daily schedule, only for purposes of verifying and ensuring the operational stability of Registry Services, the DNS, and the Internet.



The procedures for providing access, and the specification of the content and format of this data, will be as stated below, until changed according to the Sponsored TLD Registry Agreement. This Appendix is subject to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. In addition, Registry Operator shall implement changes to this Appendix specified by ICANN to conform to the IETF provreg working group's protocol specification no later than 135 days after the

IETF specification is adopted as a Proposed Standard [RFC 2026, section 4.1.1].

Accordingly, the following represents the target architecture and initial functionality.



A. Procedures for Providing Access



Registry Operator shall ensure the preparation of a full data set for one day of each week (the day to be designated by ICANN). Full data sets shall be up-to date and coherent as of 1200 UTC on the day to which they relate. Until a different day is designated by ICANN, the full data sets will be prepared for

Sundays.



1. Preparation of Files Containing Data Sets. Each full data set consists of an XML document meeting the content and format requirements of Parts B and C of this document. Once the XML document is generated, the following preparation steps will be performed:



a. The XML document will be placed in a file named according to the following convention: "wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two digits of year; MM=number of month; DD=day; in all cases a single-digit number should be left-padded with a zero).



b. The Registry Operator may optionally specify to split the document using the Unix SPLIT command (or equivalent) to produce files no less than 1GB each (except the final file). If files are split, an .MD5 file (produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors. The Registry Operator may optionally compress the document using the Unix GZIP command (or equivalent) to reduce the file size.



c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the escrow file in addition to encrypting it.) An ICANN public key will be used for the encryption and the Registry Operator's private key will be used for the signature. Public keys will be exchanged between the Registry Operator and ICANN by e-mail, physical delivery of floppy diskettes or other agreed means.



2. Transmission of Full Data Sets. Once prepared, full data sets will be provided according to paragraph a below or, at Sponsor and Registry Operator's option, according to paragraph b below:



a. Registry Operator shall specify to make full data sets available for download by ICANN by Internet File Transfer Protocol (FTP) (FTP access will be password protected and limited to prespecified IP ranges). The data sets will be made available for download beginning no later than 2000 UTC on the day to which they relate and until the next full data set becomes available for download.



b. Registry Operator shall specify to write the full data set to DAT (DDS-4) tape (or other media specified by ICANN) and ensure the tape is sent to ICANN by expedited delivery service (such as FedEx or DHL). The full data set will be scheduled for arrival at ICANN no later than the second calendar day following the day to which the data set relates.



B. Content



The full data sets will consist of the objects and contents described for full data sets in the “Public WhoIs” section of Appendix S.



C. Format



Full data sets will be XML version 1.0, UTF-8 encoded documents conforming to the schema/document type declaration set forth in Exhibit B of Appendix 1.