|
 |
Appendix S
|
Appendix
S to Sponsored TLD Registry Agreement
Contents
Part I: TLD Charter
Part II: Delegated
Authority
Part III: Description
of Sponsored TLD Community
Part IV: Start-Up Plan
Part V: Selection of
Registrars
Part VI: Public WhoIs
Part I
.Travel Charter
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
1, above:
- Airlines
- 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
- Ferries
- Hotels/Resorts/Casinos
- National Tourism Offices
- Passenger Rail Lines
- Restaurants
- Tour Operators
- Travel Agents
- Travel Media
- Travel-Consumer and Market
Research Organizations
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
Changes.
_______________________________________________
Part II
Delegated Authority
The
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:
1.
Establishment of naming conventions to be used in the Sponsored TLD.
2.
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.
3.
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.
4.
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.
5.
Mechanisms for enforcement of the restrictions in items 2 and 3,
including procedures for revocation or cancellation of registrations.
6.
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.
7.
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.
8.
Functional and performance specifications for, and pricing of,
Registry Services.
9.
Matters concerning the operation of the registry for the Sponsored
TLD.
10.
Selection of ICANN-Accredited Registrars to act as registrars for the
Sponsored TLD, consistent with Part V of this Appendix S.
11.
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
registrars.
12.
Practices of ICANN-Accredited Registrars selected by Registry with
respect to Registered Names and their registration.
13.
Terms of agreement between registrars and registrants under which
Registered Names are registered.
14.
Uses and practices by registrants with respect to Registered Names.
15.
Procedures and schedule for the start-up of the Sponsored TLD,
provided they are consistent with Part IV of this Appendix S.
16.
Provisions for publication of registry and registrar data consistent
with the TLD Sponsorship Agreement and Registrar Accreditation
Agreements.
_______________________________________________
Part III
Description
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
Appendix S).
The Registry may extend
or amend the description of the Community consistent with the terms
of the Agreement and the .travel Charter.
_______________________________________________
Part
IV
STARTUP PLAN
PHASED LAUNCH AND SERVICES
This
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
-
Registrar interface
-
Data entry into the .travel industry directory
-
Industry directory public availability
The
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.
DEFINED TERMS
Specialized
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
registrations;
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
eligibility policies;
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
eligible entity.
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;
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
6.19-6.24; and
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
registration.
TIMETABLE
The
following is a summary of the three-phase startup period including
its functions and relative dates:
Phase
|
Functions
|
Start/End
|
Initial
Pre-authentication Announcement
|
Announces the
starting date of pre-authentication to the eligible community
|
Start C: -120 days
End C: -90
|
Initial
Pre-authentication
|
Eligibility and
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
|
Start: Commencement
of Service
End: C +90 days
|
SERVICE DESCRIPTIONS
INITIAL
PRE-AUTHENTICATION ANNOUNCEMENT
1.
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
ICANN contracting.
INITIAL
PRE-AUTHENTICATION
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,
2005.
2. Initial Pre-authentication Key Elements — The
Initial Pre-authentication phase has the following key elements:
2.1
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.
2.2
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.
2.3
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
Required" below.
2.4
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
eligibility.
2.5
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
the registry.
2.6
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.
2.7
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.
3.
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
selection data.
3.1 Identifying Data by Applicant Type — The following are the
specific data elements required for each of the four designated
applicant types:
3.1.1
Identifying Data for Registered Businesses and Organizations
-
Data Type
|
Required Data (.)
|
1. Incorporation
(legal) Name
|
.
|
2. Business
Identifier (registration or similar number)
|
.
|
3. Business
Identifier Issuer
|
.
(Name and location of issuer)
|
3.1.2
Identifying Data for Partnerships
-
3.1.3
Identifying Data for Tourist and Convention Bureaus
-
Data Type
|
Required Data (.)
|
1. Registered
(legal) Name
|
.
|
2. Business
Identifier (registration or similar number)
|
.
|
3. Business
Identifier Issuer
|
.
(Name and location of issuer)
|
4. Designated by
City
|
.
(Required
if intending to register a city name)
|
3.1.4
Identifying Data for Individuals (sole proprietors)
-
Data
Type
|
Required Data (.)
|
1. Sole
Proprietor's Name
|
.
|
2. Additional
Confirmation Data (third-party issued data supporting name and
business: business license, utilities bill, supplier letter, as
determined by AP)
|
.
|
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:
-
Data Type
|
Required
Data (.)
|
|
1. All Name Types
|
Not
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".
Name Types:
a) "Doing Business As", "Trade Name" or
"Usual" Business Name
b) Usual Business Name as used in a URL
c) Trademark
d) Service Mark
e) Club or
Association Name
f) Vessel Name
g) Competition/
Event Name
h) Division Name
i) Subsidiary Name
|
2. Travel Sector
|
.
|
Applicants
select one of the eighteen .travel sectors
|
3. Membership
|
.
|
Applicants
select which AP or TTPC member they are a member of
|
4. Applicant
Address
|
.
|
|
5. Mailing Address if different
|
|
|
6. Applicant
Phone Number
|
.
|
|
7. Applicant Fax
Number
|
|
|
8. Applicant
business Email address
|
|
|
9. Business
Owner/Officer First Name
|
.
|
|
10. Business
Owner/Officer Last Name
|
.
|
|
11. Business
Owner/Officer Title
|
.
|
|
12. Applicant
Contact First Name
|
.
|
|
13. Applicant
Contact Last Name
|
.
|
|
14. Email
address of applicant
|
.
required if available
|
|
15. Current URL
of applicant
|
This need not be a .travel URL
|
|
4.
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.
5.
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.
6.
Pre-authentication Process — The Pre-authentication process will
proceed as follows:
6.1
Pre-authentication will be offered to all members or affiliates of
Authentication Providers during the Pre-authentication phase and
during Limited Launch.
6.2
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
website.
6.3
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
Required" above.
6.4
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.
6.5
The Authentication Database will be available 24 hours a day
throughout the entire Startup Period.
6.6
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
.travel policies.
6.7
The confirmation of eligibility will be recorded in the
Authentication Database.
6.8
The confirmation of eligibility will be recorded with a Unique
Identification Number issued as a permanent identifier for the
applicant.
6.9
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
Names List.
6.10
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.
6.11
The applicant will be able to apply to register only names on the
Names List.
6.12
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
Names List.
6.13
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
public.
6.14
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.
6.15
All denials of eligibility will be recorded in the Authentication
Database.
6.16
A log and archive of all denials will be maintained.
6.17
All applicant entities supplying Authentication Data will be
matched against the list of denied entities.
6.18
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.
6.19
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.
6.20
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.
6.21
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
calendar month).
6.22
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.
6.23
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).
6.24
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.
6.25
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
early pre-authentication.
6.26
Rolling Pre-authentication ends on the last day of Limited Launch.
6.27
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
1.
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.
During
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.
Once
a registrant receives its first .travel name, any industry directory
listing it has completed will automatically be made public
The
Limited Launch phase will conclude 90 days after its start date.
2. Limited Launch Registration Process —
2.1
Limited Launch will begin at 12:01 AM EST on the Commencement Date.
2.2
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.
2.3
There will be no limit to the number of names a holder of a UIN
will be permitted to register.
2.4
All registrations will be carried out by Registrars that are
approved by the Registry.
2.5
All communications between the Registry and the Registrar will
follow the "Format for .travel Domain Name Transactions" below.
2.6
Any name denials will be communicated to the Registrar together
with a notice of denial review application procedures.
2.7
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.
2.8
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.
2.9
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.
SUMMARY
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
Authentication Provider.
-
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
name.
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
applicant.
- 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
authentication manipulation:
4.1
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.
4.2
All denials by association Authentication Providers will be
recorded, logged and archived by the Registry.
4.3
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.
4.4
All Authentication Data and review is standard across all
Authentication Providers.
4.5
All Authentication Data is entered directly into the
Authentication Database and is always available for review by the
Registry.
-
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
issues.
POST
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
TRANSACTIONS
1.
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
responses.
1.
EPP command <domain:create>
<?xml
version="1.0" encoding="UTF-8"?>
<epp
xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<create>
<domain:create
xmlns="urn:ietf:params:xml:ns:domain-1.0"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
domain-1.0.xsd">
<domain:name>tralliance.travel</domain:name>
<domain:registrant>tralliance</domain:registrant>
<domain:contact
type="admin">tralliance</domain:contact>
<domain:contact
type="tech">tralliance</domain:contact>
<domain:contact
type="billing">tralliance</domain:contact>
<domain:authInfo>
<domain:pw>secret</domain:pw>
</domain:authInfo>
</domain:create>
</create>
<extension>
<neulevel:extension
xmlns="urn:ietf:params:xml:ns:neulevel-1.0"
xmlns:neulevel="urn:ietf:params:xml:ns:neulevel-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:neulevel-1.0
neulevel-1.0.xsd">
<neulevel:unspec>UIN=1234567890123456</neulevel:unspec>
</neulevel:extension>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
2.
EPP command <domain:transfer>
<?xml
version="1.0" encoding="UTF-8"?>
<epp
xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<transfer
op="request">
<domain:transfer
xmlns="urn:ietf:params:xml:ns:domain-1.0"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
domain-1.0.xsd">
<domain:name>tralliance.travel</domain:name>
<domain:authInfo>
<domain:pw>mysecret</domain:pw>
</domain:authInfo>
</domain:transfer>
</transfer>
<extension>
<neulevel:extension
xmlns="urn:ietf:params:xml:ns:neulevel-1.0"
xmlns:neulevel="urn:ietf:params:xml:ns:neulevel-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:neulevel-1.0
neulevel-1.0.xsd">
<neulevel:unspec>UIN=1234567890123456</neulevel:unspec>
</neulevel:extension>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
3.
EPP command <domain:renew>
<?xml
version="1.0" encoding="UTF-8"?>
<epp
xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<renew>
<domain:renew
xmlns="urn:ietf:params:xml:ns:domain-1.0"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
domain-1.0.xsd">
<domain:name>tralliance.travel</domain:name>
<domain:curExpDate>2007-03-08</domain:curExpDate>
<domain:period
unit="y">1</domain:period>
</domain:renew>
</renew>
<extension>
<neulevel:extension
xmlns="urn:ietf:params:xml:ns:neulevel-1.0"
xmlns:neulevel="urn:ietf:params:xml:ns:neulevel-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:neulevel-1.0
neulevel-1.0.xsd">
<neulevel:unspec>UIN=1234567890123456</neulevel:unspec>
</neulevel:extension>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
4.
EPP response if UIN data is missing
<?xml
version="1.0" encoding="UTF-8"?>
<epp
xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result
code="2003">
<msg
lang="en-US">Required parameter missing</msg>
<value>
<text>UIN
data is missing</text>
</value>
</result>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>12345-XYZ</svTRID>
</trID>
</response>
</epp>
5.
EPP response if UIN validation failed
<?xml
version="1.0" encoding="UTF-8"?>
<epp
xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result
code="2202">
<msg
lang="en-US">Invalid authorization information</msg>
<value>
<text>UIN
validation failed</text>
</value>
<value>
<text>1234567890123456</text>
</value>
</result>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>12345-XYZ</svTRID>
</trID>
</response>
</epp>
Part
V
Selection
of Registrars
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
Sponsored TLD.
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
Registrars:
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;
3. Demonstrated
familiarity with the needs of the .travel community;
4. Demonstrated
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
Registrar;
6. Demonstrated
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;
9. Demonstrated
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
registrants;
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
criteria.
Part
VI
WHOIS
Specification — Public WHOIS
The
WHOIS service is compliant with RFC 3912 (formerly 954). The primary
WHOIS services substantially consist of:
- Port
43 WHOIS services (thick registry)
- Web-based
WHOIS services
The
primary WHOIS services are described in more detail below.
Registry's
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.
The
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
necessary.
This
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
standards process.
The
WHOIS service is described in more detail below.
1. PORT
43 WHOIS SERVICE (THICK REGISTRY)
- The
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.
2.
WEB-BASED WHOIS SERVICE (THICK REGISTRY)
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.
3.
MINIMUM DATA UPDATE FREQUENCY
The
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.
5.
PROTOCOLS THROUGH WHICH ACCESS IS PROVIDED
Access
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.
5.
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 and samples of the various types of WHOIS
result records are available in the WHOIS Output Fields and Sample
WHOIS Output sections below.
5.2 Query Controls
WHOIS query controls fall into
two categories: those that specify the type of field and those that
modify the interpretation of the input or determine the type of
output to provide.
Object Type Control
The following keywords restrict a
search to a specific object type:
-
Domain:
|
Search only domain objects. The input string
is searched in the Name field.
|
Host:
|
Search only nameserver objects. The input
string is searched in the Name field and the IP Address field.
|
Contact:
|
Search only contact objects. The input string
is searched in the ID 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.
Interpretation Control
The following keywords modify the
interpretation of the input or determine the level of output to
provide:
-
partial
|
All records matching string are returned
|
.
|
Same as partial keyword
|
full
|
Displays entire detail associated with each
returned record
|
=
|
Same as full keyword
|
summary
|
Displays summary
|
$
|
Same as summary keyword
|
help
|
Displays help text
|
?
|
Same as help keyword
|
By default, if no interpretation
control keywords are used, the output will include full details if a
single record is found and a summary if multiple matches are found.
5.3 WHOIS Output Fields
This section describes the output
fields provided for each type of object. Registry will not be
required to post WHOIS Output Fields that are not required for
posting in the Registrar Accreditation Agreement.
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 Name
Domain ID
Sponsoring
Registrar
Registrar IANA ID
Domain Status
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, Facsimile (optional).
Nameservers associated with this
domain
Domain Registration Date
Domain Expiration Date
Domain
Last Updated Date
Created by Registrar
Last Updated by
Registrar
Note:
For domains on PendingDelete Status, the registry's front-end web
interface will provide an additional explanation of the status as
follows:
Up to 30 days after deletion:
|
PendingDelete (Restorable)
|
More than 30 days after deletion:
|
PendingDelete (Scheduled for release)
|
Nameserver Record
A WHOIS query that results in
nameserver information will return the following set of information
referred to as the Nameserver Record or Host Record.
Nameserver Host Name
Nameserver
ID
Nameserver IP Addresses if applicable Sponsoring
Registrar
Nameserver Creation Date
Nameserver Last Updated
Date
Nameserver Status
Created by Registrar
Sponsoring
Registrar
Contact Record
A WHOIS query that results in
contact information will return the following set of information
referred to as the Contact Record.
Contact ID
Sponsoring
registrar
Contact Name
Contact Organization
Contact Address,
City, State/Province, Country
Contact Postal Code
Contact
Phone, Facsimile, Email
Contact Registration Date
Contact Last
Updated Date
Last Updated by Registrar
Created by
Registrar
Contact Status
Registrar Record
A WHOIS query that results in
registrar information will return the following set of information
referred to as the Registrar Record.
Registrar ID (conforms to IANA
registrar-ids registry)
Registrar Name
Registrar Address, City,
State/Province, Country
Registrar Postal Code
Registrar Phone,
Facsimile, Email
Registrar Administrative Contacts
Registrar
Technical Contacts
Registrar Billing Contacts
Registrar URL
(registration services)
Registrar Creation Date
Registrar
Last Updated Date
6.
Extensible-Field Capability
Registry
reserves the right to introduce the ability for registrars to use
EPP, to add customized fields to a record in the registry database.
These fields will appear in an "additional information"
section of the WHOIS data. The maximum number of custom fields
allowed per record is yet to be determined.
|