RFC 1736

Functional Recommendations for Internet Resource Locators

📅 published February 1995, from ietf

RFC 1736: Functional Recommendations for Internet Resource Locators 🔗✨

okay bestie, title block first! 🎀

  • Network Working Group 🌐
  • Author: J. Kunze, IS&T, UC Berkeley 🧑‍💻
  • Category: Informational 📚 (it's informational, so it doesn't set a standard)
  • Date: February 1995 📅
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🤷‍♀️
  • Part: 1 of 2 🧩

Status of This Memo 📜

ok so this memo is just here to give info to the Internet community 💁‍♀️ It does not specify an Internet standard of any kind, and distribution is unlimited, so share it with whoever 🫶

1. Introduction ✨

okay so this doc lays out a minimum set of requirements for Internet resource locators 🔗 These are the things that tell you where a resource lives and how to get to it. Typical resources include network accessible documents, WAIS databases, FTP servers, and Telnet destinations 💻

Locators may apply to resources that aren't always network accessible, or ever, 🙈 like human beings and physical objects that have no electronic instantiation. That means objects whose existence isn't completely defined by digital objects like disk files. Wild, right? 🌸

A resource locator is a kind of resource identifier. Other kinds of resource identifiers let you attach names and descriptions to resources 🏷️ A resource name is a stable handle 💖 meant to refer to a resource long after the resource has moved or maybe even gone out of existence. A resource description is a body of meta-information that helps with resource search and selection 🔍

In this document, an Internet resource locator is a locator defined by an Internet resource location standard. A resource location standard works together with resource description and resource naming standards to make a whole infrastructure for network based information dissemination 🏗️ Mapping between locators, names, and descriptive identifiers is out of scope here, so it's not this doc's problem 💅

2. Overview of Problem 🌸

Network-based information resource providers need a way to describe where their resources are and how to access them 📣 Information systems users need client software that can interpret those access and location descriptions for them, in a relatively transparent way 🫶 Without a method like that, transparent and widely distributed, open information access on the Internet would be difficult if not impossible 😭

2.1 Defining the General Resource Locator 🧩

okay the requirements in this doc put restrictions on the general resource locator 🔒 To get what the Internet resource locator actually is, it helps to look at a general locator definition first, for contrast 👀

     Definition:  A general resource locator is an object
                  that describes the location of a resource.

this definition is deliberately super flexible 💜 It's there to hold the wildest corners of the big debate about resource location standards. The problem space is huge, but it's a useful backdrop for the requirements (coming later) that shrink it into something smaller and more manageable 🌈 A resource location standard shrinks it again by adding its own requirements 💅

Consider the definition in four parts: (1) a general resource locator is an object, (2) that describes, (3) the location of, (4) a resource. Let's go through them 🎀

2.1.1. A general resource locator is an object... 🧸

the object could be a complex data structure 🏛️ It could be a contiguous sequence of bytes 🔢 It could be a pair of latitude-longitude coordinates, or a three-color road map printed on paper 🗺️ It could even be a sequence of characters that can be printed on paper 🖨️

2.1.2. ...that describes 🗣️

in the fully general case, there are tons of ways a resource locator could describe the location 🤯 It could use a graphical or natural language description 🎨 It could be heavily encoded or compressed 🗜️ It could be lightly encoded and easy for humans to read 👀 The description could be a multi-level hierarchy with common semantics at each level 🪜 Or it could be a multi-level hierarchy with common semantics at only the first two levels, where the semantics below level two depend on the value given at level one 🌀 These are just a few possibilities, babe 💖

2.1.3. ...the location of 📍

a resource locator describes a location but it never guarantees that access can be established 🙅‍♀️ Clients following location instructions in a conformant resource locator usually want access, sure, but the resource might not exist anymore, or might not exist yet 😬 It might never exist at all, even though the locator keeps describing a location where a resource might exist (for example, it could be a placeholder where availability depends on something like a payment 💸)

Also, some potential resources, especially animate beings or physical objects with no electronic instantiation, make network access meaningless in some cases 🙃 Their locators might imply non-networked access, but again, access isn't guaranteed ✨

