If the latter then surely the standardized callout protocol becomes that
channel of communication (which means the protocol needs to consider
potential transcoding issues that may occur, er, yuk ;-) ).
No, the protocol between intermediaries is a transfer protocol, such as
HTTP, SMTP, SOAP/HTTP, etc..
Er... isn't the use of HTTP as a transport between the intermediary and
callout server something that iCAP attempted (and if memory serves, failed)
Kinda. It didn't do it properly. It broke HTTP's end-to-end model.
Even if using a common application layer protocol as a transport, surely
there's still a need to standardize the callout protocol subelements (e.g.
which service is being addressed) so that gateways and the OPES
intermediary can talk a common language. Doesn't that then become the
I'm not sure I understand, so I won't risk a response.
I'll admit that I haven't read all of the drafts recently, but I didn't
think there was a requirement for the callout protocol to be "something
totally and utterly new" if an existing protocol (HTTP, SOAP etc.) fitted.
We must be disconnected, but I'm not sure where. Let's dig a little
Perhaps you could give some quick back-of-the-envelope examples of how HTTP
and/or SMTP might be used as the protocol between OPES intermediary and the
Well, the gateway is just another intermediary in the chain. So it
might look like this;
C -| I1 |---| I2 |- OS
| E1 |
C = client, OS = origin server, I1 = some intermediary, E1 = some
external service accessed by a different protocol, I2 = a gateway
intermediary to E1. C, S, and I1 don't care what E1's protocol is, and
that's why I don't think it's important to pick just one. I2's job is
just to make E1 look like an intermediary.
BTW: I'm not sure that your gateway is an "intermediary" as such since
within the flows under consideration it's not in the path of user-request
traffic. It's only an intermediary in the modification flows, which is a
Hopefully that diagram above explains what I'm talking about.
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker(_at_)planetfred(_dot_)com