RE: [xri] Nested XRDS documents in Ref processing (was RE: [xri] Special XRI TC Telecon 1PM PT Thursday 2007-10-01)

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

Steve,

Ahhh, my fault, I didn't understand your original message. I thought you
were saying that the CID for *foo had to be a child of @ootao*steve.

I just talked with John, and since you and Les both feel strongly that the
context of the XRDs representing the rest of the authority resolution chain
should be preserved, I believe the rest of the TC will support that. It also
makes the ref= attribute on the nested XRDS simpler as it will be an exact
match of the value of the Ref attribute that produced the nested XRDS.

John also suggested what I think is the best solution to tracking a Redirect
in the XRDS document, which is to nest it as an XRDS document just like with
a Ref, except use a redirect= attribute on the XRDS container. This is one
step more complex that what Markus would prefer like (in his email this
morning, he'd prefer a Redirect to have direct substitution semantics, so
you don't see the original XRDS at all). However it would provide the "audit
trail" that Wil and Les felt strongly about, so I expect we can reach
consensus on that.

It also harmonizes how both Redirects and Refs are represented inside an
XRDS document.

I will proceed immediately to write all this up in revision #4 of the
proposal page at http://wiki.oasis-open.org/xri/XriCd02/RefProcessing. I'll
send email as soon as it's updated.

=Drummond 

> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Tuesday, October 02, 2007 3:57 AM
> To: xri@lists.oasis-open.org
> Cc: 'John Bradley'; 'Kermit Snelson'; andy.dale@ootao.com
> Subject: RE: [xri] Nested XRDS documents in Ref processing (was RE: [xri]
> Special XRI TC Telecon 1PM PT Thursday 2007-10-01)
> 
> 
> There was never any question that the final XRD in the nested XRDS is the
> parent of *foo. It has been this way for at least 18 months.
> 
> > XRDS: {
> >     XRD:        *ootao
> >     XRDS: {
> >         XRD:    *steve
> >         XRD:    *steve's Ref for $res*auth
> >     }
> >     XRD: 	      *foo
> > }
> 
> By moving the XRD for *foo into the nested XRDS you've done nothing more
> that erase contextual information (ie. the ref traversal structure) from
> the
> audit trail.
> 
> ~ Steve
> 
> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Tuesday, October 02, 2007 12:25 AM
> To: 'Steven Churchill'; xri@lists.oasis-open.org
> Cc: 'John Bradley'; 'Kermit Snelson'; andy.dale@ootao.com
> Subject: [xri] Nested XRDS documents in Ref processing (was RE: [xri]
> Special XRI TC Telecon 1PM PT Thursday 2007-10-01)
> 
> Steve, we discussed the question you asked again on the special telecon
> today. Our conclusion is that the example on
> http://wiki.oasis-open.org/xri/XriCd02/RefProcessing is correct, even
> though
> as you point out it is a change from what had been in earlier drafts.
> (Note
> also that two errors in the example were corrected during today's call --
> the Ref element was in the wrong place and the value of the ref= attribute
> was incorrect.)
> 
> The reason for enforcing that all XRDs are in the nested XRDS document is
> to
> preserve the proper chain of authority for CanonicalID verification. To
> use
> the example at
> http://wiki.oasis-open.org/xri/XriCd02/RefProcessing#head-
> 9d7bccc6f42688cc94
> 6ac8412539d751872e8d50 for reference (since it has the full detail), it
> shows that when resolving @a*b*c, when @a*b has a Ref to @x*y, from that
> point on, the CanonicalID verification chain is rooted in @x. Only @x can
> assert a CanonicalID for @x*y, and only @x*y can assert a CanonicalID for
> @x*y*c.
> 
> So in essence, when a Ref appears during the authority resolution phase,
> it
> means that a resolver MUST substitute a new XRI for the old XRI being
> resolved, and thus that the only verifiable CanonicalID that can be
> returned
> is for the new XRI. (This has been written up in more detailed in the
> revisions to the proposal at
> http://wiki.oasis-open.org/xri/XriCd02/RefProcessing that I made tonight).
> In the example above, that means @x*y*c is substituted for @a*b*c, and
> @x*y*c is the CanonicalID that the resolver can verify because it
> traverses
> the entire chain with a Ref, and thereby can confirm that each authority
> is
> authoritative for its child.
> 
> Note that @x*y*c could still assert @a*b*c as its CanonicalEquivID, and
> the
> resolver could verify this in its final step by looking for an EquivID
> element with the value @a*b*c.
> 
> Hope this helps,
> 
> =Drummond
> 
> > -----Original Message-----
> > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > Sent: Monday, October 01, 2007 12:59 PM
> > To: xri@lists.oasis-open.org
> > Cc: 'John Bradley'; 'Kermit Snelson'; andy.dale@ootao.com
> > Subject: RE: [xri] Special XRI TC Telecon 1PM PT Thursday 2007-10-01
> >
> >
> > I'm not clear about the "Nested XRDS Documents" wording at the
> > RefProcessing
> > page on the wiki.
> >
> > For @ootao*steve*foo, say *steve's $res*auth service has a Ref.
> >
> > XRDS: {
> >     XRD:        *ootao
> >     XRDS: {
> >         XRD:    *steve
> >         XRD:    *steve's Ref for $res*auth
> >     }
> >     XRD: 	    *foo
> > }
> >
> > In this case then another XRD would follow the nested XRDS, no?
> >
> > ~ Steve
> >
> >
> >
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Monday, October 01, 2007 12:06 AM
> > To: xri@lists.oasis-open.org
> > Cc: 'John Bradley'; 'Kermit Snelson'; andy.dale@ootao.com
> > Subject: [xri] Special XRI TC Telecon 1PM PT Thursday 2007-10-01
> >
> > Following is the agenda for a SPECIAL unofficial telecon of the XRI TC
> at:
> >
> > Date:  Monday, 01 October 2007 USA
> > Time:  1:00PM - 2:30PM Pacific Time
> >
> > Event Description:
> > Special telecon to discuss XRI resolution reference processing as
> > described
> > below.
> >
> > TO ACCESS THE AUDIO CONFERENCE:
> >     Dial In Number: 571-434-5750
> >     Conference ID: 5474
> >
> >
> > AGENDA
> >
> > 1) REVISED REF PROCESSING PROPOSAL
> > At last Thursday's XRI/XDI TC telecon we had extensive discussion of Ref
> > processing. We were not able to close on the telecon, however subsequent
> > discussion has produced an updated proposal posted tonight (Sunday) at:
> >
> > 	http://wiki.oasis-open.org/xri/XriCd02/RefProcessing
> >
> > The three key changes in this new proposal (vs. the one discussed on the
> > TC
> > call last Thursday) are:
> >
> > a) Addition of a Redirect element to take over the function of what was
> > previously a "service ref" (which Steve points out operated differently
> > than
> > an "authority ref").
> >
> > b) Keeping the refs= parameter as a boolean (as it was in ED05).
> >
> > c) Elimination of the proposed "find all" option -- too complex to be
> > introduced at this stage (and can be performed by a separate utility if
> > needed).
> >
> > PLEASE REVIEW THIS UPDATED PROPOSAL BEFORE THE CALL IF YOU HAVE TIME --
> it
> > is of paramount importance that we close on ref processing so we can
> > complete ED06 and proceed to a Committee Draft vote.