.AERO Agreement Appendix 5 | Whois Specifications
  ICANN Logo

.AERO Agreement Appendix 5
Whois Specifications
(11 June 2009)


Public Whois Specification

RFC954-Conformant Whois

The standard Whois service is intended as a lookup service for registries, registrars, registrants, as well as for other individuals and businesses that wish to query details of domain names or nameservers stored in the registry. The standard Whois service will provide a central location for all authoritative .aero TLD data. The registry provides a front-end web interface to allow convenient user access to the Whois service.

The RFC954-conformant Whois service will be engineered to handle moderate transaction load and be integral to the standard suite of Registry Services. The Whois service will return a single response per domain name or nameserver query. The RFC954-conformant Whois service will conform to the requirements of Appendix 5.

The RFC954-conformant service provided by the registry will have the following features:

Whois Service Data Elements

The RFC954-conformant service will include the following data elements:

Minimum Data Update Frequency

The Registry Operator shall make reasonable efforts to update the data continuously as requests are processed, in a matter of seconds or minutes. The typical update cycle will be 30 seconds but may be different depending on performance considerations. The Registry Operator shall ensure that records in the Whois server are updated no later than 24 hours after the completion of the registration or modification transaction with the registrar.

Additional Fields Capability

If necessary, .aero may introduce after a 6 to 12 month period of operational stability some additional fields to the list of Whois fields. Those fields will be preceded and identified by appropriate tags.

Privacy Capability

The Sponsor may introduce the optional ability to associate privacy labels to a record in the Registry Database. These fields would appear in an "additional information" section of the Whois data. The maximum number of custom fields allowed per record is yet to be determined.

The privacy label capability allows certain data to be associated with an indication of any special disclosure or handling restrictions.

Query Control - Object Type Control

The following keywords restrict a search to specific object type:

Domain: Search only by domain objects. The input string is searched in the Name field.

Contact: Search only contact objects. The input string is searched in the ID field.

Nameserver: Search only by nameserver objects. The input string is searched in the nameserver field or the IP address field.

Registrar: Search only registrar objects. The input string is searched in the Name field.

By default, if no object type control is specified, then the Name field of the Domain object is searched.

Whois Output Fields

Domain Record:

A Whois query that results in domain information will return the following fields from the Domain object and the associated data from host and contact objects. This set of data is also referred to as the Domain Record.

Domain ID
Domain Name
Domain Status
Sponsoring Registrar <Registrar Name> (IANA-assigned identifier)
ENS_AuthID
Registrant, Administrative, Technical and Billing Contact Information including
 Contact ID
 Contact Name
 Contact Organization
 Contact Address, City, State/Province, Country
 Contact Postal Code
 Contact Phone, Fax, E-mail
Maintainer URL
Names of Nameservers associated with this domain
Created by Registrar <Registrar Name> (IANA-assigned identifier)
Last Updated by Registrar <Registrar Name> (IANA-assigned identifier)
Last Transferred Date
Additional fields (Sponsor specified, will be defined later, if required)
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date

Nameserver Record:

Nameserver ID
Nameserver name
Currently Associated (true/false)
Nameserver status
IP addresses associated (if applicable)
Created by Registrar <Registrar Name> (IANA-assigned identifier)
Sponsoring Registrar <Registrar Name> (IANA-assigned identifier)
Last Updated by Registrar <Registrar Name> (IANA-assigned identifier)
Created Date
Last Updated Date
Last Transferred Date
Additional fields (Sponsor specified, will be defined later, if required)

Contact Record:

A Whois query that results in contact information will return the following. This set of information is referred to as the Contact Record.

Contact ID
Contact Name
Contact Organization
Contact Address, City, State/Province, Country + 3 street fields
Contact Postal Code
Contact Phone, Fax, E-mail
Contact Registration Date
Contact Last Updated Date
Currently Associated
Contact Status
Additional fields (Sponsor specified)
Sponsoring Registrar <Registrar Name> (IANA-assigned identifier)
Created by Registrar <Registrar Name> (IANA-assigned identifier)
Last Transferred Date

Registrar Record:

A Whois query that results in registrar information will return the following. This set of information is referred to as the Registrar Record.

Registrar ID <Registrar Name> (IANA-assigned identifier)
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

Sample Whois Output

This section provides sample output from the Whois server for each type of Registry Object: Domain, Contact, Nameserver, and Registrar. The output is structured as key/value pairs, which simplifies machine-readability. In the Input section, the quoted string represents the string actually passed to the server in the request packet.

Domain Record:

Input: whois "domain = sita.aero"
Output: Domain ID: AAA-0001
Domain Name: SITA.AERO
Sponsoring Registrar: SITA (REG-01)
ENS_AuthId : AERO-123456789
Domain Status: ACTIVE
Registrant ID: PER-00001
Registrant Name: ANDREW CHARLTON
Registrant Organization: SITA, ICN
Registrant Address: 1234 MAIN STREET
Registrant City: GENEVA
Registrant State/Province: A
Registrant Country: SWITZERLAND
Registrant Postal Code: 1234
Registrant Phone Number: +41-22-747-6704
Registrant Facsimile Number: +41-22-747-6212
Registrant Email: CHARLTON@SITA.AERO
Admin ID: PER-00002
Admin Name: ANDREW CHARLTON
Admin Organization: SITA, INC.
Admin Address: 26 CHEMIN DA JOINVILLE
Admin City: GENEVA
Admin State/Province: A
Admin Country: SWITZERLAND
Admin Postal Code: 1234
Admin Phone Number: +41-22-747-6704
Admin Facsimile Number: +41-22-747-6212
Admin Email: CHARLTON@SITA.AERO
Tech ID: PER-00002
Tech Name: ANDREW CHARLTON
Tech Organization: SITA, INC
Tech Address: 26 CHEMIN DA JOINVILLE
Tech City: GENEVA
Tech State/Province: A
Tech Country: SWITZERLAND
Tech Postal Code: 1234
Tech Phone Number: +41-22-747-6704
Tech Facsimile Number: +41-22-747-6212
Tech Email: CHARLTON@SITA.AERO
Billing ID: PER-00002
Billing Name: ANDREW CHARLTON
Billing Organization: SITA, INC.
Billing Address: 26 CHEMIN DA JOINVILLE
Billing City: GENEVA
Billing State/Province: A
Billing Country: SWITZERLAND
Billing Postal Code: 1234
Billing Phone Number: +41-22-747-6704
Billing Facsimile Number: +41-22-747-6212
Billing Email: CHARLTON@SITA.AERO
Name Server: NIC.AERO.ORG
Name Server: WWW.ICOM.ORG
Maintainer: SPECIALCARE@RESELLER.COM
Created By: SITA (REG-02)
Updated By: SITA (REG-01)
Created On: 2002-01-02
Expires On: 2004-01-02
Updated On: 2002-03-02
Transferred On: 2002-03-02

Nameserver Record:

Input: whois "nameserver nic.sita.aero"
or
whois "nameserver 130.242.24.6"
Output: Nameserver ID: HST-1
Nameserver name: NIC.SITA.AERO
Currently Associated (true/false):T
Nameserver status: ACTIVE
IP addresses associated: 130.242.24.6
Sponsoring Registrar: SITA (REG-01)
Created By: SITA (REG-02)
Updated By: SITA (REG-01)
Created On: 2002-01-02
Updated On: 2002-03-02
Transferred On: 2002-03-02
Additional fields (Sponsor specified, will be defined later, if required)

Contact Record:

Input: whois "contact = PER-00002"
Output: Contact ID: PER-00002
Name: ANDREW CHARLTON
Organization: SITA, INC
Address: 26 CHEMIN DA JOINVILLE
City: GENEVA
State: A
Country: SWITZERLAND
Postal Code: 1234
Phone Number: +41-22-747-6704
Facsimile Number +41-22-747-6212
E-mail: CHARLTON@SITA.AERO
Status: Active
Sponsoring Registrar: SITA (REG-01)
Created By: SITA (REG-01)
Created On: 2002-01-02
Updated On: 2002-01-02
Transferred On: 0000-00-00

Registrar Record:

Input: whois "registrar SAMPLE"
Output: Registrar ID: SITA (REG-01)
Registrar Name: SAMPLE
Registrar Status: ACTIVE
Registrar Address 1: 123 Some Street
Registrar Address 2:
Registrar City: Acity
Registrar State/Province: RE
Registrar Country: CC
Registrar Postal Code: 12345
Registrar Phone: +11-11-1111-1111
Registrar Fax: +22-22-2222-2222
Registrar E-mail: jdoe@sample.tld
Admin Contact ID: PER-00003
Tech Contact ID: PER-00004
Billing Contact Name: PER-00005

Whois Provider Data Specification

Sponsor shall ensure Registry Operator provides bulk access 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 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 Sponsor 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 Subsection 3.1(c)(v) of the TLD Sponsorship Agreement (including Appendix S, Part 5, as it may be amended from time to time). 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 TLD Sponsorship Agreement. This Appendix is subject to change by agreement of Sponsor and ICANN during the design process as well as during the IETF standards process. In addition, Sponsor agrees to require Registry Operator to 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 provides the target architecture and initial functionality.

A. Procedures for Providing Access

Sponsor shall ensure Registry Operator prepares (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 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 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, Sponsor shall ensure Registry Operator makes 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 <Registrar Name> (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 <Registrar Name> (IANA-assigned identifier)
Last Updated by Registrar (IANA-assigned identifier)
Last Transferred Date
Additional fields (Sponsor 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 <Registrar Name> (IANA-assigned identifier)
Created by Registrar <Registrar Name> (IANA-assigned identifier)
Nameserver Last Updated by Registrar <Registrar Name> (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 (Sponsor specified)
Sponsoring Registrar <Registrar Name> (IANA-assigned identifier)
Created Registrar <Registrar Name> (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 <Registrar Name> (IANA-assigned identifier)
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 "aero"
 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 | CLIENT-LOCK | 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-, e-mail) >
 <!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

Sponsor shall ensure Registry Operator provides 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 Sponsorship Agreement. This Appendix is subject to change by agreement of Sponsor and ICANN during the design process as well as during the IETF standards process. In addition, Sponsor agrees to require Registry Operator to 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

Sponsor shall ensure Registry Operator prepares 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 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 filesize.

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. Sponsor shall ensure Registry Operator makes 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. Sponsor shall ensure Registry Operator writes the full data set to DAT (DDS-4) tape (or other media specified by ICANN) and sends it 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 four types of the objects and contents described for full data sets in Appendix 5.

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 Appendix 5.