

Shopzilla co-founder discusses how .tel will change the way we communicate - wibblenut
http://www.windley.com/archives/2010/03/using_the_tel_tld_for_contact.shtml

======
devicenull
"This is pretty cool because it means that anything that can speak DNS (pretty
much everything) could have programmatic access to this data."

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).

~~~
wibblenut
You can encrypt your records.

>DNS isn't exactly designed to withstand that kind of abuse (You can't block
someone, you can't ratelimit someone, etc).

It's hard to take out somebody's nameservers, since there's no single point of
failure (unlike with most web setups). But even then there's still (hopefully)
some resolvers with cached records :)

~~~
qeorge
_You can encrypt your records._

Perhaps this is a dumb question: How does that solve the problem? Either its
readable by all or by none.

 _It's hard to take out somebody's nameservers, since there's no single point
of failure (unlike with most web setups). But even then there's still
(hopefully) some resolvers with cached records :)_

I think you may have missed the point. He's not worried about the data being
unavailable, quite the opposite.

~~~
wibblenut
>Perhaps this is a dumb question: How does that solve the problem? Either its
readable by all or by none.

There's a service called TelFriends that brokers keys between you and your
friends.

Ordinary people don't have to care about that - typically their
username/password is used in whatever app they're using to transparently
decrypt records on the fly.

And since we're talking about privacy, you _own_ your domain and its data -
not Telnic, Google, or Facebook.

------
qeorge
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.

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?

Finally, what's with the registrar ballot screen that doesn't list prices? For
anyone who's wondering, name.com looks the cheapest ($10).

------
viraptor
NAPTR is already misused for sip location imho... but this is even worse. The
cryptic string

    
    
        "u" "E2U+web:http" "!^.*$!http://www.windley.com!"
    

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.

Could they make it any more complicated than this?

~~~
wibblenut
>NAPTR is already misused for sip location imho

Why?

>Could they make it any more complicated than this?

It may look messy, but complicated? You can write a parser in a few minutes.
It's simple and it works.

~~~
viraptor
Misused, because why should the client care about your routing? SIP already
provides a way to drop the router from the path after relaying the first
packet - why put the same exact capability onto DNS then? There are caching
issues, routing delays caused by 3 resolver queries (NAPTR -> SRV -> A), etc.
etc. Imho enum should be available only explicitly - not as the base routing
mechanism.

Complicated - because of regexes and usage of prefixes such as E2U which don't
make sense here. Someone created a service based on a custom TLD and marks the
entries as E2U even though they don't use E.164 numbers at all. If they cannot
get it right, how can users understand it?

------
phpnode
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.

"This is pretty cool because it means that anything that can speak DNS (pretty
much everything) could have programmatic access to this data."

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.

~~~
wibblenut
Using an e-mail address as your identifier kind of defeats the purpose.

Google's webfinger takes this approach, using TXT records to map your email
address to an XRD document. But this adds a lot more complexity and means
doing an extra HTTP request - so now it's much slower than a single DNS query
and there's probably a SPoF.

Simplicity wins.

~~~
phpnode
it wouldn't have to be a SPoF, you'd just replicate your server and add an
additional record, if the client can't reach the first server it failovers
(failsover? fails over?) to the next one. I don't think it adds to the
complexity too much and it's hardly going to be slow - it'd be much faster
than the time it takes to send even the smallest email message.

~~~
wibblenut
Well, if you're looking up a name, for example from a dialer on a mobile
device, or navigating through some kind of directory service; are you going to
be happy hanging around for a HTTP request (or several)?

DNS was born to do this; it's lightweight, super fast and wonderfully
distributed. :)

~~~
phpnode
A fraction of a second delay probably wouldn't be noticeable to the end user -
you'd only ever lookup the number when actually making the call. DNS may be
distributed but that's part of the problem - you can't just set your address
to redirect to another number when you're out on lunch - it'd take too long
for the changes to propagate through the system. You wouldn't put email
addresses at the DNS level, so why do this?

~~~
wibblenut
>A fraction of a second delay probably wouldn't be noticeable to the end user

It is (try it), and retries/outages would be very noticeable. One of the
applications I'm particularly interested in is directory services, and as you
can imagine browsing through trees is extremely sensitive to responsiveness.
Dialing a name should also be near instantaneous.

>DNS may be distributed but that's part of the problem - you can't just set
your address to redirect to another number when you're out on lunch

You can (.tel allows you to switch between "profiles").

>it'd take too long for the changes to propagate through the system.

You can set TTLs to whatever you like (60 by default).

------
nym
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 <http://henri.tel/>

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.

Their main webpage is <http://www.telnic.org/> and they're in wide release
now. Unfortunately, tom.tel is already taken ;-)

~~~
theBobMcCormick
You can remember <http://henri.tel>, but if this takes off, it's gonna be like
the old AOL user ID's or most of the big webmail providrs where the namespace
is so crowded that everyone ends up as <http://henriloveshiscat182.tel>. :-)

~~~
sjs
Governments could begin programs to create namespaces for citizens who would
like a domain. We already have TLDs for countries, and often for smaller
divisions as well (i.e. provinces, states, etc), we could just keep adding sub
domains for family name, and so on. e.g. I could be
sami.samhuri.victoria.bc.ca. Of course, then people will move so we'd have to
have everyone involved in a redirect scheme, there are likely other issues
with the idea, but I think it's neat.

With ipv6 we could each get a static IP as well.

~~~
theBobMcCormick
As you said, that'd be a bit of a pain when you move. Plus to me, the big
question is do people (average people, not us HN geeks), actually _want_ or
care about something like this?

BTW.. The individual static IPv6 addresses seems unlikely also. Because of the
much larger address space provided by IPv6, there's a great deal of concern
about the potential of massive increases in the size of the routing tables for
Internet backbone routers. Because of this, one of the goals of the IPv6
Allocation and Assignment Policy is "Aggregation". Addressing is going to be
assigned strictly on the basis of network topology to maximize the ability to
to do route summarization. Relatedly, one of the policy goals for the IPv6
Allocation and Assignment Policy is that IP addresses are not to be considered
private property. Unlike IPv4 where many non-ISP organizations "own" a block
of IP addresses, in IPv6 the policy will be that IP addresses are only leased,
never owned.

------
andrewtj
I don't understand the motivation for ".tel" — why would I want to use that
namespace rather than any other?

~~~
wibblenut
Fair question. The short answer is simplicity and practicality:

* Most people don't own a .com (or .whatever) for personal use - and never will - so what are the advantages?

* The suffix indicates the capability. It wouldn't be obvious that andrewtj.com contained your contact records. I'm not sure how you could change public perception of .com/etc, but you at least have a shot at it with a TLD exclusively for this purpose.

* TelHosting providers are obligated to provide standard public APIs, and there are also specs for consuming structured data from DNS. Would you use these, or create your own?

* For people who do own a .com they most likely won't be running their own nameservers, so you'd have to persuade nameserver operators to agree on API specs and run your management software.

* .tel has a system for brokering encryption keys used to encrypt/decrypt records - if you want privacy you'd need a system like this.

* Using a common namespace offers us a publicly accessible zone - convenient!

* Marketing. Hundreds of registrars selling a common branded product gives it the best chance of adoption.

* It's actually pretty hard to do by all accounts.

I have nothing to do with Telnic - I'm just an advocate/fanboy :)

~~~
andrewtj
* _Most people don't own a .com (or .whatever) for personal use - and never will - so what are the advantages?_

Whilst that's true, when someone decides to purchase a domain, why would they
buy a .tel when there's other namespaces with more freedoms? I'd be surprised
if .tel takes off in preference to .id.au in Australia for instance; — I know
which domain I prefer and pay for.

* _The suffix indicates the capability. It wouldn't be obvious that andrewtj.com contained your contact records. I'm not sure how you could change public perception of .com/etc, but you at least have a shot at it with a TLD exclusively for this purpose._

I'm not sure that this is as practical a benefit as it sounds. If you were to
ask me what my ".tel" is and I responded, just use "andrew.tj.id.au" you'd
plug it in and use it. If you were to use andrew.tj.id.au on a computer, you'd
likely consume it without even thinking about it.

* _TelHosting providers are obligated to provide standard public APIs, and there are also specs for consuming structured data from DNS. Would you use these, or create your own?_

* _For people who do own a .com they most likely won't be running their own nameservers, so you'd have to persuade nameserver operators to agree on API specs and run your management software._

* _.tel has a system for brokering encryption keys used to encrypt/decrypt records - if you want privacy you'd need a system like this._

I've written a DNS server and run a DNS service so it's a bit disingenuous for
me to answer these questions. That said, I would and am considering providing
the infrastructure for myself and others.

* _Using a common namespace offers us a publicly accessible zone - convenient!_

I'm not clear on what benefit this outlines?

* _Marketing. Hundreds of registrars selling a common branded product gives it the best chance of adoption._

* _It's actually pretty hard to do by all accounts._

Agreed on both accounts. The later is part of the reason for my lack of
enthusiasm for it.

~~~
wibblenut
>why would they buy a .tel when there's other namespaces with more freedoms?

What freedoms are you referring to?

>I'm not sure that this is as practical a benefit as it sounds. If you were to
ask me what my ".tel" is and I responded, just use "andrew.tj.id.au" you'd
plug it in and use it.

Fair enough, it would be great to reach that point!

>I'm not clear on what benefit this outlines?

Search. That's what I'm working on :)

>Agreed on both accounts. The later is part of the reason for my lack of
enthusiasm for it.

But it works :) And from a developers perspective it's easy - there's a bunch
of apps you can play with (iPhone, Blackberry, softphones, etc).

~~~
andrewtj
> What freedoms are you referring to?

I can point the A records for any other domain anywhere I like but with .tel
I'm stuck with the providers choice (or have I misunderstood?).

> Search. That's what I'm working on :)

Ah, I can see how that would be problematic. Do you have a blog or something I
can follow your progress on?

~~~
wibblenut
>I can point the A records for any other domain anywhere I like but with .tel
I'm stuck with the providers choice (or have I misunderstood?).

Ah I see. Yes, the Address record stays pointing at the TelProxy web server
(incidentally a major overhaul will be released later this month). Anyway, I
don't personally see this as a matter of "freedom" - better to keep the focus
on its intended purpose.

>Ah, I can see how that would be problematic. Do you have a blog or something
I can follow your progress on?

andy.tel - no blog, but I tweet, mostly rubbish. :-)

------
gojomo
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.

(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.)

