Hi,
thank you very much, Alex, for getting back with the examples.
regarding priority:
different priorities may or may not make sense; we should leave minimum
support for it in the core I guess.
But changing priority on the fly for an existing connection does not
make any sense to me; let's take it out.
Let's take your example: If OPES processor and callout server are
able to support VIP connections and the OPES processor suddenly
receives a request from an important client, it makes only little
sense to change priority of one of maybe 200 open connections.
While the connection is not yet on high priority when the change-
priority-message is sent, there is no guarantee that changing
priority will be handled very soon.
I assume that such an OPES processor will better want to keep one
or more VIP connections open and alive to ensure even higher
quality of that service.
So one (optional) parameter in the connection-start message should
pretty much cover this.
regarding services:
The usage examples do not convince me that changing of services
will be needed but the security example is very important.
Thank you very much.
If a server can do virus filtering plus language translation and
we assume that there are two types of service requests (only
AV filter or both filters), I guess that there will be many
files for either types, so that keeping multiple connections
open, some with service type 1, the others with service type 2,
makes probably more sense than switching single (sub-)services
on the fly. (for example to avoid loading and unloading
of language dictionaries in the callout server)
The other example with the different services depending on hours
of a day: I personally do not believe that this will happen
(often) in real-world examples. Either services are very much
reduced to one task (do classification of URLs OR do virus
checking) and so OPES processor handles the results by itself,
may check the time, combine results of different services, or
services are rather complex (offer different modules like URL
classification AND virus checking) and then want to handle the
complete policy by themselves and also include the user profiling,
date-time policies and so on and don't allow the OPES processor
to select the single services.
(I think some of you have a different view on this.)
But still then I think we can better live with opening new
connections with new sets of services rather than switching
services on the fly; makes (programmer's) life just simpler.
What remains is your very important remark about the secrecy
of connection-start parameters. This may be imporant for any
parameter that we add to the core now or will be added later
by a application protocol binding (which is possible, isn't it?).
So, putting it together and taking your proposal:
To keep things symmetric we can do this:
- no dedicated Connection Services (CSvcs) message
yes, and also remove Connection Priority message
- Connection Start (CS) and Transaction Start (TS)
messages have a Services parameter
Only Connection Start message has a services parameter and
an optional priority message. TS messages have not.
- transport negotiations MAY happen before
Connection Start (CS) message
Transport negotiations (if any) MUST happen before CS message.
Would you prefer this? I think I would. The last item may sound
strange, but I think it is actually the right thing to do because, in
theory, a single transport connection can carry multiple OCP
connections and so transport negotiations are one level above OCP
connections.
I agree.
Thank you.
Martin