Re: [urn] Re: Proposal: urn:local: namespace for context-scoped identifiers

Howdy,

I agree with Martin that this seems to be a poor fit for the URN
properties.  If something like urn:local:version does not mean the same
thing in all contexts, this doesn't seem like it's a good candidate for
using a URN.

I also agree with him that you could probably create a URI scheme that had
the relevant properties, using something like "local-scope-data" as the
name of the scheme; you could probably also reuse the NSS definitions from
the URN documents as syntax if those truly do match what you want.

I am somewhat skeptical, though, that trying to create  a single scheme to
cover this set of use cases:

* Distributed configs and state machines (urn:local:version, urn:local:pool)
* Configuration artifacts (urn:local:database, urn:local:cache)
* JSON-LD and other graph-shaped documents requiring local entity references
* Multi-tenant systems with per-context identifiers
* Structured data processing by generic agents (including, but not limited
to, AI systems)

is going to be easy or successful.  At best, i think you will have created
a single-bit context marker for an opaque string, with all the relevant
semantics being utterly opaque at the URI layer.  I think that means that
the advantage over this:

Ad-hoc names ("version", “config”) lack URI semantics and machine cues

will be minimal.

If you have a single use case that you believe will drive adoption, I'd
suggest starting with that single protocol context, using a provisional
registration of something like local-scope-data, and see if it gets taken
up.  If it does, you can use that experience to review the initial
definition and propose other contexts of use.

best regards,

Ted Hardie

On Mon, Jan 5, 2026 at 6:13 AM Martin J. Dürst <duerst@it.aoyama.ac.jp>
wrote:

> Hello Melvin, others,
>
> Reading the Introduction to RFC 6963 (urn:example: URN namespace,
> https://www.rfc-editor.org/rfc/rfc6963.html#section-1), and given the
> general idea that URNs should be stable and unique, I'm not sure at all
> that a urn:local: namespace is a good idea.
>
> Your explanations seem to fit much more with a "local:" URI scheme. URI
> schemes have much less restrictions on their semantics than URN
> namespaces. (copying the uri list)
>
> Another issue is that "local" isn't very clearly defined. Many mime
> media types can contain information from different origins; if "local"
> identifiers from different origins get mixed, there may be conflicts.
>
> Regards,   Martin.
>
> On 2026-01-03 04:34, Melvin Carvalho wrote:
> > Hello,
> >
> > I would like to propose a new URN namespace for explicitly context-scoped
> > identifiers:
> >
> > - urn:local:
> >
> > 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.
> >
> > 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."
> >
> > PROPOSAL
> >
> > Define urn:local: as a URN namespace for identifiers whose meaning is
> > explicitly scoped to a containing context.
> >
> > Examples:
> >
> > * urn:local:version — "version" of software or specification
> > * urn:local:db:primary — primary database in this configuration
> > * urn:local:user:alice — user "alice" within this system context
> >
> > SEMANTICS
> >
> > When an agent encounters urn:local:<NSS>:
> >
> > 1. No external resolution MUST be attempted
> > 2. Interpretation MUST be limited to the applicable scope
> >
> > The scope is defined by the containing artifact (e.g., document, message,
> > configuration unit) and/or by an application-specific profile that
> > establishes the processing context.
> >
> > RATIONALE
> >
> > URNs are syntactically absolute identifiers, but this proposal uses that
> > property to provide unambiguous signaling.
> >
> > urn:local: is analogous to relative references in URI processing: the
> > identifier is globally well-formed, while its interpretation is
> > intentionally context-dependent.
> >
> > This follows the precedent of RFC 6963 (urn:example:), which introduced a
> > utility namespace for a narrowly defined, non-resolvable purpose.
> >
> > USE CASES
> >
> > * Distributed configs and state machines (urn:local:version,
> urn:local:pool)
> > * Configuration artifacts (urn:local:database, urn:local:cache)
> > * JSON-LD and other graph-shaped documents requiring local entity
> references
> > * Multi-tenant systems with per-context identifiers
> > * Structured data processing by generic agents (including, but not
> limited
> > to, AI systems)
> >
> > SYNTAX
> >
> > urn:local:<NSS>
> >
> > Where <NSS> follows RFC 8141 rules for Namespace Specific Strings.
> > Hierarchical naming (e.g., urn:local:foo:bar) would be permitted.
> >
> > QUESTIONS FOR THE LIST
> >
> > 1. Is there interest in pursuing a short Internet-Draft for this?
> > 2. Are there existing mechanisms that already address this cleanly?
> > 3. Any concerns with the local NID or the proposed semantics?
> >
> > If there is interest, I am happy to draft a specification.
> >
> > Best regards,
> >
> > Melvin Carvalho
> >
> > References:
> > RFC 8141: Uniform Resource Names (URNs)
> > RFC 6963: A URN Namespace for Examples (urn:example:)
> >
> >
> > _______________________________________________
> > urn mailing list -- urn@ietf.org
> > To unsubscribe send an email to urn-leave@ietf.org
>
> _______________________________________________
> urn mailing list -- urn@ietf.org
> To unsubscribe send an email to urn-leave@ietf.org
>