RFC 2611

URN Namespace Definition Mechanisms

📅 published June 1999, from ietf

RFC 2611: URN Namespace Definition Mechanisms 🎀

Okay bestie, this one is from June 1999 and it's a Best Current Practice (that's BCP 33 🧚), which means it's the community's recommended way of doing things. It's written by four people: L. Daigle (Thinking Cat Enterprises), D. van Gulik (ISIS/CEO, JRC Ispra), R. Iannella (DSTC Pty Ltd), and P. Faltstrom (Tele2/Swipnet). It came out through the Network Working Group, and the title block doesn't list anything it obsoletes or updates, so it stands on its own 💅.

Status of This Memo ✨

This doc is a Best Current Practice for the Internet community, and it's openly asking for discussion and suggestions for improvements. Distribution of it is unlimited, so share away 🦋

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌸

The URN working group came up with a syntax for Uniform Resource Names (URNs) [RFC2141], plus some proposed ways to resolve them and use them in Internet applications ([RFC2168, RFC2169]). The whole thing is built on the idea of individual "namespaces" inside the URN structure. Beyond the proof-of-concept namespaces, people have talked about reusing existing identifiers in URNs ([RFC2288]). This document is where the general definitions and the mechanisms for setting up URN "namespaces" actually live 🔥

1.0 Introduction 🧚

Uniform Resource Names (URNs) are resource identifiers with a specific job: giving a resource an identity that doesn't depend on where it lives, and that stays valid for a long time. There are 2 assumptions that are key to this document, and they're kind of the whole vibe ✨

Assumption #1: Assignment of a URN is a managed process.

I.e., not every string that follows URN syntax is automatically a valid URN. A URN gets assigned according to the rules of a particular namespace, and those rules cover syntax, semantics, and process 🎀

Assumption #2: The space of URN namespaces is managed.

I.e., not every syntactically correct URN namespace (per the URN syntax definition) is a valid URN namespace. A URN namespace needs a recognized definition before it counts as valid 🙈

The purpose of this document is to outline a mechanism and provide a template for explicit namespace definition. It also covers how you attach an identifier to that namespace, called a "Namespace ID" (or NID), which gets registered with the Internet Assigned Numbers Authority, IANA 👑

Note that this document only describes the process for creating URN namespaces. If you also want "resolution" of the URNs you've created, you need a separate step: registering in a global NID directory, like the one provided by the NAPTR system [RFC2168]. See [NAPTR-REG] for how to get registered in the NAPTR global NID directory. Different job, different process, so don't mix them up, bestie 💀

2.0 What is a URN Namespace? 🦋

For URN purposes, a "namespace" is a collection of uniquely-assigned identifiers. A URN namespace has its own identifier so that:

  • global uniqueness of URNs is ensured
  • (where desired) there's a cue for the structure of the identifier

For example, ISBNs and ISSNs are both collections of identifiers used in the traditional publishing world. You might have a number that's both a valid ISBN and a valid ISSN, but using different designators for the two collections means no two URNs will ever match up for different resources. Iconic behaviour 🍓

Building an identifier structure, and therefore a collection of identifiers, depends heavily on what the community defining it needs, how the identifiers get assigned, and what they're going to be used for. All of those details are specific to whichever community is trying to define a namespace (publishers, a booksellers' association, protocol developers, and so on). Honestly, those things are outside the scope of the IETF URN work 🫶

This document lays out the processes that let a collection of identifiers, as long as it meets certain constraints (like uniqueness of assignment), become a bona fide URN namespace by getting a NID. In a nutshell: you complete a template for defining the namespace, deposit it with IANA, and a NID gets assigned. The details of the process and the options for NID strings are coming up below. First up, the template for the definition 💖

Stay tuned, this is part 1 of 4. The rest of the RFC is still coming, so keep your eyes peeled! 👀✨

3.0. URN Namespace Definition Template ✨

Okay bestie, so defining a URN namespace means filling in this info template 📝 Besides showing how the namespace is structured, it's super useful for two groups:

  • entities seeking to have a URN assigned in a namespace (if applicable)
  • entities seeking to provide URN resolvers for a namespace (if applicable)

This matters most for communities deciding whether to borrow a piece of an existing URN namespace instead of making their own 🫶 Anyway, here's the template:

Namespace ID

Assigned by IANA. In some contexts, a particular one may be requested (see below). 🎀

Registration Information

This is the info that pins down which version of the registration you're looking at 🦋

  • registration version number: starting with 1, incrementing by 1 with each new version
  • registration date: date submitted to the IANA, using the format YYYY-MM-DD as outlined in [ISO8601].

Declared registrant of the namespace

Required: Name and e-mail address. Recommended: Affiliation, address, etc. 💜

Declaration of syntactic structure

This section should outline any structural features of identifiers in this namespace. At the very least, it can introduce the terminology used in the other sections. This structure may also help with figuring out realistic caching/shortcut approaches, but suitable caveats should be provided 🙈 If there are any specific character encoding rules (e.g., which character should always be used for single-quotes), those should be listed here too ✨

Answers might include, but are not limited to:

  • the structure is opaque (no exposition) - a regular expression for parsing the identifier into components, including naming authorities

Relevant ancillary documentation

This section should list any RFCs, standards, or other published documentation that defines or explains all or part of the namespace structure 📚

Answers might include, but are not limited to:

  • RFCs outlining syntax of the namespace
  • Other of the defining community's (e.g., ISO) documents outlining syntax of the identifiers in the namespace
  • Explanatory material introducing the namespace

Identifier uniqueness considerations

This section should address the requirement that URN identifiers be assigned uniquely. Basically, they're assigned to at most one resource, and they are not reassigned 👑

(Note that the definition of "resource" is fairly broad; for example, information on "Today's Weather" might be considered a single resource, although the content is dynamic.) 🌤️

Possible answers include, but are not limited to:

  • exposition of the structure of the identifiers, and partitioning of the space of identifiers amongst assignment authorities which are individually responsible for respecting uniqueness rules
  • identifiers are assigned sequentially
  • information is withheld; the namespace is opaque

Identifier persistence considerations

Okay, so non-reassignment means a URN keeps pointing at the same resource even after the "lifetime of the resource" ends 🦋 But some thought should still go into whether the URN stays usable. This is especially important for URN namespaces that provide global resolution 🌈

Possible answers include, but are not limited to:

  • quality of service considerations

Process of identifier assignment

This section should detail the mechanisms and/or authorities for assigning URNs to resources. It should make clear whether assignment is completely open or, if it's limited, how to become an assigner of identifiers and/or get one assigned by existing assignment authorities 🍓 Answers could include, but are not limited to:

  • assignment is completely open, following a particular algorithm
  • assignment is delegated to authorities recognized by a particular organization (e.g., the Digital Object Identifier Foundation controls the DOI assignment space and its delegation)
  • assignment is completely closed (e.g., for a private organization)

Process for identifier resolution

If a namespace is meant to be accessible for global resolution, it must be registered in an RDS (Resolution Discovery System, see [RFC2276]) such as NAPTR. ✨ Resolution then follows standard URI resolution processes, plus the mechanisms of the RDS. This section should outline what it takes to become a recognized resolver of URNs in this namespace (and get listed in the RDS registry) 🧚

Answers may include, but are not limited to:

  • the namespace is not listed with an RDS; this is not relevant
  • resolution mirroring is completely open, with a mechanism for updating an appropriate RDS
  • resolution is controlled by entities to which assignment has been delegated

Rules for Lexical Equivalence

If there are particular algorithms for determining equivalence between two identifiers in the underlying namespace (so, in the URN string itself), the rules can go here 💅

Some examples include:

  • equivalence between hyphenated and non-hyphenated groupings in the identifier string
  • equivalence between single-quotes and double-quotes
  • Namespace-defined equivalences between specific characters, such as "character X with or without diacritic marks".
Note that these are not normative statements for any kind of best practice for handling equivalences between characters. They only reflect the namespace's own rules 🙈

Conformance with URN Syntax

This section should outline any special considerations needed for conforming with the URN syntax. This is especially relevant for legacy naming systems that are used in the context of URNs 🌸

For example, if a namespace is used in contexts other than URNs, it may use characters that are reserved in the URN syntax. This section should flag any such characters and outline the mappings needed to conform to URN syntax. Usually this is handled by hex encoding the symbol 🔥

For example, see the section on SICIs in [RFC2288].

Validation mechanism

Apart from attempting resolution of a URN, a URN namespace may provide a mechanism for "validating" a URN. That means figuring out whether a given string is currently a validly-assigned URN 👀 For example, even if an ISBN URN namespace is created, it isn't clear that every ISBN will translate directly into an "assigned URN". 📖

A validation mechanism might be:

  • a syntax grammar
  • an on-line service
  • an off-line service

Scope

This section should outline the scope of how the identifiers in this namespace get used. Apart from the private vs. public question, this section is critical for evaluating whether a requested NID actually fits 💖 For example, a namespace claiming to deal in "social security numbers" should have a global scope and address all social security number structures (which is unlikely 💀). On the other hand, at a national level, it's reasonable to propose a URN namespace for "this nation's social security numbers" 🌍

4.0 URN Namespace Registration, Update, and NID Assignment Process ✨

Okay bestie, so there are different levels of disclosure for namespaces 💅 Depending on how much open-forum discussion surrounds the disclosure, a URN namespace might just get assigned, or it might request a particular identifier 🎀 [RFC2434] says we need to spell out update mechanisms for registrations, like who gets the authority to do updates from time to time and what the processes are 🧚 URNs are meant to be persistently useful, so few (if any) changes should be made to the structural interpretation of URN strings (e.g., adding or removing rules for lexical equivalence that might affect the interpretation of URN IDs already assigned) 🔒 Still, it may be important to introduce clarifications, expand the list of authorized URN assigners, etc., over the natural course of a namespace's lifetime 🌸 Specific processes are outlined below.

There are 3 categories of URN namespaces defined here 🦋 They're distinguished by expected level of service and required procedures for registration, and registration maintenance procedures vary slightly from one category to another.

I. Experimental ✨

These are not explicitly registered with IANA, and they take the form:

X-<NID>

No provision is made for avoiding collision of experimental NIDs, because they're intended for use within internal or limited experimental contexts 🧪

As there is no registration, no registration maintenance procedures are needed 💅

II. Informal 🌈

These are registered with IANA and get a number sequence as an identifier, in this format:

"urn-" <number>

where <number> is chosen by the IANA on a First Come First Served basis (see [RFC2434]) 🎀

Registrants should send a copy of the registration template (see section 3.0), duly completed, to the mailing list:

urn-nid@apps.ietf.org

and allow for a 2 week discussion period for clarifying the expression of the registration information and suggestions for improving the namespace proposal 🫶

Once suggestions for clarification of the registration information have been incorporated, the template may be submitted to:

iana@iana.org

for assignment of a NID 💖

The only restrictions on <number> are that it consist strictly of digits, and that it not cause the NID to exceed the length limitations outlined in the URN syntax ([RFC2168]) 🍓

Registrations may be updated by the original registrant, or by an entity the registrant designates. You update the registration template, submit it to the discussion list for a further 2 week discussion period, and then resubmit it to IANA as described above 🔁

III. Formal 👑

These are processed through an RFC review process. The RFC need not be standards-track 💜 The template defined in section 3.0 may be included as part of an RFC defining some other aspect of the namespace, or it may be put forward as an RFC in its own right. The proposed template should be sent to the mailing list:

urn-nid@apps.ietf.org

to allow for a 2 week discussion period for clarifying the expression of the registration information, before the IESG progresses the document to RFC status 🧚

A particular NID string is requested, and it's assigned by IETF consensus (as defined in [RFC2434]). There are also extra constraints. The NID string must:

  • not be an already-registered NID
  • not start with "x-" (see Type I above)
  • not start with "urn-" (see Type II above)
  • not start with "XY-", where XY is any combination of 2 ASCII letters (see NOTE, below)
  • be more than 2 letters long
NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters, are reserved for potential use as countrycode-based NIDs for eventual national registrations of URN namespaces. The definition and scoping of rules for allocating responsibility for such namespaces is beyond the scope of this document 🌍

Registrations may be updated by updating the RFC through standard IETF RFC update mechanisms. So proposals for updates may come from the original authors, other IETF participants, or the IESG 🔄 In any case, the proposed updated template must be circulated on the urn-nid discussion list, allowing for a 2 week review period 💅

URN namespace registrations will be posted in the anonymous FTP directory ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/ 📂

5.0 Example 🎀

This example is here to illustrate the URN NID template described in section 3.0. It's based on a hypothetical "generic Internet namespace" that has been discussed informally within the URN WG, but there are still technical and infrastructural issues that would have to be resolved before such a namespace could be properly and completely described 🧐

Namespace ID:
   To be assigned

Registration Information:

   Version 1
   Date: <when submitted>

Declared registrant of the namespace:

   Required: Name and e-mail address.
   Recommended:  Affiliation, address, etc.

Declared registrant of the namespace:

   Name:           T. Cat
   E-mail:         leslie@thinkingcat.com
   Affiliation:    Thinking Cat Enterprises
   Address:        1 ThinkingCat Way
                   Trupville, NewCountry

Declaration of structure:

   The identifier structure is as follows:

   URN:<assigned number>:<FQDN>:<assigned US-ASCII string>

   where FQDN is a fully-qualified domain name, and the assigned
   string is conformant to URN syntax requirements.

Relevant ancillary documentation:

   Definition of domain names, found in:

   P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
   RFC1035, November 1987.

Identifier uniqueness considerations:
   Uniqueness is guaranteed as long as the assigned string is never
   reassigned for a given FQDN, and that the FQDN is never
   reassigned.

   N.B.:  operationally, there is nothing that prevents a domain name
   from being reassigned;  indeed, it is not an uncommon occurrence.
   This is one of the reasons that this example makes a poor URN
   namespace in practice, and is therefore not seriously being
   proposed as it stands.

Identifier persistence considerations:

   Persistence of identifiers is dependent upon suitable delegation
   of resolution at the level of "FQDN"s, and persistence of FQDN
   assignment.

   Same note as above.

Process of identifier assignment:

   Assignment of these URNs delegated to individual domain name
   holders (for FQDNs).  The holder of the FQDN registration is
   required to maintain an entry (or delegate it) in the NAPTR RDS.
   Within each of these delegated name partitions, the string may be
   assigned per local requirements.

   e.g.  urn:<assigned number>:thinkingcat.com:001203

Process for identifier resolution:

   Domain name holders are responsible for operating or delegating
   resolution servers for the FQDN in which they have assigned URNs.

Rules for Lexical Equivalence:

   FQDNs are case-insensitive.  Thus, the portion of the URN

           urn:<assigned number>:<FQDN>:

   is case-insenstive for matches.  The remainder of the identifier
   must be considered case-sensitve.

Conformance with URN Syntax:

   No special considerations.

Validation mechanism:

   None specified.

Scope:

   Global.

6.0 Security Considerations 🚨

This document mostly focuses on providing mechanisms for declaring public information. These declarations should nominally be of relatively low security profile, but there is always the danger of "spoofing" and providing mis-information 😭 Information in these declarations should be taken as advisory 🫣

7.0 References 📚

[RFC2168]   Daniel, R. and M. Mealling, "Resolution of Uniform
            Resource Identifiers using the Domain Name System", RFC
            2168, June 1997.

[RFC2169]   Daniel, R., "A Trivial Convention for using HTTP in URN
            Resolution", RFC 2169, June 1997.

[ISO8601]   ISO 8601 : 1988 (E), "Data elements and interchange
            formats - Information interchange - Representation of
            dates and times"

[RFC2288]   Lynch, C., Preston, C. and R. Daniel, "Using Existing
            Bibliographic Identifiers as Uniform Resource Names", RFC
            2288, February 1998.

[NAPTR-REG] Mealling, M., "Assignment Procedures for NAPTR DNS URI
            Resolution", Work in Progress.

[RFC2141]   Moats, R., "URN Syntax", RFC 2141, May 1997.

[RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
            October 1998.

[RFC1737]   Sollins, K. and L. Masinter, "Functional Requirements for
            Uniform Resource Names", RFC 1737, December 1994.

[RFC2276]   Sollins, K., "Architectural Principles of Uniform
            Resource Name Resolution", RFC 2276, January 1998.

8.0 Authors' Addresses 🦋

Leslie L. Daigle
Thinking Cat Enterprises

EMail:  leslie@thinkingcat.com


Dirk-Willem van Gulik
ISIS/STA/CEO - TP 270
Joint Research Centre Ispra
21020 Ispra (Va)
Italy.

Phone: +39 332 78 9549 or 5044
Fax:   +39 332 78 9185
EMail:  Dirk.vanGulik@jrc.it


Renato Iannella
DSTC Pty Ltd
Gehrmann Labs, The Uni of Queensland
AUSTRALIA, 4072

Phone:  +61 7 3365 4310
Fax:    +61 7 3365 4311
EMail:  renato@dstc.edu.au


Patrik Faltstrom
Tele2/Swipnet
Borgarfjordsgatan 16
P.O. Box 62
S-164 94 Kista
SWEDEN

Phone:  +46-5626 4000
Fax:    +46-5626 4200
EMail:  paf@swip.net

Okay bestie, the legal bit, but make it cute 🎀 Copyright is The Internet Society (1999), all rights reserved 🔒

So here's the deal 💅 You're allowed to copy this doc and pass it around to people, and you can even make derivative works that comment on it, explain it, or help people implement it, and you can publish and distribute all of that, whole or in part, no restrictions 🦋 The one catch is that the copyright notice and this paragraph MUST stay on every copy and every derivative work. Nobody is allowed to change the document itself, like ripping out the copyright notice or erasing the references to the Internet Society or other Internet organizations 🙅‍♀️ There are two exceptions to that: you can change it if you need to for developing Internet standards (and then you have to follow the copyright procedures in the Internet Standards process), or if you need to translate it into a language that isn't English 🌸

These permissions are perpetual 💜 The Internet Society and its successors or assigns will never revoke them, so this is forever, no cap ✨

Now the disclaimer, which is a little dramatic 😭 This document and everything in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED 💀 That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Translation: they're not promising it'll work for you, so be your own main character about it 👑

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 🌈 Shoutout to them for keeping the RFC Editor running! 💖

📦 where this page comes from