Subject: RE: NO messages

From: "Martin Stecher" <[email-masked]>
Date: Wed, 2 Jul 2003 20:58:16 +0200

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

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 2 Jul 2003 13:38:50 -0600 (MDT)

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

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