On Wed, 22 Aug 2012, John MacAuley wrote:
LOL - I argued endlessly about this and gave up.
I would rather have the provider return the new connectionId
So, 3 for solution B :-).
So how does the UUID not work? You just need it to. E unique within the provider NSA to solve your problem do you not?
If you let the client generate the connection id, you have two choices: 1. Scope the connection id within the identity of requester nsa This guaranties that the connection id is not taken, assuming the client have not specified the connection id before (something might have gone wrong and it tried to reserve again). This is what we have today. Unfortunately referencing to connections created by other NSAs are rather tricky / messy. 2. Let the client use its specified connections id if it is not taken (solution A). In theory, UUIDs should work here assuming everything uses them correctly. However as we have a protocol, I just see the UUID as a format, and not as a way of generating non-clashing identifiers. There are some slighly tricky problems concerning if it is allowed to reuse connection ids for re-reservation with this, but nothing major. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet