HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 08:59:34 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 11 Jun 1997 10:48:00 GMT ETag: "323db7-4e31-339e8260" Accept-Ranges: bytes Content-Length: 20017 Connection: close Content-Type: text/plain URN Working Group M.Mealling INTERNET-DRAFT Network Solutions, Inc. Expires six months from June 1997 Ron Daniel Jr. Intended category: Standards Track Los Alamos National Laboratory draft-ietf-urn-resolution-services-01.txt URI Resolution Services Necessary for URN Resolution Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract Fetching the resource identified by a Uniform Resource Identifier (URI) [3] is only one of the operations that can be performed on a URI. We might ask for a list of other identifiers that are aliases for the original URI, a bibliographic description of the resource the URI denotes, etc. Because of the diverse nature of resources on the network, it may be difficult (or impossible) to offer all those operations, therefore a means of indicating what services are and are not supported by a given resolver must be specified. This memo gives an initial set of those operations, and the requirements that must be met when those operations are encoded in a protocol. 1. Introduction In the course of formulating current proposals [1] regarding Uniform Resource Names [2] it became apparent that requiring servers to deal with all desired functions or requiring clients to deal with complicated information returned by a server was unrealistic and a barrier to adoption. There needed to be some way for a client to be able to pick between a server that specialized in the complex and another that specialized in the simple (but fast). Also, in subsequent conversations it became obvious that, in most cases, some of the operations were inappropriate or difficult for certain identifiers. For example, ISSNs identify books or magazines that are serial in nature. An operation to return the resource for an ISSN pointing to "Time" magazine would result in dumping hundreds of thousands of pages of "Time" onto a user's machine. This does not seem like a reasonable thing to do in the normal case. The Problem The problem, stated simply, is one of a client needing to convey to a service the desired operation that the client wishes to have done on a given URI. The converse of this problem was that the server needed some way to convey to a client which services a network entity supported. This problem requires some well understood set of identifiers that identify those operations. But it was also realized that an exhaustive set would both be impossible and not very necessary. Thus, this document will list several operations as well as lay out requirments for specifying new operations. Historical Note: Since these services originated with the discussions surrounding URN resolution, there needs to be a clarification about at which point in the resoulution process these services reside. The URN resolution framework [] uses a two step process. The first step is called a Resolution Discovery Services or RDS. The second part is called a local resolver. The RDS uses hints to point a client toward a local resolver which actually answers the questions about the URI. The services described here reside at the level of the local resolver. The identifiers are used in the RDS to specify which local resolvers handle which services. Also, previous versions of this document referred to services where the arguments were specific types of URIs such as URNs or URLs. These services were called "N2L", "L2L", etc. Their use has been deprecated here in favor of the more general URI form. Design Criteria The design criteria used to meet these requirements were fairly simple. The need to simply identify the operation with some token and know its operands, algorithm and errors was seen as sufficient to meet the requirements. 2. General Specification In order to provide a framework both for the specifications in this document and for new ones to be written by others, the following requirments are placed on any documents that seek to specify new operations. Any specification of a member of this set of operations MUST contain at least the following pieces of information with respect to its operands, its algorithm, output and errors. 2.1 Operands Must contain the following pieces of information: * name of the operation * mnemonic for the operation * number of operands * type of each operand * format of each operand 2.2 Algorithm Must either specify the exact algorithm for the operation or that the algorithm is opaque and defined by the server. 2.3 Output Must specify one of the following: * there is no output * the output is undefined * the output itself and its content * the fact that the output is an object and the object's type and format. 2.4 Error Conditions Must include all errors that are considered applicable across all implementations and application environments. Errors that depend on the system conveying the service are not included. Thus, many of the expected errors such as syntax errors or service availability are not included in this document since they are implementation dependent. 2.5 Security Considerations Must specify any security considerations relating to the serivce provided. This does NOT include considerations dealing with the protocol used to convey the service or to those that normally accompany the results of the service. For example, an I2L service would need to discuss the situation where someone maliciously inserts an incorrect URL into the resolver but NOT the case where someone sends personal information across the Internet to the resource identified by the correct URL. 3. Encoding The Operations To be useful these operations have to be used within some system or protocol. In many cases these systems and protocols will place restrictions on which operations make sense and how those that do are syntactically represented. Also, a given system or protocol will have its own output formats that will restrict the output formats of a given operation. Additionally, a given protocol may have better solution for output than the ones given here. For example, the I2L result may be encoded in a protocol specific manner that causes the client to treat it as special. Thus, the requirements on encoding these operations within a given system are the following: * which subset of the operations are allowed * how the operator is encoded * how the operands are encoded * how the error codes are returned For those system that can use it, MIME [4] is the suggested output format. The operations listed here use the text/uri-list Internet Media Type or IMT [4] that is specified in Appendix A. Other system are strongly encouraged to use this IMT. In the case where a system does not use an IMT a justification should be given. 4. The Incomplete Set 4.1 I2L (URI to URL) * name: URI to URL * mnemonic: I2L * number of operands: 1 * type of each operand: 1st operand is a URI * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: 1 and only one URL encoded in a text/uri-list * Errors Conditions: o No such URI o No URL to return * Security Considerations: o Malicious Redirection One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the URI into the wrong URL. The intent may be to cause the client to retrieve a resource possibly containing fradulent or damaging material. o Denial of Service By removing the URL that the URI maps to, a malicious intruder may remove the clients ability to retrieve the resource. This operation is used to map a single URI to a single URL. It is used by light weight clients that do not have the ability to select from a list of URLs or understand a Uniform Resource Characteristic (URC). The algorithm for this mapping is dependent on the URI scheme. 4.2 I2Ls (URI to URLs) * name: URI to URLs * mnemonic: I2LS * number of operands: 1 * type of each operand: 1st operand is a URI * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: a list of 0 or more URLs encoded in a text/uri-list * Errors: o No such URI o No URLs to return * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) This operation is used to map a single URI to 0 or more URLs. It is used by a client that can pick from a list of URLs based on some criteria that is important to the client. The client should not make any assumptions about the order of the URLs returned. No matter what the particular media type, the result MUST be a list of the 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 specification [6]. 4.3 I2R (URI to Resource) * name: URI to Resource * mnemonic: I2R * number of operands: 1 * type of each operand: 1st operand is a URI * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: an instance of the resource named by the URI. Encoding is not specified. * Errors: o No such URI. o No resource available. * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) This operation is used to return a single instance of the resource that is named by the URI. The format of the output is dependent on the resource itself. 4.4 I2Rs (URI to Resources) * name: URI to Resources * mnemonic: I2Rs * number of operands: 1 * type of each operand: 1st operand is a URI * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: 0 or more instances of the resource named by the URI. Encoding is not specified. * Errors: o No such URI. o No resource available. * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) This operation is used to return 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 output shall be a MIME multipart/alternative [4] message with the alternative versions of the resource in separate body parts. If there is only one version of the resource identified by the URN, it MAY be returned without the multipart/alternative wrapper. 4.5 I2C (URI to URC) * name: URI to URC * mnemonic: I2C * number of operands: 1 * type of each operand: 1st operand is a URI * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: A Uniform Resource Characteristic. Encoding is not specified. * Errors: o No such URI. o URC not available. * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) URCs (Uniform Resource Characteristics) are descriptions of other resources. This request allows the client to obtain a description of the resource identified by a URI, as opposed to the resource itself or simply the resources URLs. The description might be a bibliographic citation, a digital signature, a revision history, etc. This draft does not specify the content of any response to a URC request. That content is expected to vary from one server to another. 4.6 I2CS (URI to URCs) * name: URI to URCs * mnemonic: I2CS * number of operands: 1 * type of each operand: 1st operand is a URI * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: 0 or more Uniform Resource Characteristic. Encoding is not specified. * Errors: o No such URI. o URCs not available. * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) URCs can come in different formats and types. This operation returns 0 or more URCs that are appropriate for the given URI. 4.7 I2N (URI to URN) * name: URI to URN * mnemonic: I2N * number of operands: 1 * type of each operand: 1st operand is a URN * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: One URN encoded in a text/uri-list IMT. * Errors: o No such URI. o No URN considered equivalent at this time. * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) While URNs are supposed to identify one and only one resource, that does not mean that a resource may have one and only one URN. For example, consider a resource that one organization wishes to name 'foo'. Another organization, in agreement with the first, wants to call the resource 'bar'. Both organizations can agree that both names 'name' the same resource and that the URNs 'foo' and 'bar' are equivalent. The result a URN, known to the server, which identifies the same resource as the input URN. The result shall be encoded in a text/uri-list IMT. Extreme care should be taken with this service as it toys with the idea of equality with respect to URNs. As mentioned in several URN documents the idea of equality is very domain specific. For example, a URN pointing to a weather map for a particular day and a URN pointing to the the map as it changes from day to day would NOT by returned in this example because they point to do different resources. Some other concept of equality is at work. This service instead deals with resources that have two different names where the binding between the names and resources is permanent. 4.8 I2Ns (URI to URNs) * name: URI to URNs * mnemonic: I2NS * number of operands: 1 * type of each operand: 1st operand is a URI * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: A list of URNs encoded in a text/uri-list IMT. * Errors: o No such URI. o No URNs considered equivalent at this time. * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) This operation simply returns 0 or more URNs following the same criteria and cautions as the I2N operation. 4.9 I2I (URI to URI): * name: URI to URI * mnemonic: I2I * number of operands: 1 * type of each operand: 1st operand is a URL * format of each operand: 1st operand is encoded as a URI * algorithm: opaque * output: A URI. * Errors: o No such URI. o No URIs considered equivalent at this time. * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) This operation is used to map any arbitrary URI to any other arbitrary URI. No other assertions are made about whether or not the URI exhibits characteristics of URNs or URLs. 4.10 I=I (Is URI equal to URI): * name: URI = URI * mnemonic: I=I * number of operands: 2 * type of each operand: Both operands are URIs * format of each operand: both operands are encoded as a URIs * algorithm: opaque * output: TRUE or FALSE * Errors: o No such URI. o No URIs considered equivalent at this time. * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L) This operation is used to determine whether two given URIs are considered to be equal by the server being asked the question. The algorithm used to determine equality is opaque. No assertions are made about whether or not the URIs exhibits characteristics of URNs or URLs. 6. The text/uri-list Internet Media Type [This section will be augmented or replaced by the registration of the text/uri-list IMT once that registration has been performed]. Several of the resolution service requests, such as I2Ls, 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 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. 4. The order of the URIs given MUST be preserved upon retransmission. The client should not make any inferences about what the order of the returned list means. 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 -------------------------------------------------- 7. References [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt, February, 1997. [2] R. Moats, "URN Syntax", RFC2141, Jan. 1997. [3] 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", T. Berners-Lee, June 1994. [4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft, September 1993. 8. Security Considerations Communications with a server may be of a sensitive nature. Some servers will hold information that should only be released to authorized users. The results from servers 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 rights-holders. Server requests may be of interest to traffic analysts. The requests may also be subject to spoofing. 9. Author Contact Information Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 voice: (703)742-0400 fax: (703)742-9552 email: michaelm@rwhois.net Ron Daniel 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: rdaniel@lanl.gov