[Just a metanote that while I understand the arguments here and I remember
the discussions about this with Steve, it's been long enough that I need
time to go back and reconstruct them. It's too close to bed to do that
tonight. I'll try to follow through first thing in the morning. =Drummond]
> -----Original Message-----
> From: Steven Churchill [mailto:]
> Sent: Tuesday, August 21, 2007 4:31 PM
> To: 'Tan, William'; 'Markus Sabadello'
> Cc:
> Subject: RE: [xri] FW: Dereferencing rules are required for interop
>
>
> 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:]
> Sent: Tuesday, August 21, 2007 2:25 PM
> To: Markus Sabadello
> Cc: Steven Churchill;
> 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* <
> > <mailto:>> 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:
> > <mailto:>]
> > *Sent:* Friday, August 17, 2007 12:10 PM
> > *To:* ' <mailto:>'
> > *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
> >
> >
> >
> >
> >
> >
> >
