.CAT Registry Agreement | Whois Specifications
  icann logo
Appendix 5


Whois Specifications

Public Whois Specification

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

Whois Provider Data Specification

Registry shall ensure the provision of bulk access to up-to-date data concerning domain name and nameserver registrations maintained on behalf of Registry in connection with the .cat sTLD 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 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 for the purpose of providing free public query-based Whois access as described in Section 3.1(c)(v) of the .cat 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 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 or on behalf of the Registry 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 .cat Sponsored TLD Registry Agreement. This Appendix is subject to change by agreement of Registry and ICANN during the design process as well as during the IETF standards process. In addition, Registry 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 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, or its technical operator on its behalf, 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 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's private key will be used for the signature. Public keys will be exchanged between the Registry 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 technical operator, on behalf of the Registry. or the Designated Recipient, by writing the full data set to DAT tape (or other media mutually agreed by Registry 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 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 XML format is designed to represent both complete and incremental registry data sets.

  • The escrow format describes domain, host, contact and registrar objects stored in the registry repository.

  • The full escrow describes a snapshot of the given date, while the incremental escrow represents a transaction log. In the full escrow, only the "domain", "host", "contact" and "registrar" elements appear, while in the incremental escrow, the other elements may also appear.

  • For the incremental escrow, three additional attributes are specified: the "actor" denotes the entity that caused the modification. This is either a registrar ID, the ID of a support staff member or the name of an internal process of the SRS that performed the modification automatically (like auto-renew). The "timestamp" documents the point in time when the modification has taken place. The "txn" is an identifier that further details the precise activity.

  • To allow a differentiation between the creation and updates of an object within an incremental escrow, the "domain", "host", "contact" and "registrar" elements contain an "action" attribute that provides this information.

The following core data is reproduced in the escrow file:

Domain

the internal ID of the domain object

the domain name, including the assigned language and the reserved IDN domain name variants.

the internal ID of the sponsoring registrar

the IDs of the registrant, administrative, technical and billing contact

the status values

the ENS authorization ID

the EPP authentication information

the maintainer URL

the creation, expiration, update and transfer dates

Host

the internal ID of the host object

the domain name

the assigned IP addresses

the internal ID of the sponsoring registrar

the status values

the maintainer URL

the creation, update and transfer dates

Contact

the ID of the contact object

the name, organization, streets, city, state, postal code and country code

the phone and fax numbers and the e-mail address.

the EPP authentication information

the maintainer URL

the creation and update dates

Registrar

the internal ID of the registrar object

the organization, streets, city, state, postal code, country code, phone and fax number, e-mail address, web server address

the creation and update dates

the IDs of the administrative, technical and billing contact

C. Format

The document type declaration (DTD) for the XML formatted escrow files is the following:

<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT escrow-data (domain | del-domain | tr-domain | renew-domain | host | del-host | contact | del-contact | registrar | del-registrar)*>
<!ATTLIST escrow-data
    tld NMTOKEN #REQUIRED
    date CDATA #REQUIRED
    type (full | incremental) #REQUIRED
    version CDATA #FIXED "1.0"
>
<!ELEMENT domain (idn-domainname)>
<!ATTLIST domain
     dom-id NMTOKEN #REQUIRED
     registrar-id NMTOKEN #REQUIRED
     registrant-id NMTOKEN #REQUIRED
     admin-id NMTOKEN #REQUIRED
     tech-id NMTOKEN #REQUIRED
     billing-id NMTOKEN #REQUIRED
     nameserver-ids NMTOKENS #IMPLIED
     status NMTOKENS #REQUIRED
     ens-auth-id NMTOKEN #IMPLIED
     authinfo CDATA #IMPLIED
     maintainer-url CDATA #IMPLIED      period CDATA #IMPLIED
     cre-date CDATA #REQUIRED
     exp-date CDATA #REQUIRED
     upd-date CDATA #REQUIRED
     xfer-date CDATA #IMPLIED
     action (create | update) #IMPLIED
     actor NMTOKEN #IMPLIED
     timestamp CDATA #IMPLIED
     txn CDATA #IMPLIED
>
<!ELEMENT del-domain EMPTY>
<!ATTLIST del-domain
     dom-id NMTOKEN #REQUIRED
     actor NMTOKEN #REQUIRED
     timestamp CDATA #REQUIRED
     txn CDATA #REQUIRED
>
<!ELEMENT tr-domain EMPTY>
<!ATTLIST tr-domain
     dom-id NMTOKEN #REQUIRED
     registrar-id NMTOKEN #IMPLIED
     xfer-date CDATA #REQUIRED
     actor NMTOKEN #REQUIRED
     timestamp CDATA #REQUIRED
     txn CDATA #REQUIRED
