RFC 2276

Architectural Principles of Uniform Resource Name Resolution

📅 published January 1998, from ietf

(part 1 of 6)

Architectural Principles of Uniform Resource Name Resolution 🌈

Okay bestie, the title block tea ☕ This is RFC 2276, written by K. Sollins at MIT/LCS for the Network Working Group, dated January 1998. It's Informational 🫶, so it's here to share useful info with the Internet community, not to set a standard. It doesn't obsolete or update any other RFCs, so it's a solo queen 👑 in that department.

Status of This Memo ✨

Tbh this memo is just giving information to the Internet community 💅 It does not specify an Internet standard of any kind, and it can be shared as much as you want, since distribution is unlimited 🦋

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

Abstract 🦋

Okay so this doc is all about discovering URN resolver services, the things that translate URNs into URLs and URCs (Uniform Resource Characteristics) 🔥 It's split into three big parts: the assumptions everything is built on, the guidelines a service has to meet to be a viable Resolver Discovery Service (RDS), and a framework for designing RDSs. The guidelines hit three areas: evolvability, usability, and security and privacy ✨

Here's the lowkey important bit 👀 An RDS that follows the framework won't automatically follow the guidelines. Compliance with the guidelines will need to be validated separately, so don't assume the framework got you there 🙈

Table of Contents 🧚

   1.    Introduction..................................................2
   2.    Assumptions...................................................5
   3.    Guidelines....................................................7
   3.1   Evolution.....................................................7
   3.2   Usability....................................................10
   3.2.1 The Publisher................................................11
   3.2.2 The Client...................................................12
   3.2.3 The Management...............................................13
   3.3   Security and Privacy.........................................14
   4.    The Framework................................................18
   5.    Acknowledgements.............................................23
   6.    References...................................................23
   7.    Author's Address.............................................23
   8.    Full Copyright Statement.....................................24

1. Introduction ✨

Okay, so the purpose of this doc is to lay out the engineering criteria for what we're calling a Resolver Discovery Service (RDS) 🌸 An RDS is a service that helps you learn about URN (Uniform Resource Name) resolvers. Here, "resolver" means a service that translates URNs into URLs (Uniform Resource Locators) or URCs (Uniform Resource Characteristics). Some resolvers may also give direct access to resources. An RDS helps you find a resolver to contact for further resolution, and some RDS designs may also bake in resolver functionality themselves 💖

URN resolution is a piece of building an information infrastructure. In this case, that infrastructure is supposed to be available "in the Internet" or globally, so the solutions have to be globally scalable 🌍 This doc is focused specifically on designing RDS schemes ✨

The Uniform Resource Identifier Working Group defined a naming architecture across three RFCs: 1736 [1], 1737 [2], and 1738 [3]. Several more documents are needed to finish describing that architecture, but it already bundles three core functions that people usually associate with "naming": identification, location, and mnemonics or semantics 🦋 By location, we mean fully-qualified Domain Names or IP addresses, possibly extended with TCP ports and/or local identifiers like pathnames. Names can help tell one resource apart from another by distinguishing their "names." They can help you access a resource by including "location" info. And they can carry other semantic or mnemonic info that helps humans remember or figure out a name, or that describes the resource being named 💅

The URI working group concluded there was a need for persistent, globally unique identifiers, separate from location or other semantic info. These got called URNs 🔥 These "names" give you identity: if two of them are "the same" (under some simple canonicalization rule), they identify the same resource. The group also decided that these names were generally meant for machines rather than humans to read 🤖 And finally, with these RDS guidelines in mind, the group recognized how valuable it is to keep name assignment management separate from name resolution management 👑

Compared to URNs, you can imagine a bunch of human-friendly naming (HFN) schemes supporting different sets of applications and user communities 🌈 These will need to map to URNs with tighter or looser couplings, depending on the namespace. HFNs are the ones that will be mnemonic, content-full, and maybe mutable, so they can track changes in use and semantics. They might offer nicknaming and other aliasing, relative or short names, context-sensitive names, descriptive names, and more 🧚 Defining them isn't part of this effort, but they're clearly going to play an important role in the long run ✨

URNs, as described in RFC 1737, are defined globally. They're ubiquitous, meaning a URN anywhere, in any context, identifies the same resource 💖 So, given that requirement, you have to ask what it means for an RDS. Does ubiquity mean RDS resolution is guaranteed everywhere? Does it mean resolving to the same information about resolution everywhere? In both cases, the answer is probably not 🙈 You can't make global, systemic guarantees except at a cost that's beyond reason. There can also be policy reasons, not just technical ones, for not resolving the same way everywhere 🫣

Here's the tea: it's entirely possible that resolving a URN to an instance of a resource reaches different instances or copies under different conditions. So even though a URN always refers to the same resource, in some environments, under some conditions, and at different times, a URN may sometimes be resolvable and other times or places not. That could be due to the vagaries of network conditions or to policy controls 🌧️ Ubiquitous resolution can't be assumed just because naming is ubiquitous. On the other hand, wide deployment and usage will be an important feature of any RDS design 📣

