|
Re: Draft on Callout Protocol Requirements
2001-11-23 00:31:08
OK, I found the disconnect, and it was down to a mis-read of your initial
message on my part. Argh (and I can't even blame Turkey Day excess).
Let's try getting back to a point where I wasn't burying myself in invalid
assumptions and start afresh.
--On Thursday, November 22, 2001 20:26 -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?
Kinda. It didn't do it properly. It broke HTTP's end-to-end model.
OK, I see what you meant here now, and it sounds similar or identical to
something a few of us discussed just after the Minneapolis meeting.
Taking the SMTP model and virus checking you're using the analogy of "pass
it through another MTA that knows how to speal SMTP but can do special
stuff in a black box that we really don't care about".
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.
It would appear that you still need to signal which transformations are
required.
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.
OK, I think this is where I went off at a rather wild tangent.
And now coming back to it (and considering some of the other things you've
said) I'm not totally clear as to whether I1 is any part of the
transformation environment.
I think I can see where you're going with the "use the base protocol" thing
and I'd like to dive deeper into it...
If you could clarify (use HTTP is probably easiest) in the above diagram
which boxes are part of the transformation environment, which box(es)
do(es) the transformation then I think that would be useful. It could be
useful to add a couple more transformations so we can catch issues; put the
second transformation on E1 and a third on E2. [And my apologies for the
headaches of ASCII art that request may cause]
It still looks like you need to signal the transformations to be performed
somehow. If that happens in, for example, HTTP headers then my comment on
standardization is simply related to the fact that those headers need to be
documented. (There are some trivial security issues in such a method, so
you'd want to be able to have the authority to remove offending headers
that shouldn't be there at an appropriate point in the system.)
As an aside (this is to the group), recalling your point on the end-to-end
HTTP stuff... hmm... many of these transformations are going to change
things like the size of the object. Yet if Content-Length is changed, can
we claim to have HTTP between user agent and origin server? If we don't
change Content-Length then, well, yuk.
|
|