[alac] Re: Do we care about *.travel ?
I hear that the technical committee for the *.travel application will be convening shortly, so it would be good for us to have our comments in soon. Suggested reasons we don't like the *.travel wildcard: The ALAC has significant concerns about the proposed wildcard in .travel, and strongly urges ICANN to reject the proposal. Our concerns somewhat echo those of the SSAC, although of course ours primarily are related to stability and security issues experienced by Internet users. 1. Any TLD wildcard decreases user choice. 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. This issue is identical to the analogous one that arose with SiteFinder. 2. We note that the search.travel directory proposed for the wildcard web site is already available. This directory is extremely confusing to users, and it is disingenuous to compare it to the one for .museum. The .museum wildcard leads to a page that suggests domains within .museum that 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", 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 completely negated by the random admixture of domains they present. 3. The proposed wildcard completely fails to deal with Internet services other than the World Wide Web. 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, but we note both that .museum is so small that it's not a useful model for a larger domain, and that mail to one's travel agent is considerably more likely to be time sensitive than mail to a museum. This same issue arose with SiteFinder, all of the proposed remedies then had serious problems of user confusion, of user privacy, or both, and the situation is identical here. 4. The wildcard proposal admits that it would also 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. 5. 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 as mail, that a wildcard makes a non-existent domain indistinguishable from a host that is temporarily offline.
|