[urn] Re: Proposal: urn:local: namespace for context-s coped identifiers
[email protected] (Dale R. Worley) Mon, 05 Jan 2026 10:29:37 -0500
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <[email protected]> |
Melvin Carvalho <[email protected]> writes: > I would like to propose a new URN namespace for explicitly context-scoped > identifiers: > > - urn:local: The first sentence of section 1 of RFC 8141, which defines the URN scheme, is A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) [RFC3986] that is assigned ... with the intent that the URN will be a persistent, location-independent resource identifier. So you can't make URNs whose meaning is context-dependent. > PROBLEM > > In many systems that process structured data (e.g., JSON-LD documents, > ledgers, configuration artifacts, protocol messages), there is a recurring > need for identifiers that are intentionally local to a defined scope. Though it seems quite possible to define a URI scheme for this sort of purpose. I am reminded of the "cid" scheme used to refer to component parts of a MIME multipart within the multipart itself. > Existing approaches have drawbacks: > > * http(s) URLs imply dereferenceability, even when none is intended > * did: methods require resolvers and global identity semantics > * RDF blank nodes (_:) are RDF-specific and opaque outside that ecosystem > * urn:example: is reserved for documentation only (RFC 6963) > * Ad-hoc names ("version", “config”) lack URI semantics and machine cues > > What is missing is a clear, protocol-agnostic way to signal "this > identifier is local by design." The interpretation of such an identifier will depend on the containing object but also on what processing that object is subject to, that is, the object's type. So there's no real burden if each object type has its own ad-hoc identifier scheme. Where a URI scheme gains value is if the local identifier can be used in a place where some other URI scheme might appear. An example is use of a "cid" URI in an HTML component of a MIME multipart as the SRC of an IMG tag: That specifies that the image is in some other component of the multipart, but if that same SRC attribute contains an html: URI, the image has to be fetched with HTTP. "cid" URIs (RFC 2392) have roughly the right semantics, but their syntax is restricted: the rest of the URI has to look like an e-mail address. Dale _______________________________________________ urn mailing list -- [email protected] To unsubscribe send an email to [email protected]