Subject: RE: NO messages

From: "Martin Stecher" <[email-masked]>
Date: Thu, 3 Jul 2003 18:01:16 +0200

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:[email-masked]]
> 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)
> ------------------------------------------------------------
>