On Mon, 26 Apr 2004, Stephen Sprunk wrote: > > You're confusing URI methods, protocols, and TLDs disastrously. I think it is you who is reading too much into the .tel and .mobi TLD. These are not proposals to put URI method functionality into domain names, but to qualify general business types, such as telephone companies, and mobile phone companies. This is no different from using .museum for museums and .aero to represent aerospace companies. The URI method tel: was a bad example, but otherwise completely orthogonal to the intelligibility of using .tel and .mobi TLDs. Let me restate without using the tel: method: The URL somemethod://cellularone.mobi Has a completely intelligible and meaningful interpretation. It is different from the following sip://cellularone.mobi http://cellularone.mobi telnet://cellularone.mobi etc. Similarly, sip://verizon.tel Is meaningful, and intelligible. So what is the _technical_ problem with having .tel and .mobi TLDs? A technical problem, for example, would be similar to the problem with edu.com, which if you recall, was created back in about 1994 or so. If I recall the problem, the dns searches from .com resolvers resolving .edu hosts appended their search domains to the name being resolved. So for example, ksr.com machines trying to contact mit.edu first looked up mit.edu.ksr.com., finding nothing, it tried mit.edu.com., and made a request to edu.com. Unfortunately, at the time, edu.com had a dialup connection. I see no such problems with creating .tel and .mobi TLDs. It is not the case that URI methods can't share names with TLDs. It would be fine to have a URI method of, say museum: if you could attach some sensible meaning to such a method. > The "tel" URI method is for dialing using E.164 numbers, e.g. > "tel:+18005551212", which will probably be translated to a different URI via > ENUM. For telephones using user/domain names, use the "sip" URI method, > e.g. "sip:support@xxxxxxxxxxx". There is no need for a .tel TLD, and adding > one ignores existing, logical solutions. > > Likewise, there is no reason for a .mobi TLD; either mobile clients should > use the standard "http" method to negotiate the content/format/encoding with > servers as needed via HTTP's existing mechanisms, or if necessary a new > method/protocol should be defined, e.g. "wap://www.example.com/". I don't think you understand the proposal for the TLDs. .mobi is not for mobile _clients_. Its for mobile _Companies_ --Dean _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf