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:

1. Airlines
2. Attractions/Theme Parks
3. Bed & Breakfast Houses
4. Bus/Taxi/Limousine Operators
5. Camp Facility Operators
6. Car Rental Companies
7. Computer Reservation/Travel Technology Provider
8. Convention & Visitor's Bureaus
9. Cruise Lines
10. Ferries
11. Hotels/Resorts/Casinos
12. National Tourism Offices
13. Passenger Rail Lines
14. Restaurants
15. Tour Operators
16. Travel Agents
17. Travel Media
18. 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:

1. Eligibility and name selection policy implementation
2. Gathering and analysis of authentication data
3. Delivery of eligibility confirmations
4. Registration of eligible entities
5. Registrar interface
6. Data entry into the .travel industry directory
7. 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:

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

Data Type	Required Data (.)
1. Partnership Name -and- General Partner Name (if applicable)	. List the name under which the partnership is registered and the general partner's name if applicable
2. Partnership Identifier	Required if a number is available
3. Partnership Identifier Issuer	Required if a number is available

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

1. 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.
2. 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.

3. 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.
4. 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.

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

6. 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

1. Commencement — Full live operation of the Registry will begin without interruption upon the conclusion of Limited Launch.
2. 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.
3. 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.
4. 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.
5. 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.