Re: [alac] dot travel wildcard, take 2bis
Given the utter unanimity I've heard on the list and yesterday's phone call, I think we can send out the note I drafted on the .travel wildcard as the ALAC's consensus position. Here's a final version, the same as last time other than a few grammar and spelling improvements. Roberto, can you pass this along to the board? R's, John 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. 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. 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. 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. 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. 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. 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.
|