On Wed, 21 May 2003, Martin Stecher wrote:
If services is an optional xaction-start parameter, why not also
make it an optional parameter of connection-start? If OPES
processor wants to use the default service for a connection
feature, it could set it already with the connection-start
message rather than sending an extra connection-services
message. Same for connection-priority?
I agree that the current specs are inconsistent. I am not sure
what the right fix is though. We can limit support to a dedicated
message for each state change (e.g., connection-priority) or we
can have both dedicated messages and message parameters (e.g.,
priority parameter in a connection-start message). Note that
dedicated messages are required because sometimes you want to
change the state in the middle of a "process" (e.g., change
priority or default services of an existing connection).
Can you give me an example where changing of priority or default
service is required?
Changing priority:
A processor establishes a connection with a callout server.
Uses default priority for a while. Then the processor
receives a message from an "important" client. The processor
raises the priority to speed up processing of the
transaction. An alternative is to open another connection,
or to keep an idle high-priority connection around, waiting
for VIP messages.
This is not a very convincing example; perhaps a time-based
example I used below would be better. However, I am not even
sure the whole priority concept needs to be supported. Do you
think we should yank priorities out of the Core?
Do you expect many implementations support priority/QoS
optimizations?
Changing service:
A processor establishes a connection with a callout server
and sets a default service to filter viruses. Then the
processor receives a message that can contain a virus, but
that also needs translation. The processor adds translation
service ID to the list of default services, for this
transaction only.
Another example where the default for the connection is
changed: From 8-17, employees are prohibited to surf porn.
From 17-8, employees (working over time) are allowed to
surf porn as a stimulus or whatever. Viruses should
be checked for at any time. The default connection
services will change at 8 and 17 hours. An alternative
would be to open a new connection, of course.
Also, keep in mind that connection is not encrypted
when Connection Start message is sent. A list of services
may be confidential and would need to be exchanged after
the transport is encrypted, via a designated message.
An alternative is to re-send a Connection Start message
after the transport is encrypted (BEEP does that, I think),
but it feels like a kludge to me.
Overall, I think that overwriting default connection services on
transaction basis is an important feature. Changing connection
defaults is not an important feature, but having a separate message
allows us to keep a list of services private.
To keep things symmetric we can do this:
- no dedicated Connection Services (CSvcs) message
- Connection Start (CS) and Transaction Start (TS)
messages have a Services parameter
- transport negotiations MAY happen before
Connection Start (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.
Thanks,
Alex.