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
