----- Original Message -----
From: "Markus Hofmann" <markus(_at_)mhof(_dot_)com>
To: "OPES Group" <ietf-openproxy(_at_)imc(_dot_)org>
Sent: Saturday, April 05, 2003 8:34 PM
Subject: Re: Comments on ocp-00
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").
Markus,
that's on example versus several mature protocols running in the Internet
for years and years. Moreover we have already ruled transport negotiation
out. So, can you give other examples of these increasing voices? Because
although the negotiation of transport in SIP might be a problem, SDP's offer
and answer model is what makes a SIP session so easy.
Anyway, I guess that if the majority feels that capability negotiation is
not useful then we should edit the requirements draft and modify the MUST to
SHOULD or MAY. Otherwise it will seem strange that the protocol the WG
itself propose does not abide by its own requirements.
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!
How can that be possible? The OPES processor needs to be addressed explicily
by the client, so it needs to deal with IP/TCP and application. If has to
implement a full TCP/IP stack. You might consider that "not part of OPES",
but the box in which OPES run clearly has to implement everything.
If it was some sort of transparent proxy, we could have TCP Proxy/Splicing,
but this is not the case.
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