NoPrimaryContentURI

A NoPrimaryContentURI is intentionally not browsable, and in fact offers no content at all. UUIDs, GUIDs, OIDs, tag: URIs, ....

They address WhenBrowsableAndUnambiguousCollide by giving up on browsability.

URNs confuse the issue a little bit: they don't encode network address information into their name, so there must be some resolver system if one is retrieve any content. Such a resolver could potentially be used on any string, so that any string (even those not conforming to the URI syntax) could be used like a URI, and a single URN could lead to different content depending on which resolver was being used. However, this is not the intent of URNs; they are meant to have a single, authoritative mechanism for retrieving content just like URLs.

EtanWexler: That last statement seems mighty bold to this novice. I thought that one of the features of URNs was the possibility of an arbitrarily large number of resolution and retrieval mechanisms. Did I miss the emergence of a contrary consensus?

PeterAnsell: There *could* be any number of retrieval mechanisms, but the defacto web standard of resolving using DNS servers is the actual way that people use, so why not utilise it with URL protocols. That seems to be the reasoning behind the use of completely resolvable identifiers as opposed to purposely unresolvable (without extra resolution rules past DNS) URNs.