I think this discussion is missing the original requirements that led to “urn:” https://tools.ietf.org/html/rfc1737 “Functional Requirements for Uniform Resource Names”. > >That conversation predates the mistake of introducing the false >distinction between URLs and URNs. The distinction between URLs and URNs is not merely that one is a “location” and the other is a “name” in some abstract sense. I think the practical distinction between “urn:<nsid>:<blah>” and “<nsid>:<blah>” is that the “urn:” form provides some useful information in the cases where <nsid> identifies an externally, non-algorithmic organization that maintains the authority of deciding when two expressions are “the same” (see paragraph 2 of section 5 of RFC 1737). Whether two streams of data, concepts, protocol parameters, get the same ISSN, ISBN, UPC code, RFC number, MIME type, etc. and thus are considered “the same” depend on an identified “naming authority”; the nsid identifies the naming authority. With this perspective, urn:uuid: was a mistake, since there is no uuid naming authority to resolve the question. So while I agree that in many cases, the initial four characters “urn:” are unnecessary, at least in some situations, the prefix is useful in pointing out that no resolution service that ultimately doesn’t consult the identified naming authority for dispute resolution can be authoritative. Larry — http://larry.masinter.net