[Top] [All Lists]

RE: HTTP as OCP transport, ICAP/2.0

2003-04-23 06:36:27

yes I do concur with you.

We have addressed the other issue before (not in the same administrative
domain, the VPCN solution if you remember).


-----Original Message-----
From: 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

"Transport" in the classicial meaning is layer 4.  However, 
it's possible for a protocol, like ICAP, to use a layer 5 
protocol as its transport.  That is, to fit entirely within 
the semantics of layer 5 and to introduce its own further 
semantics.  I think that is the best way to view ICAP, from 
an architectural viewpoint.  The deviations from HTTP 
semantics are trivial.  The intent was to have something that 
ran on devices that already understood HTTP, so very little 
additional code would be writtent to support ICAP.

Most multimedia streaming protocols run over HTTP fairly well.

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.


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