Great. We have it, I guess.
Summary:
- NO and NR have optional named parameter SG, which has an uni value sg-id
- sg-id was previously created by SGC
- If NR is sent in response to NO with SG parameter, NR also needs the same SG
parameter
- TS has mandantory sg-id anonymous parameter; the optional "service" parameter
will go away
Regards
Martin
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Thursday, July 03, 2003 5:13 PM
To: OPES WG
Subject: RE: NO messages
On Thu, 3 Jul 2003, Martin Stecher wrote:
Looks good. It is either it now or it is very close. Let's check for
finetuning:
1. The sequence
P:NO (profile1, profile2, profile3)
Service-Group: sg-id;
S:NR profile2;
negotiates that profile2 will be used in transactions for sg-id.
There is no direct switch to profile2 on the connection.
Correct.
P:NO (profile1, profile2, profile3)
S:NR profile2;
negotiates profile2 on a connection level independend of any
service or tranaction. Switch to profile2 is implied with the
response.
Correct.
We may want to make this more obvious by adding a parameter also
to the NR message that acknolowledgs that there is no direct
profile switch.
I thought about doing that as well. Let's make Service-Group mandatory
in the response. Semantically, it would mean that the responder
understands that we are negotiating service group settings (other than
that, there is no information in that parameter in NR).
Let's also call the parameter SG since it is going to be used a lot.
2. More NO-NR dialogs are introduced with this approach. If one
agent wants to check for several service group profile after each
other, it always needs to wait for a NR message before sending the
next NO message.
In some cases, it is possible to do optimistic negotiation (sending
offers without waiting for responses). We will need to document that
somehow (provide an example?) but the current spec wording should
allow for that.
For example (each line represents a moment in time):
Processor Server
send NO#1
send NO#2
send NO#3 recv NO#1
send NO#4 send NR to NO#1
recv NR to NO#1 recv NO#2
send NO#5 send NR to NO#2
recv NR to NO#2
TS 1 sg-id from NO#5 recv NO#3
... ...
As you can see, there is ordering/matching of NO and NR messages, but
there is no synchronization at all.
Note that the first TS is also optimistic. It may be rejected by the
server if NR to NO#5 is negative. If processor wants to play it safe,
it can wait for the corresponding NR before starting a transaction
using its sg-id.
The rid parameter had been removed from NO/NR before. Do we need
to add it again?
It will not help because there can be only one negotiation taking
place at any given time. This may seem like a contradiction to the
optimistic negotiation statement above, but it is not.
Eventually we can combine 1 and 2 by making sg-id an anonymous
parameter and let it play the role of rid. But is it good to have
that functionality through a second and optional parameter of NO/NR?
Not sure.
We should try to avoid semantic overloading in protocols. Moreover, I
do not think rid helps here (see above). Does the availability of
optimistic negotiation address your concerns?
Alex.
------------------------------------------------------------
This mail has been scanned by debian3-smtp
(WebWasher 4.4 fcs Build 556)
------------------------------------------------------------