[Top] [All Lists]

RE: HTTP as OCP transport, ICAP/2.0

2003-04-23 11:49:46

-----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 
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.


<Prev in Thread] Current Thread [Next in Thread>