Two important specifications reach their final stage last month: XRD 1.0 as an OASIS Standard and Web Linking as an RFC. Both are essential building blocks in web discovery and richer distributed web services. It was a long journey getting both of these published in their respective communities – over 2 years of effort for each.
I would like to thank Mark Nottingham for his leadership and hard work authoring the Web Linking specification. This specification will hopefully help bridge the gap between the various formats (XRD, ATOM, HTML, etc.) and provide a consistent way to type links.
Special thanks go to Will Norris for his editorial lead of XRD 1.0, taking my blog posts and notes and turning them into a useful specification with his own added ideas and improvements, and to Drummond Reed for superbly chairing the XRI TC over the past 5+ years and for supporting my crazy idea to drop XRDS and replace it with something simpler.
OExchange is a newly-introduced protocol stack that allows users to share URL-based content with any service on the web. It covers posting links to social networks as well as sending content to things like online translation and printing services.
The protocol — driven by the folks at Clearspring (where I work) with the support of a long list of online services — builds on several existing open web specifications. It is backed by an open development list, tools for developers, and lots of additional resources.
After almost three years working on various discovery proposals, I’m finally starting to see the light at the end of the tunnel. While slow, good progress is being made and the drafts are reaching maturity and gaining popularity.
Just a quick update on the status of the various parts of the discovery stack (aka The Hammer Stack):
- What started as site-meta and changed into Well-known URIs is now RFC 5785.
- Web Linking, the heart of the entire discovery stack was finally approved for RFC publication with a new registry for link relation types coming shortly.
- XRD 1.0 concluded its second public review with no material changes and is moving to Committee Standard next week.
- host-meta is under review by the IETF Applications area director and pending IETF Last-Call.
- New draft available for LRDD – the top-most component of the discovery stack where everything comes together into a single discovery flow. The new draft incorporates all the feedback received (mostly editorial), and is hopefully ready for last-call in a week or so.
- First draft of the ‘acct’ URI specification (as used by the WebFinger protocol) is due shortly.
If you care about any of this, it is critical to review the host-meta and LRDD documents. They are both short and include plenty of detailed examples. Feedback would be greatly appreciated on the Apps Discuss list.
This first piece of the discovery stack was published today as an RFC. RFC 5785 defines a registry for new well-known URIs which will provide a standard location for the host-meta document. This work started a year and a half ago as a well-known document called /site-meta, and slowly evolved into a simple registry. While this isn’t a breakthrough idea, it does codify existing behavior and hopefully encourages people to share ideas, discuss proposals, and reusing existing well-known URIs.
Many thanks to my co-author Mark Nottingham for got this ball rolling. Continue reading
We made a lot of important progress in 2009, even if it doesn’t feel like it. While there were no big new ideas, no final drafts, and very little overall progress, the progress made was still extremely valuable. It represents the maturity and stabilization of these efforts and technologies. We are getting close to the finish line of the discovery stack.
The following is a quick report on the status of the efforts I am involved in and what to expect in the next few months. Continue reading
The majority of the time, downloads just work. Most downloads are relatively small files. But, when files are larger, you are more likely to encounter errors. Errors with large downloads can be frustrating and a waste of time. That’s even more true for areas with unreliable Internet connections, such as developing parts of the world. Continue reading
Discovery discussions tend to be very technical and detail-oriented. I have been looking for ways to explain how the basic elements in my discovery proposals are based on simple concepts taken directly from how humans interact with the unknown. Our brain is nothing but a big pattern-matching machine, and machine discovery works in a very similar way.
The basic idea is that discovery is the combination of three concepts:
Discovery = Patterns + Interfaces + Descriptors Continue reading
What started as a small, simple specification ended up spread over 5 (and counting) documents. Given that these are still moving targets, at least for a little bit longer, it can get very confusing for people trying to follow this work. A few months ago I wrote about the new discovery stack which included XRD, LRDD, and the three links. Since then, the design has changed to include new components and some shuffling of the existing ones. Continue reading
Over the past two weeks Well-Known URIs (draft-nottingham-site-meta) completed its last-call review at the IETF and is now pending IESG review before publication as an RFC. In addition, Host-meta (draft-hammer-hostmeta) was introduced to fill in the gap created by the recent revisions.
There is a lot of confusion about these drafts, not because they are complicated – they are pretty simple – but because of how they evolved and ended up solving different problems. It makes a good story for wannabe standards editors but that’s for another day.
One of the criticisms leveled against OpenID is that it uses HTTP URLs to identify users, and that users don’t understand URLs-as-identifiers (especially those who are not very technical). User Experience research confirms this.
Email addresses, on the other hand, are widely understood to identify people. So why can’t we use email addresses as OpenIDs? The reason is that, in OpenID 2.0, the way you perform discovery on an OpenID makes it necessary for that OpenID to be an HTTP URL: discovery information is obtained either through an X-XRDS-Location HTTP header sent by the server when accessing the OpenID (which is an HTTP URL), or by parsing through the document itself that is returned when accessing the OpenID HTTP URL. Continue reading