A Trivial Convention for using HTTP in URN Resolution
RFC 2169
|
Document |
Type |
|
RFC - Experimental
(June 1997; No errata)
|
|
Author |
|
Ron Daniel
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 2169 (Experimental)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group R. Daniel
Request for Comments: 2169 Los Alamos National Laboratory
Category: Experimental June 1997
A Trivial Convention for using HTTP in URN Resolution
Status of this Memo
===================
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract:
=========
The Uniform Resource Names Working Group (URN-WG) was formed to
specify persistent, location-independent names for network accessible
resources, as well as resolution mechanisms to retrieve the resources
given such a name. At this time the URN-WG is considering one
particular resolution mechanism, the NAPTR proposal [1]. That
proposal specifies how a client may find a "resolver" for a URN. A
resolver is a database that can provide information about the
resource identified by a URN, such as the resource's location, a
bibliographic description, or even the resource itself. The protocol
used for the client to communicate with the resolver is not specified
in the NAPTR proposal. Instead, the NAPTR resource record provides a
field that indicates the "resolution protocol" and "resolution
service requests" offered by the resolver.
This document specifies the "THTTP" resolution protocol - a trivial
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 be simple to implement so that existing HTTP servers may easily
add support for URN resolution. We expect that the databases used by
early resolvers will be useful when more sophisticated resolution
protocols are developed later.
1.0 Introduction:
==================
The NAPTR specification[1] defined a new DNS resource record which
may be used to discover resolvers for Uniform Resource Identifiers.
That resource record provides the "services" field to specify the
"resolution protocol" spoken by the resolver, as well as the
"resolution services" it offers. Resolution protocols mentioned in
Daniel Experimental [Page 1]
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/<service>?<uri> 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: <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 determining cachability, negotiating formats, etc.
apply.
Daniel Experimental [Page 2]
RFC 2169 HTTP in URN Resolution June 1997
Handling these requests on the server side is easy to implement using
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 will remain in their %encoded
state in that string. The script can take the URN, look it up in a
Show full document text