Re: [xri] XRD trusted discovery workflow

["David Fuelling" <david.fuelling@cordance.net>]

On Thu, Dec 11, 2008 at 6:43 PM, Breno de Medeiros <breno@google.com> wrote:

If the <Service> tag is included, and the document specifies how to
change URI to URL when performing XRD discovery, that should work and
I can see the benefits for the larger picture. Leaving unspecified how
to use URI/ResourceMaps to resolve XRDs, or deferring to a (possible)
future spec is not acceptable because it does not provide a complete
picture of XRD resolution. I understand you mean the former.

Any <Service> tag arguably needs a <type> inside of it, so context can be given to what the "service" in question actually is.  It seems like you'll need to define a Service "Type" that outlines what exactly to do with a URIMap inside of said service.  That's why I think some "other spec" (could even be XRD spec for that matter) needs to define such a service type, and exactly what should be done with that Service-Type/URIMap combination. 

I wonder if it would be helpful to distinguish between two scenarios:

1. How do we bootstrap or "do discovery" on a particular URI.
2. Once we've done discovery on a URI, we should get back an XRD that allows us to "do stuff" with the initial URI (i.e., consult various services inside the XRD)
   

I think the "bootstrapping" part of the wiki document is addressing #1 above, and in that case, selecting only the mailto: URI for inclusion, but deferring to other specs for other URI's (like xri://, ftp://, urn://, etc) seems like reinventing the wheel, as well as very restrictive.  I'm not sure XRD will go anywhere if we mandate a *brand new*, one size fits all URI dereferencing protocol -- many URIs already have ways to dereference them.