RE: HTTP as OCP transport, ICAP/2.0
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).
From: The Purple Streak, Hilarie Orman
Sent: Wednesday, April 23, 2003 2:25 AM
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]
||[Next in Thread>
- Re: HTTP as OCP transport, ICAP/2.0, (continued)
- Re: HTTP as OCP transport, ICAP/2.0, The Purple Streak, Hilarie Orman
- Re: HTTP as OCP transport, ICAP/2.0, Markus Hofmann
- RE: HTTP as OCP transport, ICAP/2.0, Abbie Barbir
- RE: HTTP as OCP transport, ICAP/2.0,
Abbie Barbir <=
- RE: HTTP as OCP transport, ICAP/2.0, Martin Stecher