The State of the Hammer Discovery Stack

xri-comment message

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

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@googlegroups.com) and we'll play traffic cop.