ietf-openproxy
[Top] [All Lists]

RE: NO messages

2003-07-03 07:30:27


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




<Prev in Thread] Current Thread [Next in Thread>