>
<!ELEMENT renew-domain EMPTY>
<!ATTLIST renew-domain
     dom-id NMTOKEN #REQUIRED
     period CDATA #IMPLIED
     exp-date CDATA #REQUIRED
     actor NMTOKEN #REQUIRED
     timestamp CDATA #REQUIRED
     txn CDATA #REQUIRED
>
<!ELEMENT host (domainname, ip*)>
<!ATTLIST host
     host-id NMTOKEN #REQUIRED
     registrar-id NMTOKEN #REQUIRED
     status NMTOKENS #REQUIRED
     maintainer-url CDATA #IMPLIED
     cre-date CDATA #REQUIRED
     upd-date CDATA #REQUIRED
     action (create | update) #IMPLIED
     actor NMTOKEN #IMPLIED
     timestamp CDATA #IMPLIED
     txn CDATA #IMPLIED
>
<!ELEMENT del-host EMPTY>
<!ATTLIST del-host
     host-id NMTOKEN #REQUIRED
     actor NMTOKEN #REQUIRED
     timestamp CDATA #REQUIRED
     txn CDATA #REQUIRED
>
<!ELEMENT contact (addr, phone, fax, e-mail)>
<!ATTLIST contact
     contact-id NMTOKEN #REQUIRED
     registrar-id NMTOKEN #REQUIRED
     status NMTOKENS #REQUIRED
     authinfo CDATA #IMPLIED
     maintainer-url CDATA #IMPLIED
     cre-date CDATA #REQUIRED
     upd-date CDATA #REQUIRED
     action (create | update) #IMPLIED
     actor NMTOKEN #IMPLIED
     timestamp CDATA #IMPLIED
     txn CDATA #IMPLIED
>
<!ELEMENT del-contact EMPTY>
<!ATTLIST del-contact
     contact-id NMTOKEN #REQUIRED
     actor NMTOKEN #REQUIRED
     timestamp CDATA #REQUIRED
     txn CDATA #REQUIRED
>
<!ELEMENT registrar (org, street, street?, street?, city, state, post-code, country-code, phone, fax, e-mail, url)>
<!ATTLIST registrar
     registrar-id NMTOKEN #REQUIRED
     status NMTOKENS #REQUIRED
     admin-id NMTOKEN #REQUIRED
     tech-id NMTOKEN #REQUIRED
     billing-id NMTOKEN #REQUIRED
     cre-date CDATA #REQUIRED
     upd-date CDATA #REQUIRED
     action (create | update) #IMPLIED
     actor NMTOKEN #IMPLIED
     timestamp CDATA #IMPLIED
     txn CDATA #IMPLIED
>
<!ELEMENT del-registrar EMPTY>
<!ATTLIST del-registrar
     registrar-id NMTOKEN #REQUIRED
     actor NMTOKEN #REQUIRED
     timestamp CDATA #REQUIRED
     txn CDATA #REQUIRED
>
<!ELEMENT domainname (#PCDATA)>
<!ELEMENT idn-domainname (basename, variant*)>
<!ATTLIST idn-domainname
     lang NMTOKEN #IMPLIED
>
<!ELEMENT basename (#PCDATA)>
<!ELEMENT variant (#PCDATA)>
<!ELEMENT ip (#PCDATA)>
<!ELEMENT addr (name, org, street, street?, street?, city, state, post-code, country-code)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT org (#PCDATA)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT post-code (#PCDATA)>
<!ELEMENT country-code (#PCDATA)>
<!ELEMENT phone (#PCDATA)>
<!ATTLIST phone
     ext CDATA #IMPLIED
>
<!ELEMENT fax (#PCDATA)>
<!ATTLIST fax
     ext CDATA #IMPLIED
>
<!ELEMENT e-mail (#PCDATA)>
<!ELEMENT url (#PCDATA)>

Whois Data Specification — ICANN

Registry shall ensure the provision of bulk access by ICANN to up-to date data concerning domain name and nameserver registrations maintained by Registry (or on Registry's behalf) in connection with the .cat 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 this .cat Sponsored TLD Registry Agreement. This Appendix is subject to change by agreement of Registry and ICANN during the design process as well as during the IETF standards process. In addition, Registry 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 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, or its technical operator on its behalf, 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 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 technical operator's private key will be used for the signature. Public keys will be exchanged between the Registry, Registry's technical 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 Registry's option, according to paragraph b below:

a. Registry 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 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 Part VI of Appendix S ("Public Whois").

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.