RE: [xri] RE: XRDS ref

["Gabe Wachob" <gabe.wachob@amsoft.net>]

This is consistent with my understanding - the ref attribute is merely
informational/debugging/consistency.. Cool!

	-Gabe

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Friday, September 29, 2006 11:25 AM
> To: 'Gabe Wachob'; 'Tan, William'; 'Steve Churchill'; 'Chasen, Les'
> Cc: xri@lists.oasis-open.org
> Subject: [xri] RE: XRDS ref
> 
> Wil & Gabe,
> 
> Here's my answer to Wil's original question: the ref attribute in the
> outermost XRDS document: a) MUST be absolute, and b) is ALWAYS set by the
> resolver (either a local resolver or a proxy) and never by the server. I
> think of it as the resolver just "echoing back" the XRI it was asked to
> resolve.
> 
> If a local resolver "hands off" resolution of a ref to another resolver,
> the
> calling resolve should simple check that the value of the ref element on
> the
> returned XRDS document is identical to what it asked for.
> 
> I agree that the ref attribute on the outermost XRDS document is primarily
> a
> convenience -- it makes the document self-describing. However the role the
> ref attribute plays in nested XRDS documents (those used to follow Refs)
> is
> critical because it's the only place where the identifier for the root
> authority MUST appear. In other words, because the first XRD in the nested
> XRDS is relative to the root authority for the Ref XRI, it's <Query> is
> going to contain a relative XRI subsegement like *foo. The only *required*
> data that tells you that this is @*foo and not =*foo is the ref attribute
> on
> the XRDS wrapper. (The ProviderID element in the first XRD identifies the
> provider, but this element is not required, and furthermore it may be a
> different identifier than the one used to identify the root authority.)
> 
> Wil, let us know if you have any other questions about this. I've made a
> note in the WD11 Improvements section
> (http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11#head-
> 7d258f97dc15
> 79a6f262bde09b98405ad86f69ec) to reflect what we've discussed here.
> 
> =Drummond
> 
> 
> -----Original Message-----
> From: Gabe Wachob [mailto:gabe.wachob@amsoft.net]
> Sent: Monday, September 25, 2006 10:08 AM
> To: 'Tan, William'; 'Drummond Reed'; 'Steve Churchill'; 'Chasen, Les'
> Subject: RE: XRDS ref
> 
> I personally don't know what the point of the ref attribute is outside of
> the recursive resolution (ie the XRDS which contains the results of
> following a ref). And even then its just a sanity check.
> 
> I have been surprised to see the ref on out outer enclosing XRDS
> document...
> 
> 	Gabe
> 
> > -----Original Message-----
> > From: Tan, William [mailto:William.Tan@neustar.biz]
> > Sent: Monday, September 25, 2006 5:37 AM
> > To: Drummond Reed; Gabe Wachob; Steve Churchill; Chasen, Les
> > Subject: XRDS ref
> >
> > Hi guys,
> >
> > It just occurred to me while writing the Perl resolver that there aren't
> > any clear rules in WD10 about what a resolver should do when it sees the
> > XRDS/@ref attribute.
> >
> > If I understand correctly, the XRDS/@ref attribute is meant to contain
> an
> > absolute XRI (though nothing in the spec says that it can't be a
> relative
> > reference). An XRDS document returned by an authority resolution server
> > may have the ref attribute set to a different absolute XRI than what was
> > intended to resolve because the authority resolution server does not
> know
> > who is pointing to it.
> >
> > Should the resolver bother to sanity-check that value, or correlate that
> > value with the contained XRDs?
> >
> > I'm thinking the resolver shouldn't bother inspecting that value and
> only
> > check the child XRD's.
> >
> > I'm hoping someone could give a simple answer, otherwise we can move it
> to
> > the wd11 open issues wiki.
> >
> >
> > =wil (http://xri.net/=wil)
> >
> >
> > p.s. I've checked in an early version of perl library that has a simple
> > parser and resolver that uses xri.net. It took a few module namespace
> re-
> > organization to get to the current naming conventions that I'm quite
> happy
> > with. A full-blown direct resolver is being baked with whatever spare
> time
> > I have.
> >
> > http://openxri.cvs.sourceforge.net/openxri/perl-xri/
> >
>