The State of the Hammer Discovery Stack

John Panzer jpanzer at google.com
Fri Nov 6 19:41:19 UTC 2009


All (and I do mean all, I've pulled in a lot of related lists, so please be
selective in replies to this email):

At IIW this week, there was a spontaneous marathon session about nailing
down open issues around discovery (which Webfinger depends on and is helping
to drive).  The notes from the discussion are available at
https://docs.google.com/a/johnpanzer.com/Doc?docid=0AZojn6fzr_tFZGRqNjhzcXZfOWY1cXA3emY5&hl=en.
 A  lot of people were there, my estimate as 20+ at one point.

Since the Hammer Discovery Stack encompasses no fewer than 6 independent
standards, there is no one mailing list to go to in order to discuss the
whole thing top to bottom.  I suggest the Webfinger mailing list as a place
to talk about all of the pieces together.  First off, I'm going to draw a
box around the whole stack (L(a)RDD, XRD, host-meta, Webfinger, .well-known,
Web Linking).  The consensus at IIW was that this was the "Hammer Discovery
Stack" so that's what I'll call it (see
http://www.flickr.com/photos/57287692@N00/4081200654/).

So, what's the state of the Hammer Discovery Stack?  I'll try to capture *the
consensus of the sub-group at IIW* below.  Note that these all need to be
ratified by the various standards groups for doing the various bits of the
Stack.

1. HDS needs the .well-known/host-meta XRD file to be able to indicate what
"host" it's talking about.  *RESOLVED*: <hm:Host>example.com</hm:Host>, no
Subject, contents of hm:Host to be RFC 3986 "Host" string.

2. HDS needs a simple URI template syntax for template XRD files (XRD files
that contain recipes for URIs rather than actual URIs).  It also needs a
vocabulary, e.g., what variable names does HDS require? *RESOLVED*:  Use
{uri} and {+uri}.  These are forward-compatible with RFCs that are
in-the-works but don't depend on to-be-minted RFCs.  We use one variable,
"uri", no sub-parts.

3. HDS (via L(a)RDD) needs to define what priority to use when doing
discovery between Link: header, various resource-specific link elements, and
host-meta.  This comes down to one question:  Should HDS prioritize *
host-first* discovery, meaning that if host-meta exists it has the final
word, or should it prioritize *resource-first* discovery, meaning that if
Link: header or <link> element exists it has the final word?  *RESOLVED*:
 There Can Be Only One; everyone agreed that there must be one priority
order, it cannot be left undefined or optional, and everyone was willing to
give up their favorite ordering in order to standardize on just one.  *NOT
RESOLVED*:  Exactly which of host-first or resource-first we should pick.
 (I plan to start a separate thread for this topic.)

4. We also discovered that the HDS does not currently define what it means
to have a template {uri} inside anything other than a host-meta XRD.  This
is because the spec writers didn't have a use case for this.  Breno has a
use case for this, and believes that signed XRDs for individual resources
are only going to be deployable in many situations if you can sign a
template rather than having to dynamically sign millions of individual XRD
representations.  *RESOLVED*:  To solve this, *Breno* needs to write up a
proposal for the semantics and get it adopted by the HDS (somewhere).

RAN OUT OF TIME/COFFEE, NO DISCUSSION:
*Webfinger - syntax of acct: URI *
*Webfinger - rel value *
*Generalized Discovery for URIs *
*Rel value for xrd-edit URL (a way to discover how to add services? go to
web page?)*

Please follow up on individual issues by starting or contributing to threads
in the appropriate spec discussion lists.  If you can't figure out what that
is for one or more issue, please start with the webfinger list (
webfinger at googlegroups.com) and we'll play traffic cop.

--
John Panzer / Google
jpanzer at google.com / abstractioneer.org / @jpanzer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091106/922a1d6d/attachment.htm>


More information about the specs mailing list