Hi On Tue, 21 Jan 2014, John MacAuley wrote:
I got nervous when hans explained the parsing from the right. It seems we are giving up on agreement of the format parsing from the left, but still forcing a specific format when parsing from the right. I understanding what you are trying to do, but surely we can agree on a full format that can provide a consistently parsable URN?
Well, your suggestion assumes that it starts with urn:ogf:network:... That might be okay, but it is not assumption that is required for us as such.
If the IETF can I can only assume we are smart enough to do it as well.
Not sure what you are referring to here.
I don't really see a need for all the other stuff. It it just rules without a good reason for it. I mean, why even bother writing all the stuff down and making the standards bigger without a real need?
My issue is incompleteness of specification. You need two URN formats specified for this to work:
1. The Network Id must be parsed from the NML Topology Id for you to determine the available networks.
Or have another mechanism to discover the networks/topologies.
2. The STP Id must be parsed into the Network Id and the Local Id.
Yep.
Why would we specify the format of only two of the identifiers in the specification when we can easily specify them all?
Because we only need the two. I don't see a reason to standardise something we don't need to standardise.
What we did was to restrict the <stpId> such that there cannot be any ':' characters in it, and then we split from the back.
Not an unreasonable restriction, but both the networkId and localId will need to be free of colons.
Ehh... AFAICT, only the local id needs to be free of colons.
Your name is also only parsable given the context of the name, where as the proposal here provide naming context in the name its self.
Yes, but there is no need for that. I also assume that people/implementations are sane enough to use the right identifiers in the right place. Trying to provide explicit context for all identifiers doesn't prevent anything anyway.
NORDUnet, SURFnet, and GEANT have made up their mind and gone with the split from the back here. It is NOT a permanent solution. But the suggestion here doesn't really feel like it either.
Understood, but I would like a solution agreed and documented for standard, unless of course we believe there should be nothing documented in the standard and we are free to make it deployment specific.
Yes.
If we do this, could we use lowercase all the way please. We are not doing Java here :-).
It is CamelCase, but comment is understood.
I think what I intended to say is that case comparison with urns is a mess, due to the case-insensitivity of the initialy part and potential case sensisitivity in the latter part. Having all lowercase is just much less brittle. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet