Hello Frank,
in general we are taking the current doc as a starting point and will write
a new one taking a step back to find what is the best protocol to fit OPES
needs. I sent the preso that we will give today in the IETF to Martin (which
I assume works with you)
other comments inline...
-----Original Message-----
From: Frank Berzau [mailto:frank(_at_)webwasher(_dot_)com]
Sent: Wednesday, March 20, 2002 2:38 AM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: Comments on draft-dracinschi-opes-callout-requirements-00.txt
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.
agreed. This goes back to the discussion last week on what minimum
personalization requirements we need to feed into opes.
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.
We are proposing (or should I say asking for opinions) about having a
capability negotiation phase for the whole boxes (intermediary and callout)
and also for the channels. At any time you should be able to renegotiate the
capabilities.
4: I would expect to mandate the use of MD5 password security like in
WCCP v2.0 to make sure implementations are interoperable.
Not sure about the minimum secdurity requirements at this point...
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.
yep, The (www) virus scanners that I dealt with send you a HTML page saying
something like "you file/page/whatever is being scanned...wait.."
thanks,
Reinaldo
Thanks, Frank