[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OCP Core: one service, two profiles
On Sat, 25 Oct 2003, Martin Stecher wrote:
> You are right. It will produce problems.
> Highlander principle: There can only be one!
While trying to explicitly fix this, I realized that it is not
possible for the Core to say which negotiated features are in conflict
(and so only one can be selected for a given service group). For
example, HTTP profile does not conflict with support-for-huge-sizes
but does conflict with FTP profile.
I also realized that we said nothing about conflict resolution between
group-scoped and global negotiations. For example, can a connection
have HTTP profile while a given group has an SMTP profile? My current
answer is no. Specific rules from the draft are quoted below.
Negotiating OCP agents have to take into account prior negotiated
(i.e., already enabled) features. OCP agents MUST NOT make and MUST
reject offers that would lead to a conflict with already negotiated
features. For example, an agent cannot offer an HTTP application
profile for a connection that already has SMTP application profile
enabled because there would be no way to resolve the conflict for a
given transaction. Similarly, once TLSv1 connection encryption is
negotiated, an agent must not offer and must reject offers for
SSLv2 connection encryption.
An optional "SG" parameter is used to narrow the scope of
negotiations to the specified service group. If SG is present, the
negotiated features are negotiated and enabled only for
transactions that use the specified service group ID. Globally
negotiated features are negotiated and enabled for all service
groups. When negotiating global features, an agent MUST check for
conflicts within each existing service group. When negotiating
group-scoped features, an agent MUST check for conflicts with
globally negotiated features. For example, it must not be possible
to negotiate a global HTTP application profile if one service group
has an SMTP application profile and vice versa.
OCP agents SHOULD NOT send offers with service groups used by
pending transactions. Unless explicitly noted otherwise in a
feature documentation, OCP agents MUST NOT apply any negotiations
to pending transactions. In other words, negotiated features take
effect with the new OCP transaction.
We should probably avoid the term "global" in the above.
Connection-scoped is probably better.