2.1.4. ...a resource. 🌷

a resource can be so many things! 🌟 Besides the non-networked or non-electronic resources we just mentioned, familiar examples are an electronic document, an image, a server (like FTP, Gopher, Telnet, or HTTP), or a collection of items (like a Gopher menu, an FTP directory, or an HTML page) 📂 Other examples come with multi-function protocols like Z39.50, which can do single round trip network access, session-oriented search refinement, and index browsing 🦋

2.2 Producers and Interpreters of Resource Locators 🎭

okay the big thing when we talk about locator requirements is parsability 🧠 That's the ability of an agent to recognize or understand a locator, in whole or in part. It helps to clearly tell apart the two main actions that happen with locators 💅

Resource locators get both produced and interpreted 🔁 Producers are bound by the resource location standards, which are in turn bound by the requirements in this document 📜 Interpreters of locators aren't bound by the requirements at all. They're the beneficiaries of them 🎁

2.2.1 Resource Locator Interpreters 🔍

a resource locator gets interpreted by interpreting agents, which this document just calls interpreters 🤖🧑 Interpreters can be human beings or software. On the way to establishing access based on info in a locator, you might use one or more interpreters 🛤️ A few examples of multiple interpreters working on one locator show that a locator might only be understandable in part by each interpreter, but still be understandable in its entirety when you combine them 🧩

In the first example, a software interpreter recognizes enough of a locator to know which external agent to forward it to 📨 That external agent could be a user, with the locator being a library call number. The software forwards the locator simply by displaying it 📺 Or the agent could be a network software layer that specializes in a particular communications protocol. Once the service is recognized, the locator gets forwarded to it along with an access request 🚀

In another example, a human interpreter might also recognize enough of a locator to know where to send it 👩‍💻 Here the person could be a user who recognizes a library call number as one, but doesn't understand the location info encoded in it. So they forward it to a library employee (an external agent) who knows how to establish access to the library resource 📚💖

A prerequisite to interpreting a locator is knowing when an object actually is a locator, or contains one or more locators 🕵️‍♀️ Some constrained environments make that easy to answer, like within HTML anchors or Gopher menu items 🪄 Less constrained environments, like running text, make it harder to answer without well-defined assumptions 😵‍💫 A resource location standard needs to make any such assumptions explicit 📝

2.2.2 Resource Locator Producers 🏭

resource locators get produced in lots of ways, and often by an agent that also interprets them 🔄 The provider of a resource can produce a locator for it and leave it where it's meant to be discovered, like an HTML page, a Gopher menu, or an announcement to an e-mail list 📬

non-providers of resources can be major producers of locators too 👑 For example, WWW client software produces locators by translating foreign resource locators (like Gopher menu items) into its own format 🌀 Some locator databases (like Archie) have been maintained by automated processes that produce locators for hundreds of thousands of FTP resources they "discover" on the Internet 🤖🔎

users are major producers of resource locators too 🫶 A user constructing one to share with others is responsible for conformance with locator standards 📏 Sometimes a user composes a resource locator based on an educated guess and submits it to client software to try to establish access 🤞 That user is a producer in a sense, but if the locator is purely for personal consumption, the user isn't bound by the requirements 💅 Some client software may even offer, as a service, to translate abbreviated, non-conformant locators that users typed in into working access instructions or into conformant locators (for example, by adding a domain name to an unqualified hostname) 🪄

2.3 Uniqueness of Resource Locators 🔑

the topic of a "uniqueness" requirement for resource locators has been discussed a lot 🗣️ This document looks at the following aspects of uniqueness, but deliberately rejects them as requirements 🙅‍♀️ Any resource location standard that takes this on is responsible for being clear about which aspects it addresses 📢

2.3.1. Uniqueness and Multiple Copies of a Resource 👯

a uniqueness requirement might say that no identical copies of a resource may exist. This document doesn't make that requirement 🙌

2.3.2. Uniqueness and Deterministic Access 🎯

a uniqueness requirement might say that the same resource accessed in one attempt will also be the result of any other successful attempt. This document doesn't make that requirement either, and it doesn't define "sameness" 🤷‍♀️ It's inappropriate for a resource location standard to define "sameness" among resources 🚫

2.3.3. Uniqueness and Multiple Locators 🔗🔗

a uniqueness requirement might say that a resource has no more than one locator, unless all of those locators are the same. This document doesn't make that requirement, and it doesn't define "sameness" among locators 🙅‍♀️ (A standard might do that using, for example, canonicalization rules 🧼)

2.3.4. Uniqueness, Ambiguity, and Multiple Objects per Access 🧐

a uniqueness requirement might say that a resource locator identifies exactly one object, as opposed to several objects 💭 This document doesn't make any general definition of what counts as one object, several objects, or one object made up of several objects 🫠

3. Resource Access and Availability ✨

okay so a locator NEVER guarantees access 🙃 but getting access is literally the whole reason locators exist, so it's the main thing they're for 💅 it's considered rude to advertise a locator for something that will never be reachable (whether it's a "networkable" resource or not), but it's totally normal for access to start failing more and more as the locator gets older 💀

there are SO many reasons access can fail 😭 providers can move, replace, or delete resources over time, and how often that happens depends on the kind of resource and the provider's habits, among other stuff 🌸 a locator that follows a location standard but fails for one of these reasons is called "invalid" in this doc 🦋 and "invalid locator" does NOT mean malformed or non-conformant locators, that's a totally different vibe 🙈 resource naming standards are the ones that deal with the invalid locator problem, so that's their job 💜

then there's the stuff that makes things unavailable on purpose or by accident ⏰ provider support policies can shut resources down during predictable windows (like certain hours of the day or certain days of the year), or when the system is super busy. rights clearance restrictions that can't be written into a locator also block certain users 🚫 and heavy network load can stop access too. in those situations this doc calls the resource "unavailable" 🔥 a locator can be valid AND point to something that's unavailable at the same time, which is kind of iconic if you think about it ✨ resource description standards cover some parts of availability, among other things 🍓

overall, the chance that a given locator actually works goes down over time, and it depends on stuff like the resource itself, the provider's support policies, and how loaded the network is 📉🌈

4. Requirements List for Internet Resource Locators 🎀

okay so this is the checklist 📝 we take the general locators from section 2.1 and apply these requirements to them. whatever's left over is the group called Internet locators in this doc, and that group is ready to be refined by an Internet resource location standard 💅 some requirements are about how locators get encoded, and others are about what they actually do 🧚

one requirement from the original draft list got dropped 😭 after a LOT of discussion everyone agreed it was not practical to meet. it said that software could recognize Internet locators with high reliability inside relatively unstructured stuff, like running ASCII text. honestly rip to that one 💀

4.1 Locators are transient.

the chance that a given Internet resource locator leads to successful access goes down over time 📉 more stable resource identifier schemes are covered by resource naming standards, and they are outside the scope of a resource location standard 🦋

4.2 Locators have global scope.

the name space of resource locators covers the ENTIRE world 🌍 the chance of successful access using an Internet locator has NO connection, apart from resource availability, to where the client is located geographically or on the Internet 🫶

4.3 Locators are parsable.

Internet locators can be broken down into complete constituent parts, enough for interpreters (software or human) to try accessing the resource if they want to 🔍 these requirements don't actually bind interpreters, but there are three points worth emphasizing 👑

4.3.1 A given kind of locator may still be parsable even if a given interpreter cannot parse it.

4.3.2 Parsable by users does not imply readily parsable by untrained users.

4.3.3 A given locator need not be completely parsable by any one interpreter as long as a combination of interpreters can parse it completely.

4.4 Locators can be readily distinguished from naming and descriptive identifiers that may occupy the same name space.

during a transition period (which could be indefinite, honestly 🙃), other kinds of resource identifiers are expected to hang out in the same data structures alongside Internet locators 🧚

4.5 Locators are "transport-friendly".

Internet locators can be sent from user to user (e.g., via e-mail) over Internet standard communications protocols without losing or corrupting any information ✨📨

4.6 Locators are human transcribable.

