RE: [xri] Clarity around Ref processing behavior.

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

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Saturday, September 22, 2007 3:55 PM
> To: Chasen, Les; 'Steven Churchill'; xri@lists.oasis-open.org
> Cc: andy.dale@ootao.com
> Subject: RE: [xri] Clarity around Ref processing behavior.
> 
> Les, Steve, Wil:
> 
> I was on a plane yesterday and only just this morning uploaded the
minutes
> from Thursday's meeting that explained why: a) we didn't want
> backtracking,
> and b) directional Refs to any depth were fine.
> 
> I've quickly read this thread and have to go to my son's soccer game,
> however I believe the decisions we made on Thursday's call are the
right
> ones. Again, these decisions were:
> 
> 1) Once a resolver has followed a Ref and successfully obtained a new
XRDS
> document, it is in a new XRDS "path" and MUST NOT backtrack from that
> path,
> but can only move forward on that path.

[Chasen, Les] 
[Chasen, Les] I think this is wrong and essentially makes the
cardinality of the ref 0 or 1.

> 
> 2) A resolver continues down that XRDS path, and if necessary
continues to
> follow additional Refs on that path, until it: a) satisfies the query
it
> was
> given, b) errors out, or c) hits its own internal maximum number of
refs.
> 
> I read Steve's use case and while I agree that in theory a resolver
COULD
> backtrack to try additional Refs, as Wil says, that produces much more
> complex behavior. Instead, Steve's use case is beautifully handled by
the
> new Service Ref feature, because that way Steve can direct each
service
> type
> to another specific authority.
[Chasen, Les] Based on my conversation with Wil after the Thursday call
I don't think what you incorrectly call backtracking is complex.  Steve
is correct in his discussion on this topic.  

> 
> This is, IMHO, much finer-grained than using a full XRD-level Ref,
which
> is
> a much coarser approach.
> 
> Regarding Les's concern about following a Ref to an XRDS that has
another
> Ref, since a Ref is fundamentally delegation of service endpoint
authority
> to another entity, I think it is exactly what should happen. Does that
> mean
> authorities should be extremely careful about delegation of XRD-level
> Refs?
> Yes.
[Chasen, Les] With this model it is impossible to be *careful*.  I
strongly feel that ref's should be handled in a breadth mode rather than
this proposed depth model.   It is much more important to ensure that a
ref is only between the two authorities in which it was declared.  Some
very bad and unexpected things will happen if you go to an XRD with
greater degrees of separation. 


I would like to here what others think.