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.
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
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.
The very nature of WebFinger is experimentation.
This means we are likely to see implementation before a fully baked specification. Since at the moment the various bits and pieces of the protocol are somewhat scattered across multiple drafts, this post will attempt to provide a quick implementer guide for those looking to jump right in and get something working.
WebFinger is an updated take on the Name/Finger protocol using HTTP, XRD, and host-meta (instead of a direct TCP connection on port 79) to obtain information about user accounts. It works by defining a new account URI scheme and a protocol for resolving it into an extensible descriptor of the account and its owner.
The account URI, using the newly proposed ‘acct‘ scheme, is used to identify user accounts at a given host which are typically used for the purpose of resource management and establishing local identity (at the host). User accounts include a local identifier (username, screenname, or handle), and a host which can resolve and (usually) authenticate the local identifier.
The protocol consists of:
- A URI scheme to identify accounts using a familiar syntax.
- A simple protocol for resolving account URIs into an extensible descriptor.
Actually, I don’t have a well-thought, proven, and complete case to make.
What I have instead is some loose consensus from a small group of people and a lot of experience trying other ideas. Historically, this is a bad way to start a discussion about new URI schemes. Getting consensus for new URI schemes is often more difficult than solving American healthcare.
The proposed ‘acct’ URI scheme is designed to identify an account. ‘Account’ is a pretty straight-forward concept. It is some sort of identifier – a string – that is specific to an authority – usually a server or domain. For most people, their account is also their email address, and in recent years, the emphasis on email has surpassed the concept of an account. When I started using the web 20 years ago, I had an account on a server. It just happened that this account has a mailbox associated with it.