Within the URI community, there's a concept that's used a lot. For lack of a better term, this doc calls it a hint 🦋 A hint is something that helps resolve a URN. In theory, we map URNs to hints as an interim stage on the way to accessing a resource. In practice, an RDS may map a URN straight to the resource itself if it wants to 💅 It's very likely there will be hints that apply to large sets of URNs. For example, a hint might say that all URNs with a certain prefix or suffix can be resolved by a particular resolver 🌸 A hint may also carry meta-information, like an expiration time or a certification of authenticity. We expect that meta-information to stay with the hint instead of being managed somewhere else. For the rest of the discussion, we'll assume hints include any necessary meta-information along with the hint information itself ✨

Examples of hints are:

  1. The URN of a resolver service that may further resolve the URN
  2. The address of such a service
  3. A location where the resource was previously found

The defining feature of hints is that they're only hints 🙈 They may be out of date, temporarily invalid, or only applicable within a specific locality. They don't guarantee access, but they probably will help with the resolution process 💖 However a set of hints gets discovered, some mix of software and human choice decides which hints get tried and in what order 🧠

We have to assume most URN resolutions will be handled using locally stored hints, because keeping a database of globally available, completely up-to-date location info is infeasible for performance reasons 😭 There are a bunch of situations where hints can become invalid, either because a resource has moved or because a different URN resolver service has taken over responsibility for resolving that URN 🔄 Hints can come from all kinds of places. It's generally assumed that a well-engineered system will maintain or cache a set of hints for each URN at each location where that URN is found. Those hints may have come from the owner of the resource, from a recommendation of the resource, or from many other sources 🌈 And for when the locally found hints fail, a well-engineered system will provide a fall-back mechanism for discovering more hints. That fall-back mechanism is the RDS, and it's what this doc is addressing 🧚

Like with all hints, there can never be a guarantee that every client gets access to a resource, even if some clients can access it. Still, an RDS is expected to work with reasonably high reliability, and so it may result in increased response time ⏳

The rest of this document breaks into three sections. The first one identifies several sets of assumptions behind this work. There are three general assumptions:

  • URNs are persistent;
  • URN assignment can be delegated;
  • Decisions can be made independently, enabling isolation from decisions of one's peers.

The next section lays out three central principles for RDS design. For each principle, there's a bunch of more specific guidelines that further define and refine it. This section is probably the most critical part of the document, because you have to hold any proposed RDS scheme up against these principles and their corollary guidelines to learn whether or not it's adequate 🔍 The three central principles can be summed up as:

  1. An RDS must allow for evolution and evolvability;
  2. Usability of an RDS with regard to each of the sets of constituents involved in the identification and location of resources is paramount;
  3. It is centrally important that the security and privacy needs of all constituents be feasibly supported, to the degree possible.

Each of the three major subsections of the guidelines section starts with a summary list of the more detailed guidelines in that section 📝

The final section of the document lays out a framework for these RDSs 🏗️ Its purpose is to bound the search space for RDS schemes. The RDS designer should know that meeting the guidelines is of primary importance, and it's possible to meet them without conforming to the framework. As the last section discusses further, designing within the framework does not guarantee compliance, so compliance evaluation must also be part of evaluating a scheme 💅✨

2. Assumptions 💅

okay bestie, so based on the older internet drafts and the chats in both the URN BOFs and the URN WG mailing list, three big buckets of assumptions keep popping up: longevity, delegation, and independence. we'll go through each one 🫶

First up, longevity! 🦋 The URN requirements [2] say a URN is supposed to be a "persistent identifier". Honestly, nothing lasts forever, ngl. But compared to the lifetimes of the resources, the people using them, and the systems supporting them, the identifier should be treated as persistent, or as lasting longer than all of those things. 💜 Two assumptions come out of longevity: mobility and evolution.

Mobility is the first one 🧚. Resources may move from one machine to another, owners of resources may move between organizations, or the organizations themselves may merge, split, or otherwise transform. Evolution is the second one 🌈. The Internet is always changing: protocols get revised, new ones get created, and security policies and mechanisms evolve too. Those are only examples. In general, we must assume that almost any piece of the supporting infrastructure for URN resolution will evolve. So to deal with both mobility and evolution, we must assume that users and their applications can stay independent of these changing details of the supporting infrastructure ✨.

Next, delegation 🌸. Naming and resolution authorities may delegate some of their authority or responsibility, and in both cases, delegation is the only known method of getting the kind of scaling we expect. The big thing here is that this work can separate name assignment (the job of labelling a resource with a URN) from name resolution (the job of discovering the resource given its URN). That split is a huge deal 👑. In both cases, we expect multi-tiered delegation. There may be RDS schemes that merge these two sets of responsibilities and delegation relationships, but by doing that they bind together or overload two very different activities, which probably slows down growth 🙈.

Last, independence 🍓. This is the isolation of one authority from another and, to some extent, from its parent. When one authority delegates some of its rights and responsibilities, the delegatee can operate in that domain independently of its peers, staying within the bounds set by the delegation and independent of the delegator. This isolation is critically important for allowing independence of policy and mechanism 💖.

This third assumption has several corollaries, so let's break them down:

  • First: we assume that the publisher of a resource can choose resolver services, independently of choices made by others. At any given time, the owner of a namespace may choose a particular URN resolver service for that delegated namespace. That resolver service may sit outside the RDS service model, and only be identified or located by the RDS service 🎀.
  • Second: it must be possible to make a choice among RDS services. Multiple RDS services can show up because an RDS service evolves, or because new ones get developed. At any given time there's likely to be only one, or a small set, of these services, but the number is likely to increase during a transition period from one architecture to another. So it must be assumed that clients can make a choice among a probably very small set of RDSs 🔥.
  • Third: there must be independence in the choice of the levels and models of security and authenticity required. This choice may be made by the owner of a naming subspace, by controlling who can modify hints in that subspace. A naming authority may delegate this choice to the owners of the resources named by the names it has assigned. There may be limitations on this freedom of choice so that other participants can have the level of security and authenticity they need, for example, to maintain the integrity of the RDS infrastructure as a whole 🔐.
  • Fourth: there's an assumption of independence in choosing the rule of canonicalization for URNs within a namespace, limited by any restrictions or constraints the parent namespace may have set. This is a choice held by naming authorities over their own subnamespaces. Rules for canonicalization will be discussed further in the framework section below 🧩.

So yeah, the assumptions of independence and isolation are there to allow for delegated, independent authority across a whole bunch of domains 🌈.

The modularity assumptions of delegation and isolation imply independence of decision and implementation. That leads to a decentralization that gives a certain degree of safety from denial of service 🛡️. Based on these assumptions, together with longevity and the ones for URLs and URNs detailed in RFCs 1736 and 1737, we can now turn to the guidelines for an RDS. Let's go! 🚀

3. Guidelines 🍓

okay the guidelines for an RDS are centered around three important design principles: evolvability, usability, and security and privacy 💜. At its core, the function of an RDS is to provide hints for accessing a resource given a URN for it. These hints may range in applicability from local to global, and from short-lived to long-lived. They also may vary in their degree of verifiable authenticity. It may be neither feasible nor necessary for initial implementations to support every guideline, but every implementation must support evolution toward systems that do support the guidelines more fully 🌸.

Not everything that matters is about the RDS itself! There are requirements that aren't specific to an RDS but still must be met. A whole URN system is made up of names in namespaces, the resolution information for them, and the mapping from names in the namespaces to that resolution information (or hints). URNs themselves must meet the requirements of RFC 1737. On top of that, namespaces must meet certain requirements, described by the URN Working Group [4]. Even though all of these requirements and guidelines aren't written out here, they must be supported to make an acceptable system 💅.

Each section below begins with a summary of the points made in that section. There's some overlap among the areas, like allowing for the evolution of security mechanisms, so an issue may get addressed in more than one section 🦋. It's also important to recognize that conformance with the guidelines will often be subjective. Like with many IETF guidelines and requirements, a lot of these can't be quantified, so conformance is a judgment call and a matter of degree 🫠. Lastly, some of the guidelines apply generally to distributed systems and some are specific to URN resolution. The general ones are included for completeness and aren't marked as such, so keep your eyes open! 👀✨

3.1. Evolution 🦋

Okay bestie, evolvability is the first big issue here, and it's giving "be ready for literally anything." The issues in this area are:

  • 1.1) An RDS MUST be able to scale in at least three dimensions: how many resources need URNs, how many publishers and users there are, and how complicated the delegation gets as resolution authority grows and maybe reflects delegation in naming authority;
  • 1.2) A hint resolution environment MUST support evolving mechanisms, specifically for:
    • a growing set of URN schemes;
    • new kinds local URN resolver services;
    • new authentication schemes;
    • alternative RDS schemes active simultaneously;
  • 1.3) An RDS MUST allow the development and deployment of administrative control mechanisms to manage human behavior with respect to limited resources.

One lesson the Internet has taught us, and that we MUST build into how URNs get resolved, is that change is coming. ✨ Changes might roll out slowly enough to count as evolution of what's already running, or hit hard enough to count as a full revolution. They might spread bit by bit, living side by side with older services, or they might take over the whole Internet in a short window and completely transform it 😭. There are several directions where we can already see change coming, and at the very least, the community and the proposed mechanisms SHOULD be ready for them. 💅

First up is scaling, which is a major part of evolution. Users (both human and electronic) and resources are going to keep growing exponentially, at least for the near term, so the number of URNs grows right along with them 📈. On top of that, more people usually means more delegation of both naming authority and resolution authority. So an RDS design MUST be ready to handle growing numbers of requests for inclusion, update, and resolution, across RDS servers that might be connected in more complex ways 🧠. That doesn't mean there will be more updates or resolutions per URN, bestie, because we can't predict that yet! But the infrastructure can still get more complicated because of delegation, which (as can be seen in Section 4 on the framework) may lead to more complex rules for rewriting or extracting terms for staged resolution. Any design is likely to perform worse above some set of limits, so it's worth thinking about the growth limitations of each design option 🌸.

Second, we expect there to be additions and changes to the mechanisms. The community already understands that there MUST be room for new URN schemes, as described in [4]. A URN scheme will define a set of URNs that meet the URN requirements [2], but MAY have further constraints on the internal structure of the URN. The idea is that URN schemes can be free to specify parts of the URN that are left opaque in the bigger picture. In fact, a URN scheme MAY choose to make public or keep private the algorithms for any such "opaque" part of the URN 🔐. Either way, we MUST be prepared for a growing number of URN schemes.

Often alongside a new URN scheme, but possibly on its own too, new kinds of resolver services may pop up. For example, picture a specialized resolver built around the structure of ISBNs that finds documents from their ISBNs super efficiently 📚. Or imagine a general-purpose resolver that trades performance for generality. It's only average at resolving ISBNs, but it understands every URN scheme, so its clients can use the same service to resolve URNs no matter the naming scheme 🧚. There's always room to improve services, whether through better performance, better adaptability to new URN schemes, or lower cost, for example. New models for URN resolution will keep evolving, and we MUST allow for their participation in the overall resolution of URNs 🎀.

If we start with one overall plan for URN resolution where those enhancements can fit, we also MUST be prepared for an evolution in the authentication schemes that end up being useful or necessary later on. There's no single globally accepted authentication scheme, and there may never be one. Even if one does show up at some point, we MUST always be ready to move on to newer and better schemes, because the old ones get too easily spoofed or guessed 🙈.

Even though we might deploy a single RDS scheme at first, we MUST be prepared for that top-level model to evolve. So if the RDS model has an apparently centralized (from a policy standpoint) way of inserting and modifying authoritative information, we may eventually need to shift to a different model, maybe one with a more distributed approach to authority and authenticity 🌈. And if the model has no core and instead relies on a cascaded partial discovery of information, that may become unmanageable as scaling increases. Whatever the model, we MUST be prepared for it to evolve along with changes in scaling, performance, and policy constraints like security and cost 💜.

The third evolutionary issue is even more mechanical than the others. At any point in time, the community is likely to be supporting a compromise position when it comes to resolution. We'll probably be operating somewhere balanced between feasibility and the ideal, maybe with policy controls helping to keep use of the service stable. Ideally, the service would be providing exactly what customers wanted, and they in turn would never request more support than they need, but that's extremely unlikely, ngl 💀. Since some service provision resources will almost always be in short supply, some form of policy controls will generally be necessary. Some policy controls may be realized as mechanisms within the servers or in the details of protocols, while others may only be realized externally to the system. For example, say hint entries are being submitted in such volume that the hint servers are using up their excess capacity and need more disk space. Two suggestions for policy control are pricing and administrative ones. As technology changes and the balance of which resources are in short supply shifts, the mechanisms and policies for controlling their use MUST evolve as well 👑.

3.2. Usability 🎀

To sum up, the usability guidelines fall into three areas based on participation in hint management and discovery:

  • 2.1) The publisher
    • 2.1.1) URN to hint resolution MUST be correct and efficient with very high probability;
    • 2.1.2) Publishers MUST be able to select and move among URN resolver services to locate their resources;
    • 2.1.3) Publishers MUST be able to arrange for multiple access points for their location information;
    • 2.1.4) Publishers SHOULD be able to provide hints with varying lifetimes;
    • 2.1.5) It MUST be relatively easy for publishers to specify to the management and observe their hint information as well as any security constraints they need for their hints.
  • 2.2) The client
    • 2.2.1) The interface to the RDS MUST be simple, effective, and efficient;
    • 2.2.2) The client and client applications MUST be able to understand the information stored in and provided by the RDS easily, in order to be able to make informed choices.
  • 2.3) The management
    • 2.3.1) The management of hints MUST be as unobtrusive as possible, avoiding using too many network resources;
    • 2.3.2) The management of hints MUST allow for administrative controls that encourage certain sorts of behavior deemed necessary to meet other requirements;
    • 2.3.3) The configuration and verification of configuration of individual RDS servers MUST be simple enough not to discourage configuration and verification.

Usability can be looked at from three distinct perspectives: a publisher who wants to make a piece of information public, a client asking for URN resolution, and the provider or manager of resolution information. We'll take the usability issues from each of these three perspectives separately. Heads up, though: the interests of some participants (like a user and a publisher) can clash, and some resolution will be needed 🤝.

There are also two extra kinds of participants in the whole naming process, as discussed in the URN WG. Naming authorities choose and assign names, and authors include URNs in their resources. Those two aren't relevant to the design of an RDS, so we won't go into them any further here 🫶.

3.2.1 The Publisher 💅

Okay bestie, let's talk about publishers 🎀. From a publisher's point of view, the biggest deal is that URNs MUST be correctly and efficiently resolvable by potential clients with very, very high probability 😭. Publishers literally win from long-lived URNs, because the longer they last, the more likely it is that references keep pointing at their stuff ✨.

