ietf-openproxy
[Top] [All Lists]

Comments on draft-dracinschi-opes-callout-requirements-00.txt

2002-03-20 03:38:51

3.1.3 Additional information about the client should be included, e.g.
client ip address, or user name or group membership (in case the
intermediary is doing authentication). The client ip could also be
transmitted in the payload (like x-forward-for in HTTP), however, it is
normally much more efficient to have that information as an additional
header in the callout protocol. Similarly the callout server may return
the policy that has been applied in the response for further processing
at the intermediary.

3.2.2 Negotiation of parameters need to happen more dynamic, not only
when establishing a channel. If this is a must feature then we could
assume that the callout server can close a channel if a configuration
change or other event requires to re-negotiate parameters. If not, there
need to be other possibilities to re-negotiate parameters at any time.

4: I would expect to mandate the use of MD5 password security like in
WCCP v2.0 to make sure implementations are interoperable.

Other issues:

There is a problem in performing time consuming services, especially if
the service requires to transmit the complete object. An example would
be a virus scanner. In this case the client may time-out before the
callout server sends a response to the intermediary. While it is out of
the scope of a callout protocol to prevent the timeout of the client <->
intermediary connection, it would be beneficial to indicate a progress
information so that the user does not cancel the attempt to download a
large object before receiving the response. Of course the callout server
could just send CR-LF's until the complete object has been processed,
but this leaves the client in the dark about the progress.

Thanks, Frank