rfc1736.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 564 行 · 第 1/2 页
TXT
564 行
Network Working Group J. KunzeRequest for Comments: 1736 IS&T, UC BerkeleyCategory: Informational February 1995 Functional Recommendations for Internet Resource LocatorsStatus of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.1. Introduction This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. Typical examples of resources include network accessible documents, WAIS databases, FTP servers, and Telnet destinations. Locators may apply to resources that are not always or not ever network accessible. Examples of the latter include human beings and physical objects that have no electronic instantiation (that is, objects without an existence completely defined by digital objects such as disk files). A resource locator is a kind of resource identifier. Other kinds of resource identifiers allow names and descriptions to be associated with resources. A resource name is intended to provide a stable handle to refer to a resource long after the resource itself has moved or perhaps gone out of existence. A resource description comprises a body of meta-information to assist resource search and selection. In this document, an Internet resource locator is a locator defined by an Internet resource location standard. A resource location standard in conjunction with resource description and resource naming standards specifies a comprehensive infrastructure for network based information dissemination. Mechanisms for mapping between locators, names, and descriptive identifiers are beyond the scope of this document.2. Overview of Problem Network-based information resource providers require a method of describing the location of and access to their resources. Information systems users require a method whereby client software can interpret resource access and location descriptions on theirKunze [Page 1] RFC 1736 Recommendations for IRLs February 1995 behalf in a relatively transparent way. Without such a method, transparent and widely distributed, open information access on the Internet would be difficult if not impossible.2.1 Defining the General Resource Locator The requirements listed in this document impose restrictions on the general resource locator. To better understand what the Internet resource locator is, the following general locator definition provides some contrast. Definition: A general resource locator is an object that describes the location of a resource. This definition deliberately allows many degrees of freedom in order to contain the furthest reaches of the wide-ranging debate on resource location standards. Vast as it is, this problem space is a useful backdrop for discussion of the requirements (later) that generate a smaller, more manageable problem space. A resource location standard shrinks the space again by applying additional requirements. Consider the definition in four parts: (1) A general resource locator is an object (2) that describes (3) the location of (4) a resource.2.1.1. A general resource locator is an object... The object could be a complex data structure. It could be a contiguous sequence of bytes. It could be a pair of latitude- longitude coordinates, or a three-color road map printed on paper. It could be a sequence of characters that are capable of being printed on paper.2.1.2. ...that describes In the fully general case, there are many ways that a resource locator could describe the location. It could employ a graphical or natural language description. It could be heavily encoded or compressed. It could be lightly encoded and readily understandable by human beings. The description could be a multi-level hierarchy with common semantics at each level. It could be a multi-level hierarchy with common semantics at only the first two levels, where semantics below the second level depend on the value given at the first level. These are just a few possibilities.Kunze [Page 2] RFC 1736 Recommendations for IRLs February 19952.1.3. ...the location of A resource locator describes a location but never guarantees that access may be established. While access is often desired when clients follow location instructions given in a conformant resource locator, the resource need not exist any longer or need not exist yet. Indeed it may never exist, even though the locator continues to describe a location where a resource might exist (e.g., it might be used as a placeholder with resource availability contingent upon an event such as a payment). Furthermore, the nature of certain potential resources, especially animate beings or physical objects with no electronic instantiation, makes network access meaningless in some cases; such resources have locators that would imply non-networked access, but again, access is not guaranteed.2.1.4. ...a resource. A resource can be many things. Besides the non-networked or non- electronic resources just mentioned, familiar examples are an electronic document, an image, a server (e.g., FTP, Gopher, Telnet, HTTP), or a collection of items (e.g., Gopher menu, FTP directory, HTML page). Other examples accompany multi-function protocols such as Z39.50, which can perform single round trip network access, session-oriented search refinement, and index browsing.2.2 Producers and Interpreters of Resource Locators Central to the discussion of locator requirements is the issue of parsability. This is the ability of an agent to recognize or understand a locator in whole or in part. Discussion may be assisted by clearly distinguishing the two main actions associated with locators. Resource locators are both produced and interpreted. Producers are bound by the resource location standards that are in turn bound by requirements listed in this document. Interpreters of locators are not bound by the requirements; they are beneficiaries of them.2.2.1 Resource Locator Interpreters A resource locator is interpreted by interpreting agents, which in this document are simply called interpreters. Interpreters may be either human beings or software. Along the way to establishing access based on information in a locator, one or more interpreters may be employed. Some examples of multiple interpreters processing a single locator illustrate the concept that a resource locator may beKunze [Page 3] RFC 1736 Recommendations for IRLs February 1995 understandable only in part by each of several interpreters, but understandable in its entirety by a combination of interpreters. In the first example, a software interpreter recognizes enough of a locator to understand to which external agent it needs to forward it. Here, the external agent might be a user and the locator a library call number; the software forwards the locator simply by displaying it. The agent might be a network software layer specializing in a particular communications protocol; once the service is recognized, the locator is forwarded to it along with an access request. In another example, a human interpreter might also recognize enough of a locator to understand where to forward it. Here, the person might be a user who recognizes a library call number as such but who does not understand the location information encoded in it; the person forwards it to a library employee (an external agent) who knows how to establish access to the library resource. A prerequisite to interpreting a locator is understanding when an object in question actually is a locator, or contains one or more locators. Some constrained environments make this question easy to answer, for example, within HTML anchors or Gopher menu items. Less constrained environments, such as within running text, make it more difficult to answer without well-defined assumptions. A resource location standard needs to make any such assumptions explicit.2.2.2 Resource Locator Producers Resource locators are produced in many ways, often by an agent that also interprets them. The provider of a resource may produce a locator for it, leaving the locator in places where it is intended to be discovered, such as an HTML page, a Gopher menu, or an announcement to an e-mail list. Non-providers of resources can be major producers of locators; for example, WWW client software produces locators by translating foreign resource locators (e.g., Gopher menu items) to its own format. Some locator databases (e.g., Archie) have been maintained by automated processes that produce locators for hundreds of thousands of FTP resources that they "discover" on the Internet. Users are major producers of resource locators. A user constructing one to share with others is responsible for conformance with locator standards. Sometimes a user composes a resource locator based on an educated guess and submits it to client software with the intent of establishing access. Such a user is a producer in a sense, but if the locator is purely for personal consumption the user is not bound by the requirements. In fact, some client software may offer as aKunze [Page 4] RFC 1736 Recommendations for IRLs February 1995 service to translate abbreviated, non-conformant locators entered by users into successful access instructions or into conformant locators (e.g., by adding a domain name to an unqualified hostname)2.3 Uniqueness of Resource Locators The topic of a "uniqueness" requirement for resource locators has been discussed a great deal. This document considers the following aspects of uniqueness, but deliberately rejects them as requirements. It is incumbent upon a resource location standard that takes on this topic to be clear about which aspects it addresses.2.3.1. Uniqueness and Multiple Copies of a Resource A uniqueness requirement might dictate that no identical copies of a resource may exist. This document makes no such requirement.2.3.2. Uniqueness and Deterministic Access A uniqueness requirement might dictate that the same resource accessed in one attempt will also be the result of any other successful attempt. This document makes no such requirement, nor does it define "sameness". It is inappropriate for a resource location standard to define "sameness" among resources.2.3.3. Uniqueness and Multiple Locators A uniqueness requirement might dictate that a resource have no more than one locator unless all such locators be the same. This document makes no such requirement, nor does it define "sameness" among locators (which a standard might do using, for example, canonicalization rules).2.3.4. Uniqueness, Ambiguity, and Multiple Objects per Access A uniqueness requirement might dictate that a resource locator identify exactly one object as opposed to several objects. This document makes no general definition of what constitutes one object, several objects, or one object consisting of several objects.3. Resource Access and Availability A locator never guarantees access, but establishing access is by far the most important intended application of a resource locator. While it is considered ungracious to advertize a locator for a resource that will never be accessible (whether a "networkable" resource or not), it is normal for resource access to fail at a rate that increases with the age of the locator used.Kunze [Page 5]⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?