Publishers also MUST be able to easily pick from a bunch of possible services that could translate URNs into location information 🦋. So the RDS architecture MUST support those transitions, but still within policy control bounds 🔒. Phone books have multiple listing services too, but those usually come with a fee 💸. Nothing is stopping fees from being collected for similar services for URNs, so keep that in mind 🍓.

Publishers MUST be able to set up multiple access points to a published resource 🌸. For that to be useful, resolver services SHOULD be ready to give different resolution or hint info to different clients, based on things like location and the different access privileges each client has 🧚. This MAY have serious implications for caching that info, so it's giving complicated 👀. For example, companies might set up locally replicated copies of popular resources and only want their own employees to access those local copies 🏢. That's different from access control on the whole resource, and it MAY be applied differently to different copies 💖.

Publishers SHOULD be able to provide both long and short term location info about accessing the resource ⏳. Long term info is stuff like the long term address of the resource itself, or the location or identity of a resolver service the publisher has a long term relationship with 🤝. You can imagine that the deal with that long term "authoritative" resolver might come with a guarantee of reliability, resiliency to failure, and atomic updates 🛡️. Short term info is for short term changes in services, or for dodging short lived congestion or failure problems 🌩️. For example, if the actual repository is temporarily inaccessible, the resource MAY be made available from another repository 📦. Short term info can be seen as temporary refinements of the long term info, so it SHOULD be more easily and quickly made available, but it MAY be less reliable 🫠. Some RDS designs MAY not distinguish between these two extremes, and that's valid too 🤷.

Lastly, publishers are going to be the source of a ton of hint info that the infrastructure stores and serves 🧠. Even though lots of publishers won't understand the details of the RDS mechanism, it MUST be easy and straightforward for them to install hint info 💅. So in general, anyone who wants to publish, and who has been given the privilege of resolution through delegation, can do it 🙌. The publisher MUST be able not only to express hints, but also to verify that what the manager serves is correct ✅. And to the extent there are security constraints on hint info, the publisher MUST be able to both express those constraints and verify compliance with them easily 🔐.

3.2.2 The Client 🫶

From the client's side, simplicity and usability are everything 🌈. Getting an efficient protocol for acquiring hint information is critical, because resolving the name is only the first step toward actually getting to a resource, so that time needs to be kept as short as possible ⏱️.

It's also going to matter a lot to build simple, standard interfaces to the RDS, so both the client and the applications acting for the client can interpret hints and make informed choices 🧐. The client, perhaps with help from the application, MUST be able to specify preferences and priorities and then apply them 🎯. If the ordering of hints is only partial, the client MAY end up getting directly involved in choosing and interpreting them, which means they MUST be understandable to that client 📖. On the other hand, it SHOULD be possible to configure default preferences, with individual preferences overriding any defaults 💜.

Clients are most likely to interact directly with only human friendly names (HFNs) 🍭. Like in regular human conversation (not computer mediated), names get shared on a small, private, or domain specific scale 👭. HFNs are the kinds of references and names that are easy to remember, type, choose among, assign, and so on 💭. There will also need to be a bunch of mechanisms for mapping HFNs to URNs, like "yellow pages" or "search tools" 🔍. Even though HFNs are mentioned here, HFNs and the mappings from HFNs to URNs are a separate functionality from an RDS, and they MUST remain separate 🚧. So even though HFNs are critical to clients, they don't fall into the domain of this document 🙈.

3.2.3 The Management 👑

Finally, we MUST deal with the usability concerns around managing the hint infrastructure itself 🛠️. "Management" is a service that's distinct from publishing, and it's the core of an RDS 💎. It involves storing and providing hints to clients so they can find published resources 🗂️. It also provides security for name resolution, to the extent there's a commitment to providing that security. This is addressed in Section 3.3 below 🔐.

The management of hints MUST be as unobtrusive as possible 🌷. First, its infrastructure (hint storage servers and distribution protocols) MUST have as little impact as possible on other network activities. It MUST be remembered that this is an auxiliary activity, and it MUST stay in the background 🫧.

Second, to make hint management feasible, there MAY need to be a system of administrative incentives and disincentives, like pricing or legal restrictions 💸. Recovering the cost of running the system is only one reason for charging anything 🧾. Introducing payments often changes social behavior, which is a whole thing 🤭. It MAY be necessary to discourage certain behaviors that, when they get out of control, cause serious negative impact on the whole community 🚫. At the same time, any administrative policies SHOULD encourage behavior that benefits the community as a whole 🌍. For example, a small one-time charge for authoritatively storing a hint might encourage people to use hints more conservatively 🧠. If we assume managing a hint has a fixed cost, then the broader its applicability across the URN space, the more cost effective it is 📈. So when one hint can serve a whole collection of URNs, there's an incentive to submit one general hint instead of a large number of more specific hints 🧩. Similar policies can be set up to discourage frequently changing hints 🔁. In these ways and others, behavior that benefits the community as a whole can be encouraged 💖.

