Hi John On Mon, 5 Sep 2011, John MacAuley wrote:
On Fri, 2 Sep 2011, John MacAuley wrote:
True, but one could also read the documentation which states "correlationId - An identifier provided by the requesting NSA used to correlate to an asynchronous response from the responder. It is recommended that a Universally Unique Identifier (UUID) URN as per IETF RFC 4122 be used as a globally unique value." :-)
OK, I actually missed the URN part.
This is not a UUID (correlationId is a uuidType). It is a URI/URN, which happens to by a UUID. Also there is a slew of ways to represent UUIDs. I do not see the reason for forcing the usage of UUIDs. Given the constraints I would have choosen UUIDs myself, but forcing a specific technology into the spec. seems a bit silly. A string would do fine as type.
This comment I do not understand.
UUID: 5c731826-d7ba-11e0-b36f-00144f20a8d2 URN: urn:uuid:5c731826-d7ba-11e0-b36f-00144f20a8d2
We are using names spaces throughout the specification to provide context to a field. For example, the STP, NSA, and global reservation Id all use them so why not be consistent throughout the message? In addition, we have forced specific formats and naming standards on all the fields.
The question is "why", not "why not". I simply do not see what value the URNs provides, besides "Hey, I know URNs, we should use them".
UUID happens to be a globally accepted standard for generating unique identifiers, We needed one, so why not use the standard everyone else in the computer industry uses :-)
I do not mind UUIDs, I've used them before and will probably use them again. But technology tends to change a lot, and in some years there might be something else. Put the restriction for generating ids there, but keep there spec. free from specific technologies in any way possible. The UUID can be in an appendix with implementation recommendations.
Are we just using URNs because it is possible? I have a hard time seeing what value they add here? (they do not provide a global namespace).
Is your main issue that I prefixed the UUID with "urn:uuid" or are you fundamentally against enforcement of a unique identifier in the field?
The issue is that URN just adds a prefix here. They do nothing to ensure uniqueness, as a field must explicitely begin with "urn:ogf...". The last part is the implementation name, which is the only place there is a real difference, and despite us using URNs we still have to ensure uniqueness there. As I see it, it is a solution to a problem we do not have. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.