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] New thread: Rethinking ref processing



Hmm I don't know.. Yes my inital thought was, report an error whenever a Ref is tried but no XRDS could be retrieved.

I think the problem with a special success status code would be that the user wouldn't know which Ref exactly had a problem, and we have unpredictable behavior. SEPs may get selected that would never ever get selected if all the Refs worked well.

I guess the real question is, are Refs for service aggregation, or for redundancy. My feeling says they should be for aggregation, and therefore if one of the Refs is needed and doesn't work, throw an error.

Not sure about this. I really liked what Wil said, "don't bury the error".

Markus

On 9/26/07, Chasen, Les < les.chasen@neustar.biz> wrote:

Are you suggesting that an error be reported due to a bad REF even if the SEP is found through another?  Or are you suggesting a version of a success status code that gives the user a warning that there may be a problem with one of their refs?  I say "may" because network errors could be very transient in nature.

 

 

contact: =les

voice : =les/(+phone)

chat: =les/skype/chat

pibb me  =les/+pibb

 

 

 

 


From: markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Wednesday, September 26, 2007 8:35 AM


To: Drummond Reed
Cc: Steven Churchill; xri@lists.oasis-open.org; andy.dale@ootao.com; Kermit Snelson
Subject: Re: [xri] New thread: Rethinking ref processing

 


Yes I think that is exactly how it should work. This would be the combined depth&breadth option (i.e. your B4).

I also think the resolver should report an error if any of the Refs can't be followed because of a network error.

Markus

On 9/26/07, Drummond Reed <drummond.reed@cordance.net> wrote:

Markus (et al):

 

See [=Drummond] inline – especially the question near the end.

 


From: markus.sabadello@gmail.com [mailto: markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Tuesday, September 25, 2007 1:54 PM
To: Drummond Reed
Cc: Steven Churchill; xri@lists.oasis-open.org; andy.dale@ootao.com; Kermit Snelson
Subject: Re: [xri] New thread: Rethinking ref processing

 


This is funny. I always understood service ref behavior exactly how you describe it (i.e. to work like authority refs, but only applying to specific SEP selection criteria). I wasn't even aware that as of now they don't allow XRIs and don't produce full nested XRDS.

I totally agree they should work just like authority refs and result in a nested XRDS.

 

[=Drummond] Great.



I think I also understand the CanonicalID verification problem, and I'm all for your solution of "not backing up" once you start nesting an XRDS. Using the authority resolution SEP of a different authority seems to be a tricky case, but I guess your solution makes it possible.

 

[=Drummond] Agreed.



I have two more comments:

1) If someone designs XRDS documents with Refs so that the authority resolution service endpoint of a different authority is used, then I think it would be good practice for the two identifiers to also assert synonymity using one of the synonym elements ( e.g. EquivID).
So in your example, =a and @x*y*z should be considered to be real synonyms, in addition to sharing
service endpoints.

 

[=Drummond] Agreed.



2) You say the following about backtracking:

> In my mind it boils down to one question: should "backtracking" be allowed
> or not? By backtracking, I mean that once a resolver starts down a ref
> resolution chain, if it finds it is a "dead end" (i.e., the resolver is not
> able to successfully satisfy its resolution query), should it:
>
> 1) Start "backing up" through the chain of XRDs it has resolved within this
> new XRDS resolution chain to try their refs?
>
> 2) If that fails, should it back up into the XRD that contained the
> "dead-end" and try its next ref?
>
> 3) If THAT fails, should the resolver back up still further, i.e., into the
> parent of the current XRD, to see if IT might have a ref that can be
> successfully followed?

Not sure if I fully understand this.. I can speak only for myself, but after reading the other thread, I would assume that one aspect of what we mean with "backtracking" is the following:

- You NEVER go back to the parent XRD of the current XRD. You only go back to the XRD that caused the new XRDS resolution chain. E.g. if you look for a SEP in =a*b and don't find it there, you follow its Refs (breadth or depth or both is being discussed), but you NEVER go back to =a and look for Refs there.

 

