|
![ICANN Logo](https://www.icann.org/sites/default/files/unmanaged/logos/icann-logo.gif) |
Proposed Unsponsored TLD Agreement: Appendix P (.name)
(28 June 2001)
|
Whois Provider Data Specification
Registry Operator will provide bulk access to up-to-date data concerning Registered Names, SLD E-mail (as defined in Appendix C) addresses, nameservers, contacts, registrars, and Defensive Registrations (as defined in Appendix L) maintained by Registry Operator in connection with the Registry TLD on a daily schedule, only for purposes of providing free public query-based access to up-to-date data concerning these 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 Registry Operator for the purpose of providing free public query-based Whois access as described in Subsection 3.10.1 of the Registry Agreement (including Appendix O, as it may be amended from time to time). The Designated Recipient may not use such data for any other purpose or substantively alter the data.
2. The Designated Recipient shall use best efforts to implement any updates to the data provided by 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 Registry Operator with respect to such data.
4. The Designated Recipient shall not transfer (other than through the free query-based public access described above) 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 Registry Agreement. This Appendix is subject to change by the agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. In addition, Registry Operator agrees to implement changes to this Appendix specified by ICANN to conform to the IETF provreg working group's EPP specifications 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 The Registry Operator will prepare (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 12:00 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: "NAMEwfCCYYMMDD" where "CCYYMMDD" is replaced with the date (CCYY=four digit year including century; MM=number of month; DD=day; in all cases a single-digit number should be left-padded with a zero).
For incremental data sets: "NAMEwiCCYYMMDD" where "CCYYMMDD" follows the same format.
b. The Registry Operator may optionally split the document using the Unix SPLIT command (or equivalent) to produce files no less than 640MB each (except the final file). If files are split, a .MD5 file (produced with MD5SUM or equivalent) must be included with the escrow files to isolate errors in case of transfer fault. 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 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 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). Registry Operator will use reasonable commercial efforts to ensure that the full data set will be scheduled for arrival no later than the second business day following the day to which the data set relates.
3. Transmission of Incremental Data Sets. To permit the transmission of incremental data sets, the Registry Operator will 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 20:00 UTC on the day to which they relate.
B. Content The data sets (whether full or incremental) will consist of different types of objects. All data associated with each object included in the data set will be included to the extent it exists in the Registry.
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 ID Domain Status Registrant Contact ID Administrative Contact ID Technical Contact ID Billing Contact ID Name Server IDs associated with this domain Domain Creation Date Domain Expiration Date Domain Last Modified Date
2. SLD e-mail objects. A second type of object is the SLD e-mail object, which corresponds to a single Registered SLD E-mail Address. Each SLD e-mail object includes the following data:
SLD E-mail ID SLD E-mail Address Sponsoring Registrar ID SLD E-mail Status Registrant Contact ID Administrative Contact ID Technical Contact ID Billing Contact ID SLD E-mail Creation Date SLD E-mail Expiration Date SLD E-mail Last Modified Date
3. Nameserver objects. A third type of object is the nameserver object, which corresponds to a single registered nameserver. The nameserver object includes the following data:
Name Server ID Name Server Host Name Name Server IP Addresses if applicable Current Registrar ID Name Server Status Name Server Created Date Name Server Last Modified Date
4. Contact objects. A fourth 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 Registrar ID Contact Status Contact Organization Contact Address, City, State/Province, Country Contact Postal Code Contact Phone, Fax, E-mail Contact Creation Date Contact Last Modified Date
5. Registrar object. The fifth type of object corresponds to a single registrar. It includes the following data: Registrar ID (conforming to IANA registrar-ids directory)
Contact ID of Registrar Registrar URL Registrar Status Registrar Creation Date Registrar Last Modified Date
6. Defensive registration object. The final type of object corresponds to a defensive registration. It includes the following data:
Defensive Registration ID Defensive Registration String Sponsoring Registrar ID Defensive Registration Status Trademark Identifier Trademark Date Trademark Country Registrant Contact ID Administrative Contact ID Billing Contact ID Defensive Registration Creation Date Defensive Registration Last Modified Date Defensive Registration Expiration Date
7. Objects Contained in Full and Incremental Data Sets. Full data sets include one domain object for each Registered Name within the Registry TLD; one SLD e-mail object for each Registered SLD E-mail Address; one defensive registration object for each Defensive Registration; one nameserver object for each nameserver referred to in any domain object; andcontact and registrar objects for each contact and registrar referred to in any domain, SLD e-mail, or defensive registration 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*,sld-email*, del-sld-email*, nameserver*, del-nameserver*, contact*, del-contact*, registrar*, del-registrar*, def-reg*, del-def-reg*) > <!-- del-domain, del-sld-email, del-nameserver, del-contact, and del-registrar, and del-def-reg child elements are only meaningful where the attribute type=Incremental --> <!ATTLIST whois-data tld NMTOKEN #FIXED name date CDATA #REQUIRED type (Full | Incremental) version CDATA #FIXED 1.0>
<!ELEMENT domain (name)> <!ATTLIST domain dom-id ID #REQUIRED registrar-id IDREF #REQUIRED registrant-id IDREF #REQUIRED admin-id IDREF #REQUIRED tech-id IDREF #REQUIRED billing-id IDREF #REQUIRED nameserver-id IDREFS #IMPLIED status (clientDeleteProhibited | clientHold | clientRenewProhibited | clientTransferProhibited | clientUpdateProhibited | inactive | ok | pendingDelete | pendingTransfer | pendingVerification | serverDeleteProhibited | serverHold | serverRenewProhibited | serverTransferProhibited | serverUpdateProhibited ) cre-date CDATA #REQUIRED exp-date CDATA #REQUIRED upd-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 sld-email (e-mail)> <!ATTLIST sld-email sld-email-id ID #REQUIRED registrar-id IDREF #REQUIRED registrant-id IDREF #REQUIRED admin-id IDREF #REQUIRED tech-id IDREF #REQUIRED billing-id IDREF #REQUIRED status (clientDeleteProhibited | clientHold | clientRenewProhibited | clientTransferProhibited | clientUpdateProhibited | inactive | ok | pendingDelete | pendingTransfer | pendingVerification | serverDeleteProhibited | serverHold | serverRenewProhibited | serverTransferProhibited | serverUpdateProhibited ) cre-date CDATA #REQUIRED exp-date CDATA #REQUIRED upd-date CDATA #REQUIRED>
<!ELEMENT del-sld-email EMPTY > <!the presence of this element in an incremental data set indicates that the sld-email has been deleted since the last incremental data set --> <!ATTLIST del-sld-email sld-email-id ID #REQUIRED >
<!ELEMENT nameserver (name, ip+) > <!ATTLIST nameserver nameserver-id ID #REQUIRED registrar-id IDREF #REQUIRED status (clientDeleteProhibited | clientUpdateProhibited | linked | ok | pendingDelete | pendingTransfer | serverDeleteProhibited | serverUpdateProhibited ) upd-date CDATA #REQUIRED cre-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, city, state-province, post-code, country, phone, fax, e-mail) > <!ATTLIST contact contact-id ID #REQUIRED registrar-id IDREF #REQUIRED cre-date CDATA #REQUIRED upd-date CDATA #REQUIRED> status (clientDeleteProhibited | clientTransferProhibited | clientUpdateProhibited | linked | ok | pendingDelete | pendingTransfer | serverDeleteProhibited | serverTransferProhibited | serverUpdateProhibited )
<!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 def-reg (name)> <!ATTLIST def-reg def-reg-id ID #REQUIRED registrar-id IDREF #REQUIRED registrant-id IDREF #REQUIRED admin-id IDREF #REQUIRED billing-id IDREF #REQUIRED status (clientDeleteProhibited | clientHold | clientRenewProhibited | clientTransferProhibited | clientUpdateProhibited | inactive | ok | pendingDelete | pendingTransfer | pendingVerification | serverDeleteProhibited | serverHold | serverRenewProhibited | serverTransferProhibited | serverUpdateProhibited ) trademark CDATA #REQUIRED trademark-country CDATA #REQUIRED trademark-date CDATA #REQUIRED cre-date CDATA #REQUIRED exp-date CDATA #REQUIRED upd-date CDATA #REQUIRED>
<!ELEMENT del-def-reg EMPTY > <!the presence of this element in an incremental data set indicates that the defensive registration has been deleted since the last incremental data set --> <!ATTLIST del-def-reg def-reg-id ID #REQUIRED >
<!ELEMENT name (#PCDATA) > <!ELEMENT ip (#PCDATA) > <!ELEMENT org (#PCDATA) > <!ELEMENT address (#PCDATA) > <!ELEMENT city (#PCDATA) > <!ELEMENT state-province (#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) > ]>
Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.
Page Updated 28-Jun-2001 (c) 2001 The Internet Corporation for Assigned Names and Numbers. All rights reserved.
|