--- 1/draft-ietf-urn-resolution-services-05.txt 2007-12-18 19:10:04.000000000 +0100 +++ 2/draft-ietf-urn-resolution-services-06.txt 2007-12-18 19:10:04.000000000 +0100 @@ -1,16 +1,15 @@ - URN Working Group M.Mealling INTERNET-DRAFT Network Solutions, Inc. Expires six months from March 1998 Ron Daniel Jr. Intended category: Experimental Los Alamos National Laboratory -draft-ietf-urn-resolution-services-05.txt +draft-ietf-urn-resolution-services-06.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. @@ -21,88 +20,88 @@ 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 Retrieving the resource identified by a Uniform Resource Identifier -(URI) [3] is only one of the operations that can be performed on a URI. +(URI) [1] is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. A service in the network providing access to a resource may provide one or some of these options, but it need not provide all of them. This -memo specifies an initial set of these functions, to be used to -describe the functions provided by any given access service and the -requirements that must be met when those operations are encoded in a -protocol. +memo specifies an initial set of these operations that can be used to +describe the interactions provided by a given access service. It also +suggests guidelines that should be adhered to when those operations +are encoded in a protocol. 1. Introduction -In the course of formulating current proposals [1] regarding URNs -[2], it became apparent that requiring servers to deal with all desired -functions or requiring clients to deal with complicated information +In the course of formulating current proposals [2] regarding URNs +[3], it became apparent that requiring servers to manage all of the desired +functions or requiring clients to process varied 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 +needed to be some way for a client to be able to identify 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. The Problem In the process of learning about a resource in the Internet, there -are a variety of possible functions that may be important or useful, +are a variety of possible functions that may be important and/or useful, such as discovery of locators, names, descriptions, and accessing the resource itself. A given service may support only a subset of these; hence, it is important to describe such an access service by the types -of functions it supports, those resources about which it knows -anything. For example, in the framework for an RDS described in [5] the +of functions supported and the resources of which it has some knowledge. +For example, in the framework for an RDS described in [5] the RDS itself may provide URLs [6][7], while the resolvers may provide descriptions, URLs, or even the resources themselves. The design of an -RDS, as proposed in RFC 2168 [1], may be more generous and provide all +RDS, as proposed in RFC 2168 [2], may be more generous and provide all of the above. This problem requires some well understood set of identifiers that -identify those operations. But an exhaustive set would both be +specify those operations. But an exhaustive set would both be impossible and not very necessary. Thus, this document will list -several operations as well as lay out requirements for specifying new +several operations, as well as, lay out requirements for specifying new operations. The purpose of this document is to define a list of such functions -and short names for them and use them in defining the interface to an +and short names for them and then use them in defining the interface to an access service. 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" and "L2L",for example. Their use has been changed in favor of the more general URI form. Design Criteria -The design criteria used to meet these requirements were fairly -simple. The need to identify the operation with some token and know its -operands, algorithm, and errors was sufficient to meet the +To meet these requirements a fairly simple design criteria +was used. The need to identify the operation with some token such that its +operands, algorithm, and errors were known proved sufficient to meet these requirements. 2. General Specification To provide a framework both for the specifications in this document and for future work to be written by others, the guidelines below are -suggested for documents that seek to specify new operations. Any -specification of a member of this set of operations should address -these issues with respect to its operands, its algorithm, output, and errors. +suggested for documents that seek to specify new operations. Any specification +of a member of this set of operations should address these issues with respect +to its operands, algorithm, output, and errors. Due to the small number of listed functions, a registration mechanism was dismissed as premature. If this list grows, a registration mechanism will probably be needed. Also, due to the experimental nature of this document and the systems that use its specifications, the use of words like MUST and SHALL are limited. Where used they reflect a case where this specification could cause harm to existing, non-experimental systems such as HTTP and URNs. Thus, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -114,22 +113,22 @@ Operands must contain the following pieces of information: * name of the operation * case insensitive mnemonic for the operation * number of operands * type of each operand * format of each operand 2.2 Algorithm -The exact algorithm for the operation must be specified, or it must -be specified that the algorithm is opaque and defined by the server. +The exact algorithm for the operation must either be specified completely +or it must be considered opaque and defined by the server or application. 2.3 Output 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 @@ -141,41 +140,42 @@ and application environments must be included. Errors that depend on the system conveying the service are not included. Thus, many of the expected errors such as service availability or operation syntax are not included in this document since they are implementation dependent. 2.5 Security Considerations Any security considerations relating to the service provided must be specified. 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 +the results of the service. For example, a service that returned a single +URL 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. It is sufficient for those protocols to define new operations within their own protocol specification documents but care should be taken to make this fact well known. Also, a given system or protocol will have its own output specifications that may 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 conveys information about -the closeness of each resource on the network. +than the ones given here. For example, the result of an operation that +converts a URI to more than one URL may be encoded in a protocol- +specific manner that conveys information about the closeness of each +resource on the network. Thus, the requirements on encoding these operations within a given system are as follows: * which subset of the operations are allowed * how the operator is encoded * how the operands are encoded * how the error codes are returned The text/uri-list MIME Media Type is specified in Section 5. This Media Type @@ -240,21 +240,22 @@ * 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 are 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 should 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 [3]. +URI. All URIs shall be encoded according to the URL [7] and URN [3] +specifications. 4.3 I2R (URI to Resource) * Name: URI to Resource * Mnemonic: I2R * Number of Operands: 1 * Type of Each Operand: First operand is a URI. * Format of Each Operand: First operand is encoded as a URI. * Algorithm: Opaque * Output: An instance of the resource named by the URI. @@ -461,22 +462,22 @@ 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 as follows. 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[3]. Each URI shall - appear on one and only one line. + encoded according to the URN [3] or URL [7] specification RFCs. + 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 @@ -504,29 +505,29 @@ be subject to spoofing. The "Access denied" error message assumes a system within which the operation is being performed that can convey an authenticated concept of access control. Thus, the "Access denied" message should only be returned by systems that have an appropriate method of determining access control. 7. References -[1] Daniel, R., and Mealling, M., "Resolution of Uniform Resource -Identifiers using the Domain Name System", RFC2168, February, 1997. - -[2] R. Moats, "URN Syntax", RFC2141, January, 1997. - -[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying +[1] Berners-Lee, T., "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", RFC 1630, June, 1994. +[2] Daniel, R., and Mealling, M., "Resolution of Uniform Resource +Identifiers using the Domain Name System", RFC2168, February, 1997. + +[3] R. Moats, "URN Syntax", RFC2141, January, 1997. + [4] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993. [5] Sollins, K., draft-ietf-urn-req-frame-02, "Guidelines and a Framework for URN Resolution Systems", MIT/LCS, June, 1997. [Note to RFC Editor: Please change this reference to point to the correct RFC number for the draft] @@ -539,11 +540,11 @@ 8. Author Contact Information Michael Mealling Ron Daniel Network Solutions Advanced Computing Lab, MS B287 505 Huntmar Park Drive Los Alamos National Laboratory Herndon, VA 22070 Los Alamos, NM, USA, 87545 voice: (703) 742-0400 voice: (505) 665-0597 fax: (703) 742-9552 fax: (505) 665-4939 email: michaelm@rwhois.net email: rdaniel@lanl.gov - This document expires 6 months from November, 1997 + This document expires 6 months from March, 1998