Can you give an example of a URN for private-use
Asked Answered
W

1

8

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?

Wain answered 19/5, 2015 at 14:32 Comment(0)
G
8

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 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.

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).

Glyceryl answered 20/5, 2015 at 1:2 Comment(1)
I think this helps, thanks. I'll wait for more votes. URNs look like a good choice for a programming language-agnostic fully-qualified name. So rather than endeavouring to be unique, I should endeavour to keep them private.Wain

© 2022 - 2024 — McMap. All rights reserved.