-----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 The
Purple
Streak, Hilarie Orman
Sent: Wednesday, April 23, 2003 2:25 AM
To: markus(_at_)mhof(_dot_)com
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: HTTP as OCP transport, ICAP/2.0
We've stated several times that the OPES processor and callout server
have to be in the same administrative domain for security reasons.
But, let's look at the case where they aren't, just for fun. Suppose
someone put an HTTP intermediary in their path, as you suggest, and
suppose it is an OPES process and it does HTTP content modification,
wouldn't that be a mess?
Even if the callout protocol is something else (SE), there might be an
OPES box doing SE modification in the path.
So, I'd think the callout protocol MUST carry a transport header with
"no OPES" in order to control what could turn into an uncontrollable
routing problem.
Hilarie, I do not quite understand your fears. An OPES box is (should be)
a legitimate building block for network application architecture. If rules
and protocols are designed correctly they should not require additional
restrictions of this kind. Moreover, imposing such specific restrictions
looks like introducing per-case patches. Unless there is a specific
scenario that result in problem we should avoid patching.
Oskar