Subject: RE: OCP Core version head_sid6 available

From: Alex Rousskov <[email-masked]>
Date: Wed, 4 Jun 2003 11:14:27 -0600 (MDT)

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.

---

From: "Martin Stecher" <[email-masked]>
Date: Thu, 5 Jun 2003 23:18:08 +0200

On Thu, 5 Jun 2003, Alex Rousskov wrote:
> 
> > 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?).
> 
> Yes, it is. In addition to bingings, extensions may add parameters or
> new messages as well.
> 
> > Transport negotiations (if any) MUST happen before CS message.
> 
> That's probably too restrictive because some transports may require
> run-time negotiations in addition to startup negotiations. Also,
> please note that the other side can reject any insecure transmissions
> if it insists on secure communications (causing an interoperability
> problem). I believe each negotiable feature must document when it can
> or MUST be negotiated.

You are right.

> 
> This also reminds me that the only purpose of an OCP Connection (as
> defined in the Core draft) is to specify the default services to be
> applied to all transactions within an OCP Connection. The only
> relationship between an OCP Connection and transport connection is
> that we assume that transport will somehow distinguish OCP connections
> from each other (e.g., by allowing only one OCP connection per
> transport connection or by using some transport channel IDs). Thus,
> the "Connection" word is really misleading and not appropriate. The
> reason it exists in the current draft is because the OCP requirements
> draft uses it, but we do not have to follow the requirements
> terminology as long as we provide intended functionality.
> 
> I would like to propose the following:
> 
> 	1. Remove the concept of OCP Connection. OCP Connection
> 	   is the same as transport connection.
> 
> 	   Document that Connection Start (CS) and Connection
> 	   End (CE) messages refer to OCP transport connection.
> 	   The Connection Start (CS) message MUST be the first
> 	   message on the connection. It is nice to have a
> 	   protocol-specific "Hello" message before any
> 	   negotiations begin. Connection End (CE) message
> 	   MUST be sent immediately before closing the
> 	   transport connection. Its purpose is to allow
> 	   one side to inform the other why the transport
> 	   connection is being closed.
> 
> 	   The current "scope for common services" aspect
> 	   of OCP Connection should be supported directly,
> 	   see "handling common callout services" e-mail.
> 
> 	2. There will be no other connection-specific
> 	   messages or options, for now.
> 
> 	3. When documenting TLS negotiations, insist that
> 	   they start immediately after Connection Start (CS).
> 
> Would that work for you?

Absolutely, sounds very good to me.

Regards
Martin