RE: [xri] FW: Dereferencing rules are required for interop

["Steven Churchill" <steven.churchill@xdi.org>]

Wil,

I'm not following the first part of your argument. If you're interested in
my thoughts about this, please clarify, or give me a call or something.

You said:
> Specifying that the CID query parameter affects the decision of whether 
> to follow a Ref or not kind of imposes equivalence semantics onto Refs, 
> which we are trying to separate.

To visualize what's going on here, take a look at figure 5 in
<http://www.oasis-open.org/committees/download.php/22395/xri-polyarchy-artic
le.pdf>. 

The issue is whether or not the Resolver returns (1) an XRD describing the
red node or (2) an XRD describing the black node in lower right corner. 

Say that the client has addressed the red node using the identifier
@xdi*andy.dale and specified resolver parameter sep=false. Drummond proposed
last fall (and I think rightly so) that the existence of the CID should
interplay with the cid=true behavior. The table captures this interplay. For
example, if the red node's XRD does not contain a CID, then cid=false will
cause the red node's metadata to be returned whereas cid=true will cause the
black node's.

Again, I will leave it to Drummond to defend that proposal. (If he doesn't,
then I will chime in later on his behalf--if I can remember all the
details.)

~ Steve
 



-----Original Message-----
From: Tan, William [mailto:William.Tan@neustar.biz] 
Sent: Tuesday, August 21, 2007 2:25 PM
To: Markus Sabadello
Cc: Steven Churchill; xri@lists.oasis-open.org
Subject: Re: [xri] FW: Dereferencing rules are required for interop

I think I agree with Markus, and maybe this is where my opinion about 
CID verification differs from Steve's.

With the original motivating use case of CID verification in mind, which 
is to prevent one authority from spoofing another authority's CID from 
another part of the tree. /Ideally, /clients using a /proxy resolver/ 
would just request for a filtered XRD using 
_xrd_r=application/xrd+xml%3Bsep=true%3Brefs=true%3Bcid=true
And if clients has only this choice (of using a proxy resolver and can 
only make a single call), the side effect is that you have the take the 
CID from the final XRD in the entire resolved XRDS. It also has the 
interesting effect of allowing a model whereby a client will use as 
primary key the CID of =steven.churchill when @ootao*steve contains a 
Ref to =steven.churchill's CID. This may not suit the model for all 
client applications that consume XRIs, but a certain class of 
application may want to specify this particular behavior. IMO specifying 
this is out of the scope of the resolution specs.

Specifying that the CID query parameter affects the decision of whether 
to follow a Ref or not kind of imposes equivalence semantics onto Refs, 
which we are trying to separate.

=wil

Markus Sabadello wrote:
> Hey Steve,
>
> Are you sure about lines 3 and 5 in the table? Should a Ref be 
> dereferenced just because there is no CID in the XRD? Even if there is 
> a matching SEP?
>
> My understanding of CID verification was that it simply verifies a CID 
> (if there is one), not influence the resolution process, but maybe I 
> was wrong. Maybe its purpose is more like "give your best to find me a 
> verified CID".
>
> Markus
>
> On 8/21/07, *Steven Churchill* <steven.churchill@xdi.org 
> <mailto:steven.churchill@xdi.org>> wrote:
>
>     Woops. I sent this to the list last week but it bounced due to my
>     not using my xdi.org <http://xdi.org> account.
>
>      
>
>
------------------------------------------------------------------------
>
>     *From:* Steve Churchill [mailto:steven.churchill@ootao.com
>     <mailto:steven.churchill@ootao.com>]
>     *Sent:* Friday, August 17, 2007 12:10 PM
>     *To:* 'xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>'
>     *Subject:* Dereferencing rules are required for interop
>
>      
>
>     Drummond,
>
>      
>
>     I've sent this document to you at least twice already. It does not
>     appear in the spec.
>
>      
>
>     If you do not feel that this specificity is absolutely required
>     for interoperability, then please explain why.
>
>      
>
>     ~ Steve
>
>      
>
>
>
>
>