ietf-openproxy
[Top] [All Lists]

Re: Draft on Callout Protocol Requirements

2001-11-22 20:35:32

--On Thursday, November 22, 2001 21:19 -0500 Mark Baker <distobj(_at_)acm(_dot_)org> wrote:

>      +----+   +----+
>   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.

So in terms of the end-to-end HTTP flow (assume no modifications for
now)  I1 and I2 are functionally equivalent: they're both HTTP proxies
from what  I can see.

HTTP intermediaries.

OK, let's be careful... there's not to my knowledge any definition of an "HTTP intermediary" that we can actually point to as a reference. (And yes, I know that I'm guilty of using that phrase too.)

 Not necessarily proxies.  Re your comment about
gateway below, yes, I didn't mean to use the term.  Though in the
example I had in my head, it was also a gateway.  In that diagram I
provided, there's insufficient information to determine whether the
intermediaries are gateways or proxies.

If I2 is a gateway then I'm starting to see some very icky requirements in the I* cloud (if there could be an I3 between I2 and OS). I think I'm starting to see source routing too... I'm definitely seeing encapsulation issues.

The only reason to add I2 as a "gateway"(*) is in order to support the
custom protocol between I2 and E1.  If you're going to do that then
you're  right that there's no need to have a standardized OPES callout
... but it's  kindof missing the point of standardizing an OPES callout
protocol in the  first place.  If there is a series of transformations
that need to occur  between OS and C (or vice versa) your model could
requre as many additional  I* entities as transformations.

It could, but need not.  There is room for optimization.

Of course. But if I have 5 transformations from 5 vendors each of whom wishes to run their own I-E protocol that means I have a total mess.

I thought the whole point of OPES was to have one I-E protocol so that we had an open standard... kindof like HTTP... so that things can work together properly.

I'm not sure I've seen a requirement for the OPES callout protocol being a new on-the-wire protocol, but if it's going to be run on top of, say, HTTP then we still need a document to be able to point to so we can all write to the same encapsulation. (You mentioned SOAP over HTTP - that's definitely been discussed as a candidate. If OPES uses SOAP over HTTP then it still needs to be documented, even if the resulting documentation is a 3 page RFC.)

 Even scarier than the latency each
application layer hop would add is the configuration of the I* entities
in  the correct order to accomplish a set of arbitary transformations
potentially spread across multiple E* entities.

Enter the application router.  My company sells them.

When can we expect to see an Internet Draft explaining the operation of the application router and how it interoperates with proxies and gateways to provide transformation services?

I'd already considered an entity sat in the middle of a star-like collection of transformation engines but chose to omit that part from my earlier email. If you're going to be using HTTP then again you run the potential of a hideous number network stacks that the data is passing through. It would also differ from your initial diagram in that I2 would not have a direct connection to OS (the request would have to pass back through the "application router").

[Also, if I2 is only necessary to speak with E1 then it might be better
to  just create a custom proxy on I2 to do the job itself]

I didn't mean to suggest that they were *necessarily* distributed about
the network.  It would definitely make sense to put E1 and I2 on the
same box.

E1 + I2 = an OPES intermediary with E1 being provided by a proxylet. Right? The "application router" is then the rule logic tying together the various transformations that are available both in proxylets and via callout server(s).


Mark, please feel free to contact me off-list. I agree that there's some degree of disconnect and as such we might not be using the list in the most productive manner.