According to Wikipedia,
urn:<NID>:<NSS>
The leading urn: sequence is case-insensitive.
<NID>
is the namespace identifier, which determines the syntactic interpretation of<NSS>
, the namespace-specific string. The functional requirements for uniform resource names are described in RFC 1737.[5]
Source: http://en.wikipedia.org/wiki/Uniform_resource_name
And then it goes on to say that the experimental NID is prefixed X-
but then says:
RFC 6648 deprecates the use of "X-" notation for new ID names, but makes no recommendation on substituting existing "X-" names, and does not override existing specifications that require the use of "X-". [7]
So now what?
If I want to make-up a URN for some identifiers in a private system, how do I name them correctly?
My gut says that the x-
prefix doesn't gain anything because two developers could just as easily start using urn:x-foo
and it wouldn't be any different to if they'd just chosen urn:foo
, except perhaps that it'd be clear that it wasn't officially registered with IANA.
So we should just try and make up something unique and make best endeavors to check that it is. Right?
As far as I know, RFC 6648 does not make experimental NIDs (as defined by RFC 3406) invalid.
The draft for the next RFC about URNs (currently) has, following the recommendations from RFC 6648, removed experimental NIDs (making URNs that use x-
invalid).
My gut says that the
x-
prefix doesn't gain anything because two developers could just as easily start usingurn:x-foo
and it wouldn't be any different to if they'd just chosenurn:foo
, except perhaps that it'd be clear that it wasn't officially registered with IANA.
Well, RFC 3406 defines that
No provision is made for avoiding collision of experimental NIDs
and that they are
intended for use within internal or limited experimental contexts.
So in the first place, you are not supposed to use experimental NIDs in such a way that other parties (that don’t know about your use/definition of these experimental NIDs) would come across them.
Or in other words: Collisions of experimental NIDs should be unproblematic, as each party should use them only internally or experimentally, and should not expect to be able to do anything useful with experimental NIDs not under their control.
So …
If you want to use URNs only for private purposes, you may still use X-
NIDs (by following RFC 3406), until it gets obsoleted by the new RFC. Alternatively, you could mint URNs from the example
NID.
If you want to use URNs publicly/seriously, you want them to be unique (avoiding collisions) and defined (making them useful to other authors and consumers). That’s the whole point of URNs, right? To achieve this, you have to register your NID.
If you don’t want to register, don’t use URNs. There are many other URI schemes available (e.g., Tag URIs come to mind).