diff options
Diffstat (limited to 'doc/rfc/rfc2483.txt')
| -rw-r--r-- | doc/rfc/rfc2483.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc2483.txt b/doc/rfc/rfc2483.txt new file mode 100644 index 0000000..de3a3c8 --- /dev/null +++ b/doc/rfc/rfc2483.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group M. Mealling +Request for Comments: 2483 Network Solutions, Inc. +Category: Experimental R. Daniel, Jr. + Los Alamos National Laboratory + January 1999 + + + URI Resolution Services + Necessary for URN Resolution + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + Retrieving the resource identified by a Uniform Resource Identifier + (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 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 [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 identify a server + that specialized in the complex and another that specialized in the + + + +Mealling & Daniel Experimental [Page 1] + +RFC 2483 URI Resolution Services January 1999 + + + 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 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 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 [2], may be + more generous and provide all of the above. + + This problem requires some well understood set of identifiers that + 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 operations. + + The purpose of this document is to define a list of such functions + 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 + + 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, algorithm, output, and + errors. + + + + + +Mealling & Daniel Experimental [Page 2] + +RFC 2483 URI Resolution Services January 1999 + + + 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described in + RFC 2119. + +2.1 Operands + + 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 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 + * any non-protocol specific errors + +2.4 Error Conditions + + All errors that are considered applicable across all implementations + 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. + + + +Mealling & Daniel Experimental [Page 3] + +RFC 2483 URI Resolution Services January 1999 + + +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, 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 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 is merely a suggestion for experimental systems that need + a simple implementation. It is included here merely as an example to + show completeness (however simple it may be). + + + + + + + + + + + +Mealling & Daniel Experimental [Page 4] + +RFC 2483 URI Resolution Services January 1999 + + +4. The Incomplete Set + +4.1 I2L (URI to URL) + + * Name: URI to URL + * Mnemonic: I2L + * 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: One and only one URL + * Errors Conditions: + o Malformed URI + o URI is syntactically valid but does not exist in any form. + o URI exists but there is no available output from this + operation. + o URI existed in the past but nothing is currently known + about it. + o Access denied + + * 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 possible intent may be to cause the client to retrieve + a resource containing fraudulent or damaging material. + o Denial of Service + By removing the URL to which the URI maps, a malicious + intruder may remove the client's ability to retrieve the + resource. + + This operation is used to map a single URI to a single URL. It is + used by lightweight clients that do not have the ability to select + from a list of URLs or understand a 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: First operand is a URI. + * Format of Each Operand: First operand is encoded as a URI. + * Algorithm: Opaque + * Output: A list of zero or more URLs + * Errors: + o Malformed URI + + + +Mealling & Daniel Experimental [Page 5] + +RFC 2483 URI Resolution Services January 1999 + + + o URI is syntactically valid but does not exist in any form. + o URI exists but there is no available output from this + operation. + o URI existed in the past but nothing is currently known + about it. + o Access denied + * 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 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. + * Errors: + o Malformed URI + o URI is syntactically valid but does not exist in any form. + o URI exists but there is no available output from this + operation. + o URI existed in the past but nothing is currently known + about it. + o Access denied + * 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. + + + + + + + + +Mealling & Daniel Experimental [Page 6] + +RFC 2483 URI Resolution Services January 1999 + + +4.4 I2Rs (URI to Resources) + + * Name: URI to Resources + * Mnemonic: I2Rs + * 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: Zero or more instances of the resource named by the URI. + * Errors: + o Malformed URI + o URI is syntactically valid but does not exist in any form. + o URI exists but there is no available output from this + operation. + o URI existed in the past but nothing is currently known + about it. + o Access denied + * 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: First operand is a URI. * Format of Each + Operand: First operand is encoded as a URI. * Algorithm: Opaque * + Output: A URC * Errors: + o Malformed URI + o URI is syntactically valid but does not exist in any form. + o URI exists but there is no available output from this + operation. + o URI existed in the past but nothing is currently known + about it. + o Access denied * Security Considerations: + o Malicious Redirection (see I2L) + o Denial of Service (see I2L) + + + + + +Mealling & Daniel Experimental [Page 7] + +RFC 2483 URI Resolution Services January 1999 + + + Uniform Resource Characteristics are descriptions of 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 + resource's URLs. The description might be a bibliographic citation, a + digital signature, or a revision history. This memo 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: First operand is a URI. + * Format of Each Operand: First operand is encoded as a URI. + * Algorithm: Opaque + * Output: Zero or more URCs + * Errors: + o Malformed URI + o URI is syntactically valid but does not exist in any form. + o URI exists but there is no available output from this + operation. + o URI existed in the past but nothing is currently known + about it. + o Access denied + * Security Considerations: + o Malicious Redirection (see I2L) + o Denial of Service (see I2L) + + URCs can come in different formats and types. This operation returns + zero 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: First operand is a URN. + * Format of Each Operand: First operand is encoded as a URI. + * Algorithm: Opaque + * Output: One and only one URN + * Errors: + o Malformed URI + o URI is syntactically valid but does not exist in any form. + o URI exists but there is no available output from this + operation. + o URI existed in the past but nothing is currently known + about it. + + + +Mealling & Daniel Experimental [Page 8] + +RFC 2483 URI Resolution Services January 1999 + + + o Access denied + * 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 is a URN, known to the server, that identifies the same + resource as the input URN. + + 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 map as it changes from day to day would NOT be + returned in this example because they point to do different + resources. Some other concept of temporary equivalence is at work. + This service instead deals with resources that have two different + names where there is a binding between the names that is agreed by + both name assigners. I.e., both namespaces MUST have agreed that the + each name can be used in place of the other and the meaning does not + change. + +4.8 I2Ns (URI to URNs) + + * Name: URI to URNs + * Mnemonic: I2NS + * 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: A list of URNs + * Errors: + o Malformed URI + o URI is syntactically valid but does not exist in any form. + o URI exists but there is no available output from this + operation. + o URI existed in the past but nothing is currently known + about it. + o Access denied + * Security Considerations: + o Malicious Redirection (see I2L) + + + +Mealling & Daniel Experimental [Page 9] + +RFC 2483 URI Resolution Services January 1999 + + + o Denial of Service (see I2L) + + This operation simply returns zero or more URNs following the same + criteria and cautions as the I2N operation. + +4.9 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 Malformed URIs + o URIs are syntactically valid but do not exist in any form. + o URIs exist but there is no available output from this + operation. + o URIs existed in the past but nothing is currently known + about them. + o Access denied + * 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. + + + + + + + + + + + + + + + + + + + + +Mealling & Daniel Experimental [Page 10] + +RFC 2483 URI Resolution Services January 1999 + + +5. The text/uri-list Internet Media Type + + 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. + + This is a copy of the IANA registration of the text/uri-list Media + Type. + + Date: Fri, 18 Apr 97 08:36:07 PDT + From: Ron Daniel Jr. <rdaniel@lanl.gov> + To: iana@iana.org, rdaniel@lanl.gov + Subject: Request for MIME media type Text/IETF Tree - uri-list + + Name : Ron Daniel Jr. + + E-mail : rdaniel@lanl.gov + + MIME media type name : Text + + MIME subtype name : IETF Tree -uri-list + + Required parameters : none + + Optional parameters : charset + + Currently, URIs can be represented using US-ASCII. However, there + are many non-standard URIs which use special character sets. + Discussion of how to best achieve internationalization of URIs is + underway. This registration will be updated with a discussion of the + URI charsets once that discussion has concluded. + + Encoding considerations : Some transfer protocols, such as SMTP, + place limits on the length of lines. Very long URIs might exceed + those limits. Systems must therefore be prepared to use a suitable + content transfer encoding. This is anticipated to be a rare + occurance. + + Security considerations : Client software should be aware of the + security considerations of URIs. For example, accessing some URIs + can result in sending a death threat to a head of state, frequently + prompting a visit from the relevant protective service. Accessing + other URIs may result in financial obligations, or access to + resources considered inappropriate by one's employer. + + + + + + +Mealling & Daniel Experimental [Page 11] + +RFC 2483 URI Resolution Services January 1999 + + + While the legitimate provider of a uri-list could exploit these + properties for good or ill, it is more likely that uri-lists will be + falsified in order to exploit such characteristics of URIs. + + Additionally, the lookup and reverse lookup potential of the uri- + list may be attractive to traffic analysts. URI lists may also + reveal confidential information, such as the location of sensitive + information. + + Because of these considerations, external confidentiality measures + should be available to protect uri-list responses when appropriate. + + Interoperability considerations : none known + + Published specification : Uniform Resource Locators (URLs) and + Uniform Resource Names (URNs) are two instances of the more general + class of identifiers known as Uniform Resource Identifiers (URIs). + URN resolution methods frequently wish to return lists of URLs for a + resource so that fault-tolerance and load balancing can be achieved. + The text/uri-list format is intended to be a very simple format for + communicating such lists of URLs (and URNs) in a form suitable for + automatic processing. + + 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 URIs may contain + the '#' character, so it is only a comment character when it is + the first character on a line.) + + 2) The remaining non-comment lines shall be URIs (URNs or URLs), + encoded according to the URL or URN specifications (RFC2141, + RFC1738 and RFC2396). Each URI shall appear on one and only one + line. Very long URIs are not broken in the text/uri-list format. + Content-transfer-encodings may be used to enforce line length + limitations. + + 3) As for all text/* formats, lines are terminated with a CRLF pair. + + In applications where one URI has been mapped to a list of URIs, the + first line of the text/uri-list response SHOULD be a comment giving + the original URI. + + + + + + + + + +Mealling & Daniel Experimental [Page 12] + +RFC 2483 URI Resolution Services January 1999 + + + An example of the format is given below: + + # urn:isbn:0-201-08372-8 + http://www.huh.org/books/foo.html + http://www.huh.org/books/foo.pdf + ftp://ftp.foo.org/books/foo.txt + + Applications which use this media : URN resolvers are the initial + applications. Web clients and proxies are applications that are + likely to support this format in the future. + + Additional information : + + 1. Magic number(s) : none at this time + 2. File extension(s) : .uris or .uri recommended + 3. Macintosh file type code : URIs recommended + + This media type is the product of the URN working group of the IETF. + + Person to contact for further information : + + 1. Name : Ron Daniel Jr. + 2. E-mail : rdaniel@lanl.gov + + Intended usage : Limited Use + The text/uri-list media type is intended for use in applications + which utilize URIs for replicated resources. + + Author/Change controller : Ron Daniel Jr. + Los Alamos National Laboratory + rdaniel@lanl.gov + + + + + + + + + + + + + + + + + + + + +Mealling & Daniel Experimental [Page 13] + +RFC 2483 URI Resolution Services January 1999 + + + 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. + +6. 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 that pay royalties to rights- + holders. Server requests may be of interest to traffic analysts. The + requests may also 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] 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", RFC 2168, February + 1997. + + [3] Moats, R., "URN Syntax", RFC 2141, January 1997. + + [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [5] Sollins, K., "Architectural Principles of Uniform Resource Name + Resolution", RFC 2276, January 1998. + + [6] Kunze, J., "Functional Recommendations for Internet Resource + Locators", RFC 1736, February 1995. + + [7] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource + Locators (URL)", RFC 1738, December 1994. + + + + +Mealling & Daniel Experimental [Page 14] + +RFC 2483 URI Resolution Services January 1999 + + +8. Authors' Addresses + + Michael Mealling + Network Solutions + 505 Huntmar Park Drive + Herndon, VA 22070 + + Phone: (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 + + Phone: (505) 665-0597 + Fax: (505) 665-4939 + EMail: rdaniel@lanl.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mealling & Daniel Experimental [Page 15] + +RFC 2483 URI Resolution Services January 1999 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Mealling & Daniel Experimental [Page 16] + |