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] FW: Dereferencing rules are required for interop


It is my recollection that if sep=true and cid=true that once we find
the requested SEP the following of REFs ceases as we are done with
service selection.   If the XRD in which we found the SEP does not have
a CID then CID validation fails and a return code of CID_NOT_VERIFIED
(102) is returned along with the XRD in a format that depends on the
_XRD_R parameter.  The service selection rules in section 10 seem to
confirm my recollection.  

So, I agree with Wil and Markus the table is incorrect on that line.
CID validation does not instruct the resolver to dereference REFs.
Service selection and authority resolution will cause a resolver to
follow REFs.  CID validation simply says whether the resulting XRDS(es)
should be validated based on CID validation rules.  

contact: =les
sip: =les/(+phone)
chat: =les/skype/chat
 
 

> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Tuesday, August 21, 2007 7:31 PM
> To: Tan, William; 'Markus Sabadello'
> Cc: xri@lists.oasis-open.org
> 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: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
> >
> >
> >
> >
> >
> >
> >


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