[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRD for host-meta
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]