RE: [xri] XRD for host-meta

["Drummond Reed" <drummond.reed@cordance.net>]

Will,

It's a very good question. /host-meta never needed the concept of a
"Subject" because it inherently described the authority that hosts it. I
believe the same principle applies to an XRD that serves this same role. 

I call this a "root XRD", and by definition all root XRDs have the same
subject, which conceptually is "self" or "root". 

This could be indicated simply by not including an <XRD:Subject> element at
all in the XRD, and specifying clearly that an XRD without a <XRD:Subject>
element describes the authority that hosts it.

Alternately we could specify a well-known URI to use as the value of the
<XRD:Subject> element for all root XRDs. There is fact an XRI specifically
for this purpose:

	Unbound XRI:		$
	http bound URI:		http://xri.net/$

We might also be able to use the rel "self" for this purpose, as defined in
http://tools.ietf.org/html/draft-nottingham-http-link-header-05.

Anyway, those are my initial thoughts. What were the other issues you ran
into adapting XRD to serve as a host-meta document?

=Drummond 


> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Tuesday, June 09, 2009 10:02 PM
> To: XRI TC
> Subject: [xri] XRD for host-meta
> 
> One of the things talked about at IIW was how there is movement toward
> establishing the "/.well-known/" directory to serve as a container for
> well-known files of various types.  This makes the /host-meta file
> somewhat obsolete for many use cases, since anyone can simply register
> a filename within the .well-known directory directly.  The main group
> left with a real use for host-meta then was the XRD community, as host-
> meta is still the place where you define the Link Pattern used to get
> the XRD document for a given URI.  Since we were the only ones who
> still cared, we generally agreed that it made sense to drop the
> existing plain-text format for host-meta, and instead use XRD.  Two
> major reasons for this:
>   - consumers were going to have to parse XRD anyway, so why use two
> different formats?
>   - host-meta needs to be signed.  XRDs are going to be signable also
> so again, why use two different formats?
> 
> So with that in mind....
> 
> I've recently been going through a number of the XRD use-cases, and I
> can't actually figure out how to use XRD for a host-meta document.
> One particular piece of the puzzle doesn't seem to fit -- what is the
> <Subject> ?  The current host-meta draft states:
> 
> > Note that the metadata provided by a host-meta resource is
> > explicitly scoped to apply to the entire authority (in the URI
> > [RFC3986] sense) associated with it
> 
> host-meta is about an authority, but <Subject> is a URI.  This makes
> sense, because XRD is intended to describe a resource.  Authorities
> are not resources.  You could fudge it by converting the authority
> "example.com" into "http://example.com/";, but now the XRD is just
> wrong.  It's saying that it is describing the specific resource
> "http://example.com/
> ", when it's really intending to describe the entire authority.
> 
> How big of a problem is this?
> 
> I've actually come across a number of potential wrinkles, but this one
> was fairly discrete and easy to explain first.
> 
> -will
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php