[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Regrep: revised RFC 2169
25 November 1999
Terry Allen
This is a revision (v 0.1) of RFC 2169 to bring it into alignment with
http://www.ietf.org/internet-drafts/draft-ietf-urn-naptr-rr-03.txt
for use by the OASIS Regrep TC. It has no status at the moment, but
presumably has to start life again as an I-D. Revisions are marked
by verbars at the left margin.
For distribution to the OASIS Regrep TC list, I've deleted
Appendix B, and as of today (24 December 99) I still haven't
done anything about an XML version of Appendix A's format.
CHANGES
(minor copy edits are marked but not listed here):
- removed the ^L page breaks (*not* marked) to preserve my sanity
and improve printing functionality. Presumably the whole
thing needs to be reformatted, but I've kept the page headers
where they are during revision to allow reference by page number.
- changed "URN resolution" to "URI resolution" and added language
throughout to support the notion that the same convention
works for all the services described in RFC 2483. No change
made to page headers.
- deleted 3.6, N2NS, which as I understand things is not now a listed
service; it's covered by I2NS (3.7); 3.8, L2LS, which is
covered by I2LS; and 3.9, L2C, which is
covered by I2C (3.5) . Substituted new 3.6, 3.7, I2CS and I2N,
and renumbered old 3.7.
- changed spec of encoding of I2NS to be same as I2LS
Network Working Group R. Daniel
Request for Comments: 2169 Los Alamos National Laboratory
Category: Experimental June 1997
A Trivial Convention for using HTTP in URI 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, and for resolution of requests relating
| to URLs in which the returned information is not the resource itself
| (see [5]). 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), and
| so forth. RFC 2483 specifies additional services for URIs in general.
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 specify a URI 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 URI 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, and so on,
apply.
Daniel Experimental [Page 2]
RFC 2169 HTTP in URN Resolution June 1997
| Handling of 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 URI will remain in their %encoded
state in that string. The script can take the URI, look it up in a
database, and return the requested information.
TODO One caveat should be kept in mind. The URN syntax document [4]
discusses the notion of lexical equivalance and requires that
resolvers 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, as 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 enumerates the various resolution services established
| TODO - RFC 2483 in the URN services document [5], stating how to encode each of
them, how the results should be returned, and any special status
codes that are likely to arise.
Unless stated otherwise, the THTTP requests are formed according to
the simple convention above, either for HTTP/1.0 or HTTP/1.1. The
response is assumed to be an entity with normal headers and body
unless stated otherwise. (N2L is the only request that need not
return a body).
| 3.1 I2L (URI to URL):
----------------------
The request is encoded as above. The URL MUST be returned in a
Location: header for the convienience of the user in the most common
case of wanting the resource. If the lookup is successful, 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 particular reasons
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 to
provide a body in the response to explain the reason for refusing
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 I2LS (URI to URLs):
------------------------
The request is encoded as above. The result is a list of 0 or more
| URLs. The Internet Media Type (also known as Content Type) of the result may be
negotiated using standard HTTP mechanisms if desired. 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
| suitable for machine processing of the list of URLs. Resolvers may
also return the results as text/html, text/plain, or any other media
type they deem suitable.
No matter what the particular media type, the result MUST be a list
| of URLs that may be used to obtain an instance of the resource
identified by the URI. All URIs shall be encoded according to the URI
TODO specification [6].
>>>>All URIs shall be encoded according to the URL [7] and URN
[3] specifications. says rfc 2483
If the client has requested the result be returned as text/html or
application/html, the result should be a valid HTML docment
containing the 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... are replaced by the n'th URL in the
list.
| 3.3 I2R (URI to Resource):
---------------------------
The request is encoded as above. The resource is returned using
standard HTTP mechanisms. The request may be modified using the
Accept: header as in normal HTTP to specify that the result be given
in a preferred Internet Media Type.
| 3.4 I2RS (URI to Resources):
-----------------------------
This resolution service returns multiple instances of a resource, for
example, GIF and JPEG versions of an image. The judgment about the
resources being "the same" resides with the naming authority that
| issued the URI.
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 is only one version of the
| resource identified by the URI, it MAY be returned without the
Daniel Experimental [Page 4]
RFC 2169 HTTP in URN Resolution June 1997
multipart/alternative wrapper. Resolver software SHOULD look at the
Accept: header, if any, and only return versions of the resource that
are acceptable according to that header.
| 3.5 I2C (URI to URC):
----------------------
URCs (Uniform Resource Characteristics) are descriptions of other
resources. This request allows us to obtain a description of the
resource identified by a URN, as opposed to the resource itself. The
description might be a bibliographic citation, a digital signature, a
revision history, etc. This document does not specify the content of
any response to a URC request. That content is expected to vary from
one resolver to another.
| The format of any response to an I2C request MUST be communicated
| using the Content Type header, as is standard HTTP practice. The
Accept: header SHOULD be honored.
| 3.6 I2CS
----------------------
This resolution service returns multiple URCs, for example versions of
the same URC in different formats (the meaning of "the same" being
left to the creator or creators of the URC), or different URCs (possibly
also in different formats).
The request is encoded as above. The result shall be a MIME
multipart/alternative message with the multiple URCs, or alternative
versions of the URC, in separate body parts. If there is only one URC,
it MAY be returned without the multipart/alternative wrapper. Resolver
software SHOULD look at the Accept: header, if any, and only return
URCs, or versions of URCs, that are acceptable according to that header.
| 3.7 I2N
----------------------
This resolution service returns a single URN for the resource
identified by the request URI.
The request is encoded as above. The URN MUST be returned in a
Location: header for the convienience of the user in the most common
case of wanting the resource.
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 to
provide a body in the response to explain the reason for refusing
access, and/or to provide alternate information about the resource,
such as the price it will cost to obtain the resource's URN.
| 3.8 I2NS (URI to URNs):
----------------------
| The request is encoded as above. The response is a list of all URNs
known to be assigned to the resource at the given URL. The result
| shall be encoded as for the I2LS request.
Daniel Experimental [Page 5]
RFC 2169 HTTP in URN Resolution June 1997
Daniel Experimental [Page 6]
RFC 2169 HTTP in URN Resolution June 1997
Appendix A: The text/uri-list Internet Media Type
=================================================
[This appendix will be augmented or replaced by the registration of the
text/uri-list IMT once that registration has been performed].
| Two of the resolution service requests, I2LS and I2NS,
| result in a list of URIs being returned to the client. The
text/uri-list Internet Media Type is defined to provide a simple
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 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
TODO 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 I2Ls 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 I2L request is shown below in
figure 1.
# 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC