A Decentralised, Namespaced URI Scheme for Resource Identifiers

Root
Home
Back

Request for Comments: #1

Status: DRAFT

Author: snit

Date: August 2025

A Decentralised, Namespaced URI Scheme for Resource Identifiers

Abstract

This specification defines a new Uniform Resource Identifier(URI) scheme, ns, as an alternative scheme to that of Uniform Resource Names(URN). The intent for this new scheme is to provide a decentralised means to identify namespaced resources. This document details the canonical syntax for the new scheme, and the means by which namespaces may be defined and used.

Table of Contents

1. Introduction

A Uniform Resource Name(URN) is a Uniform Resource Identifier(URI) which is designed to be a persistent, location-independent resource identifier. Unfortunately, URNs rely heavily on a centralised namespace registry to consistently group resources and prevent conflicts. As there is no means defined within the specification to create new namespaces, other than by registering with a specific centralised authority, URNs are unfortunately limited solely to organisations with the resources and patience to go through the proper procedures to register a namespace. As a result, only around one hundred namespaces are currently registered, many of which have very little use outside of specific organisations or fields, which may have contributed to URNs' failure to gain widespread adoption.

As an alternative, many areas in which namespaces are used, such as XML namespaces, rely on HTTP URIs like http://www.w3.org/1999/xhtml. This is an unsatisfactory solution, and often leads to confusion for beginners. In first learning how namespaces function, many implicitly assume that all HTTP URIs resolve to a specific resource, and carry such assumptions over to the URIs used in namespaces. Alas, the URI may be anything whatsoever, and it need not resolve to anything at all. Ideally, there would exist a URI scheme which identifies namespaced resources in such a decentralised manner as HTTP URIs, whilst simultaneously providing no implication of resolvability. This is where the namespace URI scheme comes in.

The namespace URI scheme sacrifices the location-independent, and, indeed, temporal-independent, nature of URNs in favor of decentralised namespacing. With namespace URIs, users point to a location they control on a given date, allowing them to specify any arbitrary namespace they would like, just as in the HTTP URIs from earlier, but without the need for a central registry of namespaces. For example, the following URI could theoretically be used to identify the current section of this document:

ns:isekai.rocks:2025:rfc:1

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Grammar

The syntax for a namespace URI is defined via the following ABNF grammar:

nsURI = "ns:" [ location ":" date ":" ] namespace [ ":" resource ]

location  = host                     ; see: RFC3986
date      = year [ month [ day ] ]
namespace = 1*ipchar                 ; see: RFC3987
resource  = 1*( ipchar / "/" / "?" ) ; see: RFC3987

year  = 4DIGIT
month = 2DIGIT
day   = 2DIGIT

The location is case-insensitive, but the namespace and resource components are not. A pair of namespaces or resources that differ only in capitalisation MUST NOT be considered equal.

The location and date MUST consist of ASCII characters, International domain names MUST be punycode-encoded. The namespace and resource MAY be percent-encoded ASCII, or UTF-8 directly. A URI which has been percent-encoded from Unicode MUST be considered equal to its original form.

Section 4 describes a means by which long namespace URIs may be shortened within a given context. When the location and date components are omitted, the namespace MUST refer to a shorthand form.

3.1. Syntax Components

In general, the namespace URI consists of the following components. Details on each are below.

ns:::[:]

The location consists of a host component as defined in RFC3986. When creating a new namespace, the author MUST own the location it falls under, or have prior permission from those that do.

The date component MUST refer to a period of time in which the namespace author owns/owned, or had permission from the owners of, the location component. The date MAY be in the past, but MUST NOT be in the future. Date components refer to the entire time range for which they are specified; that is, a date of 20250828 refers to the entire day of August 28th, 2025, 202508 refers to the entire month, and 2025 refers to the entire year. Less specific dates SHALL NOT be considered equal to more specific dates that fall within their range.

The namespace is a collection of common resources. The namespace MAY be identified directly, by excluding the resource component. The namespace SHALL be unique for a given location and date; if changes to its definition are needed, at least one of the location, date, or namespace MUST be altered.

The resource is a specific object or concept identified within a namespace. The expected structure of a resource for a given namespace is not specified here. The structure SHALL be specified when the namespace is created. So long as the URI remains the same, the resource identified by the URI MUST NOT change. A single URI MUST NOT refer to multiple distinct resources, but a single resource MAY be referred to by multiple URIs.

