"This is pretty cool because it means that anything that can speak DNS (pretty much everything) could have programmatic access to this data."<p>That scares me. It then becomes simple for anyone with an internet connection to pull the phone and email addresses of anyone using this. DNS isn't exactly designed to withstand that kind of abuse (You can't block someone, you can't ratelimit someone, etc).
Cute idea, but I don't see it gaining real traction. There's been many attempts at vanity TLDs that were arguably more useful/intuitive (e.g., .jobs, .me) and they've yet to see any real adoption. For that matter, even .net's are hard to sell.<p>I also think that not allowing you to host a website at .tel is a fatal mistake. The group of people who'd prefer to look up their friend's phone number from console is tragically small. The hope I suppose is that Google indexes my .tel, and people then find my number through Google, but then why do I need the .tel?<p>Finally, what's with the registrar ballot screen that doesn't list prices? For anyone who's wondering, name.com looks the cheapest ($10).
NAPTR is already misused for sip location imho... but this is even worse. The cryptic string<p><pre><code> "u" "E2U+web:http" "!^.*$!http://www.windley.com!"
</code></pre>
means that "E2U" is a protocol (E2U doesn't seem to be defined in the same RFC as NAPTR - it means "E.164 to URI" even though the NAPTR query didn't send an E.164 request), "web:http" is a "resolution service" (they should be used the other way around if you believe the RFC, although wikipedia also uses this order). "u" indicates that the original query should be passed through the regex substitution to get a URI.<p>Could they make it any more complicated than this?
Wouldn't it be better to tie a phone number to an email address? An email address is still much more memorable than a phone number but the crowded namespace issue has already been solved. You could add something similar to an MX record to your domain's DNS that specifies where your "phone number server" is. The phone number server would be a simple database of username/alias and "real" phone number (although it could be expanded to do redirects, voicemail, 404s etc). The client making the call then consults this server which returns the number that it should dial.<p>"This is pretty cool because it means that anything that can speak DNS (pretty much everything) could have programmatic access to this data."<p>I don't think this offers an advantage over my solution, as any application that needs to use this will have to be modified anyway, the protocol I'm proposing would be equally trivial (or not) to implement.
I had the pleasure of meeting Henri last year, and he talked about how long it's taken to get this idea off the ground. I like the idea, as I hate phone numbers, and can easily remember something like <a href="http://henri.tel/" rel="nofollow">http://henri.tel/</a><p>At the time, I tried to get a quote for tom.tel but they were in their initial "companies only" stage. I believe Google or Facebook could more easily make a service like this successful, but I hope it takes off.<p>Their main webpage is <a href="http://www.telnic.org/" rel="nofollow">http://www.telnic.org/</a> and they're in wide release now. Unfortunately, tom.tel is already taken ;-)
Facebook/LinkedIn and Google make this DNS trick superfluous, but also each has a vested interest in having people use the web, not a novel DNS-based registry, for such discovery. For those reasons, I pronounce .TEL dead-on-arrival.<p>(Web hits are even easier than DNS. Why not telnic.org/henri instead of henri.tel? Both could, at Telnic's discretion, imply the exact same thing. One just makes it even clearer you're bought-into a single company's namespace. But that's a bug, not a feature.)