"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