RFC 2483

URI Resolution Services Necessary for URN Resolution

📅 published January 1999, from ietf

RFC 2483: URI Resolution Services Necessary for URN Resolution 💖

Okay bestie, this is RFC 2483 🎀. M. Mealling from Network Solutions, Inc. and R. Daniel, Jr. from Los Alamos National Laboratory wrote it in January 1999. It's an Experimental doc 🧪, and its header doesn't list anything it obsoletes or updates ✨.

Status of This Memo 📝

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

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

Abstract 🌸

Okay so, retrieving the resource behind a Uniform Resource Identifier (URI) [1] is only ONE thing you can do with a URI 👀. You could also ask for a list of other identifiers that are aliases for the original URI, or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) get discussed in this document too, but only as descriptions of resources, not as identifiers 🦋.

A service in the network that gives you access to a resource might offer one or some of these options, but it doesn't need to offer all of them 💅. This memo lays out an initial set of these operations that can be used to describe the interactions a given access service provides. It also suggests guidelines that should be adhered to when those operations get encoded in a protocol 🧚.

1. Introduction 🍓

Bestie, while people were working out current proposals [2] for URNs [3], it became super clear that making servers handle every single function, or making clients process all the random info a server sends back, was unrealistic and a total barrier to adoption 😭. We needed a way for a client to identify one server that specializes in the complex stuff and another that specializes in the simple (but fast) stuff 🔥. Also, later conversations made it obvious that, in most cases, some operations were inappropriate or hard to do for certain identifiers 🙈.

The Problem

When you're learning about a resource on the Internet, there are a bunch of possible functions that might matter, like finding locators, names, descriptions, and accessing the resource itself ✨. A given service might only support a subset of these, so it's important to describe an access service by the types of functions it supports and the resources it has some knowledge of. For example, in the framework for an RDS described in [5], the RDS itself may provide URLs [6][7], while the resolvers may provide descriptions, URLs, or even the resources themselves. The design of an RDS, as proposed in RFC 2168 [2], may be more generous and provide all of the above 💖.

This problem needs a well understood set of identifiers that specify those operations. But an exhaustive set would be both impossible and not very necessary 🙃. So this document lists several operations and also lays out requirements for specifying new operations 🎀.

The purpose of this document is to define a list of these functions, give them short names, and then use them to define the interface to an access service 💜. Earlier versions of this document talked about services where the arguments were specific types of URIs, like URNs or URLs. Those services were called "N2L" and "L2L", for example. That's been changed in favor of the more general URI form, which is so much cleaner 🌈.

Design Criteria

To meet these requirements, a fairly simple design criteria was used 🧁. Identifying each operation with some token, so that its operands, algorithm, and errors are known, turned out to be enough ✅.

2. General Specification 📚

To give a framework both for the specifications in this document and for future work by others, the guidelines below are suggested for documents that seek to specify new operations 🫶. Any specification of a member of this set of operations should address these issues with respect to its operands, algorithm, output, and errors.

Because the list of functions is small, a registration mechanism was dismissed as premature 🌷. If the list grows, a registration mechanism will probably be needed.

Also, because this document is experimental and the systems that use its specifications are experimental too, the use of words like MUST and SHALL is limited 🧪. Where they are used, they reflect a case where this specification could cause harm to existing, non-experimental systems such as HTTP and URNs 😬. So the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 💅.

2.1 Operands

Operands must contain the following pieces of information:

  • name of the operation
  • case insensitive mnemonic for the operation
  • number of operands
  • type of each operand
  • format of each operand

2.2 Algorithm

The exact algorithm for the operation must either be specified completely or it must be considered opaque and defined by the server or application 🔮.

2.3 Output

Output must specify one of the following:

  • there is no output
  • the output is undefined
  • the output itself and its content
  • the fact that the output is an object and the object's type and format
  • any non-protocol specific errors

2.4 Error Conditions

All errors that are considered applicable across all implementations and application environments must be included. Errors that depend on the system conveying the service are not included. Thus, many of the expected errors, such as service availability or operation syntax, are not included in this document, since they are implementation dependent 🙈.

2.5 Security Considerations

🚨 Security is serious, bestie. Any security considerations relating to the service provided must be specified.

This does NOT include considerations dealing with the protocol used to convey the service, or those that normally accompany the results of the service. For example, a service that returned a single URL would need to discuss the situation where someone maliciously inserts an incorrect URL into the resolver, but NOT the case where someone sends personal information across the Internet to the resource identified by the correct URL 🕵️‍♀️.

3. Encoding The Operations 🎀

To be useful, these operations have to be used within some system or protocol 🧩. In many cases, those systems and protocols will place restrictions on which operations make sense and how the ones that do are syntactically represented. It's enough for those protocols to define new operations within their own protocol specification documents, but care should be taken to make this fact well known 📣.

Also, a given system or protocol will have its own output specifications that may restrict the output formats of a given operation. Additionally, a given protocol may have a better solution for output than the ones given here. For example, the result of an operation that converts a URI to more than one URL may be encoded in a protocol-specific manner that conveys information about how close each resource is on the network 🗺️.

So the requirements on encoding these operations within a given system are as follows:

  • which subset of the operations are allowed
  • how the operator is encoded
  • how the operands are encoded
  • how the error codes are returned

The text/uri-list MIME Media Type is specified in Section 5. This Media Type is merely a suggestion for experimental systems that need a simple implementation. It's included here only as an example to show completeness, however simple it may be 🫧.

4. The Incomplete Set 🦄

4.1 I2L (URI to URL)

  • Name: URI to URL
  • Mnemonic: I2L
  • Number of Operands: 1
  • Type of Each Operand: First operand is a URI.
  • Format of Each Operand: First operand is encoded as a URI.
  • Algorithm: Opaque
  • Output: One and only one URL
  • Errors Conditions:
    • Malformed URI
    • URI is syntactically valid but does not exist in any form.
    • URI exists but there is no available output from this operation.
    • URI existed in the past but nothing is currently known about it.
    • Access denied
  • Security Considerations:
    • Malicious Redirection: One of the fundamental dangers with any service like this is that a malicious entry in a resolver's database will cause clients to resolve the URI into the wrong URL. The possible intent may be to cause the client to retrieve a resource containing fraudulent or damaging material 🚫.
    • Denial of Service: By removing the URL that the URI maps to, a malicious intruder may remove the client's ability to retrieve the resource 💀.

This operation maps a single URI to a single URL 🎯. It's used by lightweight clients that can't select from a list of URLs or understand a URC. The algorithm for this mapping depends on the URI scheme 🧠.

4.2 I2Ls (URI to URLs)

  • Name: URI to URLs
  • Mnemonic: I2LS
  • Number of Operands: 1
  • Type of Each Operand: First operand is a URI.
  • Format of Each Operand: First operand is encoded as a URI.
  • Algorithm: Opaque
  • Output: A list of zero or more URLs
  • Errors:
    • Malformed URI
    • URI is syntactically valid but does not exist in any form.
    • URI exists but there is no available output from this operation.
    • URI existed in the past but nothing is currently known about it.
    • Access denied
  • Security Considerations:
    • Malicious Redirection (see I2L)
    • Denial of Service (see I2L)

This operation maps a single URI to 0 or more URLs 🌟. It's used by a client that can pick from a list of URLs based on criteria that matter to the client 💖. The client should not make any assumptions about the order of the URLs returned. No matter the particular media type, the result should be a list of the URLs that may be used to obtain an instance of the resource identified by the URI 🛤️. All URIs shall be encoded according to the URL [7] and URN [3] specifications 📐.

4.3 I2R (URI to Resource)

  • Name: URI to Resource
  • Mnemonic: I2R
  • Number of Operands: 1
  • Type of Each Operand: First operand is a URI.
  • Format of Each Operand: First operand is encoded as a URI.
  • Algorithm: Opaque
  • Output: An instance of the resource named by the URI.
  • Errors:
    • Malformed URI
    • URI is syntactically valid but does not exist in any form.
    • URI exists but there is no available output from this operation.
    • URI existed in the past but nothing is currently known about it.
    • Access denied
  • Security Considerations:
    • Malicious Redirection (see I2L)
    • Denial of Service (see I2L)

