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.