RFC 1737

Functional Requirements for Uniform Resource Names 🦋

Okay bestie, this is RFC 1737 🎀 (Request for Comments: 1737). It came from the Network Working Group and was written by K. Sollins of MIT/LCS and L. Masinter of Xerox Corporation 👩‍💻. It's Informational in category and dated December 1994 🌸. The title block doesn't list anything it obsoletes or updates, so no drama there ✨.

---

Status of this Memo 📜

Quick vibe check: this memo is here to give the Internet community some info 📚. It does not specify an Internet standard of any kind, so it's not a standard 🙅‍♀️. Distribution of this memo is unlimited, so share it with everyone 💌.

1. Introduction ✨

Okay so this document lays out a minimum set of requirements for a kind of Internet resource identifier called Uniform Resource Names (URNs) 🦋. URNs live inside a bigger Internet information architecture that also has Uniform Resource Characteristics (URCs) and Uniform Resource Locators (URLs) 🧩. The big picture: URNs are for identification, URCs are for including meta-information, and URLs are for locating or finding resources 🗺️. This doc is basically the foundation for evaluating standards for URNs 📝. The discussions happened on the mailing list uri@bunyip.com and at the URI Working Group sessions of the IETF 💜.

The requirements here are not necessarily exhaustive 🙈. There are several issues about supporting replication of resources and about security that people have talked about, but those problems aren't well enough understood yet to put specific requirements in those areas here 💀. We're being honest about what we don't know yet 🫶.

Within distributed object systems design, there are loads of concepts and designs discussed under the general topic of "naming" 🏷️. The URN requirements here are for a facility that handles a different set of needs than general object naming usually does, and in general those needs are more stringent 🔥.

The requirements for Uniform Resource Names fit into the overall architecture of Uniform Resource Identification 🌈. To build applications in the most general case, the user has to be able to discover and identify the information, objects, or what this architecture calls resources, that the application is going to operate on 👑. Beyond that statement, the URI architecture doesn't define "resource," so it's up to the rest of us 💅. As networks and interconnectivity grow, being able to use remote (and maybe independently managed) resources matters more and more ✨.

Discovering and using resources can be split into two buckets: activities where human utility and ease is a main constraint, and activities where human involvement is small or nonexistent 🤖. Human names must be mnemonic and short 🍓. Humans are great at heuristic disambiguation and handling wide variability in structure, unlike computers 🧠. For computer and network systems to support global naming and access to resources with a possibly indeterminate lifetime, the flexibility and the attendant unreliability of human-friendly names should be translated into a naming infrastructure that suits the underlying support system better 🛠️. That underlying support system is exactly what the Internet Information Infrastructure Architecture (IIIA) is tackling 🏗️.

Within the IIIA, several sorts of information about resources are specified and divided among different structures along functional lines 🧁. To access information, you have to be able to discover or identify the particular information you want, and figure out both how and where it might be used or accessed 🔍. So the functionality is partitioned into uniform resource names (URN), uniform resource characteristics (URC), and uniform resource locators (URL) 🎀.

A URN identifies a resource or unit of information 🪪. It might identify intellectual content, a particular presentation of intellectual content, or whatever a name assignment authority decides is a distinctly namable entity 📖. A URL identifies the location, or a container for an instance, of a resource identified by a URN 📍. The resource identified by a URN may reside in one or more locations at any given time, may move, or may not be available at all 🚚. Not every resource will move during its lifetime, and not every resource, even when it's identifiable and identified by a URN, will be instantiated at any given time 🌙. So a URL is identifying a place where a resource may reside (or a container for it), which is different from the resource itself that the URN identifies 🫧. A URC is a set of meta-level information about a resource 📋. Some examples of that meta-information are: owner, encoding, access restrictions (perhaps for particular instances), and cost 💸.

With all of that in mind, here's the main takeaway:

• Purpose: The purpose or function of a URN is to provide a globally unique, persistent identifier used for recognition, for access to characteristics of the resource, or for access to the resource itself 🏆.

More specifically, there are two kinds of requirements on URNs: requirements on the functional capabilities of URNs, and requirements on the way URNs are encoded in data streams and written communications 💖.

2. Requirements for functional capabilities

These are the requirements for URNs' functional capabilities 🧠✨:

• Global scope: A URN is a name with global scope, and it does not imply a location. It has the same meaning everywhere 🌍.
• Global uniqueness: The same URN will never be assigned to two different resources 👯‍♀️.
• Persistence: It is intended that the lifetime of a URN be permanent. That is, the URN will be globally unique forever, and may well be used as a reference to a resource well beyond the lifetime of the resource it identifies or of any naming authority involved in assigning its name 🕰️💜.
• Scalability: URNs can be assigned to any resource that might conceivably be available on the network, for hundreds of years 📈🌌.
• Legacy support: The scheme must permit support of existing legacy naming systems, insofar as they satisfy the other requirements described here. For example, ISBN numbers, ISO public identifiers, and UPC product codes seem to satisfy the functional requirements, and allow an embedding that satisfies the syntactic requirements described here 📚🛒.
• Extensibility: Any scheme for URNs must permit future extensions to the scheme 🧩🔮.
• Independence: It is solely the responsibility of a name issuing authority to determine the conditions under which it will issue a name 👑.
• Resolution: A URN will not impede resolution (translation into a URL, q.v.). To be more specific, for URNs that have corresponding URLs, there must be some feasible mechanism to translate a URN to a URL 🔁✨.

3. Requirements for URN encoding

In addition to the requirements on the functional elements of URNs, there are requirements on how they're encoded in a string 🧵💅:

• Single encoding: The encoding for presentation to people in clear text, electronic mail, and the like is the same as the encoding in other transmissions 💌.
• Simple comparison: A comparison algorithm for URNs is simple, local, and deterministic. That means there is a single algorithm for comparing two URNs that does not require contacting any external server, and it is well specified and simple 🧁.
• Human transcribability: For URNs to be easily transcribable by humans without error, they should be short, use a minimum of special characters, and be case insensitive. (There is no strong requirement that it be easy for a human to generate or interpret a URN, and explicit human-accessible semantics of the names is not a requirement.) For this reason, URN comparison is insensitive to case, and probably to white space and some punctuation marks 🍓🙈.
• Transport friendliness: A URN can be transported unmodified in the common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc., as well as on printed paper 🖨️🚀.
• Machine consumption: A URN can be parsed by a computer 🤖💜.
• Text recognition: The encoding of a URN should enhance the ability to find and parse URNs in free text 🔎✨.

4. Implications

For a URN specification to be acceptable, it must meet the previous requirements. Those requirements lead to the conclusions below. A specification that satisfies the requirements without meeting these conclusions is deemed acceptable, although unlikely to occur 🙃.

Here's what falls out of those requirements 🎀:

• To satisfy the requirements of uniqueness and scalability, name assignment is delegated to naming authorities, who may then assign names directly or delegate that authority to sub-authorities 🏛️. Uniqueness is guaranteed by requiring each naming authority to guarantee uniqueness 🔐. The names of the naming authorities themselves are persistent and globally unique, and top level authorities will be centrally registered 🗂️💖.
• Naming authorities that support scalable naming are encouraged, but not required 🌱. Scalability implies that a scheme for devising names may be scalable both at its terminators and within the structure. For example, in a hierarchical naming scheme, a naming authority might have an extensible mechanism for adding new sub-registries 🌳.
• It is strongly recommended that there be a mapping between the names generated by each naming authority and URLs 🗺️💫. At any specific time there will be zero or more URLs into which a particular URN can be mapped. The naming authority itself need not provide the mapping from URN to URL 🙌.
• For URNs to be transcribable and transported in mail, it is necessary to limit the character set usable in URNs, although there is not yet consensus on what the limit might be 🔤🌸.

In assigning names, a name assignment authority must abide by the preceding constraints, as well as defining its own criteria for determining the necessity or indication of a new name assignment 👑💅.

5. Other considerations ✨

okay so there are three things this doc intentionally does NOT take a side on 💅 because they're supposed to be decided locally or by other services in the information infrastructure. The three are: equality of resources, reflection of visible semantics in a URN, and name resolution. 🫶

First up, equality! Naming authorities (the folks who assign the names) can make themselves distinctive by how they decide whether resources are the same or different 👑. Like, a publisher might want to tell apart different printings of a book where there are tiny spelling or typo fixes, but a library might prefer to not make that distinction at all 📚. And honestly no single equality algorithm is going to work for every kind of information 🙈. Testing two books for equality is not gonna help you compare two spreadsheets, periodt. So even though this document requires that any particular naming authority use one algorithm for deciding whether two resources it's comparing are the same or different, each naming authority can pick its own algorithm, and a naming authority can restrict the set of resources it chooses to identify in any way at all 🦋.

Next, how names get picked 🧚. A naming authority also has some algorithm for actually choosing a name inside its namespace. That algorithm might somehow embed knowledge about the resource in the name 🌸. And whether that embedding is made public, or visible to potential clients, is up to the naming authority. For example, an unreflective URN just hands out monotonically increasing serial numbers for resources 🍓. That tells you nothing except the identity from the equality algorithm and the order that this server assigned names in. It carries zero info about the resource itself 💀.

Now the spicy one 🌶️. An MD5 of the resource at some point might, by itself, reflect its contents, and the naming authority might be totally fine publishing that it's using MD5 💖. But if the resource is mutable, a potential client still can't do much with the URN except check for equality ngl 😭. On the flip side, if a URN scheme has a lot in common with how ISBN numbers are assigned, and the assignment algorithm is public, then knowing that algorithm lets you learn more about the resource from a given ISBN number ✨. This whole range of possibilities is allowed by this requirements document. That said, naming authorities are intended to be discouraged from making semantic information about the resource accessible to clients 🙅‍♀️, because that stuff may change over time, so it's unwise to encourage anyone to depend on that semantics staying valid. Main character energy, but make it responsible 🎀.

Last, name resolution 🦋. This document intentionally doesn't address the problem of name resolution, other than recommending that every naming authority have a name translation mechanism. Naming authorities assign names, while resolvers or location services of some sort help out with, or provide, the URN-to-URL mapping 🗺️. There might be one service or many for the resources a particular naming authority names. There can also be generic ones serving resources from lots of different naming authorities. Some might be authoritative, and others not. Some might be super reliable, highly available, really responsive to updates, or focused on something like subject matter 🔥. It's also possible that some naming authorities will act as resolvers for the resources they named themselves. This document supports and encourages third-party and distributed services in this area, so it intentionally makes no statements about requirements on resolvers for URNs or naming authorities 💜.

---

Security Considerations 🔐

okay this part is serious bestie 😤. Applications that need to translate names into locations, and the resources themselves, may need the resources to be authenticated. It seems generally that information about authenticating either the name or the resource it refers to should be carried by separate information passed along with the URN, rather than inside the URN itself 🫶✨.

---

Authors' Addresses 💌

The two iconic brains behind this doc 👑🌈:

Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304

Phone: (415) 812-4365
Fax:   (415) 812-4333
EMail: masinter@parc.xerox.com


Karen Sollins
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139

Voice: (617) 253-6006
Phone: (617) 253-2673
EMail: sollins@lcs.mit.edu