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] Clarity around Ref processing behavior.


My votes:

A: 1 (same policy for auth refs and svc refs)
B: 4 (unlimited breadth, unlimited depth)
C: 3 (depth limit attribute)

Rationale: Andy's rationale.

The only part I still don't agree in Andy's argument is:
>
> I do not find the argument that traversing a tree is ‘complex’ or 
> ‘nondeterministic’ to be true… this is a simple recursion that is the 
> bread and butter of most of our virtual world (look at windows 
> explorer, mac finder, etc…)
>
Tree traversal algorithm is dead simple. However, the experience on the 
user's part is generally not that pleasant because if you're traversing 
a deep tree like the filesystem, it is slow as hell! If I started a 
search down my C:\ accidentally, I will hit stop immediately. Not to 
mention the fact that if you are searching for something, you'd get 
multiple results. In the case of service selection, while you could 
still get multiple services in the output, the semantics is more like 
"finding" which is to locate a particular service.

The non-deterministic part is due to the fact that one could assign the 
same priority to Refs, which makes the order of traversal random. I 
would argue that we should follow the document order if priority 
attributes are absent or the same.

I would also add that this is error-prone because users are not likely 
to know why a service that is supposed to be selected from a certain 
authority somehow got selected from a different authority in the Refs 
tree. It could be due to a new Ref of a higher priority got added / 
removed somewhere along the chain, or a default service got added / removed.

HOWEVER, I'm willing to empower the user with powerful recursions if we 
think that the above issues can be controlled/contained or are not 
really valid concerns. And if they're not valid concerns, my vote would 
be for A1, B4, C1 (which I guess was Steve's original argument) and is 
#3 in Les's poll.

FWIW, I'd hate to see a new attribute on Ref but it seems to balance the 
non-deterministic / error-prone concerns with Andy's use case to 
aggregate services.

We also need to decide on the resolver behavior when an error is 
encountered. I consider it bad design to bury the error and try the next 
Ref. Therefore, we should probably specify that besides certain error 
codes such as "241 SEP_NOT_FOUND", everything else should bubble up back 
to the user.

=wil


Drummond Reed wrote:
> 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
>>     
>
>   



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