Subject: RE: NO messages

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

> 
> So let's use your scheme:
> 
> 	SGC sg-id (services);                // as before
> 
> 	NO ( profile1, profile2, profile3 )  // as before
> 	Service-Group: sg-id;                // new parameter
> 
> 	NR profile2;                         // as before
> 	...
> 	TS 1 sg-id;                   // sg-id now required
> 	...
> 	SGD sg-id;                           // as before
> 
> The first message (SGC) creates a list of services to be
> defined/remembered under sg-id Uni identifier (no need for a URI
> again). The second two messages (NO/NR) negotiate a single profile for
> the defined group of services. If the server does not support a
> service in the list, this would be the best time to reject the offer.
> The Transaction Start (TS) message used negotiated service group by
> its ID. The group is eventually deleted using Service Group Delete
> message.
> 
> This looks like a combination of the best ideas from your original
> proposal (with SwitchProfile command) and my initial reaction to it.
> Perhaps we are moving in the right direction. :-)
> 
> 
> Is this clear enough or still too messy? Anything else that is broken
> or needs to be added?
> 

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

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.
   The rid parameter had been removed from NO/NR before. Do we need to add it again?

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.

What do you think?

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 3 Jul 2003 09:13:20 -0600 (MDT)

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
>    negotiates that profile2 will be used in transactions for sg-id.
>    There is no direct switch to profile2 on the connection.

Correct.

>    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

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.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 3 Jul 2003 09:13:20 -0600 (MDT)

Correct.

Correct.

	Processor                   Server
	send NO#1
	send NO#2
	send NO#3                   recv NO#1

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 3 Jul 2003 09:13:20 -0600 (MDT)

Correct.

Correct.

	Processor                   Server
	send NO#1
	send NO#2
	send NO#3                   recv NO#1

Alex.