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.