Alex Rousskov wrote:
a) OPES processor may be able to pre-process application
messages (e.g., extract payload). Callout servers
may be able to handle various kinds of application
data (e.g., complete HTTP messages versus MIME-encoded
payload). Thus, somebody needs to tell OPES processor
and callout server what is an "application message"
definition that they should both use during OCP
communications. Should OCP support auto-negotiation or
rely on out-of-band (e.g., manual) configuration?
Please, let's try to stay away as much as possible from building
(potentially complex) capability negotiation mechanisms into OCP. I
would prefer to keep OCP simple.
In an earlier email, other protocols were mentioned as positive
reference for integrating capability negotiation. I'm not sure about
that, since I hear increasingly voices expressing problems with that
approach (e.g. negotiation of transport protocol in SIP, for example,
is often considered a "trouble maker").
c) OPES processor can be [a part of] an application-level
proxy. Can OPES processor be a transport-level gateway
too? For example, can OPES processor manipulate with
raw TCP packets and care about things like
retransmissions and ACKs?
OPES clearly is about application-level proxies and does *not* operate
on network or transport layer!! Please let's be very clear about that!
Hilarie also had some nice charts in San Franciso, which might help
illustrating this, see http://ietf.org/proceedings/03mar/slides/opes-1.pdf
-Markus