ietf-openproxy
[Top] [All Lists]

Re: Draft on Callout Protocol Requirements

2001-11-22 18:28:46

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?

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 
"callout protocol"?

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
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?

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 
bit different.

Hopefully that diagram above explains what I'm talking about.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker(_at_)planetfred(_dot_)com
http://www.markbaker.ca   http://www.planetfred.com