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

Hi!

Agreeing with the other responses, I note that there exists a URI scheme that 
has local(ish) semantics, viz file:.

Despite working with URIs for many years, it was relatively late in the day that 
I noticed the way that the authority part of file: URIs is defined:

    A file URL takes the form:

        file://<host>/<path>

    where <host> is the fully qualified domain name of the system on
    which the <path> is accessible, and <path> is a hierarchical
    directory path of the form <directory>/<directory>/.../<name>.

-- https://datatracker.ietf.org/doc/html/rfc1738#section-3.10

(and similar in https://datatracker.ietf.org/doc/html/rfc8089#section-2)


I felt this was a helpful aspect as it provides a way to provide a globally 
unique form of URI without guaranteeing accessibility, while allowing a 
convenient "local reference" form.

Just sayin'

#g



On 05/01/2026 11:14, Ted Hardie wrote:
> 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 <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     Hello Melvin, others,
> 
>     Reading the Introduction to RFC 6963 (urn:example: URN namespace,
>     https://www.rfc-editor.org/rfc/rfc6963.html#section-1
>     <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 -- [email protected] <mailto:[email protected]>
>      > To unsubscribe send an email to [email protected]
>     <mailto:[email protected]>
> 
>     _______________________________________________
>     urn mailing list -- [email protected] <mailto:[email protected]>
>     To unsubscribe send an email to [email protected] <mailto:[email protected]>
> 

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]