[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: capabilities problem
Emile van Bergen <email@example.com> wrote:
> Ok. So can we conclude that the inefficiency objection of a second
> round trip in case of GEOPRIV is moot, because it's needed anyway, and
> that this is solved perfectly by your proposal with my refinements?
> Agreed. Problably the misunderstanding lies in that I take 'advertising
> a capability', as 'This party implements standards document X,
> containing numberous clauses with musts, shoulds and mays', which I find
> problematic. That's perhaps my biggest objection.
Which is why I avoided implementation and semantic problems, by
saying "advertises a capability".
First, we can decide what we need from capabilities and their
advertisement, independent of the definitions for each capability.
Then, we can define the capabilities. Finally, we can describe their
> But I want to get rid of the explosion of possible states that a system
> can get when two parties state their abilities, their wishes, and then
> have to do a form of negotiation.
> It took numerous endless looping implementations of PPP to get that
> right in PPP.
Agreed. I vew capability negotiations a bit like the final "show of
hands" in poker. Everyone's cards go on the table, and everyone runs
the same algorithm on the available data. Once.
> If the use of challenges to get at information that can be put in the
> first access request was Avi's worry too, then I completely agree.
To put it more strongly, if we don't have *any* capability
advertisement in the first packet, we're back to today's RADIUS, and
we can't break that by changing server behavior.
> Luckily here, you've misunderstood. I'm surprised. Am I really so bad at
> explaining my position clearly?
There was significant opposition to allowing Avi's scenario.
> So I think we may have complete agreement on the problem and abstract
> solution for GEOPRIV and alike future cases, at least between you, Avi
> and myself.
> We only need to work out the attributes and values
I disagree. I think we're pretty close, but I don't think we're
ready to design a solution based on the stated requirements. I would
like to ensure that *all* capability requirements are spelled out, to
ensure that the solution is applicable to later capabilities.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.