RE: Capability Negotiation for OCPDid we have made a decision on BEEP? The
BEEP discussion had no
conclusive end, in fact for me it looks more like a pause. There were
pros and cons discussed, more pros than cons, but no conclusion.
If we are going to adopt BEEP many things will be shaped by that.
Alex, what do you think?
Oskar
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Abbie
Barbir
Sent: Monday, April 21, 2003 9:06 AM
To: Alex Rousskov; ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: Capability Negotiation for OCP
hi,
how about Authentication/Authorization/encrytption.
how/when these will be negotiated/supported etc.
Are we talking about another encapsulation (like HTTPS or SASL) here or
what?
Abbie
> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
> Sent: Thursday, April 17, 2003 2:58 PM
> To: ietf-openproxy(_at_)imc(_dot_)org
> Subject: Re: Capability Negotiation for OCP
>
>
>
>
> On Thu, 17 Apr 2003, Reinaldo Penno wrote:
>
> > These are my ideas on capability negotiation. They are a
> mix of SDP's
> > offer/answer, BGP and PPP.
>
> Sounds like a great start to me. I am sure we will run into
> arguments once the wording becomes more specific.
>
> One high-level thing to consider now is scope (level)
> definition: Do we want to have a fixed number of levels
> associated with OCP entities like connection and transaction?
> Or do we want to allow unlimited nesting? For example, is it
> possible that something needs to be re-negotiated in the
> middle of a transaction?
>
> Another issue: are negotiations always limited in scope to a
> single transport connection? Are we worried that two
> connections to the same IP may not end up at the same callout
> server? In other words, if an OPES processor wants to open 10
> connections to a callout server, does it need to negotiate
> each from scratch OR can it refer to earlier
> ("cached") negotiations?
>
> Semantically, does <offer> describe sender characteristics "I
> can use Foo" or can it describe sender desires (recipient
> characteristics) "Please use Foo" as well? For example, how
> can a callout server change OPES processor copying state from
> "yes" to "no" in the middle of an OCP connection? Using
> "Processor-uses-copying" property?
>
> How is the order of negotiations determined -- what if both
> OPES processor and callout server send <offer> messages "at once"?
>
> Finally, can we define a complete set of parameters that MUST
> be negotiated for OCP Core?
>
> Let's not spent too much effort on what you call "packet
> format" now. The choice of transport protocol and encoding
> will have a major impact on that, I think.
>
> Thank you,
>
> Alex.
>