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.