RE: [xri] Clarity around Ref processing behavior.

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

A:1
B:3
C:1

I believe that breadth only with no attributes is the simplest to
understand, implement and debug for authority owners.  Breadth is a must
because one may have multiple references to differing authorities for
different service reasons.  This is especially true given that the
synonym semantics have been removed from REF.  

Also if you do not follow a breadth model then the cardinality of REF
becomes 0 or 1 except in the case of a network failure.  This type of
redundancy was never the intention with REFs.

I believe the depth model is where the complexity comes in because as
soon as you start selecting a service from an XRD with more degrees of
separation than that very first level problems begin.  Problems that
becomes hard to track down.

Allowing Breadth and depth is where we get into this so called
backtracking issue which everyone agreed was problematic and complex.

As for new attributes ... please no we have a complex enough spec
without adding additional attributes.  


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

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Monday, September 24, 2007 2:25 AM
> To: 'Victor Grey'; 'Steven Churchill'
> Cc: xri@lists.oasis-open.org; andy.dale@ootao.com; 'Kermit Snelson'
> Subject: RE: [xri] Clarity around Ref processing behavior.
> 
> I just caught up on this thread after arriving this afternoon at
Digital
> ID
> World.
> 
> I agree with Victor that I support what Andy is saying from a
> philosophical
> and logical point of view. Distributed/aggregated identity is one of
the
> fundamental principles that XRI was designed to support.
> 
> So the first point I'd like to make is a metapoint: I believe almost
all
> the
> suggested approaches discussed on this thread about Ref processing can
> achieve this, i.e., support Andy's use cases. The difference is that
they
> all do it by applying different ref processing policies that resolvers
> must
> follow, and therefore that XRDS authors must follow when designing
what
> Refs
> (authority or service) to put in what XRDS documents to achieve their
> desired results.
> 
> What we as a TC must decide is which ref processing policies to set in
> stone
> in XRI Resolution 2.0 Committee Draft 02 so that resolver implementers
and
> XRDS authors know what to do.
> 
> Les summarized the key policy choices in his email earlier today, but
he
> didn't include the option of using service refs, which is what Victor
> explains in his email below.
> 
> So here's an attempt to enumerate the full spectrum of potential
policy
> choices for Ref processing, including both and service refs.
> 
> First, definitions of the six key terms:
> 
> * Authority ref: using the XRD:XRD/xrd:Ref element (section 12.1 of
ED05).
> * Service ref: using the XRD:XRD/xrd:Service/xrd:Ref element (section
12.2
> of ED05).
> * Breadth: how many Refs may be successfully resolved (not including
> errors)
> from the SAME XRDS.
> * Depth: how many Refs may be resolved in a chain of multiple Refs
where
> each Ref successfully resolves to a new XRDS document.
> * Breadth Limit Attribute: an attribute on the Ref element that would
> limit
> the Breadth, i.e., how many Refs could be resolved from the same
source
> XRDS.
> * Depth Limit Attribute: an attribute on the Ref element that would
limit
> the Depth, i.e., how many Refs could be resolved in a Ref chain.
> 
> Now, here's how I'd classify the policy choices we have. They fall
into
> three dimensions:
> 
> DIMENSION A:
> 1) Same policy applies to both authority refs and service refs.
> 2) Different policies apply to authority refs vs. service refs.
> 
> DIMENSION B:
> 1) Limited breadth (zero-or-one); limited depth (zero-or-one).
> 2) Limited breadth (zero-or-one); unlimited depth (zero-or-more).
> 3) Unlimited breadth (zero-or-more); limited depth (zero-or-one).
> 4) Unlimited breadth (zero-or-more); unlimited depth (zero-or-more).
> 
> DIMENSION C:
> 1) No breadth or depth limit attributes.
> 2) Breadth limit attribute; no depth limit attribute.
> 3) No breadth limit attribute; depth limit attribute.
> 4) Both breadth and depth limit attributes.
> 
> My suggestion is that we start by everyone just voting for their
choice
> along each dimension, and adding your rationale if you wish. (Andy,
Kermit
> -
> just send your votes/rationale to one of us and we'll forward it to
the
> list.)
> 
> I'll start. My votes are:
> 
> A: 1 (same policies for authority refs and service refs)
> B: 2 (limited breadth, unlimited depth)
> C: 3 (depth limit attribute only)
> 
> My rationales:
> 
> A) I believe we'd be unwise to apply different policies to authority
refs
> and service refs. The logical model will be much easier to understand
and
> implement if the same resolution policies apply at both levels.
> 
> B)
> 
> 1) It doesn't make any sense to limit both breadth and depth. I think
you
> either need to limit one, or the other, but not both.
> 
> 2) By limiting breadth but not depth for both authority refs and
service
> refs, you can support all delegation models. I don't believe the
opposite
> is
> true. See below for deeper explanation.
> 
> 3) By limiting depth but not breadth, you can't support two-level
> delegation
> models.
> 
> 4) By limiting neither breadth nor depth, resolution complexity and
> potential latency becomes too high. (In earlier conversations this
would
> have been called the "full backtracking model".)
> 
> C) Since I voted for limited breadth, unlimited depth, I think it
makes
> sense to have a depth limit attribute, so an XFDS author can control
how
> deep the delegation chain is (if they care). If this attribute is
absent
> the
> default would be no limit.
> 
> *******
> 
> WHY LIMITED BREADTH AND UNLIMITED DEPTH?
> 
> My main reason for suggesting the limited breadth/unlimited depth
model is
> the explanation Victor gives below for the use of service refs. In a
> nutshell, even if an authority can only delegate an authority ref to
one
> other authority (at a time; depth can be unlimited), that doesn't mean
the
> authority can't delegate multiple separate service refs to multiple
> authorities -- one service per authority. As Victor explains, this
means
> Andy's use cases can not only be implemented but actually with greater
> efficiency than the resolver having to traverse multiple authority
refs to
> find the service it is looking for.
> 
> So limited breadth and unlimited depth favors a "rifle shot" model
where,
> if
> you want to delegate a specific service, you use a service ref to
delegate
> directly to the authority responsible for that service. However, at
the
> saem
> time it doesn't prevent a "shotgun" model, where if you want to
delegate
> your entire XRDS, you can do still do that, by choosing one authority
to
> delegate the whole thing to.
> 
> ********
> 
> So there's a first set of votes cast. Anyone on the list (or those
cc'd),
> please do cast your vote as soon as you can. I'd love to see Les
proved
> correct that we can settle this via email. If not, let's agree to
close it
> no later than this Thursday's telecon (9/27), so please do set aside
> 10-to-noon Pacific Time on that day.
> 
> Thanks,
> 
> =Drummond
> 
> 
> > -----Original Message-----
> > From: Victor Grey [mailto:victor@idcommons.org]
> > Sent: Sunday, September 23, 2007 4:18 PM
> > To: Steven Churchill
> > Cc: xri@lists.oasis-open.org; andy.dale@ootao.com; 'Kermit Snelson'
> > Subject: Re: [xri] Clarity around Ref processing behavior.
> >
> > Steven Churchill wrote:
> > > Les has repeatedly called for other people's view on this issue,
> > > and Andy
> > > has prepared an excellent article that I have attached. (Andy is
not
> > > registered to send to the mailing list.)
> >
> > I find Andy's argument compelling from a philosophical point of
view.
> >
> > But what worries me is that in his example, a proxy resolver would
> > have to make calls to at least 8 different network endpoints to
> > ascertain that a SEP was not available, or find all the SEPs of a
> > particular type:
> > 1. resolve andy at =
> > 2. resolve ooTao at @
> > 3. resolve andy at @ooTao
> > 4. resolve mfkd at =
> > 5. resolve yahoo at @
> > 6. resolve mfkd at @yahoo
> > 7. resolve wow at @
> > 8. resolve mfkd at @wow
> >
> > Given indeterminate network latency, the proxy resolver could be
> > spinning its wheels for an unacceptable length of time.
> >
> > Pardon me if I'm just not getting it, but wouldn't Refs at the
> > Service level provide the same capabilities that Andy's use case
> > requires, but in a more efficient way? So that if =andy wants to
> > assert a freetime svc, it would include a Service element with that
> > type, but no URI, only a Ref to @ooTao*andy.
> >
> > It does make provisioning more complex, because the service would
> > have to be provisioned both at @ooTao*andy and at =andy.
> > But provisioning doesn't need to happen in real time, resolution
> > does. Besides, that could be a feature, providing even more
> > flexibility about what can be discovered from where.
> >
> > =vg