Lastly, just like the usability issues for publishers, it MUST also be simple for the management to configure the mapping of URNs to hints 🗺️. It MUST be easy both to understand the configuration and to verify that it's correct 🔎. For management, this issue MAY affect not only the information itself but also how that information is partitioned among the network servers that work together to provide the management service or RDS 🧩. For example, it SHOULD be straightforward to bring up a server and verify that the data it's managing is correct ✅. Although this isn't a guideline, it's worth noting that since we're discussing a global and probably growing service, encouraging volunteer participants makes sense. Like with the DNS, those volunteers can feel confident about the service they're providing and about its benefit to both themselves and the rest of the community 🫶✨.

3.3 Security and Privacy 🔐

okay so security and privacy basically means having some degree of protection from threats 🛡️ ngl. The guidelines under this third principle, security, are all written as possibilities or options that users of the service can ask for and use. That means they're about the functionality being available, not about anyone actually using it 💅. We totally get that all security is a matter of degree and compromise ⚖️. These might not satisfy every potential customer, and nothing here is trying to stop anyone from building more secure servers with more secure protocols to suit their own needs ✨. These are meant to satisfy the needs of the general public 🌈.

3.1) It must be possible to create authoritative versions of a hint with access-to-modification privileges controlled 🔑.

3.2) It must be possible to determine the identity of servers or avoid contact with unauthenticated servers 🪪.

3.3) It must be possible to reduce the threat of denial of service by broad distribution of information across servers 🌍.

3.4) It must be possible within the bounds of organizational policy criteria to provide at least some degree of privacy for traffic 🫣.

3.5) It must be possible for publishers to keep private certain information such as an overall picture of the resources they are publishing and the identity of their clients 🤫.

3.6) It must be possible for publishers to be able to restrict access to the resolution of the URNs for the resources they publish, if they wish 🎀.

When you talk about security, the first thing you do is list the threats you're actually trying to deal with 📋. The tradeoffs usually include cost in money, computational and communications resources, ease of use, likelihood of use, and how effective the proposed mechanisms are 🧮. With that in mind, let's look at a set of threats 👀.

Voydock and Kent [5] put together a super useful catalog of potential threats 📚. Out of all of those, the passive threats to privacy or confidentiality and the active threats to authenticity and integrity are probably the most important to think about here 🔥. Spurious association is also important, to the extent that it causes threats to privacy, authenticity, or integrity for information inside servers that manage data 🧩. Denial of service is probably the hardest of these areas to detect and prevent, so we're going to set it aside for now too 😭. It'll still turn out that solutions to other problems mitigate some denial of service problems, though 💜.

Here's the thing: this is meant to be a global service that meets the needs of lots of different communities, so the engineering tradeoffs will be different for different clients 🌸. That's why the guidelines are written as "It must be possible..." 💖. Also, the information we're worried about here is hint information, and by nature hints aren't guaranteed to be correct or up-to-date 🙈. So it's unlikely to be worth spending a ton on the correctness of hints, because there's no guarantee they're still correct anyway 🤷‍♀️. The exact degree of privacy, authenticity, and integrity has to be decided by the needs of the client and by what services the server makes available ✨.

Now, to avoid confusion, let's define some words that mean different things in other contexts 📖. Here, "authoritative" means an action or stamp of approval taken by a principal (again, in the security sense) who has the right to approve things 👑. It says nothing about whether the information is correct, and at most it hints at who claimed it was correct 🕵️‍♀️. In other places, the word often just means a primary copy of some information, with possibly secondary or cached copies floating around 🔁. In this security discussion, we're using the first meaning 💅. Still, it can matter to find out whether a piece of information came from a primary source and to ask for it to be primary, and that second meaning shows up elsewhere in the document, where it's flagged 🚩.

Next up, "access control" can mean a bunch of different things, so we have to be careful 🧐. There are two areas where you can make distinctions. First, there's the kind of access control being talked about. For hints, that could be read access, read and modify access, or read with verification for authenticity 📝. Second, there's what the access is being controlled over 🎯. In naming, that could be the names themselves (not the case for URNs), the mapping of URNs to hints (the business of an RDS), the mapping of URNs to addresses (not the business of an RDS, as we'll talk about below in terms of privacy), or the resource itself (totally unrelated to naming or name resolution) 🫠. We try to be clear about which one we mean whenever we say "access control" 💅.

There's one more thing to cover, which is the difference between mechanism and policy 🧠. Generally, a policy gets carried out through a set of mechanisms ⚙️. For an RDS, there may be internal policies it needs in order to do its job the way it sees fit 🏠. Since an RDS is basically in the business of storing and distributing information, most of its security policies are probably about keeping its own integrity, and they're pretty limited 🥹. Beyond that, as far as it's possible, it should not impose any policy on its customers, the publishers and users 🙅‍♀️. They're the ones who might have policies they want the RDS to support 💕. So an RDS should offer a spectrum of "tools," or mechanisms, that customers can have deployed on their behalf to carry out their policies 🧰. An RDS might not provide everything a customer needs 🤏. A customer may also have different requirements inside their administrative bounds than outside them 🏢. So "it must be possible..." captures the idea that the RDS must generally provide the tools customers need to implement their policies 🫶.

The first approach to URN resolution is to discover local hints 📍. For hints to be found locally, they need to be distributed as widely as possible to whatever counts as local for every locale 🗺️. The catch is that wide distribution means widely distributing updates too, which can cause network traffic problems or delays in delivering those updates 🚦. An alternative model would concentrate hint information in servers, so update information only has to go out to those servers 🏛️. In that kind of model, the vulnerable points are the sources of the information and the distribution network between them 🕸️. Attacks on the integrity of the information stored on a server can take the form of masquerading as the owner of the information or as the server itself 🎭. Replicating information widely across servers makes it harder to masquerade at every location holding the information, and it also reduces the threat of denial of service 🛡️. These lead us to three identifiable guidelines for our security model 🎀:

  • ACCESS CONTROL ON HINTS: It must be possible to create an authoritative version of each hint with change control limited only to those principals with the right to modify it. The choice of who those principals are, or whether they're unlimited, must be made by the publisher of a hint 🔐.
  • SERVER AUTHENTICITY: Servers and clients must be able to learn the identity of the servers they communicate with. This is a matter of degree, and it's possible there will be more trustworthy but less accessible servers, supported by a larger cluster of less authenticatable servers that are more widely available 🪪. In the worst case, if the client receives what appears to be unvalidated information, the client should assume the hint may be inaccurate and might seek confirmation of the data from more reliable but less accessible sources 🫢.
  • SERVER DISTRIBUTION: Broad availability will provide resistance to denial of service. Services are only trustworthy to the extent that they're available. Distributing services also reduces the vulnerability of the whole community, by reducing the trust put in any single server 🌍. This has to be balanced against the fact that when trust is based on a linked set of servers, if any one of them fails, the whole chain of trust fails. The more elements in such a chain, the more vulnerable it may become ⛓️💀.

Privacy is a total double-edged sword 🗡️. For example, an organization might think it's critically important that its competitors can't read its traffic 🤐. On the other hand, it might also think it's important to monitor exactly what its employees send to and from whom, for all sorts of reasons. Those reasons include reducing the chance that employees are giving or selling company secrets, and checking that employees aren't using company resources for private projects 👀. So even though privacy and confidentiality needs are likely to exist, what they are, who controls them, and by what mechanisms varies so much that it's hard to say anything concrete about them here 🌀.

Publisher privacy is way easier to deal with 💅. Since publishers are trying to publish something, privacy usually isn't what they want 📢. However, publishers do have information they might want to keep private, like who their clients are and what names exist in their namespace 🤫. Collecting information about clients can be tricky depending on how the resolution system is implemented 🧐. For example, if the resolution information for a given publisher is widely replicated, hits would have to be recorded on each replicated copy 📊. Of course, figuring out whether a specific client is requesting a given name can also be approached from the other direction, by watching the client, as we saw above 👁️.

Some publishers are going to be publishing for a restricted audience 🔒. If they want to restrict access to a resource, that's the job of the repository that provides and restricts access to the resource 🗄️. If they want to keep the name and hints for a resource private, a public RDS might not be enough for their needs 🙈. Generally, a public RDS is meant for people who want customers to find their resources in an unconstrained way 🌻.

The last privacy issue for publishers is access control over URN resolution 🎯. This issue depends on how the publisher's authoritative (in the sense of "primary") URN resolver server is implemented 🖥️. URN resolver servers can be designed to require proof of identity before they issue resolution information. If the client doesn't have permission to access the requested URN, the service denies that such a URN exists 🫥. An encrypted protocol can also be used so that both the request and the response are obscured 🔐. Encryption is possible in this case because the identity of the final recipient is known (i.e. the URN server) 💜. So access control over URN resolution can and should be provided by resolver servers rather than by an RDS 👑✨.

4. The Framework ✨

okay so, with all those assumptions and guidelines in mind, we wrap up with a general framework that RDS designs can fit inside 💅 as I said earlier, this is just a suggested guide for RDS designers. Following it won't automatically make your design meet the guidelines, so that check has to happen separately 🫶 Any place where you don't comply should be clearly documented, bestie.

The framework is built on the syntax of a URN, as defined in RFC-2141 [6]. It looks like this:

URN:<NID>:<NSS>

The URN: part is a prefix on every URN and is what marks it as one 🎀 <NID> is the namespace identifier, and <NSS> is the namespace specific string. The NID sets the general syntax for every URN in its namespace. The NSS is probably split into delegated and subdelegated namespaces, and that split may show up in further syntax specs 🦋 In more complex setups, each delegated namespace gets to pick the syntax for the variable part that was delegated to it. In simpler namespaces, the parent namespace fully restricts the syntax.

For example, the DNS doesn't meet every URN requirement, but its syntax is completely restricted. Any extra structure has to be added as further refinements on the left, so it goes high order to low order, right to left 🌸 A delegated syntax could be one where a host is named by the DNS, and then to the right of it, separated by an "@", is a string whose internal ordering is defined by the file system on that host. That one can go high order to low order, left to right ✨ Honestly, much more complex and nested syntaxes should be possible too, especially since we need to grandfather existing namespaces 🌈

Resolving URNs needs rules for two reasons 💜 The first is to canonicalize namespaces that don't follow a straightforward ordering of URN components (right to left or left to right), which depends on the delegated naming authorities involved. The second is that rules may also be needed to work out the names of the RDS servers that get used in stages. Check out Figure 1 below to see how that goes.

                            URN:<NID><NSS>
                                 |
                                 |
                                 |
                                 |
                                 v
                       +-------------------+
                       |Global NID registry|
                       +-------------------+
                                 |
                                 |
                                 |
              (return rule or URN resolver service reference)
                                 |
                                 +----------------------------------+
                                 |                                  |
                       +->(apply rule to determine RDS server)      |
                       |         |                                  |
                       |         |                                  |
                       |         |                                  |
                       |    +----------+                            |
                       |    |RDS server|          +-----------------+
                       |    +----------+          |
                       |      |   |               v
                       |      |   |   (set of choices)
                       |      |   +----+----------(...)--------+
                       |   (rule)      |                       |
                       |      |        |                       |
                       |      |        |                       |
                       +------+        |                       |
                                       v                       v
                                  +----------+            +----------+
                                  |URN       |            |URN       |
                                  |resolver  |            |resolver  |
                                  |service   |            |service   |
                                  +----------+            +----------+

                       Figure 1: An RDS framework

The NID defines the top level syntax 🔥 That syntax decides whether the NID alone, or the NID plus some piece pulled out of the NSS (for the top level naming authority name), is used to find the first level server to contact. At every stage of the lookup, you get one of two things: either a new rule that generates the strings for yet another lookup (the identity of another RDS server, and maybe a string to resolve if it's different from the original URN), or a reference outside the RDS to a URN resolver service, which skips the RDS scheme entirely. Figure 1 shows the whole flow.

There are a few points worth noting about the RDS framework 👑 First, it leaves open which protocols, data organization, distribution and replication are needed to support a given RDS scheme. Second, it leaves open where the computations produced by the rules actually run. Third, it leaves open the possibility that partitioning (distribution) of the RDS database doesn't have to follow the same boundaries as name delegation. This might seem radical to some people, but if the information is stored in balanced B-trees, for example, the partitioning may not line up with those naming authority delegation boundaries (see [7]) 🧚 Lastly, it leaves open how access to the Global NID Registry works. Is it distributed to every client, or managed in widely distributed servers? It's important to note that a single RDS scheme is likely to support names from many or all naming schemes, as represented by their NIDs 💖

One thing Figure 1 doesn't show is that there may be more than one RDS available at any given time, so the system can evolve to new schemes 🦋 So the picture probably looks more like Figure 2.

                         URN:<NID>:<NSS>
                               |
                               |
                   +-----------+-------(...)-------+
                   |                               |
                   |                               |
                   |                               |
                   v                               v
         +---------------------+        +---------------------+
         |Global NID registry 1|        |Global NID registry N|
         +---------------------+        +---------------------+
                   .                               .
                   .                               .
                   .                               .


             Figure 2: More than one co-existing RDS scheme

If more than one RDS scheme is going to co-exist, they'll need to coordinate how they store and propagate information and modifications 🌈 The big deal is that you should generally assume all information is available through any operational RDS scheme. Publishers can't be expected to submit updates to more than one RDS scheme, so there has to be a straightforward mapping of information from one scheme to the others 😭 The transformation might only go one way. That happens when a newer RDS service replaces an older one, and the older one stops being kept up to date to nudge people over to the new one. At some point, updates may only be made to the newer one and not passed along to the older one, kind of like what libraries do with their catalogs 📚

This framework is here to point RDS scheme designers in a direction to start building 💅 It should be obvious that following it won't guarantee compliance with the guidelines, or even the assumptions described in Sections 2 and 3. Those have to be reviewed on their own as part of the design process 🙈 There's no single correct design that conforms to these guidelines. Also, preliminary proposals may not meet every guideline, but they should be expected to itemize and justify any non-compliance 🫶

5. Acknowledgments 🌸

Huge thank you to Lewis Girod, my co-author on a preliminary URN requirements document, who also gave insightful comments on this version 💜 Thanks also to Ron Daniel, especially for his many comments on my writing 🫶 I also want to recognize the contributors to an earlier URN framework document, the "Knoxville" group. There are way too many of you to name individually, but thank you 🎀 And finally, a massive thanks to everyone in the URN working group and on the mailing list (urn-ietf@bunyip.com) for the animated discussions on these topics and related ones 🔥

6. References 📚

[1] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February 1995.

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

[3] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[4] URN Working Group, "Namespace Identifier Requirements for URN Services," Work in Progress.

[5] Voydock, V. L., and Kent, S. T., "Security Mechanisms in High-Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, 1983, pp. 135-171.

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

[7] Slottow, E.G., "Engineering a Global Resolution Service," MIT-LCS-TR712, June, 1997. Currently available as <http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or <http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>.

7. Author's Address 🖋️

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

Phone: +1 617 253 6006
EMail: sollins@lcs.mit.edu

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ✨

📦 where this page comes from