Subject: RE: HTTP as OCP transport, ICAP/2.0

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 22 Apr 2003 20:47:56 -0400

Hilarie,
Based on my understanding. This is correct.

Marshall, can we have your 2 cents.

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Tuesday, April 22, 2003 7:35 PM
> To: [email-masked]
> Subject: Re: HTTP as OCP transport, ICAP/2.0
> 
> 
> 
> 
> On Tue, 22 Apr 2003, The Purple Streak, Hilarie Orman wrote:
> 
> > I thought BEEP's security was the same as HTTP's: use TLS.
> 
> My understanding is that BEEP can _negotiate_ security 
> profile for a BEEP session (so that we do not have to worry 
> about that at all). Please correct me if I am wrong.
> 
> I know that HTTP has no idea it is being (or can be) wrapped 
> with TLS. Thus, we, as OCP writers, would have to worry about 
> negotiating and then enabling TLS.
> 
> Alex.
> 
>

---

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 23 Apr 2003 09:36:10 -0400

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

> From: The Purple Streak, Hilarie Orman [mailto:[email-masked]] 
> Sent: Wednesday, April 23, 2003 2:25 AM
> To: [email-masked]
> Cc: [email-masked]
> "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
> 
> 
> 
>