RE: HTTP as OCP transport, ICAP/2.0

Hilarie,

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


Abbie


> -----Original Message-----
> From: The Purple Streak, Hilarie Orman 
> [mailto:ho(_at_)alum(_dot_)mit(_dot_)edu] 
> 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.
>
> Hilarie