Subject: RE: NO messages

From: "Martin Stecher" <[email-masked]>
Date: Wed, 2 Jul 2003 23:53:05 +0200

> > > I suggest that we use the "variable" approach:
> > >
> > > 	P: NO ( service-feature1, service-feature2, ... );
> > > 	S: NR service-feature2;
> > > 	P: TS 1 service-group-id2;
> > >
> > > Where "service-feature" is the following structure:
> > >
> > > 	{ service-group-id service profile }
> > >
> > > Where "service-group-id" is an "sg-id:" UNI that can be used in TS
> > > messages if negotiation is successful. "Service" and "profile" are
> > > structures describing callout service and profile 
> information (they
> > > are already defined in OCP).
> >
> > Service-Group-ID defines a list of services. What is then the extra
> > service - the second element in the "service-feature" structure.
> 
> Service-Group-ID is just a variable name. Alone, it does not define
> anything; it plays the same role as the current sg-id does, but it has
> to be a URI so that the receiver of NR message knows what is being
> negotiated (services, and not, say, transport encryption). Recall that
> negotiated features must be structures that start with a "feature ID"
> field.
> 
> The "service" structure defines the service ID and service parameters,
> just like in the current spec. Same for the profile structure.
> 
> The "service-feature" structure simply ties a feature and profile
> together and assigns them an ID (variable name). It is an assignment
> operator that may raise exceptions (failed negotiation), if you will.
> 
> Does this clarify?

Still not completly. Sorry, it may be too late over here ;-)

First you defined
  "service-group-id" is an "sg-id:" UNI
now you wrote 
  "service-group-id" ... same role as ... sg-id, but it has to be a URI
So what is it uni or URI?

Until now sg-id is being used as an uni (number) within a SGC message, where a list of services is bound to that number identifier and that number can be used in a transaction.
So far so good.

Now I understand that NO with service-featureX structure defines a sg-id as uni or URI where a single service and profile are bound to.
And we may introduce the problem of the lifespan of that sg-id.

Is this correct. Please confirm or correct again (I may need an example with real values, sorry).

If this is all true, wouldn't it be more natural to re-use the existing sg-id, i.e. first use SGC and already assign a LIST of services to an ID and then use that ID in the NO message to negotiate a profile that will be used with that list of services?
That will solve the lifespan problem.

[...]

> 
> Note that old-style feature negotiations still can be used. Not all
> negotiations have to be in the above form. Old-style negotiations
> still have connection scope (by default). For example, it is possible
> to do this:
> 
[...]
> 
> Does this address your concerns?

Yes, thanks. That point is clear now.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 2 Jul 2003 17:03:11 -0600 (MDT)

On Wed, 2 Jul 2003, Martin Stecher wrote:

> Still not completly.
> [ snip ]

I am not going to clarify further because your understand was correct,
and because your proposal below is better than my scheme.

> If this is all true, wouldn't it be more natural to re-use the
> existing sg-id, i.e. first use SGC and already assign a LIST of
> services to an ID and then use that ID in the NO message to
> negotiate a profile that will be used with that list of services?

What you describe should work and will emphasize that there can be
only one profile for a given transaction, even if there are many
services. The scheme I proposed implied that each service within a
Service Group could have its own profile, which may be true in theory,
but will not work with OCP transactions (profile is application
data/metadata format of a transaction, essentially; it cannot vary
within a transaction). Your scheme seems to be better.

So let's use your scheme:

	SGC sg-id (services);                // as before

	NO ( profile1, profile2, profile3 )  // as before
	Service-Group: sg-id;                // new parameter

	NR profile2;                         // as before
	...
	TS 1 sg-id;                   // sg-id now required
	...
	SGD sg-id;                           // as before

The first message (SGC) creates a list of services to be
defined/remembered under sg-id Uni identifier (no need for a URI
again). The second two messages (NO/NR) negotiate a single profile for
the defined group of services. If the server does not support a
service in the list, this would be the best time to reject the offer.
The Transaction Start (TS) message used negotiated service group by
its ID. The group is eventually deleted using Service Group Delete
message.

This looks like a combination of the best ideas from your original
proposal (with SwitchProfile command) and my initial reaction to it.
Perhaps we are moving in the right direction. :-)

Is this clear enough or still too messy? Anything else that is broken
or needs to be added?

Thanks,

Alex.