Solving XRDS’ Host Problem with XRD and host-meta

The ongoing efforts to define standard protocols for common web services have resulted in a wide variety of specifications. If you’re interested in the Internet’s plumbing, as I am, these are truly exciting times. One of the common pieces of functionality needed by all these specifications is discovery.

The most recent, and recommended, format for discovery is XRD (currently at Working Draft 15). XRD supersedes the older XRDS format, which has a convoluted evolution that can be traced in twists and turns through XRI Resolution, Yadis, and XRDS-Simple.

These older specifications define both a data format and a resolution protocol. The resolution protocol suffers a problem, however: it can’t distinguish between a host and a root-level resource. A succinct technical statement is provided in Eran Hammer-Lahav’s host-meta draft:

Because there is no URI or a resource available to describe a host,
many of the methods used for associating per-resource metadata (such
as HTTP headers) are not available. This often leads to the
overloading of the root HTTP resource (e.g. ‘’)
with host metadata that is not specific to the root resource (e.g. a
home page or web application), and which often has nothing to do it.

Take, for example,, the URL I use to identify myself online. It has an XRDS document located at:

<xrds:XRDS xmlns:xrds="xri://$xrds"

Among the services advertised are an address book available via Portable Contacts and an EAUT-based email address to URL translation service. The address book is very specifically associated with me; it is my address book. The EAUT service, however, is simply a service that is running at the domain; it is not associated with me directly. This case exhibits the conflict between the host and the root-level resource.

The new XRD specification does not define a resolution protocol. That task is left up to other specifications such as host-meta and LRDD. host-meta, in particular, addresses this conflict by registering a well-known URI for metadata about the host.

Looking again at my digital identity, things have been broken down into two separate documents. One for information about the host at:

<XRD xmlns=""
  <Link rel="lrdd" template="{uri}"/>

And another for information about me at:

<XRD xmlns="">
  <Link rel="" href=""/>

Using this schema, my address book remains in the XRD that describes me. However, WebFinger (the modern EAUT equivalent), which utilizes LRDD, moves to the host-meta XRD. This is a much cleaner approach, which resolves ambiguities about exactly what discovery is being performed on.


Lonna Hanson
March 13, 2010 at 2:34 PM

Although I do not begin to understand the engineering behind your comments, I am amazed.

Monica Keller
May 16, 2010 at 7:41 PM

What do you think of the concept or an LRDD processor which takes an argument ?

Jared Hanson
May 16, 2010 at 8:05 PM

My initial reaction, while reading through the strawman earlier today, was that I like it.

It does raise a few questions in my mind, however.

The biggest one being will each domain have to implement an LRDD processor? If so, clients will still bear the burden of implementing LRDD for domains that don’t have a processor. Can a client be configured with a “fallback” processor(s) at a well-known domain for this case? In which case I’d suggest terming them XRD resolvers (analogous to DNS resolvers), and note that the XRI TC is looking like it solved the right problems originally, just in the wrong context.

I’m looking forward to discussing this more at IIW.

May 19, 2010 at 1:00 PM

What do you think of the concept or an LRDD processor which takes an argument ?

Post a comment