RFC 2169

RFC 2169 🎀

Okay bestie, let's talk about RFC 2169 💅 It's called A Trivial Convention for using HTTP in URN Resolution, written by R. Daniel from Los Alamos National Laboratory for the Network Working Group in June 1997. It's marked as Category: Experimental 🧪 and the title block doesn't list anything it obsoletes or updates ✨

Status of This Memo 📜

This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind 🙈 Discussion and suggestions for improvement are requested 💬 and distribution of this memo is unlimited 🌈

Abstract 🦋

So the Uniform Resource Names Working Group (URN-WG) got together to specify persistent, location-independent names for network-accessible resources, plus resolution mechanisms to fetch those resources from a name 🧚 At this point the URN-WG is looking at one particular resolution mechanism, the NAPTR proposal [1]. That proposal explains how a client can find a "resolver" for a URN.

A resolver is a database that can tell you things about the resource a URN identifies, like where it lives, a bibliographic description, or even the resource itself 📚 The NAPTR proposal doesn't say what protocol the client uses to talk to the resolver. Instead, the NAPTR resource record has a field that says which "resolution protocol" and "resolution service requests" the resolver offers 💜

This document specifies the "THTTP" resolution protocol, which is a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses ✨ The big goal of THTTP is to be simple to implement, so existing HTTP servers can easily add URN resolution 🫶 The databases used by early resolvers are expected to stay useful once more sophisticated resolution protocols show up later 👑

1.0 Introduction ✨

The NAPTR specification [1] defined a new DNS resource record that can be used to discover resolvers for Uniform Resource Identifiers 🔍 That record has a "services" field for the "resolution protocol" the resolver speaks, plus the "resolution services" it offers. The protocols named in that specification are Z3950, THTTP, RCDS, HDL, and RWHOIS, and the list is expected to grow over time 🌸 It also lists a bunch of resolution services, like N2L (given a URN, return a URL) and N2R (given a URN, return the named resource), and more 💅

This document specifies the "THTTP" (Trivial HTTP) resolution protocol 🦋 THTTP is a simple convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. The main goal is a URN resolution protocol that can be dropped into existing HTTP daemons without drama 💖 This document has a secondary purpose too: it shows what information a URN resolution protocol needs to spell out 🧠 One resolution protocol people expect to see is an extension of HTTP with new methods for the resolution services. That's why we call this one "THTTP", so the name "HTTP" stays free for those later developments 🎀

The reader is assumed to already know the HTTP/1.0 [2] and 1.1 [3] specifications 📖 Implementors of this specification should be familiar with CGI scripts, or server-specific interfaces, for database lookups 🧑‍💻

2.0 General Approach 🌈

The general approach for encoding resolution service requests in THTTP is honestly super simple 🥰

    GET /uri-res/<service>?<uri>  HTTP/1.0

For example, if we have the URN "urn:foo:12345-54321" and we want a URL, we'd send this request:

    GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.0

The request could also be sent as an HTTP 1.1 request. It would look like this:

    GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.1
    Host: <whatever host we are sending the request to>

Responses from the HTTP server follow standard HTTP practice 💌 Status codes such as 200 (OK) or 404 (Not Found) shall be returned. The normal rules for cachability, negotiating formats, and so on still apply ⭐

Handling these requests on the server side is easy with CGI or other server-specific extension mechanisms 🧚 CGI scripts will see the incoming URI in the QUERY_STRING environment variable. Any %encoded characters in the URN stay %encoded in that string. The script can take the URN, look it up in a database, and send back the info that was asked for 💜

One caveat to keep in mind! The URN syntax document [4] talks about lexical equivalence and requires resolvers to return identical results for URNs that are lexically equivalent. Implementors of this specification must be careful to obey that rule 🙈

For example, the two requests below MUST return identical results, since the URNs are lexically equivalent 💀

    GET /uri-res/N2L?urn:cid:foo@huh.com HTTP/1.0
    GET /uri-res/N2L?URN:CID:foo@huh.com HTTP/1.0

3.0 Service-specific details 🎀

This section goes through the resolution services set up in the URN services document [5]. For each one, it explains how to encode it, how the results come back, and any special status codes that are likely to show up 🦋

Unless stated otherwise, THTTP requests are formed using the simple convention above, whether for HTTP/1.0 or HTTP/1.1. The response is assumed to be an entity with normal headers and a body, unless stated otherwise. (N2L is the only request that doesn't need to return a body 🫶)

3.1 N2L (URN to URL) 🔗

The request is encoded as above. The URL MUST be returned in a Location: header, because that's the most common thing a user wants: the resource itself 💖 If the lookup works, a 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the 303 status code 🌸 HTTP/1.0 clients should be sent the 302 (Moved temporarily) status code, unless the resolver has a particular reason to use 301 (moved permanently) or 304 (not modified) codes ✨

Access controls can be applied to this service, or any other resolution service request, so the 401 (unauthorized) and 403 (forbidden) status codes are legal responses 🔐 The server may want to include a body in the response that explains why access was refused, and/or gives alternate info about the resource, like the price it costs to get the resource's URL 💅

3.2 N2Ls (URN to URLs) 📚

The request is encoded as above. The result is a list of 0 or more URLs 🌈 The Internet Media Type (aka ContentType) of the result can be negotiated using standard HTTP mechanisms if you want. At a minimum, the resolver should support the text/uri-list media type (see Appendix A for the definition of this media type). That media type is great for machine-processing of the list of URLs 🤖 Resolvers can also return the results as text/html, text/plain, or any other media type they think is suitable 🎀

No matter the media type, the result MUST be a list of the URLs that can be used to get an instance of the resource identified by the URN 👑 All URIs shall be encoded according to the URI specification [6] 🧠

If the client asked for the result to be returned as text/html or application/html, the result should be a valid HTML document containing this fragment 💌

<UL>
<LI><A HREF="...url 1...">...url 1...</A>
<LI><A HREF="...url 2...">...url 2...</A>
 etc.
</UL>

where the strings ...url n... get replaced by the n'th URL in the list 🫶

3.3 N2R (URN to Resource) 🦋

The request is encoded as above. The resource comes back using standard HTTP mechanisms 🎁 The request can be modified with the Accept: header, just like normal HTTP, to say the result should be given in a preferred Internet Media Type 💜

3.4 N2Rs (URN to Resources) 🖼️

This resolution service returns multiple instances of a resource, like GIF and JPEG versions of an image 🌷 Whether the resources are "the same" is up to the naming authority that issued the URN, not the resolver. Lowkey a very important distinction 😌

The request is encoded as above. The result shall be a MIME multipart/alternative message, with the alternative versions of the resource in separate body parts 💖 If there's only one version of the resource identified by the URN, it MAY be returned without the multipart/alternative wrapper ✨ Resolver software SHOULD look at the Accept: header, if there is one, and only return versions of the resource that are acceptable according to that header 🫧

text/uri-list Internet Media Type once that registration has been performed].

okay so several of the resolution service requests, like N2Ls, N2Ns, L2Ns, and L2Ls, hand the client back a whole list of URIs 📋. The text/uri-list Internet Media Type exists to give that list a simple format that software can process automatically 💖.

Here's how the format works 👇

1. Any lines beginning with the # character are comment lines and are ignored during processing. (Note that # is a character that may appear in URIs, so it only denotes a comment when it is the first character on a line.) ✨
2. The remaining non-comment lines MUST be URIs (URNs or URLs), encoded according to the URI specification RFC[6]. Each URI shall appear on one and only one line. 🎀
3. As for all text/* formats, lines are terminated with a CR LF pair, although clients should be liberal in accepting lines with only one of those characters. 🌸

In applications where one URI has been mapped to a list of URIs, such as in response to the N2Ls request, the first line of the text/uri-list response SHOULD be a comment giving the original URI. This is the part where the original URI gets to be the star 🌟.

Here's an example of what the N2L result looks like 💅

# urn:cid:foo@huh.org
http://www.huh.org/cid/foo.html
http://www.huh.org/cid/foo.pdf
ftp://ftp.foo.org/cid/foo.txt

Figure 1: Example of the text/uri-list format 🦋

---

Appendix B: n2l.pl script 💻

okay so this is a simple CGI script for the N2L resolution service 🖥️. It assumes there's a DBM database storing the URN to URL mappings. It's provided purely as a courtesy for implementors and does not specify standard behavior 🎀. Real talk: it doesn't process incoming Accept: headers, and it doesn't generate status codes either. A real script for any of the resolution services should handle that 💅.

#!/bin/perl
# N2L  - performs urn to url  resolution

$n2l_File = "...filename for DBM database...";


$urn = $ENV{'QUERY_STRING'} ;

# Sanity check on the URN. Minimum length of a valid URN is
# 7 characters - "urn:", a 1-character Namespace ID, ":", and
# a 1-character namespace-specific string. More elaborate
# sanity checks should be part of a real resolver script.
if(length($urn)<7)
{
    $error=1;
}

if(!$error)
{
    # Convert lexically equivalent versions of a URI into
    # a canonical version for DB lookups.
    $urn =~ s/^urn:([^:]*):(.*)$/sprintf("urn:%s:%s", lc $1, $2)/ie;

    dbmopen(%lu,$n2l_File,0444);
    if($lu{$urn})
    {
        $url=$lu{$urn};
        print STDOUT "Location: $url\n\n";
    }else{
        $error=2;
    }
    dbmclose(%lu);
}

if($error)
{
    print "Content-Type: text/html \n\n";
    print "<html>\n";
    print "<head><title>URN Resolution: N2L</title></head>\n";
    print "<BODY>\n";
    print "<h1>URN to URL resolution failed for the URN:</h1>\n";
    print "<hr><h3>$urn</h3>\n";
    print "</body>\n";
    print "</html>\n";
}

exit;

---

References ✨

• [1] Daniel, Ron and Michael Mealling, RFC 2168, "Resolution of Uniform Resource Identifiers using the Domain Name System", June 1997.
• [2] Berners-Lee, T, R. Fielding, H. Frystyk, RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, May 1996.
• [3] Fielding, R., J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, RFC 2068, "Hypertext Transfer Protocol -- HTTP/1.1", Jan. 1997.
• [4] Moats, R., RFC 2141, "URN Syntax", May 1997.
• [5] URN-WG. "URN Resolution Services". Work In Progress.
• [6] Berners-Lee, T., RFC 1630, "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", June 1994.

---

Security Considerations 🙈

okay this part is seriously important, bestie 😭. Communications with a resolver may be of a sensitive nature. Some resolvers will hold information that should only be released to authorized users 🔒. The results from resolvers may be the target of spoofing, especially once electronic commerce transactions are common and there is money to be made by directing users to pirate repositories instead of repositories that pay royalties to rightsholders 💀. Resolution requests may be of interest to traffic analysts, and the requests may also be subject to spoofing 👀.

The requests and responses in this draft can be encoded, signed, and authenticated just like any other HTTP traffic 🫶.

Author Contact Information 📮

• Advanced Computing Lab, MS B287
• Los Alamos National Laboratory
• Los Alamos, NM, USA, 87545
• voice: +1 505 665 0597
• fax: +1 505 665 4939
• email: rdaniel@lanl.gov 💌