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


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