There are two ways to support what you want: better profile scope
management (your proposal above) and profile variables (similar to
current service group variables). The scope approach means that you
cannot have two concurrent transactions on the same connection using
different profiles (or, at least, it would look awkward if
SwitchProfile applies to the immediate TS only). The variable approach
allows for concurrent transactions with different profiles at the
increased risk of leaking variables and creating a DoS (allocating and
not destroying "a lot of" variables as a result of a bug or on
purpose).
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.
BTW: When introducing this, we have the first incident of a nesting
level > 1 - list of structures of structures
If you accept the above, I would also suggest that sg-id parameter of
the Transaction Start (TS) message is made mandatory. This will allow
agents to negotiate acceptable services before they are used in any
transaction.
I like the idea of binding a profile to a service group and binding it
to a transaction. I also like that we make service groups mandantory
and so remove the single profile parameter. It's good to have only
one clear way to go, always create and use a service group even if
you only have a single service to use.
Let's make it so, if the objection below does not break the concept ;-)
As you can see, both proposals are similar. The only big difference is
that the variable approach lacks the SwitchProfile message.
Note that the variable approach does not allow to select a particular
profile outside of the transaction scope. However, since OCP Core
requires that unknown messages are ignored, it is still possible to
customize exchange outside of transaction boundaries without losing
interoperability.
That may be insufficent.
If an OCP extension defines new methods that are to be used in a new
form of a dialog, one agent may send a request and waits for a response.
If it is unclear whether that extension is supported, the agent does not
know whether the other peer is still handling that request or ignored it.
How long to wait for a response?
Using a SwitchProfile message which is defined in the core will result
in a connection end with error message if the selected profile is not
supported.
Maybe we can get around that extra message if the service-feature structure
can also describe the global, connection-wide, non-service-bound case?
As said above, I do not fully understand the proposed structure yet.
Martin