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. ‘http://example.com/’)
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, http://jaredhanson.net/, the URL I use to identify myself online. It has an XRDS document located at: http://jaredhanson.net/meta.xrds

<xrds:XRDS xmlns:xrds="xri://$xrds"
           xmlns="xri://$xrd*($v*2.0)">
<XRD>
  <Service>
    <Type>http://portablecontacts.net/spec/1.0</Type>
    <URI>http://www-opensocial.googleusercontent.com/api/people/</URI>
  </Service>
  <Service>
    <Type>http://specs.eaut.org/1.0/template</Type>
    <URI>http://jaredhanson.net/</URI>
  </Service>
</XRD>
</xrds: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 jaredhanson.net; 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: http://jaredhanson.net/.well-known/host-meta

<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0"
     xmlns:hm="http://host-meta.net/xrd/1.0">
  <hm:Host>jaredhanson.net</hm:Host>
  <Link rel="lrdd" template="http://jaredhanson.net/meta.xrd?id={uri}"/>
</XRD>

And another for information about me at: http://jaredhanson.net/meta.xrd

<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
  <Subject>acct:me@jaredhanson.net</Subject>
  <Link rel="http://portablecontacts.net/spec/1.0" href="http://www-opensocial.googleusercontent.com/api/people/"/>
</XRD>

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.

Content, as a concept, encompasses a wide area. It could be a newspaper article, a radio program, a TV show, a spreadsheet or presentation. Creating and managing content has been one of the primary purposes of computers, ever since they came into existence.

With the rise of the Internet, and particularly social networking, there has been a renewed focus on people and the role they play in a system. Proper emphasis on individuals and groups makes collaboration more efficient.

One of the problems surrounding identity in the past has been the lack of a widely adopted standard. This has made it very difficult to build solutions that are interoperable. Thankfully, OpenID is gaining traction, along with usability improvements through EAUT and other initiatives.

Underlying OpenID, the XRD specification, emerging from earlier work on XRDS-Simple and Yadis, will tie people and content together through services that allow interaction among the two.

There is a lot of work remaining, but its conceivable at this point to envision a future where signing up for a service is as simple as entering your email address and approving access. When the mesh realizes that level of usability, innovation will both flourish and be self-reinforcing.

Developers would be well advised to pay attention to these standards. Integrating these technologies will allow software to participate in the larger web-based ecosystem, both deriving and yielding benefits from and to the whole.

As I noted in my comment:

The standards are all coming together. In my mind, the flow looks something like this:

1. People become directly addressable (i.e. through email addresses).
2. Programs dereference the email address and get an XRD document, which identifies associated services.
3. Programs interact with the discovered services to publish and subscribe to content.