Re: [xri] XRD for host-meta

[Will Norris <will@willnorris.com>]

yeah... I had thought about those, but forgot to mention them (a well- 
known Subject value, or a specific Type value).  Right now <Subject>  
is required, so we'd have to change the schema if we wanted to allow  
for its absence.

Other problems were not in the site-wide XRD, but rather in doing site- 
wide delegation like Google is looking into.  I haven't quite worked  
through it all just yet, but hope to do that tomorrow.

-will


On Jun 9, 2009, at 10:34 PM, Drummond Reed wrote:

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