The State of the Hammer Discovery Stack

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


The correct link for the notes from the discussion is:

http://docs.google.com/View?id=ddj68sqv_9f5qp7zf9

On Fri, Nov 6, 2009 at 11:41 AM, John Panzer <jpanzer at google.com> wrote:

> 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
>
>


-- 
--
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/e6ea1da1/attachment.htm>


More information about the specs mailing list