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

Hi Melvin,

Thanks for continuing to engage in the process.  I think part of my
personal reluctance to start work in this direction is that "local" does
not mean the same thing in all the contexts you cited as motivating
examples.  Further, the construction of what "local" means is very much in
the eye of the beholder in some of these cases, which makes it difficult
for all users of the construct to be sure that they are using it in the
same way as it was intended.

RFC 3986 starts out defining URIs with this text:

A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource.

If the same compact sequence of characters doesn't identify the same
abstract or physical resource in all cases, you have to rely on additional
semantics, which are often scheme-specific.  By pulling "local" into the
scheme, you have lost one way to move the additional semantics along with
the URI.

You might find it useful to think instead about a special form of
authority, like "localhost", and see whether a common form of that special
authority can be used in combination with usage-specific URI schemes.
There's some discussion of that in the overview section of RFC 3986:

   URIs have a global scope and are interpreted consistently regardless
   of context, though the result of that interpretation may be in
   relation to the end-user's context.  For example, "http://localhost/"
   has the same interpretation for every user of that reference, even
   though the network interface corresponding to "localhost" may be
   different for each end-user: interpretation is independent of access.
   However, an action made on the basis of that reference will take
   place in relation to the end-user's context, which implies that an
   action intended to refer to a globally unique thing must use a URI
   that distinguishes that resource from all other things.  URIs that
   identify in relation to the end-user's local context should only be
   used when the context itself is a defining aspect of the resource,
   such as when an on-line help manual refers to a file on the end-
   user's file system (e.g., "file:///etc/hosts").

That might be a good place to start re-thinking this approach.  I'm
honestly not sure how well it will end up fitting in all your use cases,
but I strongly suspect it's a better place to start than defining a "local"
URI scheme.

best regards,

Ted Hardie


On Mon, Jan 26, 2026 at 2:04 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> po 5. 1. 2026 v 12:14 odesílatel Ted Hardie <ted.ietf@gmail.com> napsal:
>
>> 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
>>
>
> Thank you all for the thoughtful feedback. I agree with the conclusion
> that URN semantics are not an ideal fit for context-scoped identifiers, and
> that a URI scheme may be the more appropriate direction.
>
> I wanted to briefly share an observation that motivated the original
> proposal and may be relevant to whether a URI scheme is worth pursuing.
>
> In two separate, unprompted cases, different large language models
> generating structured data independently produced identifiers of the form
> `urn:local:` and, in another instance, `local://`. When asked to explain,
> the models described these as an intuitive way to signal "local by design".
> I appreciate we are somewhat in the wild west in this regard still. But it
> is likely that engineering on the internet will increasingly use such tools.
>
> I don’t present this as authoritative input, LLMs are not standards
> bodies. However, the convergent emergence is interesting: systems trained
> on existing URI/URN specifications nonetheless reach for a “local”
> identifier when faced with this gap.
>
> This suggests:
> 1. There is a real unmet need for signaling context-scoped identity
> 2. “local” is an intuitive and discoverable name for that concept
> 3. Such identifiers are likely to appear in generated data regardless of
> formal standardization
>
> Given the feedback in this thread, would there be interest in exploring
> `local:` as a URI scheme (not URN), incorporating the constraints and
> concerns raised here?
>
> Best regards,
> Melvin
>
>
>>
>> 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
>>>
>>