Subject: RE: OCP Core: one service, two profiles

From: "Martin Stecher" <[email-masked]>
Date: Sat, 25 Oct 2003 08:41:14 +0200

You are right. It will produce problems.

Highlander principle: There can only be one!

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]]
> Sent: Saturday, October 25, 2003 12:03 AM
> To: Martin Stecher
> Cc: OPES WG (E-Mail)
> Subject: RE: OCP Core: one service, two profiles
> 
> 
> On Fri, 24 Oct 2003, Martin Stecher wrote:
> 
> > > We do not explicitly allow or prohibit this, right? Should I
> > > explicitly prohibit in the Core?
> >
> > Maybe we should add to OCP core that only the last negotiated
> > profile for a service group is valid.
> 
> Meaning that profile negotiation with SG parameter selects the current
> profile? That is, the profile can be changed later? I am not sure I
> like this because renegotiation would be messy when there are pending
> transactions using the same service group but with the old profile.
> The implementation would no longer be able to identify SG properties
> based on sg-id. Do you see what I am getting at?
> 
> Alex.
> 
> 
> ------------------------------------------------------------
> This mail has been scanned by debian3-smtp
> (WebWasher 4.4.1 Build 688)
> ------------------------------------------------------------
>

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 25 Oct 2003 19:01:22 -0600 (MDT)

> 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.