ietf-openproxy
[Top] [All Lists]

RE: OCP Core: one service, two profiles

2003-10-25 18:01:21


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.

Alex.

<Prev in Thread] Current Thread [Next in Thread>