OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] XRD for host-meta


Ah, I didn't know that Subject was planned to be required (in XRDS, I don't
think any element was required). So we need to discuss that option vs. these
others.

=Drummond 

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Tuesday, June 09, 2009 10:42 PM
> To: XRI TC
> Subject: Re: [xri] XRD for host-meta
> 
> 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
> >
> >
> 
> 
> ---------------------------------------------------------------------
> 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]