<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: Tralliance Responds to ALAC Concerns
- To: <ron.andruff@xxxxxxxxxxxxxxxxx>, <tralliance-comments@xxxxxxxxx>
- Subject: RE: Tralliance Responds to ALAC Concerns
- From: <ron.andruff@xxxxxxxxxxxxxxxxx>
- Date: Mon, 16 Oct 2006 10:19:31 -0400
2nd try.
Ronald N. Andruff
President
Tralliance Corporation
The .travel Registry
220 Fifth Avenue
New York, NY 10001
(+1) 212 481-2820 x 11
www.travel.travel
www.tralliance.travel
www.search.travel <http://www.search.travelc>
_____
From: ron.andruff@xxxxxxxxxxxxxxxxx [mailto:ron.andruff@xxxxxxxxxxxxxxxxx]
Sent: Monday, October 16, 2006 9:48 AM
To: 'tralliance-comments@xxxxxxxxx'
Subject: Tralliance Responds to ALAC Concerns
Tralliance would like to thank the ALAC for giving consideration to the
.travel Registry wild card service. The ALAC represent the user perspective
and we value their experience and observation. However, as is often the case
in these circumstances (due to lack of information or confusion about the
objective) we believe that some of the issues ALAC notes need further
clarification. For clarity, we have copied the entire ALAC posting and
noted our comments within the body copy. Our comments follow the word:
"Response:"
The ALAC has significant concerns about the proposed wildcard in
.travel, and strongly urges ICANN to reject the proposal. Many of our
concerns echo those of the SSAC, although of course ours primarily are
related to stability and security issues experienced by Internet
users. Stability of the DNS is ICANN's paramount consideration, and
this TLD wildcard would cause stability problems for all of the
reasons the SSAC identified during its evaluation of SiteFinder, TLD
wildcards introduce confusing and unpredicable behavior in a core part
of the DNS that has hitherto been very stable.
We also have specific competition-related concerns that we believe
merit examination by relevant national authorities.
1. Before moving into the substance of our concerns, we note that
much of the justification in the .travel wildcard proposal is that
they claim that its behavior will be similar to that of the existing
wildcard in .museum. But the seven gTLDs introduced in 2000 were
designed to be a "testbed." ICANN did some unusual things with those
seven to see what worked. The fact that .museum was allowed to test
wildcards doesn't mean that it was a good idea, or that it's now a
precedent for every other TLD, and its very small size keeps it from
being useful as a model for other TLDs.
Response: .museum and 13 ccTLDs currently use wild cards without impacting
the stability of the Internet in any way. Moreover, the only empirical
evidence we have about this service is that .museum wildcard has functioned
without affecting the stability and integrity of the Internet or creating
any competition issues. This is a clear indication that wild card in the
"test bed" for small and well-defined TLD's is a success.
2. Any TLD wildcard decreases user choice and impairs competition.
We note that many web browsers recognize domain lookup failures and
offer a variety of spelling correction and directory services. A
wildcard such as the one proposed for .travel disguises a lookup
failure as a success, and directs the user to the TLD's directory
rather than the service the user chose, thereby replacing a
competitive set of services with a monopoly service determined by the
TLD.
This issue is identical to the analogous one that arose with
SiteFinder. Although the .travel domain is currently fairly small,
the precedent its monopoly search engine would set is extremely
troubling, which is why we believe that an analysis of the effect on
competition of per-TLD wildcards is appropriate.
Response: It is incorrect that Tralliance "disguises a lookup failure as a
success" any more than Microsoft's browser redirect disguises a failure as a
success. In point of fact, the first paragraph of #2 describes Microsoft
more than Tralliance.
However, to clarify the matter, the redirection does not automatically lead
to the .travel directory as stated. Perhaps we have not done a very good
job of explaining that all redirections will arrive at a landing page where
the searcher has the following options:
1. search the .travel directory (online "catalogue") for a
particular travel product or service (which is devoid of advertising,
placement fees, key words or any other revenue generating mechanism);
2. search for a particular product/service using search.travel
(spider the world wide web and select from either the "organic" result or
sponsored link, according to the relevancy as so deemed by the user);
3. learn more about the .travel TLD (for industry members);
4. learn more about how to register a .travel TLD (for industry
members); or
5. exit from the landing page.
In short, the user has choice - in fact, a host of choices - rather than
being forced to a page where he/she has no choice (Microsoft's redirect).
Most importantly, the user also has the option to exit from the landing
page. As the Internet continues to expand into the future, these options
will serve all Internet users vastly better than receiving an error page or
redirect to an Internet browser.
But the bigger issue - the basis upon which the sponsored top level domain
was established - is the fact that .travel is for the benefit of the global
travel and tourism trade and travel consumers. A decidedly subset of
Internet users. Implicit in that mandate is the need to develop tools
which, among other things, prevent broken searches on the DNS connecting
potential buyers to selected sellers of travel products and services in the
most efficient manner possible. In that light, one could consider this
issue a more relevant discussion within the travel and tourism industry
(which has weighed in with a request for this service with its own posting
in this forum) than one for the ICANN community - provided, of course, that
no harm is done to the stability of the Internet in any way.
Ultimately, Tralliance's intention is to serve all Internet users - whether
they be industry or consumers - looking for travel information on the
Internet. This is the beginning and end of the objective, as we trust we
have clearly stated.
3. We note that the search.travel directory proposed for the wildcard
web site is already available. This directory is extremely confusing
to users, and even if one grants that the .museum wildcard is benign,
which we do not, it is disingenuous to compare the proposed .travel
directory to the one for .museum. The .museum wildcard leads to a page
that lists domains within .museum that most closely resemble the one
the user entered. The search.travel site is a pay-for-placement
directory where the vast majority of entries are in domains other than
.travel. For example, when we went to search.travel and entered
"bermuda", it returned a page with listings of three .travel domains
and 21 domains in other gTLDs and ccTLDs. When we entered the
misspelling "bermudda", the kind of entry likely to lead via a
wildcard to this directory, it returned a page with 20 entries, none
of which were in .travel. Whatever branding and consistency the
.travel domain is supposed to provide to consumers is utterly negated
by the random admixture of domains they present.
Response: .travel wild card has compressed into one page what would
otherwise take a user four clicks using the .museum service. We presume the
intent of the wild card service for .museum is not to stop at the first
landing page. If a user should go beyond the landing page and click on
about.museum, he/she could find out about a particular museum. When one
clicks that link it takes you go to a page similar to the .travel wild card
landing page, but the .museum page includes some sponsor ads. When one
clicks on "find museum", which indeed would be the basis of the query, it
takes the user to a search window powered by Google where the search results
are returned in such a way that .museum TLDs will be shown on top. For
example, if you type in MoMa, the result would show moma.museum on top
followed by other TLDs. Tralliance has improved this offering by responding
to the query after the first click (rather than four clicks, as is the case
of .museum) in order to provide a better user experience.
The ALAC example of "bermudda" is a good one, but the explanation they have
put forward is not correct. The anomaly noted between "bermuda" and
"bermudda" has to do with domains that are registered versus those that are
not (bermudda). But more importantly, the ALAC is confused as to what the
.travel wild card offering is. It is not a redirect to a search engine. It
delivers users to a landing page where consumers have a variety of options
rather than experiencing the problem of broken searches. In this example,
the .travel landing page will clearly state that (should it be the case)
"bermudda.travel" is not registered. It will explain that should the user
have a legal claim to that name they could continue to register it. Therein
lays the key difference: The choice of the Internet user to pursue any of a
number of paths.
The ALAC is correct in its assessment that search results distinguish
between .travel TLDs and entities in other TLDs. The positioning of .travel
registrants on the top of the results page (which is a free service to
.travel registrants) has the following two advantages:
1. It enhances the value of the .travel TLD thereby resulting in
increased registrations; and
2. the search results that return .travel registrants provide
travel consumers with bona fide travel entities that have been
authenticated, therein raising the trust factor for online transactions.
4. The .travel TLD, like all gTLDs, is intended to be a global
resource, but the search.travel directory speaks only English. When
we searched for "france", it returned 27 sites, 26 of which were in
English. When we searched for "mexico", it returned 19 sites, all in
English. All of the links and text on the site are in English. As a
minimum, we would expect a global search engine to honor a browser's
language preferences and to return results in the preferred language
when possible, but this ones does not.
Response: The ALAC seems to have missed the fact that the proposed wild
card is not a search engine. Tralliance has been remiss in not making this
absolutely clear. A user moving on to use search.travel is just one of
several options that a redirected query offers. Regarding languages,
directory.travel, the core of the Registry (which will soon be reintroduced)
has been translated into 12 languages to date and will continue to be
translated into all languages as time goes by. This means that a registrant
in Beijing will be able to load his company's profile in Mandarin
Simplified, and a user in Rio will be able to read that profile in
Portuguese. Tralliance is leading the way forward when it comes to honoring
users' preferred languages and we will continue to do so.
5. The proposed wildcard completely fails to deal with Internet services
other than the World Wide Web, again leading to serious user confusion.
The most notably failure is that of e-mail. The proposal says that they
will provide no mail server on the host to which the wildcard points. This
will have an confusing and undesirable effect on users who attempt to send
mail to .travel addresses and mistype the domain. Currently, misaddressed
mail is rejected when the domain lookup fails, and the user immediately gets
a notice that his or her mail couldn't be delivered. The wildcard's
responses will be technically indistinguishable from a server that exists
but is temporarily unavailable, which means that typical mail systems will
retry for up to a week before returning the message as undeliverable.
The proposal notes that this is similar to what .museum does now,
implying that makes it acceptable. The .museum domain is too small to
provide a useful model, and in any event, mail to one's travel agent
is considerably more likely to be time sensitive than mail to a
museum. When this same issue arose with SiteFinder, all of the
proposed remedies had serious problems of user confusion, of user
privacy, or both, and the situation is identical here.
Response: While ALAC states that an email to a travel agent is more time
sensitive than an email to a museum, that is a value judgment and entirely
speculative. Furthermore, the reality is that the email response will be
exactly the same as an email sent to a registered domain that is currently
not in the zone. At any given time, there are hundreds of thousands of
registered domains without name servers, or not in the root zone for one
reason or another.
Again, it is important to re-emphasize that the .travel TLD is a very small
domain name space established for a specific constituency. It is much more
relevant to compare .travel to the museum domain space than it is to compare
it to the .com domain space. According to Verisign, they process over 13
billion DNS queries per day; this means that the .com TLD name servers
process more queries per hour than .travel will process in many, many years
at the current rates.
Further, let's be clear about the real issue: The concern about Tralliance's
wild card setting a precedent for .com. ICANN has made it very clear that a
registry service approved for one Registry does not automatically make that
service available to other registries. So let's take this straw man out of
this discussion.
6. The wildcard proposal admits that it would break a highly effective
anti-spam technique that checks addresses in incoming mail for
non-existent domains. It airily assumes that maintainers of all of
the world's spam filters will work around the problem by adding
special case code for the .travel domain. This is arrogant and
absurd.
Response: We apologize to any ALAC members that feel we are being arrogant
regarding this issue. That is not our intention by any stretch of the
imagination. Due to the relatively small size of the global industry and
early adoption rates of .travel, the amount of .travel email traffic is
extremely low. However, if the ALAC has any hard data that demonstrates the
amount of .travel email passing through spam filters, we would be more than
happy to evaluate the data and respond accordingly.
We would also like to point out that anti-spam algorithms are constantly
being updated, so over time, any issue that .travel (or any other Registry)
email might bring about will be addressed as a matter of course.
7. The proposal doesn't even acknowledge the existence of other
widely used services such as secure HTTP (https), Jabber, and FTP, all
of which would suffer the same user confusion problem, that a wildcard
makes a non-existent domain indistinguishable from a host that is
temporarily offline.
Response: We did not intend to imply that other Internet-based services are
not important. Rather, we believe that the frequency of use of these
services in negligible today in the .travel space. Again, if the ALAC has
any data concerning the usage of these services in the .travel domain space,
we are more than willing to examine the data and adjust the service
appropriately.
END
Ronald N. Andruff
President
Tralliance Corporation
The .travel Registry
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|