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 MAY happen before
Connection Start (CS) message
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