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 . 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 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  and 1.1  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 [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 database, and return the requested information. One caveat should be kept in mind. The URN syntax document  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, since the URNs are lexically equivalent. GET /uri-res/N2L?urn:cid:email@example.com HTTP/1.0 GET /uri-res/N2L?URN:CID:firstname.lastname@example.org HTTP/1.0 3.0 Service-specific details: ============================= This section goes through the various resolution services established in the URN services document  and states 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 N2L (URN 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 N2Ls (URN to URLs): ------------------------ The request is encoded as above. The result is a list of 0 or more URLs. The Internet Media Type (aka ContentType) 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 the URLs which may be used to obtain an instance of the resource identified by the URN. All URIs shall be encoded according to the URI specification . 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: URN Resolution: 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: ===========  Daniel, Ron and Michael Mealling, RFC 2168, "Resolution of Uniform Resource Identifiers using the Domain Name System", June 1997.  Berners-Lee, T, R. Fielding, H. Frystyk, RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, May 1996.  Fielding, R., J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, RFC 2068, "Hypertext Transfer Protocol -- HTTP/1.1", Jan. 1997.  Moats, R., RFC 2141, "URN Syntax", May 1997.  URN-WG. "URN Resolution Services". Work In Progress.  Berners-Lee, T., RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", June 1994. Security Considerations ======================= Communications with a resolver may be of a sensitive nature. Some resolvers will hold information that should only be released to authorized users. The results from resolvers may be the target of spoofing, especially once electronic commerce transactions are common and there is money to be made by directing users to pirate repositories rather than repositories which pay royalties to rightsholders. Resolution requests may be of interest to traffic 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 Laboratory Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: email@example.com Daniel Experimental [Page 9]
RFC, FYI, BCP