3.2. Structured Resources

It is possible that namespace URIs may be encountered which appear to be hierarchical in nature:

ns:example.com:2025:taxonomy:animalia:chordata:mammalia:primates:hominidae:homo:sapiens

Upon receiving such an arbitrary URI, it MUST NOT be assumed to have any particular structure beyond a namespace, and an opaque resource string.

taxonomy | animalia:chordata:mammalia:primates:hominidae:homo:sapiens

If any structure is assumed, such as a hierarchy, attempts to then parse:

ns:example.com:2025:tags:light-novel,fiction,isekai,year:>=2014

would likely result in:

tags | (light-novel,fiction,isekai,year | >=2014)

rather than the correct tag query structure:

tags | (light-novel | fiction | isekai | year:>=2014)

Users or software MAY attempt to parse and destructure a namespace URI's resource, but they MUST be aware of and implement the namespace's specification in doing so.

4. Namespace Shorthand

Namespace URIs may get long and unwieldy quickly, especially when nested (see: Section 5). Users and software MAY define shorthand for a given namespace. The shorthand MUST be of the form:

ns:[:]

The identifier component SHOULD include at least the location, date, and namespace components. The identifier MAY include a static prefix of the resource component. It is NOT RECOMMENDED that shorthand forms be defined for a complete resource, rather than a prefix.

The mechanism by which such shorthand is defined in a given context is unspecified. Shorthand forms SHOULD be explicitly defined before use, and unknown forms SHOULD be rejected. URIs which use shorthand forms SHOULD be canonicalised before exiting the current context, such as when being transmitted over the network, or passed into external software. Shorthand forms SHALL NOT be assumed to be unique. If two or more namespaces are found to use the same shorthand in a given context, the shorthand(s) MUST be disambiguated

5. Namespace Nesting

One aspect in which this specification is limited is that the location component is restricted to domain names and literal IP addresses. Should this be expanded? Not everyone has a domain, or a static IP address, in which they can create the namespaces they might need. It might be worth expanding the location to include one or more of email, JID, UUID, or PGP key. The three excluding UUID would allow namespaces to be created under a unique user identitiy, although email and JID would have to be disambiguated if both included. The UUID is unwieldy for human use, but perhaps it could be useful in the automated creation of ephemeral namespaces; however, the use-case for this is yet unclear to the author of this document.

Even if more options are provided, such options are not defined in a decentralised manner. Each addition would have to be added to this specification manually, with the approval of a central party. This is certainly not an ideal situation.

A workaround to the limitations of the location component is by defining namespaces whose resource component is itself a namespace URI, minus the scheme. For example, if a user wishes to create namespaces under their email address, they could define the following namespace:

ns:example.com:2025:email

Which expects a resource formatted the same as the usual namespace URI, except where the location is an email address instead of a domain/IP:

ns:example.com:2025:email:user@example.com:2025:myns

The biggest disadvantage of this mechanism as it stands is that someone might define a namespace which allows the use of XMPP JIDs, but do so under their email address. Such scenarios quickly get out of hand, even when intentionally trying to keep the URI short:

ns:example.com:2025:email:alice@example.com:2025:xmpp:bob@example.com:2025:myns

Of course, the shorthand forms defined in Section 4 can be used for convenience. If the following mappings are defined:

ns:example.com:2025:email        ->  email
ns:email:alice@example.com:xmpp  ->  xmpp

then the earlier example shrinks to half its previous size:

ns:xmpp:bob@example.com:2025:myns

6. Equality

Two namespace URIs are considered equal if and only if they consist of the same codepoints when using the same character encodings, after the location and date are converted to lowercase, and after the URIs are both either entirely percent-encoded or decoded.

7. Resolution

Namespace URIs are primarily a way to identify a resource, with no expectation of resolvability. Users and software MUST NOT assume an arbitrary namespace URI resolves to any particular location. A standard by which a particular namespace is used to resolve the location of the identified resource MAY be specified, and users of the namespace MAY attempt to resolve URIs within the namespace; knowledge and/or implementation of the specification is REQUIRED before any attempts to resolve a namespace URI are made.

8. Security Considerations

No means is provided by which ownership of a namespace's date location on the given date can be validated or verified. Users should do their own research before using a namespace, and prefer the usage of namespaces from parties they trust.

