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: Proposed CID verification rules for ED04 (was: Dereferencing rules are required for interop)


All,

I renamed this thread because dereferencing rules are just one of several
topics related to CanonicalID verification and synonym processing that need
to close on quickly in order to produce ED04. This message summarizes the
steps to prepare for our TC telecon tomorrow on which this will be a main
topic.

First, I have placed an updated CanonicalID verification proposal for ED04
on the wiki:

	http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification

This replaces the previous version of the page (always available in the page
history) that was woefully out of date with the current thinking. Please do
read through it and post any feedback to the list so we can advance
discussion as far as possible before tomorrow's call.

This page reflects the following analysis of the deferencing rules issue:

First, Steve is correct that when he and I first discussed this topic (the
interaction of CanonicalID verification and XRD selection), I thought it
made sense, when a resolution request has cid=true, for the resolver to
always attempt to find a verifiable CanonicalID.

However in reading Les's analysis below, I find myself agreeing with him,
i.e., that it will be much simpler for CanonicalID verification to be
completely independent from and orthogonal to reference processing.

One factor that has changed the equation in my view is restricting
CanonicalID cardinality to zero-or-one, which we did starting with ED03 and
which I strongly support. If CanonicalID verification is singular and
strictly hierarchical, i.e., each subsegment of a verifiable CanonicalID
must also be a valid LocalID for that leg of the resolution chain (which is
what I think we've all agreed), it is now extremely efficient for a resolver
to verify the CanonicalID element (if any) for each XRD in a resolution
chain.

Therefore I propose (in the updated page at
http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification) that if
cid=true, a resolver MUST always perform CanonicalID verification on the
CanonicalID in each XRD in the resolution chain, and this rule remains
constant whether refs=true or not and whether sep=true or not. This means
cid=true will never affect the final XRD returned by resolution, only the
status code returned in that XRD.

Note that I also propose one new status code (103 CID_NOT_PRESENT) to be
returned in an XRD when a resolution request has cid=true but an XRD in the
resolution chain does not assert a CanonicalID. It doesn't make sense to me
to return either 100 SUCCESS or 102 CID_NOT_VERIFIED if no CanonicalID is
even present in the XRD.

What do others think?

=Drummond 



> -----Original Message-----
> From: Chasen, Les [mailto:les.chasen@neustar.biz]
> Sent: Wednesday, August 22, 2007 10:45 AM
> To: Steven Churchill; Tan, William; Markus Sabadello
> Cc: xri@lists.oasis-open.org
> 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]