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

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 -- [email protected]
To unsubscribe send an email to [email protected]