On Wed, 2 Jul 2003, Martin Stecher wrote:
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?
One problem to fix would be the fact that the NR sender does not have
a way of finding out whether the recipient (NO sender) is going to use
the ID and for how long. It is not clear when an ID/variable can be
discarded. I believe this problem can be easily solved though.
BTW: When introducing this, we have the first incident of a nesting
level > 1 - list of structures of structures
I am not sure it is the first, but you may be right. As you know, I do
not see that as a big deal from implementation point of view. In fact,
enforcing any limit is extra work for the implementation (or, at
least, for an implementations I can imagine).
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 ;-)
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.
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:
NO ( profileA );
NR profileA;
... profileA is active ...
NO ( service-feature1, service-feature2, ...);
NR service-feature2;
... profileA is active, profile2 available for xactions ...
TS 1 service-feature-id2;
... profileA and profile2 are active ...
TE 1;
... profileA is active, profile2 available for xactions ...
Does this address your concerns?
Thanks,
Alex.