RFC 2169 (rfc2169) - Page 2 of 9
A Trivial Convention for using HTTP in URN Resolution
Alternative Format: Original Text Document
RFC 2169 HTTP in URN Resolution June 1997
that specification are Z3950, THTTP, RCDS, HDL, and RWHOIS. (That
list is expected to grow over time). The NAPTR specification also
lists a variety of resolution services, such as N2L (given a URN,
return a URL); N2R (Given a URN, return the named resource), etc.
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 primary goal of THTTP is to have a URN resolution
protocol that can easily be added to existing HTTP daemons. Other
resolution protocols are expected to arise over time, so this
document serves a secondary purpose of illustrating the information
that needs to be specified for a URN resolution protocol. One of the
resolution protocols we expect to be developed is an extension of
HTTP with new methods for the resolution services. Therefore, we use
"THTTP" as the identifier for this protocol to leave "HTTP" for later
developments.
The reader is assumed to be familiar with 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 used to encode resolution service requests in
THTTP is quite simple:
GET /uri-res/? HTTP/1.0
For example, if we have the URN "urn:foo:12345-54321" and want a URL,
we would send the request:
GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.0
The request could also be encoded as an HTTP 1.1 request. This would
look like:
GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.1
Host:
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 determining cachability, negotiating formats, etc.
apply.
Daniel Experimental