The lack of central authority on namespaces means that it is up to the users of a namespace to use it correctly and accurately. It is not hard at all to use a namespace incorrectly, whether by ignorance or malice. Users or software which have awareness of the resource structure for one or more namespaces MUST be prepared to deal with malformed URIs. Any software or users with no such awareness MUST NOT attempt to validate the resource, and MUST treat it as an opaque string.

When it comes to shorthand form definitions, each form in use has to be manually defined within each context. If users are not careful, especially during transmission, namespacing conflicts could arise. If a specific subset of shorthand forms are used frequently, it may be worth including them by default in most contexts. No such defaults will be defined in this document.

9. Examples

The use-case for the namespace URI scheme heavily overlaps with the use-case for the existing URN and tag URI schemes; indeed, namespace URIs were explicitly created as an alternative and improvement upon these schemes. This section demonstrates a few such use-cases.

9.1. Atom Feeds

Each entry in an Atom feed contains a unique, immutable identifier, which forever identifies a resource even when its name, content, and location change. A URN would have been a perfect way to encode this, but namespace centralisation makes it impossible, unless all entries are identified strictly using UUIDs. Namespace URIs are the perfect alternative in such a situation. To identify this specification in an Atom feed, one might use:

ns:isekai.rocks:2025:rfc:1

which can be guaranteed to forever refer to this specification, whereas the link to the specification:

A Decentralised, Namespaced URI Scheme for Resource Identifiers

could later be moved anywhere else, or deleted entirely at any point.

9.2. XML Namespaces

As discussed in the introduction, a possible use for namespace URIs is in referencing XML namespace specifications. Most XML namespaces appear to use HTTP URIs of a specific format, with the implicit agreement that such URIs are to be treated less like URLs and more like URNs. New users of XML often falsely assume that the URI in an XML namespace points to a location first and foremost, and that it could be anything, so long as it resolves to the correct data; this assumption leads many to try changing the HTTP scheme to HTTPS in an effort to better comply with modern security standards, not realising that the exact string itself, not the location it points to, is what carries the semantics.

Instead, namespace URIs could be used with a very similar structure, but which have no implication of or ability to resolve to a particular location, as in the following (fictional) example:

http://www.w3.org/1999/xhtml
ns:www.w3.org:1999:xhtml

9.3. Alternative to Tag URIs

The advantage of namespace URIs over URNs has been the main focus of this document, but another URI scheme, tag URIs, fills a very similar niche. This section highlights some potential shortcomings of tag URIs, and how namespace URIs may be used to address these issues.

Tag URIs are expected to be purely ASCII. For many purposes and many people, this unnecessarily restricts the number of languages which may be conveniently expressed, and renders any URI which wishes to use Unicode anyways entirely unreadable in the form of percent-encoded URIs. If the use for the URI expects to frequently encounter non-ASCII text, a namespace URI may be a much better fit, as a namespace URI follows the IRI specification and allows most Unicode codepoints.

When defining a tag using a tag URI, the authority tags may fall under are limited solely to domain names and email addresses; Namespace URIs, on the other hand, are restricted to domain names and literal IP addresses. Out of the box, namespace URIs make it easier for users on decentralised networks that rely on literal IP addresses, like Yggdrasil, to define namespaces, without reliance on current heavily-centralised domain name systems. Namespace URIs forgo native support for use of email addresses, but through the use of nested namespaces as described in Section 5, possibly in conjunction with Section 4's shorthand forms, it is entirely possible to add support not only for email addresses, but also to XMPP JIDs, physical addresses, UUIDs, cryptographic identities, and so on. In theory, tag URIs may also have such nesting, but the lack of standardised shorthand forms means that URIs could become unusably long incredibly quickly.

10. References

BCP 14
RFC2119 - Key words for use in RFCs to Indicate Requirement Levels
RFC2234 - Augmented BNF for Syntax Specifications: ABNF
RFC3986 - Uniform Resource Identifier (URI): Generic Syntax
RFC3987 - Internationalized Resource Identifiers (IRIs)
RFC4151 - The 'tag' URI Scheme
RFC8141 - Uniform Resource Names (URNs)
RFC8174 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

11. Acknowledgements

The majority of this specification would not have been possible without so much effort put into previous RFCs by far smarter people. In particular, RFC4151, which covers a somewhat similar use-case as this document, and which was only discovered halfway through writing, was a massive source of inspiration for the finer details of this specification.