RE: Proposed CID verification rules for ED04 (was: Dereferencing rules are required for interop)

["Chasen, Les" <les.chasen@neustar.biz>]

* I am good with the adding of a new status code for 103 CID_NOT_PRESENT

* The wiki contains a section for CID verification for HTTP URIs.  I do
not think this belongs in the XRI resolution spec ... it is out of
scope.

* The reference processing section confuses me ... I do not think that
the cid parameter should control how the resolver traverses through an
XRDS tree.  A REF will only be followed if it is needed to perform
authority resolution or service selection.  In all other circumstances a
REF will not be resolved.   This may just be terminology because I think
you said you agreed with me below.

* Not a big deal but in reading this I think instead of using 102
CID_NOT_VERIFIED  it would be more descriptive to have the label
CID_VERIFICATION_FAILED.  This instinctively tells me that verification
was done but it failed.  The other leaves it a little vague.

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

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Wednesday, August 22, 2007 4:40 PM
> To: Chasen, Les; 'Steven Churchill'; Tan, William; 'Markus Sabadello'
> Cc: xri@lists.oasis-open.org
> 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >