In message <[email protected]>, "John Levine" writes: > >Maybe those features are actually desirable. The real issue is expectations. > For the vast > >majority of uses dotless names are simply not an option as there are way too > many built-in > >expectations in pretty much every piece of software that deals with domain n > ames. > > On the other hand, have the data point of about 15 ccTLDs that publish > A or MX records at the TLD. Some of them have done so for a very long > time. I'm not saying that it's a wonderful idea to have dotless > names, but they haven't led to disaster yet.
We have plenty of evidence that when unexpected matches with search lists happen problems occur. We have even written RFC due to the issues. As for the 15 tlds people can work around the handful of collisions the 15 ccTLD's caused by not using those labels. They can't work around a continually changing list of labels as new TLDs get added if they put the wrong records there. > On the third hand, if we do think that no new TLDs should have dotless > names (a reasonal position in my book), last year's argument about > .SEARCH and the recent discussions about .HOME suggest that it's not a > great idea to depend on ICANN policies to be permanent. In the > argument about changing the policy to allow dotless .SEARCH, from what > I saw, Google's dominance of the search market had at least as much to > do with the outcome as the technical issues. Another application from > an applicant that does not dominate its industry would not necessarily > be resolved the same way. > > R's, > John > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
