S to Sponsored TLD Registry Agreement
Part I: TLD Charter
Part II: Delegated
Part III: Description
of Sponsored TLD Community
Part IV: Start-Up Plan
Part V: Selection of
Part VI: Public WhoIs
The .travel TLD will be
established to serve the needs of the international travel industry
("Community"). It will be managed in accordance with the
provisions of this charter ("Charter") and in the interests
of the Community.
1. The Registry will be
responsible for establishing registration requirements for the
.travel TLD. Registration will be limited to: people, businesses,
organizations and entities, however constituted, whose primary area
of activity is in the travel industry.
2. The Registry, with
the advice of The Travel Partnership Corporation, may enumerate and
identify industry sectors that are within the meaning of the
registration requirements set out in item 1, above. The initial
enumeration of such sectors is set out in item 4, below.
3. The Registry may
establish stricter requirements for registrants than those set out in
item 1, above, according to the Delegated Authority set out in Part
II of this Appendix S. In the event that such stricter requirements
are established at any time, the Registry will make such requirements
public in the manner contemplated in its delegation of authority and
will promptly inform ICANN of such requirements.
4. For the purposes of
this Charter, without limitation, and as may be amended or clarified
from time to time as contemplated by item 5, below, the Registry has
enumerated the following sectors of the travel industry that are
within the meaning of the registration requirements set out in item
- Attractions/Theme Parks
- Bed & Breakfast Houses
- Bus/Taxi/Limousine Operators
- Camp Facility Operators
- Car Rental Companies
- Computer Reservation/Travel Technology Provider
- Convention & Visitor's Bureaus
- Cruise Lines
- National Tourism Offices
- Passenger Rail Lines
- Tour Operators
- Travel Agents
- Travel Media
- Travel-Consumer and Market
5. The Registry may
amend, clarify, extend or re-enumerate the industry sectors
identified in item 4, above (the "Changes"), provided that such
Changes are within the scope of the requirement set out in item 1,
above. In such event the Registry will promptly make such Changes
public in the manner contemplated in its Delegated Authority set out
in Part II to this Appendix S and will promptly inform ICANN of such
following areas of responsibility for development of policies for the
Sponsored TLD are delegated to the Registry, provided the other
provisions of the Agreement and its Appendices are followed:
Establishment of naming conventions to be used in the Sponsored TLD.
Restrictions on what types of people or entities may register
Registered Names (which need not be uniform for all names within the
Sponsored TLD), provided the scope of the Charter is not exceeded.
Restrictions on how Registered Names may be used (which need not be
uniform for all names within the Sponsored TLD), provided the scope
of the Charter is not exceeded.
Performance of Eligibility and Name-Selection Services (ENS
Services), either directly by the Registry or by one or more
organizations or individuals to which it delegates the responsibility
for performing ENS Services.
Mechanisms for enforcement of the restrictions in items 2 and 3,
including procedures for revocation or cancellation of registrations.
Mechanisms for resolution of disputes concerning eligibility between
eligible entities and of disputes between owners of rights (who may
or may not be registrants) in names (such as trademarks) and
registrants, that do not supplant ICANN's dispute-resolution policies
or remedies that may be available under law.
Selection of the Registry Operator (not to be an affiliate of the
Registry) and establishment of the terms of agreement between
Registry and the Registry Operator.
Functional and performance specifications for, and pricing of,
Matters concerning the operation of the registry for the Sponsored
Selection of ICANN-Accredited Registrars to act as registrars for the
Sponsored TLD, consistent with Part V of this Appendix S.
Terms of agreement to be offered by the Registry to ICANN-Accredited
Registrars selected by Registry, including provisions for fair
treatment by the Registry and the Registry Operator of those
Practices of ICANN-Accredited Registrars selected by Registry with
respect to Registered Names and their registration.
Terms of agreement between registrars and registrants under which
Registered Names are registered.
Uses and practices by registrants with respect to Registered Names.
Procedures and schedule for the start-up of the Sponsored TLD,
provided they are consistent with Part IV of this Appendix S.
Provisions for publication of registry and registrar data consistent
with the TLD Sponsorship Agreement and Registrar Accreditation
of the .Travel Community
The .travel TLD is
intended to serve the needs of the international travel industry,
which consists of those people, businesses, organizations and
entities, however constituted, eligible to register in the .travel
TLD pursuant to the Agreement and the .travel Charter (Part I to this
The Registry may extend
or amend the description of the Community consistent with the terms
of the Agreement and the .travel Charter.
PHASED LAUNCH AND SERVICES
Part 4 of Appendix S specifies the startup plan for the .travel TLD.
The startup is designed as a phased launch consisting of the
initiation of the following core services of the .travel TLD:
Eligibility and name selection policy implementation
Gathering and analysis of authentication data
Delivery of eligibility confirmations
Registration of eligible entities
Data entry into the .travel industry directory
Industry directory public availability
launch will be conducted in three phases — Announcement, Initial
Pre-authentication and Limited Launch — with a controlled group of
potential registrants. Registration will be limited to those
authenticated entities that are: members of selected industry
associations, or that are part of the existing database of a
selected, independent, third-party accrediting organization. While
limited to an identifiable group of travel industry participants, the
registrant group will be diverse, global and sufficiently large to
give broad access to the startup period, while at the same time
providing an opportunity for a managed launch.
terms used in the below are:
Authentication Data — means the standard information provided
by a registrant to enable a determination of eligibility to hold a
.travel domain name, including data concerning potential name
Authentication Provider — means (i) an organization selected
by the Registry from among those members of The Travel Partnership
Corporation (TTPC) who choose to review Authentication Data and
confirm eligibility of their members, or the members of other travel
associations under mutual agreement, and (ii) an independent,
third-party organization that has been selected to review
Authentication Data for those entities that are not members of TTPC
associations. All Authentication Providers will be trained by the
Registry in the review of Authentication Data and the application of
Names List — means a list of names that any eligible entity is
entitled to apply to register. The Names List is generated by the
Registry based on the Authentication Data supplied by the eligible
entity. The Authentication Provider will receive supporting
document(s) from the entity for each name included in the
Authentication Data. The Names List may be amended or extended as a
result of the amendment or addition of new Authentication Data by the
Pre-authentication — means the gathering of data sufficient to
assess and determine eligibility and the recording of eligibility and
eligible names in the Registry Authentication Database prior to the
registration of a .travel name;
Registrar — means a registrar that is accredited by both ICANN
and the Registry according to the standards developed by the
Registry Authentication Database — means the secure database
system into which all Authentication Data is gathered and which
records eligibility and eligible names;
Rolling Pre-authentication — means the continuation of the
pre-authentication process during Limited Launch in the manner set
out under the heading "Initial Pre-authentication" subsections
Unique Identification Number (UIN) — means a unique number
issued by the Registry to each eligible entity upon review of their
Authentication Data and confirmation of eligibility by an
Authentication Provider. The UIN must be received prior to any name
following is a summary of the three-phase startup period including
its functions and relative dates:
starting date of pre-authentication to the eligible community
Start C: -120 days
End C: -90
name selection data gathering; confirmation of eligibility by
Authentication Providers; industry directory data entry
Start: C -60-90 days
End: C +90 days
Limited Launch and Rolling Pre-authentication
Registration; registrar interface live;
industry directory live
End: C +90 days
Dates and Authentication Providers Announced — While the Registry
has been conducting a program of general awareness within the
industry and among the members of TTPC, 30 days prior to the
initiation of Pre-authentication it will begin a series of public
announcements of the date on which Pre-authentication will begin, its
purpose, period and the name of the Authentication Providers through
whom a potential registrant may be pre-authenticated. The term of the
Pre-authentication period prior to Limited Launch will be between 60
and 90 day, depending on technical implementation and completion of
1. Pre-authentication Overview — Initial Pre-authentication is
the sixty to ninety-day period prior to the start of acceptance and
provisioning of .travel domain name registrations by the Registry.
Pre-authentication follows the same eligibility process and policies
as will be applied during Limited Launch and thereafter. However,
during the start-up period, potential registrants will be provided
with an opportunity to be pre-authenticated by the applicable
Authentication Provider prior to the Limited Launch.
Pre-authentication is designed to make the registration process more
efficient for the Registry during the Limited Launch phase and to eliminate
delays for the registrant. After the Startup Period authentication of
eligibility will continue to be required for all registrants and will be
conducted in the same manner as during the Initial Pre-authentication Phase
except that it will be open to all potential registrants.
It is anticipated that Initial Pre-authentication will begin between
May 1, and May 30, 2005 and end 60-90 days later, on or about August 1,
2. Initial Pre-authentication Key Elements — The
Initial Pre-authentication phase has the following key elements:
It is limited to entities that are members of travel associations
that are Authentication Providers or entities that are affiliated
with the third-party Authentication Provider. This process will
permit pre-authentication by entities outside the TTPC member group
located anywhere in the world, provided that those entities are
registered with the third-party Authentication Provider.
Members of a travel association must be pre-authenticated by their
association or by the independent, third-party Authentication
Provider. A travel association that is an Authentication Provider
will only be permitted to authenticate only its own members or the
members of another association where a prior agreement and
procedures have been put in place.
All Authentication Data supplied by a registrant conforms to a
standard template that is designed according to .travel eligibility
and name convention policies. See, "3. Pre-authentication Data
All Authentication Providers will be trained by the Registry in the
application of .travel policies to determine eligibility in a fair
and transparent manner. In the case of any questions of
eligibility, the Registry will be the final assessor of
Only eligibility is authenticated during Pre-authentication. Once
a travel entity has been authenticated, it must wait until the
Limited Launch period to register an applicable domain name with
In Limited Launch, registrations will be on a first-come,
first-served basis, regardless of when the entity was
pre-authenticated. Thus, there is no priority to an applicant
entity based on the date of pre-authentication.
All Authentication Data will be entered by the applicant entity
directly into the Authentication Database and all Authentication
Providers review only data entered into the Authentication
Database. All confirmations of eligibility will be made directly to
the Authentication Database thereby reducing communication
complexity and potential messaging errors.
Pre-authentication Data Required — Pre-authentication data must
be supplied by all applicant entities to support a determination of
their eligibility by the Authentication Provider and the Registry.
Applicants will provide Identification Data (according to their
business type), Contact Data and Name Selection Data. Identifying
data provides particular information for: Registered Businesses or
Organizations; Partnerships; Tourist and Convention Bureaus; and
Individuals who are sole proprietors. In addition, a standard block
of data for all applicant types provides contact data and name
3.1 Identifying Data by Applicant Type — The following are the
specific data elements required for each of the four designated
3.2 Name Selection and Contact Data Required from all Applicants — The
following are the specific data elements applicable to all of the
four designated applicant types:
Identifying Data for Registered Businesses and Organizations
Required Data (.)
Identifier (registration or similar number)
(Name and location of issuer)
Identifying Data for Partnerships
Identifying Data for Tourist and Convention Bureaus
Required Data (.)
Identifier (registration or similar number)
(Name and location of issuer)
4. Designated by
if intending to register a city name)
Identifying Data for Individuals (sole proprietors)
Required Data (.)
Confirmation Data (third-party issued data supporting name and
business: business license, utilities bill, supplier letter, as
determined by AP)
1. All Name Types
required unless the applicant intends to register a name other
than its incorporation, partnership, bureau or personal name
Applicants are required to enter each name they might register at
any time in the future. They must enter the name under the
appropriate "name type". Applicants must provide their
Authentication Provider with document(s) that confirm the use or
registration by the applicant of each included name.
More than one name may be entered under each "name type".
a) "Doing Business As", "Trade Name" or
"Usual" Business Name
b) Usual Business Name as used in a URL
d) Service Mark
e) Club or
f) Vessel Name
h) Division Name
i) Subsidiary Name
2. Travel Sector
select one of the eighteen .travel sectors
select which AP or TTPC member they are a member of
5. Mailing Address if different
7. Applicant Fax
business Email address
Owner/Officer First Name
Owner/Officer Last Name
Contact First Name
Contact Last Name
address of applicant
required if available
15. Current URL
This need not be a .travel URL
Pre-authentication Data and Eligibility — The pre-authentication
data is designed to gather information that: 1. Identifies the
applicant entity; 2. Determines their industry sector; and 3. Lists
the names they use in their business. Authentication Providers review
pre-authentication data to confirm that the entity is identified
correctly and that they operate within the industry sector that they
report they are within.
Pre-authentication Training and Testing — Pre-authentication
Providers will be given training and documentation in .travel
policies, eligibility, name selection and how to conduct a review of
eligibility. The Registry will give each Authentication Provider a
standard web page format informing their members of how to be
pre-authenticated and providing a link to the Authentication
Database. Each Authentication Provider will be given a set of test
data to enter into the Authentication Database and each
Authentication Provider will perform at least one test review,
confirmation and denial. Authentication testing will be carried out
over a period of two weeks and will involve all Authentication
Providers and will include all phases of pre-authentication data
handling and messaging, both technical and non-technical.
Pre-authentication Process — The Pre-authentication process will
proceed as follows:
Pre-authentication will be offered to all members or affiliates of
Authentication Providers during the Pre-authentication phase and
during Limited Launch.
Each applicant entity will receive a username and password
permitting it access to the Registry Authentication Database either
directly or via a hyperlink in its Authentication Provider's
The applicant entity will input Authentication Data directly into
the Registry Authentication Database. All Authentication Data will
follow the templates set out in "3. Pre-Authentication Data
Entry of pre-authentication data will be open to all applicant
entities during the entire period with no privilege or queuing
accorded to any entity or to members or affiliates of any
Authentication Provider. The receipt of a confirmation of
eligibility is not time or date based and provides no priority for
later registration. Pre-authentication is, however, a precondition
for any registration during the Limited Launch period.
The Authentication Database will be available 24 hours a day
throughout the entire Startup Period.
The entity's Authentication Provider will review the
Authentication Data via access to the Authentication Database using
a username and password and will confirm eligibility according to
The confirmation of eligibility will be recorded in the
The confirmation of eligibility will be recorded with a Unique
Identification Number issued as a permanent identifier for the
After confirmation of eligibility, the applicant's Authentication
Data will be analyzed according to an automated application of
.travel name selection policies and a list of names that the entity
is eligible to apply to register will be generated. This is the
The UIN and the Names List will be posted to a secure database and
will be made available to the applicant and its Authentication
Provider via a username and password.
The applicant will be able to apply to register only names on the
No priority will be given to any name on any Names List, or to any
holder over any other holder where each has the same name on their
Although an entity must wait until the Limited Launch to register
its domain name(s), it may, prior to that phase, complete its
listing in the .travel industry directory. When the entity later
registers a domain name, that directory listing will be made
If the Authentication Provider is unable to authenticate the
entity, it shall deny the entity's request for
pre-authentication. In such a case, the entity may request a
review by the Registry within 30 days of such denial.
All denials of eligibility will be recorded in the Authentication
A log and archive of all denials will be maintained.
All applicant entities supplying Authentication Data will be
matched against the list of denied entities.
The pre-authenticated entity may complete name registration during
Limited Launch or at any time thereafter for a period of 12 months,
after which authentication must be renewed.
Prior to the commencement of the Limited Launch, there will be a
period of five (5) days during which no pre-authentication
applications will be accepted by the Registry. Pre-authentication
will begin again on the first day of the Limited Launch phase.
All entities that have completed pre-authentication at the date
five (5) days prior to the commencement of Limited Launch will be
permitted to apply to register a name included on their Names List
at any time during Limited Launch and thereafter.
On the first day of Limited Launch pre-authentication will restart
and will continue for twenty-five (25) days (or 5 days prior to a
calendar month end, if Limited Launch begins on the first day of a
All entities that have completed pre-authentication during the
first month of Limited Launch will be permitted to apply to
register a name included on their Names List on the first day of
the second month of Limited Launch and at any time during Limited
Launch and thereafter.
On the thirty-first (31st) day of Limited Launch (or the first
calendar day of the second calendar month of Limited Launch)
pre-authentication will restart and will continue for twenty-five
(25) days (or 5 days prior to a calendar month end, if Limited
Launch begins on the first day of a calendar month).
All entities that have completed pre-authentication during the
second month of Limited Launch will be permitted to apply to
register a name included on their Names List on the first day of
the third month of Limited Launch and at any time during Limited
Launch and thereafter.
The process referred to in 6.19 to 6.24 is referred to as "Rolling
Pre-authentication" and is designed to: (i) provide the maximum
opportunity to be pre-authenticated; and (ii) provide a benefit for
Rolling Pre-authentication ends on the last day of Limited Launch.
The Registry will maintain a log of all denials, attempts by
applicants to change Authentication Provider subsequent to a denial
and any messaging or other communications problems that may occur
with Authentication Providers.
Limited Launch Overview — Limited Launch is a ninety-day period
during which only those entities that have been
pre-authenticated will be permitted to register a .travel name. All
entities that have been authenticated during the Initial
Pre-authentication Phase will be entitled to register a .travel
domain name at any time during Limited Launch and thereafter.
Entities that are pre-authenticated during Limited Launch will be
entitled to register a name according to the process described above
(6.19-6.24) as Rolling Pre-authentication.
Limited Launch all eligible entities will register a .travel name
through a Registrar that has been approved by the Registry. All name
registrations will be first-come-first served. All eligible entities
holding a UIN will be permitted to register only the name(s) on their
Names List. All entities that are denied a name they have applied for
are entitled to request a review of the name denial by the TTPC
Review Panel within 30 days following the denial.
a registrant receives its first .travel name, any industry directory
listing it has completed will automatically be made public
Limited Launch phase will conclude 90 days after its start date.
2. Limited Launch Registration Process —
Limited Launch will begin at 12:01 AM EST on the Commencement Date.
At the time of initiation of Limited Launch all entities holding a
UIN will be entitled to apply to register a name(s) included on
their Names List.
There will be no limit to the number of names a holder of a UIN
will be permitted to register.
All registrations will be carried out by Registrars that are
approved by the Registry.
All communications between the Registry and the Registrar will
follow the "Format for .travel Domain Name Transactions" below.
Any name denials will be communicated to the Registrar together
with a notice of denial review application procedures.
No name(s) will be "held". All names for which registration is
sought must be included on the applicant's Names List. Any name
that is denied will immediately be available for registration by
another holder of a UIN that also has that name on its Names List.
The Registry will match the applicant name, UIN and requested name
against the Authentication Database. No name will be registered
unless the applicant name, UIN and requested name match the data
for that applicant.
The Registry will maintain no less than two geographically diverse
SRS and DNS data centers with the requisite back-up power to
operate such data centers in the event of a power failure.
OF IMPORTANT FEATURES OF STARTUP
Assurance of Eligibility — All applicants will be required to
be pre-authenticated by supplying Authentication Data that conforms
to a standard set of data elements and that will be reviewed by a
trained Authentication Provider. Applicant identity and industry
sector data will be matched against data held or gathered by the
All entities whose eligibility has been confirmed will receive a UIN
that is their permanent identifier in the Registry Authentication
Database. All applications for domain name registration require that
the applicant identify themselves with their UIN as well as their
Protecting the Rights of Others — All holders of a UIN will
also receive a Names List that is generated by the Registry based on
the Authentication Data entered by the applicant. The Names List is
the definitive list of names that the entity is permitted to apply
to register. Each name identified in the Authentication Data must be
supported by public document(s) that show the use or registration of
that name by the applicant.
No priority will be determined or granted for one name on a Names List
as against any other name on the Names List. No Names List gives priority
to the holder of the Names List as against any other holder of a Names List
that includes the same name(s).
The Registry will register names only on a "first-come" basis.
The Registry will maintain an archive of all of the documents provided
to support a name included in the Authentication Data for a given
- Protection Against Abusive Registrations — An
applicant for a .travel name is only permitted to register a name found on
its Names List. The Registry will support UDRP and CEDRP processes.
- Avoidance of Authentication Manipulation —
Authentication manipulation might occur if the applicant were able to
"shop" for an Authentication Provider that will certify them as eligible.
The Registry will implement several procedures that will guard against
A travel association that is an Authentication Provider will be
permitted to authenticate only its own members or the members of
another association where a prior agreement and procedures have
been put in place.
All denials by association Authentication Providers will be
recorded, logged and archived by the Registry.
A third-party, independent Authentication Provider may
authenticate any entity, but all denials will be recorded, logged
and archived by the Registry in the Authentication Database and all
certifications by such an Authentication Provider will be matched
against the log of denied entities. During Limited Launch there
will be only one non-association Authentication Provider.
All Authentication Data and review is standard across all
All Authentication Data is entered directly into the
Authentication Database and is always available for review by the
Avoidance of Name "Lock-up" — Name "lock-up" might
theoretically occur where a name is applied for and put "on hold"
while authentication of eligibility and name selection are carried
out. No .travel names will be put "on hold".
The Registry will permit registrations only by holders of a UIN. All
holders of a UIN will have been pre-authenticated and each will have
a Names List. Only a name on the applicant's Names List will be
registered. The UIN and Names List will be held in the Authentication
Database and will be confirmed by the registry at the time of each
name registration. The confirmation will occur during the
registration process and will not cause a delay. No name(s) will be
"held" or "locked". Any name that is not registered will
remain available for registration by an eligible party whose Names
List includes that name.
Reporting on Eligibility and Authentication — The Registry
will maintain a log of all denials, attempts by applicants to change
Authentication Provider subsequent to a denial and any messaging or
other communications problems that may occur with Authentication
Providers. Within six months following the end of Limited Launch the
Registry will provide ICANN with a report of experience in these
STARTUP — FULL LIVE OPERATION
- Commencement — Full live operation of the Registry
will begin without interruption upon the conclusion of Limited Launch.
Pre-authentication — Pre-authentication will be required for
registrations during full, live operation as it was during Limited
Launch. A UIN will be required to initiate a registration.
Pre-authentication and receipt of a UIN and Names List will permit
immediate application for domain name registration.
Names List — All holders of a UIN will also hold a Names
List. An applicant is entitled to apply to register any name(s) on
the applicant's Names List, as during the Limited Launch phase.
Open to All — When the Registry is in full live operation
pre-authentication and name registration will be open to all
potential .travel registrants whether or not they are a member or
affiliate of an Authentication Provider. Pre-authentication will
continue to take place through Authentication Providers, which group
may vary in size and participants from time to time thereafter and
which may include one or many third-party, independent
Authentication Providers that are not travel associations. A travel
association that is an Authentication Provider will continue to be
permitted to authenticate only its own members or the members of
another association with which it has a prior agreement.
Registrars — Registration during full live operation will
take place through Registrars approved by the Registry.
FORMAT FOR .TRAVEL DOMAIN NAME
EPP 1.0 Messages — Registrars will submit EPP 1.0 messages to the
registry operator. For domain creates, renews and transfers, the
message will include an extension so that the registrant's
authentication to create, renew, or transfer the domain can be
validated. The following messages are examples of the messages and
EPP command <domain:create>
EPP command <domain:transfer>
EPP command <domain:renew>
EPP response if UIN data is missing
lang="en-US">Required parameter missing</msg>
data is missing</text>
EPP response if UIN validation failed
lang="en-US">Invalid authorization information</msg>
This Part V to Appendix
S specifies the criteria for Registry's selection of ICANN-Accredited
Registrars ("Registrars") wishing to enter into a
Registry-Registrar Agreement to register domain names in the .travel
The Registry has not
established a minimum or maximum number of Registrars that will be
selected for the .travel TLD. The Registry will accept applications
from any Registrar and will enter into agreements with Registrars
only after review of applications in the form it specifies and makes
public from time to time.
The Registry will
select from among Registrars in a manner that is based on and
promotes the following characteristics in the group of authorized
1. Recognition of the
industry-specific nature of the .travel TLD and demonstrated
willingness to participate in providing registrar services to
registrants in full support of the policy requirements established
for eligibility and name selection;
2. Thorough and
demonstrated understanding of the principles and intentions
underlying .travel TLD policies and procedures;
familiarity with the needs of the .travel community;
familiarity with the particular requirements of .travel registrants
in the language(s) and region(s) served by the Registrar;
5. Established business
relationships with one or more (proportionate to the size of the
Registrar) members of the travel industry or with organizations
representing the .travel community in the region(s) served by the
willingness and ability to publicize and market the .travel TLD, and
to follow all .travel TLD marketing guidelines and to use its
materials as appropriate;
7. Demonstration that
sufficient staff resources are available and that the Registrar has
the technical ability to interface with automated and manual elements
of the .travel TLD registry process as specified by the Registry from
time to time;
8. Demonstrated systems
designed to avoid submission of unqualified applications that will
burden the ENS system;
systems designed to avoid any disputes regarding transfers among
Registrars and acceptance of any .travel policies and procedures
established in that regard;
10. Acceptance of
Registry policies and designated procedures for grace periods for
11. Willingness and
ability to post and refresh a minimum deposit against which fees will
be drawn, in the form of cash or a letter of credit.
Registry will evaluate
and, in its reasonable discretion, render a decision with respect to
the selection of each applicant to serve as a Registrar based on, all
of the above criteria and will periodically review and, as
appropriate, revise its selection of Registrars based on such
Specification — Public WHOIS
WHOIS service is compliant with RFC 3912 (formerly 954). The primary
WHOIS services substantially consist of:
43 WHOIS services (thick registry)
primary WHOIS services are described in more detail below.
WHOIS service is the authoritative WHOIS service for all second-level
Internet domain names registered in the .travel gTLD and for all
hosts registered using these names. This service is available to
anyone. It is available via port 43 and through the Registry website.
WHOIS system has been designed for durability, availability, and
performance. Provisions for detection of abusive usage, i.e.
excessive numbers of queries from one source, have been taken into
account, and other countermeasures against abuse will be activated if
Part VI of Appendix S is subject to change by agreement of Registry
and ICANN during the design process as well as during the IETF
WHOIS service is described in more detail below.
43 WHOIS SERVICE (THICK REGISTRY)
format of responses will follow a semi-free text format outlined
below, preceded by a mandatory disclaimer specifying the rights of
the Registry, and of the user querying the database.
Each data object shall be
represented as a set of key/value pairs, with lines beginning with
keys, followed by the colon as a delimiter, followed by the value.
All WHOIS data will be in the
ASCII character set, which has encoding compatible with UTF-8 for
easy transition to including internationalized data, and as per the
IETF's recommendations on i18n in Internet protocols. For fields
where more than one value exists, multiple key/value pairs with the
same key shall be allowed (e.g. to list multiple nameservers). The
first key/value pair after a blank line should be considered the
start of a new record. It should be considered as identifying that
record and is used to group data together, such as hostnames and IP
addresses, or a domain name and registrant information.
All record and key types shall
be specified in a publicly available description on the Registry's
website. The record types and key names should change as
infrequently as possible.
WEB-BASED WHOIS SERVICE (THICK REGISTRY)
will make available a WHOIS interface on its website which can also
be accessed by each ICANN-Accredited Registrar that is a party to a
Registry-Registrar Agreement with Registry. The information available
in the WHOIS database will be returned as a results page on the
website. An example of the fields contained in the returned data,
which are identical to the Port 43 thick registry WHOIS, can be found
in the WHOIS output fields section below.
MINIMUM DATA UPDATE FREQUENCY
committed Performance Specification with regard to Update Frequency
for WHOIS is 15 minutes for 95% of the transactions; 100% within 24
hours. That is, 95% of the updates to the WHOIS will be effectuated
within 15 minutes; the remainder no later than 24 hours. This is
measured from the time that the registry confirms the update to the
Registrar to the time the update appears in the WHOIS.
PROTOCOLS THROUGH WHICH ACCESS IS PROVIDED
to the WHOIS data is provided through the WHOIS protocol, supporting
exact queries for domain names, contact IDs, registrar name,
nameserver hostname and nameserver ip-address.
QUERY AND OUTPUT FOR REPORTS DELIVERED BY WEB PAGE AND PORT 43
5.1 WHOIS Queries
For all WHOIS queries, the client
provides a character string for which information is desired and
optionally, the object type and interpretation control parameters to
limit the search. If the object type and interpretation control
parameters are not specified, WHOIS searches for the character string
in the Name fields of the Domain object. Object type controls are
available to limit the search to just data in the specified object.
Interpretation controls are available to limit the search to just the
ID field of an object, or to specify partial keyword matching or to
provide full or summary output.
Queries can be made as either an
"exact search" or a "partial search", both of
which are insensitive to the input string case. An exact search
specifies the full string to search for in the database field. An
exact match between the input string and the field value is required.
For example: "Registry.travel" will only match with
"Registry.travel". A partial search specifies the start of
the string to search for in the database field. Every record with a
search field that starts with the input string will be considered a
match. For example: "Registry.travel" will match with
"Registry.travel" as well as "Registry.Travel, Inc."
By default, if multiple matches
are found for a query, then a summary of matching results is
presented. A second query is required to retrieve the specific
details of one of the matching records. If only a single match is
found, then full details will be provided. Full detail consists of
the data in the matching object as well as the data in any associated
objects. For example, a query that results in a domain object will
include the data from the associated nameserver and contact objects.
Additional information a