users can copy Internet locators from one medium to another (like voice to paper, or paper to keyboard) without losing or corrupting any information 📝 it's not required to be comfy though 😭

4.7 An Internet locator consists of a service and an opaque parameter package.

the parameter package only has meaning to the service it's paired with 🎀 and a service is an abstract access method, which can be a software tool, an institution, or a network protocol 💜 the parameter package might contain service-specific access instructions. to protect creative development of new services, there's an extensible class of services where NO parameter package semantics shared across services can be assumed 🌈

4.8 The set of services is extensible.

new services can be added over time 🚀💖

4.9 Locators contain no information about the resource other than that required by the access mechanism.

the whole point of an Internet locator is just to describe where a resource is located ✨ not other properties like its type, size, modification date, etc. those belong in a resource description standard 🍓

5. Security Considerations 🚨

okay this part is SERIOUS bestie, so listen up 🫢 the requirements themselves don't have direct security implications, BUT apps built on standards that meet them might need to think about two potential vulnerabilities 😱

first, locators are transient. so a client using an invalid locator could accidentally end up at a resource that was NOT the intended target 💀 for example, a hostname gets unregistered for a while and then re-registered. a locator that wasn't valid during that gap might lead to a resource again, but maybe one that only pretends to be the original 🎭👀

second, a locator is a service plus a parameter package, so the processing freedom can be HUGE, depending on the service 😳 a server is vulnerable unless it properly restricts its input parameters 🔒 like, a server that advertises locators for certain local filesystem objects might accidentally open a door that lets other filesystem objects get accessed 🚪💥

clients are also vulnerable unless they understand the limitations of the service they're using ⚠️ for example, a client that trusts a locator from a sketchy source might accidentally trigger something that charges a user account 💸 having a clear definition of service limitations could help with some of these concerns 🫶

for services that offer a LOT of user freedom (remote login, for example), putting user commands inside a locator creates vulnerabilities 😬 with careful command screening, you can avoid the nasty effects of accidentally running an embedded command (at the client or the server) like "rm -fr *" 🗑️💀

6. Conclusion 💖

so resource location standards, which define Internet resource locators, give providers a way to describe access info for their resources 🎁 and they let client devs reach totally different resources while hiding the access details from users ✨

a few minimum requirements are what make an Internet locator different from a general one 🔍 Internet resource locators are impermanent handles that are qualified enough for resource access to NOT depend on client location in general 🌍 locators can be recognized and parsed, and they can get through a bunch of human and Internet communication methods totally unscathed 🦋

an Internet resource locator is a service plus access parameters that mean something to that service 🧚 the form of the locator doesn't discourage adding new services or moving to other resource identifiers 🚀 and the clean line between resource location, resource naming, and resource description standards stays intact, because Internet locators only carry as much info as an access mechanism actually needs 👑💅

7. Acknowledgements 🫶

the core requirements of this doc came from a collab between the following people at the November 1993 IETF meeting in Houston, Texas 🤝✨

  • Farhad Ankelesaria, University of Minnesota
  • John Curran, NEARNET
  • Peter Deutsch, Bunyip
  • Alan Emtage, Bunyip
  • Jim Fullton, CNIDR
  • Kevin Gamiel, CNIDR
  • Joan Gargano, University of California at Davis
  • John Kunze, University of California at Berkeley
  • Clifford Lynch, University of California
  • Lars-Gunnar Olson, Swedish University of Agriculture
  • Mark McCahill, University of Minnesota
  • Michael Mealing, Georgia Tech
  • Mitra, Pandora Systems
  • Pete Percival, Indiana University
  • Margaret St. Pierre, WAIS, Inc.
  • Rickard Schoultz, KTH
  • Janet Vratny, Apple Computer Library
  • Chris Weider, Bunyip

8. Author's Address 🧚

John A. Kunze
Information Systems and Technology
293 Evans Hall
Berkeley, CA  94720

Phone: (510) 642-1530
Fax:   (510) 643-5385
EMail: jak@violet.berkeley.edu

that's a wrap on the whole doc, bestie!! 🌈💜🦋✨ you're the GOAT for sticking with it 🫶👑

📦 where this page comes from