This operation returns a single instance of the resource named by the URI 🎁. The format of the output depends on the resource itself 🫧.

4.4 I2Rs (URI to Resources) 🎀

  • Name: URI to Resources
  • Mnemonic: I2Rs
  • Number of Operands: 1
  • Type of Each Operand: First operand is a URI.
  • Format of Each Operand: First operand is encoded as a URI.
  • Algorithm: Opaque
  • Output: Zero or more instances of the resource named by the URI.
  • Errors:
    • Malformed URI
    • URI is syntactically valid but does not exist in any form.
    • URI exists but there is no available output from this operation.
    • URI existed in the past but nothing is currently known about it.
    • Access denied
  • Security Considerations:
    • Malicious Redirection (see I2L)
    • Denial of Service (see I2L)

okay so this operation is for when you want multiple versions of one resource at once, like a GIF and a JPEG of the same image 🖼️✨ the naming authority that issued the URI is the one who decides whether those versions count as "the same" resource, so that's their call, not yours 💅

The output SHALL be a MIME multipart/alternative [4] message, with each alternative version of the resource in its own body part 🌸 If there is only one version of the resource, it MAY be returned without the multipart/alternative wrapper. Simple and iconic 🫶

4.5 I2C (URI to URC) 🦋

  • Name: URI to URC
  • Mnemonic: I2C
  • Number of Operands: 1
  • Type of Each Operand: First operand is a URI.
  • Format of Each Operand: First operand is encoded as a URI.
  • Algorithm: Opaque
  • Output: A URC
  • Errors:
    • Malformed URI
    • URI is syntactically valid but does not exist in any form.
    • URI exists but there is no available output from this operation.
    • URI existed in the past but nothing is currently known about it.
    • Access denied
  • Security Considerations:
    • Malicious Redirection (see I2L)
    • Denial of Service (see I2L)

Uniform Resource Characteristics (URCs) are descriptions of resources 📚 This request lets the client grab a description of the thing a URI points to, instead of the thing itself or just its URLs 🙈 That description could be a bibliographic citation, a digital signature, or a revision history, which is so main character energy 👑

This memo does not specify what goes inside a URC response. That content is expected to vary from one server to another, so don't go looking for a fixed format here 💀

4.6 I2CS (URI to URCs) 🌈

  • Name: URI to URCs
  • Mnemonic: I2CS
  • Number of Operands: 1
  • Type of Each Operand: First operand is a URI.
  • Format of Each Operand: First operand is encoded as a URI.
  • Algorithm: Opaque
  • Output: Zero or more URCs
  • Errors:
    • Malformed URI
    • URI is syntactically valid but does not exist in any form.
    • URI exists but there is no available output from this operation.
    • URI existed in the past but nothing is currently known about it.
    • Access denied
  • Security Considerations:
    • Malicious Redirection (see I2L)
    • Denial of Service (see I2L)

URCs can come in different formats and types 🧚 This is the plural version of the one above: it returns zero or more URCs that fit the given URI, so you get the whole gallery, not just one piece 🖼️💜

4.7 I2N (URI to URN) 👑

  • Name: URI to URN
  • Mnemonic: I2N
  • Number of Operands: 1
  • Type of Each Operand: First operand is a URN.
  • Format of Each Operand: First operand is encoded as a URI.
  • Algorithm: Opaque
  • Output: One and only one URN
  • Errors:
    • Malformed URI
    • URI is syntactically valid but does not exist in any form.
    • URI exists but there is no available output from this operation.
    • URI existed in the past but nothing is currently known about it.
    • Access denied
  • Security Considerations:
    • Malicious Redirection (see I2L)
    • Denial of Service (see I2L)

Okay, this one is a little plot twist 😭 URNs are supposed to identify one and only one resource, but that does NOT mean a resource can only have one URN 🙃 Say one organization wants to call a resource foo, and another organization, after agreeing with the first, wants to call it bar. Both orgs can agree that both names refer to the same resource, and that the URNs foo and bar are equivalent. Two names, one icon 🦋

The result is a URN, known to the server, that identifies the same resource as the input URN ✨

Be extremely careful with this service, bestie. It's basically playing with the idea of equality for URNs, and equality is super domain specific. A URN for a weather map on one particular day and a URN for the map as it changes day to day would not be returned here, because they point to different resources 🌦️ Some other kind of temporary equivalence is doing the work there. This service only deals with resources that have two different names, where both name assigners have agreed the names are bound together, so each name can be used in place of the other and the meaning does not change. Both namespaces MUST have agreed to that. No vibes-based equality allowed 💅

4.8 I2Ns (URI to URNs) 🍓

  • Name: URI to URNs
  • Mnemonic: I2NS
  • Number of Operands: 1
  • Type of Each Operand: First operand is a URI.
  • Format of Each Operand: First operand is encoded as a URI.
  • Algorithm: Opaque
  • Output: A list of URNs
  • Errors:
    • Malformed URI
    • URI is syntactically valid but does not exist in any form.
    • URI exists but there is no available output from this operation.
    • URI existed in the past but nothing is currently known about it.
    • Access denied
  • Security Considerations:
    • Malicious Redirection (see I2L)
    • Denial of Service (see I2L)

This one is basically the plural of I2N 🫶 It returns zero or more URNs, following the same criteria and cautions as the I2N operation, so everything from the section above applies here too, no skipping 💖

4.9 I=I (Is URI equal to URI): 💜

  • Name: URI = URI
  • Mnemonic: I=I
  • Number of Operands: 2
  • Type of Each Operand: Both operands are URIs.
  • Format of Each Operand: Both operands are encoded as a URIs.
  • Algorithm: Opaque
  • Output: TRUE or FALSE
  • Errors:
    • Malformed URIs
    • URIs are syntactically valid but do not exist in any form.
    • URIs exist but there is no available output from this operation.
    • URIs existed in the past but nothing is currently known about them.
    • Access denied
  • Security Considerations:
    • Malicious Redirection (see I2L)
    • Denial of Service (see I2L)

This operation asks the server whether two given URIs count as equal, in the server's opinion 🔮 The algorithm for deciding equality is opaque, so you don't get to peek inside 🙈 No claims are made about whether the URIs have the characteristics of URNs or URLs, so don't assume either way 🌸

5. The text/uri-list Internet Media Type 🎀

okay bestie, so a bunch of the resolution service requests (I2Ls and I2Ns especially) end up sending a whole LIST of URIs back to the client 📜. the text/uri-list Internet Media Type exists so that list has a super simple format that machines can process automatically 🤖💖. it's giving tidy and no-nonsense ✨

Here's a copy of the IANA registration for text/uri-list, exactly as it was filed 📋:

   Date: Fri, 18 Apr 97 08:36:07 PDT
   From: Ron Daniel Jr. <rdaniel@lanl.gov>
   To: iana@iana.org, rdaniel@lanl.gov
   Subject: Request for MIME media type Text/IETF Tree - uri-list

   Name : Ron Daniel Jr.

   E-mail : rdaniel@lanl.gov

   MIME media type name : Text

   MIME subtype name : IETF Tree -uri-list

   Required parameters : none

   Optional parameters : charset

   Currently, URIs can be represented using US-ASCII. However, there
   are many non-standard URIs which use special character sets.
   Discussion of how to best achieve internationalization of URIs is
   underway. This registration will be updated with a discussion of the
   URI charsets once that discussion has concluded.

   Encoding considerations : Some transfer protocols, such as SMTP,
   place limits on the length of lines. Very long URIs might exceed
   those limits. Systems must therefore be prepared to use a suitable
   content transfer encoding. This is anticipated to be a rare
   occurance.

   Security considerations : Client software should be aware of the
   security considerations of URIs.  For example, accessing some URIs
   can result in sending a death threat to a head of state, frequently
   prompting a visit from the relevant protective service.  Accessing
   other URIs may result in financial obligations, or access to
   resources considered inappropriate by one's employer.

   While the legitimate provider of a uri-list could exploit these
   properties for good or ill, it is more likely that uri-lists will be
   falsified in order to exploit such characteristics of URIs.

   Additionally, the lookup and reverse lookup potential of the uri-
   list may be attractive to traffic analysts. URI lists may also
   reveal confidential information, such as the location of sensitive
   information.

   Because of these considerations, external confidentiality measures
   should be available to protect uri-list responses when appropriate.

   Interoperability considerations : none known

   Published specification : Uniform Resource Locators (URLs) and
   Uniform Resource Names (URNs) are two instances of the more general
   class of identifiers known as Uniform Resource Identifiers (URIs).
   URN resolution methods frequently wish to return lists of URLs for a
   resource so that fault-tolerance and load balancing can be achieved.
   The text/uri-list format is intended to be a very simple format for
   communicating such lists of URLs (and URNs) in a form suitable for
   automatic processing.

   The format of text/uri-list resources is:

   1) Any lines beginning with the '#' character are comment lines
       and are ignored during processing. (Note that URIs may contain
       the '#' character, so it is only a comment character when it is
       the first character on a line.)

   2) The remaining non-comment lines shall be URIs (URNs or URLs),
       encoded according to the URL or URN specifications (RFC2141,
       RFC1738 and RFC2396). Each URI shall appear on one and only one
       line. Very long URIs are not broken in the text/uri-list format.
       Content-transfer-encodings may be used to enforce line length
       limitations.

   3) As for all text/* formats, lines are terminated with a CRLF pair.

   In applications where one URI has been mapped to a list of URIs, the
   first line of the text/uri-list response SHOULD be a comment giving
   the original URI.

   An example of the format is given below:

     # urn:isbn:0-201-08372-8
     http://www.huh.org/books/foo.html
     http://www.huh.org/books/foo.pdf
     ftp://ftp.foo.org/books/foo.txt

   Applications which use this media : URN resolvers are the initial
   applications. Web clients and proxies are applications that are
   likely to support this format in the future.

   Additional information :

   1. Magic number(s) : none at this time
   2. File extension(s) : .uris or .uri recommended
   3. Macintosh file type code : URIs recommended

   This media type is the product of the URN working group of the IETF.

   Person to contact for further information :

   1. Name : Ron Daniel Jr.
   2. E-mail : rdaniel@lanl.gov

   Intended usage : Limited Use
   The text/uri-list media type is intended for use in applications
   which utilize URIs for replicated resources.

   Author/Change controller : Ron Daniel Jr.
   Los Alamos National Laboratory
   rdaniel@lanl.gov

Now, the same rule shows up again here 💅: in applications where one URI has been mapped to a list of URIs, like when you send an I2Ls request, the first line of the text/uri-list response SHOULD be a comment giving the original URI. Figure 1 shows what that looks like for the I2L request 🦋.

6. Security Considerations 🔐

okay this section is serious, so let's go 🫶. communications with a server might be really sensitive. some servers hold info that should only go to authorized users 🙈. the results from servers can be spoofed too, especially once electronic commerce is everywhere, because there's money to be made by sending people to pirate repositories instead of the ones that pay royalties to rights-holders 💀. server requests can also catch the eye of traffic analysts, and requests can be spoofed as well 😭.

the "Access denied" message is only safe when the system can actually convey an authenticated concept of access control. so the "Access denied" message should only be returned by systems that have an appropriate method of determining access control 🔥.

7. References 📚

Here's the full reference list, every single entry, exactly as written:

[1] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
    Unifying Syntax for the Expression of Names and Addresses of
    Objects on the Network as Used in the World-Wide Web", RFC 1630,
    June 1994.

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

[3] Moats, R., "URN Syntax", RFC 2141, January 1997.

[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
    Extensions (MIME) Part One: Format of Internet Message Bodies",
    RFC 2045, November 1996.

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

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

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

8. Authors' Addresses 🧚

the authors, with their contact details, exactly as they were given 💌:

Michael Mealling
Network Solutions
505 Huntmar Park Drive
Herndon, VA 22070

Phone: (703) 742-0400
Fax:   (703) 742-9552
EMail: michaelm@rwhois.net


Ron Daniel
Advanced Computing Lab, MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA, 87545

Phone: (505) 665-0597
Fax:   (505) 665-4939
EMail: rdaniel@lanl.gov

this is the legal bit, so it stays word-for-word, no cap 🙏:

Copyright (C) The Internet Society (1999).  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