--On Thursday, November 22, 2001 15:58 -0500 Mark Baker <distobj(_at_)acm(_dot_)org>
wrote:
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)
to do?
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
"callout protocol"?
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
deeper.
Agreed.
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
gateway?
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
bit different.