As per Relevance of the word resolution, we have this rfc below:
Network Working Group R.
Request for Comments: 2169 Los Alamos National
Category: Experimental June 1997
A Trivial Convention for using HTTP in URN
Status of this
===================
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
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
specify persistent, location-independent names for network
resources, as well as resolution mechanisms to retrieve the
given such a name. At this time the URN-WG is considering
particular resolution mechanism, the NAPTR proposal [1].
proposal specifies how a client may find a "resolver" for a URN.
resolver is a database that can provide information about
resource identified by a URN, such as the resource's location,
bibliographic description, or even the resource itself. The
used for the client to communicate with the resolver is not
in the NAPTR proposal. Instead, the NAPTR resource record provides
field that indicates the "resolution protocol" and "
service requests" offered by the resolver
This document specifies the "THTTP" resolution protocol - a
convention for encoding resolution service requests and responses
HTTP 1.0 or 1.1 requests and responses. The primary goal of THTTP
to be simple to implement so that existing HTTP servers may
add support for URN resolution. We expect that the databases used
early resolvers will be useful when more sophisticated
protocols are developed later
1.0 Introduction
==================
The NAPTR specification[1] defined a new DNS resource record
may be used to discover resolvers for Uniform Resource Identifiers
That resource record provides the "services" field to specify
"resolution protocol" spoken by the resolver, as well as
"resolution services" it offers. Resolution protocols mentioned
Daniel Experimental [Page 1]
RFC 2169 HTTP in URN Resolution June 1997
that specification are Z3950, THTTP, RCDS, HDL, and RWHOIS. (
list is expected to grow over time). The NAPTR specification
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)
protocol. THTTP is a simple convention for encoding
service requests and responses as HTTP 1.0 or 1.1 requests
responses. The primary goal of THTTP is to have a URN
protocol that can easily be added to existing HTTP daemons.
resolution protocols are expected to arise over time, so
document serves a secondary purpose of illustrating the
that needs to be specified for a URN resolution protocol. One of
resolution protocols we expect to be developed is an extension
HTTP with new methods for the resolution services. Therefore, we
"THTTP" as the identifier for this protocol to leave "HTTP" for
developments
The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1
[3] specifications. Implementors of this specification should
familiar with CGI scripts, or server-specific interfaces,
database lookups
2.0 General Approach
=====================
The general approach used to encode resolution service requests
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
look like
GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.1
Host:
Responses from the HTTP server follow standard HTTP practice.
codes, such as 200 (OK) or 404 (Not Found) shall be returned.
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
CGI or other, server-specific, extension mechanisms. CGI
will see the incoming URI in the QUERY_STRING environment variable
Any %encoded characters in the URN will remain in their %
state in that string. The script can take the URN, look it up in
database, and return the requested information
One caveat should be kept in mind. The URN syntax document [4]
discusses the notion of lexical equivalance and requires
resolvers return identical results for URNs that are
equivalent. Implementors of this specification must be careful
obey that rule. For example, the two requests below MUST
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 various resolution services
in the URN services document [5] and states how to encode each
them, how the results should be returned, and any special
codes that are likely to arise
Unless stated otherwise, the THTTP requests are formed according
the simple convention above, either for HTTP/1.0 or HTTP/1.1.
response is assumed to be an entity with normal headers and
unless stated otherwise. (N2L is the only request that need
return a body).
3.1 N2L (URN to URL):
----------------------
The request is encoded as above. The URL MUST be returned in
Location: header for the convienience of the user in the most
case of wanting the resource. If the lookup is successful, a 30
status line SHOULD be returned. HTTP/1.1 clients should be sent
303 status code. HTTP/1.0 clients should be sent the 302 (
temporarily) status code unless the resolver has particular
for using 301 (moved permanently) or 304 (not modified) codes
Note that access controls may be applied to this, or any other
resolution service request. Therefore the 401 (unauthorized) and 403
(forbidden) status codes are legal responses. The server may wish
provide a body in the response to explain the reason for
access, and/or to provide alternate information about the resource
such as the price it will cost to obtain the resource's URL
Daniel Experimental [Page 3]
RFC 2169 HTTP in URN Resolution June 1997
3.2 N2Ls (URN to URLs):
------------------------
The request is encoded as above. The result is a list of 0 or
URLs. The Internet Media Type (aka ContentType) of the result may
negotiated using standard HTTP mechanisms if desired. At a
the resolver should support the text/uri-list media type. (
Appendix A for the definition of this media type). That media type
suitable for machine-processing of the list of URLs. Resolvers
also return the results as text/html, text/plain, or any other
type they deem suitable
No matter what the particular media type, the result MUST be a
of the URLs which may be used to obtain an instance of the
identified by the URN. All URIs shall be encoded according to the
specification [6].
If the client has requested the result be returned as text/html
application/html, the result should be a valid HTML
containing the fragment
...url 1...
...url 2...
etc
where the strings ...url n... are replaced by the n'th URL in
list
3.3 N2R (URN to Resource):
---------------------------
The request is encoded as above. The resource is returned
standard HTTP mechanisms. The request may be modified using
Accept: header as in normal HTTP to specify that the result be
in a preferred Internet Media Type
3.4 N2Rs (URN to Resources):
-----------------------------
This resolution service returns multiple instances of a resource,
example, GIF and JPEG versions of an image. The judgment about
resources being "the same" resides with the naming authority
issued the URN
The request is encoded as above. The result shall be a
multipart/alternative message with the alternative versions of
resource in seperate body parts. If there is only one version of
resource identified by the URN, it MAY be returned without
Daniel Experimental [Page 4]
RFC 2169 HTTP in URN Resolution June 1997
multipart/alternative wrapper. Resolver software SHOULD look at
Accept: header, if any, and only return versions of the resource
are acceptable according to that header
3.5 N2C (URN to URC):
----------------------
URCs (Uniform Resource Characteristics) are descriptions of
resources. This request allows us to obtain a description of
resource identified by a URN, as opposed to the resource itself.
description might be a bibliographic citation, a digital signature,
revision history, etc. This document does not specify the content
any response to a URC request. That content is expected to vary
one resolver to another
The format of any response to a N2C request MUST be
using the ContentType header, as is standard HTTP practice.
Accept: header SHOULD be honored
3.6 N2Ns (URN to URNs):
------------------------
While URNs are supposed to identify one and only one resource,
does not mean that a resource may have one and only one URN.
example, consider a resource that has something like "current
weather-map" for one URN and "weather-map-for-datetime-x" for
URN. The N2Ns service request lets us obtain lists of URNs that
believed equivalent at the time of the request. As the
example shows, some of the equivalances will be transitory, so
standard HTTP mechanisms for communicating cachability MUST
honored
The request is encoded as above. The result is a list of all
URNs, known to the resolver, which identify the same resource as
input URN. The result shall be encoded as for the N2Ls request
(text/uri-list unless specified otherwise by an Accept: header).
3.7 L2Ns (URL to URNs):
----------------------
The request is encoded as above. The response is a list of any
known to be assigned to the resource at the given URL. The
shall be encoded as for the N2Ls and N2Ns requests
Daniel Experimental [Page 5]
RFC 2169 HTTP in URN Resolution June 1997
3.8 L2Ls (URL to URLs):
------------------------
The request is encoded as described above. The result is a list
all the URLs that the resolver knows are associated with the
located by the given URL. This is encoded as for the N2Ls, N2Ns,
L2Ns requests
3.9 L2C (URL to URC):
----------------------
The request is encoded as above, the response is the same as for
N2C request
Daniel Experimental [Page 6]
RFC 2169 HTTP in URN Resolution June 1997
Appendix A: The text/uri-list Internet Media
=================================================
[This appendix will be augmented or replaced by the registration of
text/uri-list IMT once that registration has been performed].
Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns
L2Ls, result in a list of URIs being returned to the client.
text/uri-list Internet Media Type is defined to provide a
format for the automatic processing of such lists of URIs
The format of text/uri-list resources is
1) Any lines beginning with the '#' character are comment
and are ignored during processing. (Note that '#' is a
that may appear in URIs, so it only denotes a comment when it is
first character on a line).
2) The remaining non-comment lines MUST be URIs (URNs or URLs),
according to the URI specification RFC[6]. Each URI shall appear
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
one of those characters
In applications where one URI has been mapped to a list of URIs,
as in response to the N2Ls request, the first line of the text/uri
list response SHOULD be a comment giving the original URI
An example of such a result for the N2L request is shown below
figure 1.
# urn:cid:foo@huh.
http://www.huh.org/cid/foo.
http://www.huh.org/cid/foo.
ftp://ftp.foo.org/cid/foo.
Figure 1: Example of the text/uri-list
Appendix B: n2l.pl
==========================
This is a simple CGI script for the N2L resolution service.
assumes the presence of a DBM database to store the URN to
mappings. This script does not specify standard behavior, it
provided merely as a courtesy for implementors. In fact, this
does not process incoming Accept: headers, nor does it
status codes. Such behavior should be part of a real script for
of the resolution services
Daniel Experimental [Page 7]
RFC 2169 HTTP in URN Resolution June 1997
#!/bin/
# N2L - performs urn to url
$n2l_File = "...filename for DBM database...";
$urn = $ENV{'QUERY_STRING'} ;
# Sanity check on the URN. Minimum length of a valid URN
# 7 characters - "urn:", a 1-character Namespace ID, ":",
# a 1-character namespace-specific string. More
# 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
# 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 "\n";
print "URN <A HREF="/relevance/projects/rfc/resolution.html">Resolution</A>: N2L\n";
print "\n";
print "URN to URL resolution failed for the URN:
\n";
print "
$urn
\n";
print "\n";
print "\n";
}
exit
Daniel Experimental [Page 8]
RFC 2169 HTTP in URN Resolution June 1997
References
===========
[1] Daniel, Ron and Michael Mealling, RFC 2168, "Resolution of
Resource Identifiers using the Domain Name System", June 1997.
[2] Berners-Lee, T, R. Fielding, H. Frystyk, RFC 1945, "
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
Objects on the Network as used in the World-Wide Web", June 1994.
Security
=======================
Communications with a resolver may be of a sensitive nature.
resolvers will hold information that should only be released
authorized users. The results from resolvers may be the target
spoofing, especially once electronic commerce transactions are
and there is money to be made by directing users to
repositories rather than repositories which pay royalties
rightsholders. Resolution requests may be of interest to
analysts. The requests may also be subject to spoofing
The requests and responses in this draft are amenable to encoding
signing, and authentication in the manner of any other HTTP traffic
Author Contact Information
===========================
Advanced Computing Lab, MS B287
Los Alamos National
Los Alamos, NM, USA, 87545
voice: +1 505 665 0597
fax: +1 505 665 4939
email: rdaniel@lanl.
Daniel Experimental [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