[=Drummond] Ahh, good point. So the rule would be: "You never back up beyond the XRD where Ref processing began." And it would apply at any point in the resolution chain.

Does that mean that if you queried =a*b for a SEP type x, the following behavior would be correct?

1) Resolve =a*b and look for a SEP of type x. It is not found but there are two Refs (authority ref or service ref for the type x service, it doesn't matter) – a higher priority ref to @x*y*z and a lower priority ref to @m*n.

2) Resolve @x*y*z and look for a SEP of type x. It is not found but there are two Refs, a higher priority ref to =p*q*r and a lower priority ref to =w*y.

3) Resolve =p*q*r and look for a SEP of type x. No luck.

4) Resolve =w*y and look for a SEP of type x. No luck.

5) Back up to the XRD for =a*b and select the second Ref, @m*n.

6) Resolve @m*n and look for a SEP of type x. If not found, and no Refs, return SEP_NOT_FOUND.

I think that is clean and straightforward to specify. Good call.

Anyone who disagrees, please post.

=Drummond

 

On 9/25/07, Drummond Reed < drummond.reed@cordance.net > wrote:

Steve,

You say, "I feel that this would be a gross overloading of semantics for the
service ref element." I understand that, from the perspective of how service
refs are currently defined in ED05, the proposal to treat service refs the
same way as authority refs could be interpreted as a "gross overloading of
semantics for the service ref element".

However if you stand back one step further, there's a different way to look
at it: it's a dramatic simplification of the whole concept of ref
processing. Now a ref is a ref is a ref, and will always be processed the
same way, no matter where it appears in the XRD, no matter whether its value
is an XRI or HTTP(S) URI, and no matter what resolution trust model is being
applied. In other words, a ref:

1) Always produces a nested XRDS document.

2) Always starts a new CanonicalID verification chain.

3) Always repeats the same resolution query that was applied to the parent
XRDS document that caused the ref to be traversed in the first place.

Yes, it was a novel idea when it first came up this morning as a way to
solve the CanonicalID verification issue. But now that I've had all day to
think about it, it increasingly looks like a classic example of an obvious
solution that we just never saw when we first came up with the idea of
service refs last spring.

Let me put it this way: this approach is so simple and straightforward, can
anyone think of a reason we should NOT adopt it and do away with the current
complexity we have in ED05 of needing different identifier rules, processing
rules, and XRDS inclusion rules for authority refs and service refs?

Again, to be crystal clear about this proposal, here's a summary of the key
points that would go into a revised section 12 in ED06:

1) First, we would explain that a ref (whether at the authority or service
level) is a way for an XRDS author to tell a resolver, "If you don't find
the service you need in this XRD, then start a new resolution chain with the
same query parameters using this other identifier."

2) Second, the processing rules would always the same: the ref always
results in a new nested XRDS document, starting at the point the ref is
encountered. If one ref leads to another ref, then that leads to another
level of nesting.

3) The CanonicalID verification rules remain the same because each time a
new ref is encountered, CanonicalID verification restarts at the new
community root authority.

4) The ONLY remaining difference between an authority ref (the
xrd:XRD/xrd:Ref element) and a service ref (the xrd:XRD/xrd:Service/xrd:Ref
element) is that the former is used IF THE LATTER IS NOT PRESENT.

I think this is a huge point, and one that IMHO might also solve the ref
processing policy issue that started this whole thread. So let me explain in
more detail.

The logic goes like this: first, ref processing is ALWAYS triggered by a
resolver not finding the SEP URI that it needs. For example, during the
authority resolution process, the resolver ALWAYS needs a URI within a SEP
with the xri://$res*auth*($v*2.0) type (and with the appropriate trust media
type parameter if applicable).

There are two ways a resolver could fail to find this SEP URI and thus
trigger ref processing:

1) A SEP of this type was present but didn't contain a
xrd:XRD/xrd:Service/xrd:URI element, only a xrd:XRD/xrd:Service/xrd:Ref
element.

2) A SEP of this type was absent altogether but the XRD contained an
xrd:XRD/xrd:Ref element.

Option #1 above is very fine grained. It is specific to just one service
type -- the xri://$res*auth*($v*2.0) service. This lets an XRDS author
insert an xrd:XRD/xrd:Service/xrd:Ref element to repoint the browser at the
exact XRI or HTTP(S) URI for the XRDS document the XRDS author wants to use
for this type of service.

Option #2 above is a "catch all". If the resolver finds no fine-grained
service ref at the SEP level, the resolver checks to see if there is a
catch-all ref at the XRD level. If so, the resolver interprets this as an
instruction from the XRDS author: "For any query where don't find either the
specific SEP URI you are looking for, or a specific service ref, then use
this general catchall ref."

The beauty is that these ***exact*** same ref logic/processing rules can
apply once the resolver has finished the authority resolution process and
moves into the service endpoint selection process. Not one word above needs
to change: just substitute "[requested SEP query parameters here]" for
"xri://$res*auth*($v*2.0)".

*******

My final thought in this message is whether this unified ref processing
model might also help solve our ref policy debate. Because XRDS authors
would now have very precise fine-grained control over refs -- both the level
at which they appear, and also whether they use XRIs or HTTP(S) URIs as
their value -- I believe there's less reason for the spec to impose any
limitations on their use.

In my mind it boils down to one question: should "backtracking" be allowed
or not? By backtracking, I mean that once a resolver starts down a ref
resolution chain, if it finds it is a "dead end" (i.e., the resolver is not
able to successfully satisfy its resolution query), should it:

1) Start "backing up" through the chain of XRDs it has resolved within this
new XRDS resolution chain to try their refs?

2) If that fails, should it back up into the XRD that contained the
"dead-end" and try its next ref?

3) If THAT fails, should the resolver back up still further, i.e., into the
parent of the current XRD, to see if IT might have a ref that can be
successfully followed?

This illustrates my discomfort with any form of backtracking: as soon as you
allow backtracking at any point in the chain, does it not apply recursively
right back all the way up the chain to the community root authority? If not,
what's the rule about where you stop backtracking?

A "no backtracking" rule (limited breadth, unlimited depth) avoids this
problem by saying that once you successfully resolve a ref to a new XRDS
document, you never back up out of that document. You only either: a) move
forward to another new XRDS document (either directly, or by following a
ref), or b) error out.

Even with a no-backtracking rule, Andy's use case is still fully supported,
because with this unified ref processing model, every node in his tree of
authorities can be reached via either a service ref (directly) or an
authority ref (indirectly, as the authority ref processing would have to
walk the entire set of potential authority nodes).

Thoughts?

=Drummond (back at Digital ID World tomorrow, so responses may be slow)


> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org ]
> Sent: Monday, September 24, 2007 3:52 PM
> To: xri@lists.oasis-open.org
> Cc: andy.dale@ootao.com; 'Kermit Snelson'
> Subject: RE: [xri] New thread: Rethinking ref processing
>
>
> Drummond,
>
> The overriding concern is that the CanonicalID in the XRD obtained by
> following an http(s) URI must be identical to the CanonicalID in the XRD
> containing the service ref. This is required from a security standpoint,
> because a different CanonicalID cannot be validated outside of XRI
> resolution. (It cannot be validated via http(s) GET.)
>
> Your proposal below allows the (final) CanonicalID coming back different
> when the service ref contains an xri.
>
> I feel that this would be a gross overloading of semantics for the service
> ref element.
>
> Keep in mind that I originated this thread because I felt that the OpenID
> resolver implementation does not match the Ref semantics that Andy
> describes
> in his write-up. To do this, the resolver simply needs to "follow the next
> ref when the previous ref comes up empty." (The spec is ambiguous and
> needs
> to be clarified in either case.)
>
> ~ Steve
>
> -----Original Message-----
> From: Drummond Reed [mailto: drummond.reed@cordance.net ]
> Sent: Monday, September 24, 2007 12:19 PM
> To: 'Steven Churchill'; xri@lists.oasis-open.org
> Cc: andy.dale@ootao.com ; 'Kermit Snelson'
> Subject: [xri] New thread: Rethinking ref processing
>
> All,
>
> I hate to throw a twist into this whole discussion, but after writing
> response to Steve's email last night regarding: a) the limitations we
> currently have on service refs, and b) how CanonicalID verification
> processing works with all refs, more thinking this morning made me realize
> that two of our assumptions about Ref processing should be revisited.
> Specifically, I'm referring to:
>
> 1) The differences between authority refs and service refs.
> 2) Our current rules for how we nest XRDS documents in authority ref
> processing and add XRD documents in service ref processing.
>
> I'll treat these in turn (warning: this is a long and meaty topic):
>
> PART 1: THE DIFFERENCE BETWEEN AUTHORITY REFS AND SERVICE REFS
>
> At that time we designed service refs last spring, we decided that a
> service
> ref should be limited to:
>
> a) Only using an HTTP(S) URI.
> b) Only resulting in an additional XRD in the current XRDS.
>
> Steve's points made me stop and revisit those assumptions. After the whole
> CanonicalID verification discussion and all it taught us about delegated
> resolution chains, when I asked myself, "Why isn't service ref processing
> identicial to authority ref processing?", my answer was, "Hmmm. It should
> be."
>
> In other words, we could both simplify the spec and provide more
> tightly-directed references if service refs functioned identically to
> authority refs. What this would mean is:
>
> 1) A service ref can be an XRI just like an authority ref (note: it can
> also
> be an HTTP(S) URI just like an authority ref too, as we have now fully
> specified HTTP(S) URI resolution in ED05 section 6).
>
> 2) A service ref would be processed according to the same rules as an
> authority ref, i.e., if successfully resolved, it would result in the same
> nested XRDS document as an authority ref.
>
> 3) The only difference between an authority ref and a service ref would be
> that the latter is constrained to obtaining an XRDS that satisfies a
> pre-specified service endpoint selection criteria (selection of an
> xri://$auth*res*($v*2.0) service type), whereas the former can satisfy a
> service endpoint selection criteria specified at runtime.
>
> For example, to resolve =a*b for a service of type http://foo.service.org,
> if the XRD A for =a had no authority resolution service but had an
> authority
> ref to @x*y*z, and the XRD for =a*b had a service ref for its
> http://foo.service.org service to =m*n, the resolver would take the
> following steps:
>
> 1) It would resolve =a, look for an authority resolution service endpoint,
> and finding none, begin ref processing of @x*y*z.
>
> 2) It would resolve a nested XRDS for @x*y*z.
>
> 3) From the final XRD, it would choose the authority res service endpoint.
>
> 4) From that endpoint, it would resolve *b (note that under our current
> rules, the resulting XRD goes back in the outermost non-nested XRDS
> document).
>
> 5) From that XRD, the resolver would look for a service ref for the
> http://foo.service.org service. There it finds a service ref to =m*n.
>
> 6) The resolver resolves =m*n, finds the http://foo.service.org service,
> and
> it's job is done.
>
> Note again that both the authority ref to @x*y*z and the service ref to
> =m*n
> are resolved the same way and result in the same nested XRDS documents.
> Which brings us to...
>
> PART 2: THE XRDS NESTING PROBLRM
>
> The second problem that Steve's message led me to see was the way we are
> currently nesting XRDS documents. Under ED05, the closest we can get to
> the
> scenario above is the following outline.
>
> <XRDS for =a*b >
>       <XRD for =a />
>               <XRDS for @x*y*z >
>                       <XRD for @x />
>                       <XRD for *y />
>                       <XRD for *z />
>               </XRDS>
>       <XRD for *b />
>       <XRD for service ref to HTTP(S) URI for =m*n />         ;service ref
> </XRDS>
>
> The final XRD is the one resolved by the service ref, which under ED05 is
> constrained to being an HTTP(S) URI that results in a single additional
> XRD.
>
> Now, if we remove that constraint as proposed above, so that the service
> ref
> can itself be a nested XRDS document, we'd get the following:
>
> <XRDS for =a*b >
>       <XRD for =a />
>               <XRDS for @x*y*z >
>                       <XRD for @x />
>                       <XRD for *y />
>                       <XRD for *z />
>               </XRDS>
>       <XRD for *b />
>               <XRDS for =m*n >                        ;XRDS for service
> ref
>                       <XRD for =m />
>                       <XRD for *n />
>               </XRDS>
> </XRDS>
>
> Note that the nested XRDS for @x*y*z looks just like the nested XRDS =m*n.
> The reason this makes so much sense is that authority refs ARE a form of
> service ref! They are just specialized for a specific service:
> http://$res*auth*($v*2.0).
>
> But now let's look at what happens with CanonicalID verification in EITHER
> of these models. ED05 currently specifies how CanonicalID verification
> works
> with nested XRDS documents: it restarts with each nested XRDS, and tracks
> through that XRDS only. Here's what that would look like for the above
> resolution chain using the second model above:
>
> <XRDS for =a*b >
>       <XRD for =a />                  ;asserts CID for =a as child of =
>               <XRDS for @x*y*z >
>                       <XRD for @x />  ;asserts CID for @x as child of @
>                       <XRD for *y />  ;asserts CID for *y as child of @x
>                       <XRD for *z />  ;asserts CID for *z as child of @x*y
>               </XRDS>
>       <XRD for *b />                  ;asserts CID for *b as child of =a
>               <XRDS for =m*n >
>                       <XRD for =m />  ;asserts CID for =m as child of =
>                       <XRD for *n />  ;asserts CID for *n as child of =m
>               </XRDS>
> </XRDS>
>
> The problem this reveals is that @x*y*z cannot assert a valid CanonicalID
> for *b because only =a can assert a valid CanonicalID for =a*b -- in ED05
> we
> are very explicit that each verified CanonicalID MUST be a direct child of
> the parent authority that asserts it.
>
> Ouch.
>
> So for CanonicalID verification to work, whenever you hit an authority
> ref,
> you MUST restart the CanonicalID verification chain starting with the new
> community root authority in the new XRDS document. You CAN'T return
> control
> to the previous CanonicalID verification chain in the previous XRDS
> document.
>
> It didn't take very long looking at this to realize that the only solution
> compatible with CanonicalID verification as we've specified it is for XRDS
> documents to ONLY delegate to other XRDS documents. It's like walking down
> flights of stairs: each flight can lead to a new flight, but the direction
> is only down - you never go back up to a previous flight.
>
> That would mean the outline for the example scenario above would look like
> this:
>
> <XRDS for =a*b >
>   <XRD for =a />                      ;asserts CID for =a as child of =
>     <XRDS for @x*y*z >
>       <XRD for @x />          ;asserts CID for @x as child of @
>       <XRD for *y />          ;asserts CID for *y as child of @x
>       <XRD for *z />          ;asserts CID for *z as child of @x*y
>       <XRD for *b />          ;asserts CID for *b as child of @x*y*z
>         <XRDS for =m*n >
>           <XRD for =m />      ;asserts CID for =m as child of =
>           <XRD for *n />      ;asserts CID for *n as child of =m
>         </XRDS>
>     </XRDS>
> </XRDS>
>
> Key characteristics of this structure:
>
> 1) Authority refs and service refs are both treated identically.
>
> 2) XRDS documents are only nested; once the "baton is passed" via, it is
> never passed back.
>
> 3) CanonicalID verification works as specified in ED05. When a ref is
> encountered (either an authority ref or service ref), CanonicalID
> verification restarts with the new community root authority. Which means
> the
> only verification CanonicalID you can get back within the final nested
> XRDS
> is rooted in the community root authority for that XRDS. (Of course, it
> can
> assert a verifiable CanonicalEquivID rooted on any community root
> authority.)
>
> ********
>
> I'm at Digital ID World today and have been typing this during sessions
> here. Andy Dale and John Bradley are here and we're going to try to spend
> time today going over this. We'll send notes from our discussion as soon
> as
> we can. I invite everyone on the list (and the cc list) to cogitate on
> this
> and share your thoughts.
>
> I'd suggest we first need to answer these more fundamental design
> questions
> about ref processing behaviour before we can return to close the policy
> issues we have been discussing previously.
>
> Also, I definitely think this must be the main topic of this Thurday's
> telecon (10-noon Pacific Time), so please do set aside time for that call
> if
> you can.
>
> =Drummond
>
>
> > -----Original Message-----
> > From: Steven Churchill [mailto: steven.churchill@xdi.org ]
> > Sent: Monday, September 24, 2007 7:01 AM
> > To: xri@lists.oasis-open.org
> > Cc: andy.dale@ootao.com ; 'Kermit Snelson'
> > Subject: RE: [xri] Clarity around Ref processing behavior.
> >
> >
> > Drummond,
> >
> > Service Refs won't work because if an XRI client requests CanonicalID
> > verification then an error is returned when the CanonicalID in the XRD
> > returned by following the service Ref does not match the CanonicalID in
> > the
> > XRD containing the Service Ref.
> >
> > ~ Steve
> >
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto: drummond.reed@cordance.net]
> > Sent: Sunday, September 23, 2007 11:37 PM
> > To: 'Steven Churchill'; xri@lists.oasis-open.org
> > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > Subject: RE: [xri] Clarity around Ref processing behavior.
> >
> > Steve,
> >
> > Good point about resolvers doing caching. That can help with the latency
> > problem.
> >
> > However I disagree about service refs not being a better solution to
> > Andy's
> > use case. Ironically, one reason is that all you need to do to give a
> > service ref those same semantics is make it a call to an HXRI. Now that
> > service ref can return you exactly what you want from the target
> > authority.
> >
> > My gut tells me this "rifle shot" approach is faster and more precise
> than
> > "random hunting" across a set of authority refs. Both are equally valid
> > types of refs. But I'm increasingly feeling like authority refs are a
> very
> > blunt instrument, more suited for wholesale delegation of an entire
> XRDS,
> > whereas service refs are much better suited for granular delegation of
> > specific services.
> >
> > What am I missing?
> >
> > =Drummond
> >
> > > -----Original Message-----
> > > From: Steven Churchill [mailto:steven.churchill@xdi.org ]
> > > Sent: Sunday, September 23, 2007 10:35 PM
> > > To: xri@lists.oasis-open.org
> > > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > > Subject: RE: [xri] Clarity around Ref processing behavior.
> > >
> > >
> > > Victor,
> > >
> > > Regarding performance, whether an XRI client (the program asking =andy
> > for
> > > a
> > > given service type) uses a local resolver or a proxy resolver is a
> > matter
> > > of
> > > configuration. In either case, the latency you speak of would take
> place
> > > in
> > > the resolver, and only in the cases where it doesn't have the
> requested
> > > XRD
> > > already in its cache. Translated: if nothing happens to be cached,
> then
> > > the
> > > requesting XRI client will need to wait longer for the result the
> first
> > > time
> > > the request is made. (As for too much load on proxy resolvers, their
> > CPUs
> > > don't spin while they wait on TCP/IP requests, and, besides, if a
> proxy
> > > resolver cannot stand the load, then it should be load balanced or it
> > > should
> > > not be running in the first place.)
> > >
> > > Regarding using Service Refs, these have different semantics than XRD-
> > > level
> > > Refs. Service Refs can only be HTTP(S) endpoints; and they do not
> > support
> > > the "if I can't find the service here then follow the Ref" semantics.
> > That
> > > is, they really don't address Andy's use case.
> > >
> > > ~ Steve
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Victor Grey
> > > 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]