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.
Great! Thanks for taking the time to reflect on the discussion.
--On Thursday, November 22, 2001 20:26 -0500 Mark Baker
<distobj(_at_)acm(_dot_)org>
wrote:
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".
Right.
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.
Yes, definitely. "You" here can be any party in the transaction; the
client, the origin server, or any intermediary. Obviously there's
different policy & security considerations for each.
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.
See below.
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]
Ok, let's make it a bit more concrete. Let's say I1 is a firewall, E1
is a language converter available through an RPC call, and OS is an
english stock quote. We'll also assume that all requests from C are
sent with an Accept-Language header. In addition, let's assume that
I1/E2 are owned and maintained by the same authority as OS (thereby
making I1 a gateway, as C specifically addresses I1, not OS).
I2's job is to make E1 look like an HTTP intermediary. It does this by
accepting the responsibility on behalf of E1, of not just dispatching
requests to it, but of providing the end-to-end guarantees that HTTP
requires. In this example, one of those guarantees is that it will
mediate language conversion, so will look for "Accept-Language: fr" on
an inbound request (from C), "Content-Language: en" on an inbound
response (from OS), and will know to change Content-Language to the
value of the inbound Accept-Language after dispatching the conversion
process to E1 (assuming the conversion was successful).
To run through the example then,
- C does GET http://i2-host.com with "Accept-Language: fr" header
- I1 (the firewall) passes it through, perhaps perform proxy
authentication to check that the user is authorized to traverse it
- I2 receives the request, remembering the Accept-Language header,
and passes it on to OS
- OS responds with some content tagged "Content-Language: en"
(it gets the Accept-Language header, but doesn't process it).
- on the return path, I2 sees that the content is in English,
but the user wants it in French, so it dispatches the content
to E1 to do the conversion
- I2 returns this content on the response path with
"Content-Language: fr"
- C gets the French stock quote
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.)
There are scenarios where C may want to specify the path that's
taken. In that case, extension headers will definitely be required.
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.
"end-to-end" doesn't mean that information has to flow unchanged from
one end to the other of a chain. It only means that if it is changed,
that the one who changes it has to take responsibility for it by
following the rules regarding what the changes might mean. Hopefully
that example above demonstrates this.
Phew! 8-)
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker(_at_)planetfred(_dot_)com
http://www.markbaker.ca http://www.planetfred.com