|
 |
Appendix 5
(4 February
2008)
|
WHOIS Specifications
Public WHOIS Specification
Public WHOIS for the TLD will be provided according to
the specification described in Part VI of 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 .tel 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 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 or
on behalf of 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, 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 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 technical operator, on behalf of 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
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
the
internal ID of the sponsoring registrar
the
IDs of the registrant, administrative, technical and billing contact
the
status values
the disclosure confirmation and natural person confirmation flags
and
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 esrow-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 (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
disclosure-confirmed NMTOKEN #REQUIRED
natural-person NMTOKEN #REQUIRED
ens-auth-id NMTOKEN #IMPLIED
authinfo CDATA #IMPLIED
maintainer-url CDATA #IMPLIED
period CDATA #IMPLIED
ere-date CDATA #REQUIRED
exp-date CDATA #REQUIRED
upd-date CDATA #REQUIRED
xfer-date CDATA #IMPLIED
action (create Iupdate) #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 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 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 (or on
Registry Operator's behalf) in connection with the TLD on a daily
schedule, only for purposes of verifying and ensuring the operational
stability of Registry Operator 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 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, 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 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
technical operator's private key will be used for the signature.
Public keys will be exchanged between the Registry Operator,
Registry Operator'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 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 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.
|