Which makes a better architecture for service discovery, XRD lookups on email addresses (a la WebFinger) or DNS NAPTR records (a la Telnic’s .tel domains)? Hot topic. The WebFinger project has Google and Yahoo folks behind it and uses an XML format compatible with OpenID’s work. The .tel domains forego HTTP and take advantage of DNS’s ready-made caching system.
The main functional difference is the caching
Telnic recently posted a graphic showing how much simpler using DNS directly is than finding XRD. Called an “Idiot’s Guide” – I assume tongue-in-cheek – the best argument for using DNS is almost entirely unrepresented. Future library functions could ultimately make both lookup procedures trivial (ignoring for the moment you can’t do DNS lookup from javascript), so the graphical complexity does not represent a practical issue. Using DNS to make an HTTP request and parsing the response is pretty much what the entire web is made of. How often are we doing these lookups to where the overhead would be a problem?
The one advantage of using DNS to identify service endpoints is that DNS gives you a ready and reliable cache. We don’t see this in the graphic, but the authoritative source in the DNS lookup is shielded from repeat requests by DNS’s tiered cache. Better still about this, simple client apps automatically take advantage of DNS’s cache; it’s been the fabric of the internet since 1983.
There are drawbacks. UPDATE: As Blaine Cook points out in the comments below, perhaps the biggest is that DNS has security issues until DNSSEC is widely implemented. Without that, one can’t trust that the distributed cache is providing authoritative information. For storing public keys for digital signatures, that’s important.
The caching also means DNS records can take some time to propagate under normal circumstances. While DNS records can be explicit about their preferred Time-To-Live (TTL) in the cache, it’s ultimately up to the bottom tier name server to decide what minimum values it will allow. Though Telnic seems to be specifying 1 minute TTLs, we can’t be sure this low value will be observed by every bottom tier ISP.
Unpredicatable latency could potentially be an issue for applications that depend on service endpoint registration for a quick setup-and-run operation, like downloading and installing a new chat app and immediately trying to start a chat using the endpoint the app just registered on your DNS-based id.
WebFinger servers, on the other hand, will (I assume) work like the rest of the web and rely on a combination of client-side caching according to HTTP headers and in-memory caches at the authoritative server (or servers, as DNS may specify alternates). At worst, these servers see every request, and of course, no cache can be shared across individual clients without some additional mechanism being built.
So that’s what I take away from the Idiot’s Guide to WebFinger and .tel. DNS comes with free caching to lighten the server load, while HTTPS+XRD uses the web’s caching mechanisms.
Also – and I mentioned this earlier – something that’s not obvious from the diagram is that DNS can’t be directly accessed by javascript web apps. Flash apps can open a socket, but javascript cannot. Presumably this is one reason WebFinger is not using the DNS solution.
Domains can be free
I’ve noticed that critics of the DNS service lookups often point out that domains are not free, but email addresses are. I want to take a second to point out that this is not true. A name server is considerably less expensive to run than a mail system, and if you have a domain, subdomains such as myname.example.com can be given away to end-users “free”. It’s even conceivable that an email provider could create subdomains for every email address and enable WebFinger-like lookups for email addresses through DNS NAPTR records (e.g. masonlee.webfinger.gmail.com.), should that be desirable. (This is not WebFinger’s plan, though. WebFinger passes the email address as a parameter to an HTTP method on the mail host.)
.Tel is not the only DNS solution
There are three arguments that resonate with me for registering a .tel domain. None seem compelling to the tune of $12/year, especially for people that already have domains.
Argument 1. You get to use Telnic’s nameservers and APIS for privacy controls and editing NAPTR records.
If DNS is the ideal decentralized service discovery system, and we aren’t tied to Telnic Limited, then other name servers should also be implementing these same management APIs, bringing us back to the question, what’s really special about the .tel domain?
Argument 2. If we assume third-party apps will use the Telnic APIs, then [domain].tel is the shortest possible way to express “Hey, I have Telnic conforming NAPTRs and NAPTR-editing and privacy APIs!”.
Might one just as well express the same by adding a tel. subdomain to an existing domain, e.g. tel.masonlee.org.?
Argument 3. If everyone had a .tel domain, it would be an awesome namespace, where we might silently drop the “.tel” and just have global “usernames” for finding service endpoints.
This would be ideal in a lot of ways, but the current pricing is a barrier such that this is unlikely to happen. The same problem exists for top-level i-names. Email addresses (and phone numbers) are what everybody already has.
One argument against adopting .tel is that Telnic overrides all .tel DNS A records to point to their Telnic webservers. I’ve heard their reasons for doing so – guaranteed usability in old-generation mobile web browsers and to provide a consistent looking directory – but I think this is a mistake. It’s not clear that all service endpoints, especially highly technical ones, should need to be shown on a human-friendly page (example), and as is, only Telnic has the authority to decide how the records will be presented (icons, ordering, etc.) for .tel domains on the web.
Are NAPTR and XRD mappable?
Suppose you think both DNS and HTTP+XRD service listings are cool, .tel completely aside. Could we create a unified service discovery library that allows clients to look up a service for both email and domain ids? There would be some confusion as to whether domain-looking strings provided by a user should be resolved to DNS NAPTR or OpenIDs XRD via HTTP, but we could check both and prefer one.
Secondly, if we want to use DNS sometimes, but think that XRD has the momentum right now, can we transform XRD to a set of NAPTR records, and can we agree to use the same service URIs in both systems? We could get some API compatibility this way.
That said, once the net supports email addresses as ids, how many people are going to get themselves a domain name to do the same thing? Frankly, WebFinger seems likely to obsolete OpenID urls as well.
APIs needed
For both XRD and NAPTR registries to be useful beyond OAuth and single-sign-on, there’s a lot of work still to be done. XRD providers need a standard API to allow authorized third party applications to update a user’s service listing. When I download Skype app, Skype should be able to add its endpoint to my service registry. (I’m hearing that XDI might have a solution.) And while Telnic does have APIs for this that other name servers could mimic (way to go!), cursory inspection indicates they still need improvement: for example, an authorization scheme other than username/password.
All good stuff to watch for.
