On Wed, 2 Jul 2003, Martin Stecher wrote:
Still not completly.
[ snip ]
I am not going to clarify further because your understand was correct,
and because your proposal below is better than my scheme.
If this is all true, wouldn't it be more natural to re-use the
existing sg-id, i.e. first use SGC and already assign a LIST of
services to an ID and then use that ID in the NO message to
negotiate a profile that will be used with that list of services?
What you describe should work and will emphasize that there can be
only one profile for a given transaction, even if there are many
services. The scheme I proposed implied that each service within a
Service Group could have its own profile, which may be true in theory,
but will not work with OCP transactions (profile is application
data/metadata format of a transaction, essentially; it cannot vary
within a transaction). Your scheme seems to be better.
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?
Thanks,
Alex.