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