Ronald van der Pol wrote:
> After today's discussion we seem to have a couple of proposals:
>
> urn:glif:<domain>:<local>
> urn:ogf:network:<domain>:<local>
> urn:ogf:network:domain=<domain>:key1=<value1>:key2=<value2>:...:<local>
> urn:ogf:network:<domain>:localkey1=<localvalue1>:...
>
> question:
> Do we want a scheme were a lightpath can have multiple globally unique IDs?
> This would be the case where these are IDs for the same lightpath:
> urn:ogf:network:domain=<domain>:key1=<value1>:key2=<value2>:...:<local>
> urn:ogf:network:key2=<value2>:...:key1=<value1>:domain=<domain>:<local>
> urn:ogf:network:key2=<value2>:domain=<domain>:...:key1=<value1>:<local>
>
> I don't like this. This won't work in real life.
I concur. The idea of identifier is that it is unique. This isn't.
This would be very bad. One solution that was proposed in the hallway
was that the keys MUST have a specific order.
That said, I have four more objections against NURN, all stemming from
the fact that a NURN is in fact not an identifier. It is a list of
properties that happens to uniquely identify something. But it is not a
name.
> question:
> Should we (GOLE operators) start using a simplified form of naming asap
> in trouble tickets? We could start using <domain>:<local> now in trouble
> tickets. When we need it in a web services context we can stick a urn
> in front of it. We can decide on a urn later.
I would highly recommend this. This seems like a very clean identifier.
Later on other groups can decide to render this identifier in a certain
way when transmitted in a certain protocol if they want (e.g. as
urn:glif:<domain>:<local> or
urn:ogf:network:domain=<domain>:localid=<local> or
urn:ogf:network:domain=<domain>:localid=<local>:type=lightpath etc.)
However, this is then part of the representation, not of the identifier.
For example, I even appreciate NURN as a compact rendering of
properties; it's just not the same as the name/identifier anymore.
Regards,
Freek Dijkstra
