Some thoughts on .tel

Last week Carsten Schiefner talked about .tel at the nic.at Registrartag in Vienna. Now that .tel has finally launched, here are my thoughts on this new TLD:

Using DNS to directly store contact information is an interesting concept.

Well, if you hire people like Jim or Lawrence, there is of course a tilt towards DNS as the protocol. Anyway: does it make sense?

On the pro side: it’s universally available, even in heavily firewalled environments. It’s stateless, fast and perfect for mobile devices.

On the con side: it has tight limits in terms of message sizes. Caching effects might be “interesting”. It’s per definition public without access control. You need a special client to make sense of the data.

So yes, I can see why they went that route.

There is nothing special about .tel as the zone apex.

Using a TLD is pure marketing. They could just as well have used [fancy-name-with-missing-vowels].com as a good number of web 2.0 application do. From a protocol point of view, there is no difference. From a PR perspective, a new TLD is quite helpful. They would never have gotten that PR by launching just Yet Another Internet startup.

The curse and blessing of a simple namespace.

Every name under .tel can only be sold only once. On one hand, this creates artificial shortages which can drive sales and prices, on the other hand this may be off-putting to people who won’t get their desired tag.

What’s more, as Carsten mentioned: you’ll need a search engine to find the .tel domain of the right “Franz Maier”. Now here it starts to get dangerous for .tel:

Why should a search engine restrict itself to records under .tel?

And what’s the protocol for contacting this search engine?

Given a search engine, why not just use microformats?

If Google decides to scan all the pages it crawls for hcard entries and the populates dot-tel.google.com with the information contained therein then .tel is simply toast.

The DNS is public

Jim has some drafts in the IETF describing how to encrypt DNS responses so that only authorized clients can decrypt it. IMHO this is just stupid. That’s just as meaningful as having encrypted data in public white pages books. Cute, but not practical.

Final verdict

Interesting idea. The crucial question is whether they can get over the Metcalfe’s law bump: Is the current buzz strong enough and the client support sufficiently universal so that they can establish .tel as the default place to go to when you want to look up an address? That’s not impossible, but far from a given.

I give them a 20% chance of making it.

Good luck!

[Update, 2008/12/12]

Carsten refers me to a “reply” on a .tel blog. Ok, I’ve enabled comments for this post here now to allow direct feedback.

Quick answer to Rik’s posting: He is bullshitting you. Let’s take a closer look at his argument:

In order to publish your own information in one place that is forever yours, the best (and arguably only) solution today is to use a top-level domain. If you don’t use a TLD, you’re subordinated to a service provider that may or may not sell you advertising, cut you off, or even go bankrupt. Then good luck telling everyone that you switched to *another* “forever” place, and listen to the snickers.

This is stupid. He mixes up “owning a domain” vs. “using a service provider’s domain” with “normal domain” vs. “Top level domain”.

I fully agree that you should do your own business (email, web, …) based on a domain you really own. It’s utterly stupid to rely on user@yahoo.com, user@aol.com, or similar addresses for business email. No argument here.

But this has nothing to do with whether your business’ domain is example.com, example.at, or .example. The normal TLDs are stable enough. They will not go bankrupt. They won’t cut you off if you pay the yearly fee. The registry cannot place advertising on your webpage. There is very little benefit of getting your own TLD.

That is the reason why Telnic is using a TLD. We’re not making money from hidden deals or advertising, or thinking up new business models that promise to make someone else pay for your chance to control your data. You simply pay a small price ($15/year or whereabouts) for your guaranteed freedom and control, and buy your own unique domain. A .tel TLD is the only guarantee for you to own your unique, forever, publishing platform for contact information.

This is the next stupid argument. At first, he argues why Telnic is using a TLD. Fine, they’re entitled to their opinion. Then he switches gears and talks about why you should pay THEM a yearly fee and submit to be dependent on them forever. Based on his own reasoning, everybody should get his own TLD.

Summary: after explaining why telnic doesn’t want to rely on TLD registry they tell you to rely on them. What’s good for the goose isn’t good enough for the gander.


[Update 2, as an answer to the comment:]

Henri,

I think it all boils down to the question of whether .tel is more like a TLD or more like a normal web 2.0 service provider.

Telnic is trying to have it both ways.

The TLD mantle (especially the gTLD one) has some strings attached (the ICANN rules) which strengthens the position of the registrant. That is certainly more powerful that what any normal company can claim they will obey in the future. A TLD also has the aura of stability and durability.

But: the business-case behind .tel is not a proven one. You can’t on one hand claim that .tel is as stable as any other serious TLD if on the other hand you claim that this a completely different kind of TLD with a new application as the sole purpose of the TLD. There is no track record for telnic’s idea, and thus for the long-term stability of .tel.

Also, if we buy into the idea that telnic is actually selling domains (and not just accounts in some fancy online service), then why restrict this application to .tel? If the creative point of telnic’s idea is in the use of NAPTRs, then there is actually nothing special about .tel, the TLD. So why should a user enter ibm.tel when in fact they know for sure that IBM owns ibm.com, and thus just enter ibm.com into the NAPTR-reading application?