As per Relevance of the word resource, we have this rfc below:
Network Working Group J.
Request for Comments: 1736 IS&T, UC
Category: Informational February 1995
Functional Recommendations for Internet Resource
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
1.
This document specifies a minimum set of requirements for
resource locators, which convey location and access information
resources. Typical examples of resources include network
documents, WAIS databases, FTP servers, and Telnet destinations
Locators may apply to resources that are not always or not
network accessible. Examples of the latter include human beings
physical objects that have no electronic instantiation (that is
objects without an existence completely defined by digital
such as disk files).
A resource locator is a kind of resource identifier. Other kinds
resource identifiers allow names and descriptions to be
with resources. A resource name is intended to provide a
handle to refer to a resource long after the resource itself
moved or perhaps gone out of existence. A resource
comprises a body of meta-information to assist resource search
selection
In this document, an Internet resource locator is a locator
by an Internet resource location standard. A resource
standard in conjunction with resource description and resource
standards specifies a comprehensive infrastructure for network
information dissemination. Mechanisms for mapping between locators
names, and descriptive identifiers are beyond the scope of
document
2. Overview of
Network-based information resource providers require a method
describing the location of and access to their resources
Information systems users require a method whereby client
can interpret resource access and location descriptions on
Kunze [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
Internet would be difficult if not impossible
2.1 Defining the General Resource
The requirements listed in this document impose restrictions on
general resource locator. To better understand what the
resource locator is, the following general locator
provides some contrast
Definition: A general resource locator is an
that describes the location of a resource
This definition deliberately allows many degrees of freedom in
to contain the furthest reaches of the wide-ranging debate
resource location standards. Vast as it is, this problem space is
useful backdrop for discussion of the requirements (later)
generate a smaller, more manageable problem space. A
location standard shrinks the space again by applying
requirements
Consider the definition in four parts: (1) A general resource
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
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
printed on paper
2.1.2. ...that
In the fully general case, there are many ways that a
locator could describe the location. It could employ a graphical
natural language description. It could be heavily encoded
compressed. It could be lightly encoded and readily
by human beings. The description could be a multi-level
with common semantics at each level. It could be a multi-
hierarchy with common semantics at only the first two levels,
semantics below the second level depend on the value given at
first level. These are just a few possibilities
Kunze [Page 2]
RFC 1736 Recommendations for IRLs February 1995
2.1.3. ...the location
A resource locator describes a location but never guarantees
access may be established. While access is often desired
clients follow location instructions given in a conformant
locator, the resource need not exist any longer or need not
yet. Indeed it may never exist, even though the locator continues
describe a location where a resource might exist (e.g., it might
used as a placeholder with resource availability contingent upon
event such as a payment).
Furthermore, the nature of certain potential resources,
animate beings or physical objects with no electronic instantiation
makes network access meaningless in some cases; such resources
locators that would imply non-networked access, but again, access
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
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
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
Central to the discussion of locator requirements is the issue
parsability. This is the ability of an agent to recognize
understand a locator in whole or in part. Discussion may be
by clearly distinguishing the two main actions associated
locators
Resource locators are both produced and interpreted. Producers
bound by the resource location standards that are in turn bound
requirements listed in this document. Interpreters of locators
not bound by the requirements; they are beneficiaries of them
2.2.1 Resource Locator
A resource locator is interpreted by interpreting agents, which
this document are simply called interpreters. Interpreters may
either human beings or software. Along the way to
access based on information in a locator, one or more
may be employed. Some examples of multiple interpreters processing
single locator illustrate the concept that a resource locator may
Kunze [Page 3]
RFC 1736 Recommendations for IRLs February 1995
understandable only in part by each of several interpreters,
understandable in its entirety by a combination of interpreters
In the first example, a software interpreter recognizes enough of
locator to understand to which external agent it needs to forward it
Here, the external agent might be a user and the locator a
call number; the software forwards the locator simply by
it. The agent might be a network software layer specializing in
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
of a locator to understand where to forward it. Here, the
might be a user who recognizes a library call number as such but
does not understand the location information encoded in it;
person forwards it to a library employee (an external agent)
knows how to establish access to the library resource
A prerequisite to interpreting a locator is understanding when
object in question actually is a locator, or contains one or
locators. Some constrained environments make this question easy
answer, for example, within HTML anchors or Gopher menu items.
constrained environments, such as within running text, make it
difficult to answer without well-defined assumptions. A
location standard needs to make any such assumptions explicit
2.2.2 Resource Locator
Resource locators are produced in many ways, often by an agent
also interprets them. The provider of a resource may produce
locator for it, leaving the locator in places where it is intended
be discovered, such as an HTML page, a Gopher menu, or
announcement to an e-mail list
Non-providers of resources can be major producers of locators;
example, WWW client software produces locators by translating
resource locators (e.g., Gopher menu items) to its own format.
locator databases (e.g., Archie) have been maintained by
processes that produce locators for hundreds of thousands of
resources that they "discover" on the Internet
Users are major producers of resource locators. A user
one to share with others is responsible for conformance with
standards. Sometimes a user composes a resource locator based on
educated guess and submits it to client software with the intent
establishing access. Such a user is a producer in a sense, but
the locator is purely for personal consumption the user is not
by the requirements. In fact, some client software may offer as
Kunze [Page 4]
RFC 1736 Recommendations for IRLs February 1995
service to translate abbreviated, non-conformant locators entered
users into successful access instructions or into conformant
(e.g., by adding a domain name to an unqualified hostname
2.3 Uniqueness of Resource
The topic of a "uniqueness" requirement for resource locators
been discussed a great deal. This document considers the
aspects of uniqueness, but deliberately rejects them as requirements
It is incumbent upon a resource location standard that takes on
topic to be clear about which aspects it addresses
2.3.1. Uniqueness and Multiple Copies of a
A uniqueness requirement might dictate that no identical copies of
resource may exist. This document makes no such requirement
2.3.2. Uniqueness and Deterministic
A uniqueness requirement might dictate that the same
accessed in one attempt will also be the result of any
successful attempt. This document makes no such requirement,
does it define "sameness". It is inappropriate for a
location standard to define "sameness" among resources
2.3.3. Uniqueness and Multiple
A uniqueness requirement might dictate that a resource have no
than one locator unless all such locators be the same. This
makes no such requirement, nor does it define "sameness"
locators (which a standard might do using, for example
canonicalization rules).
2.3.4. Uniqueness, Ambiguity, and Multiple Objects per
A uniqueness requirement might dictate that a resource
identify exactly one object as opposed to several objects.
document makes no general definition of what constitutes one object
several objects, or one object consisting of several objects
3. Resource Access and
A locator never guarantees access, but establishing access is by
the most important intended application of a resource locator.
it is considered ungracious to advertize a locator for a
that will never be accessible (whether a "networkable" resource
not), it is normal for resource access to fail at a rate
increases with the age of the locator used
Kunze [Page 5]
RFC 1736 Recommendations for IRLs February 1995
Resource access can fail for many reasons. Providers
affect accessibility by moving, replacing, or deleting resources
time. The frequency of such changes depends on the nature of
resource and provider service practices, among other things.
locator that conforms to a location standard but fails for one
these reasons is called "invalid" for the purposes of this document
the term invalid locator does not apply to malformed or non
conformant locators. Resource naming standards address the
of invalid locators
Ordinary provider support policies may cause resources to
inaccessible during predictable time periods (e.g., certain hours
the day, or days of the year), or during periods of heavy
loading. Rights clearance restrictions impossible to express in
locator also affect accessibility for certain user populations
Heavy network load can also prevent access. In such situations,
document calls a resource "unavailable". A locator can both be
and identify a resource that is unavailable. Resource
standards address, among other things, some aspects of
availability
In general, the probability with which a given resource locator
to successful access decreases over time, and depends on
such as the nature of the resource, support policies of the provider
and loading of the network
4. Requirements List for Internet Resource
This list of requirements is applied to the set of general
defined in section 2.1. The resulting subset, called
locators in this document, is suitable for further refinement by
Internet resource location standard. Some requirements
locator encoding while others concern locator function
One requirement from the original draft list was dropped
extensive discussion revealed it to be impractical to meet.
stated that with a high degree of reliability, software can
Internet locators in certain relatively unstructured environments
such as within running ASCII text
4.1 Locators are transient
The probability with which a given Internet resource locator leads
successful access decreases over time. More stable
identifier schemes are addressed in resource naming standards and
outside the scope of a resource location standard
Kunze [Page 6]
RFC 1736 Recommendations for IRLs February 1995
4.2 Locators have global scope
The name space of resource locators includes the entire world.
probability of successful access using an Internet locator depends
no way, modulo resource availability, on the geographical or
location of the client
4.3 Locators are parsable
Internet locators can be broken down into complete constituent
sufficient for interpreters (software or human) to attempt access
desired. While these requirements do not bind interpreters,
points bear emphasizing
4.3.1 A given kind of locator may still be parsable even if a
interpreter cannot parse it
4.3.2 Parsable by users does not imply readily parsable by
users
4.3.3 A given locator need not be completely parsable by any
interpreter as long as a combination of interpreters can
it completely
4.4 Locators can be readily distinguished from naming and
identifiers that may occupy the same name space
During a transition period (of possibly indefinite length),
kinds of resource identifier are expected to co-exist in
structures along with Internet locators
4.5 Locators are "transport-friendly".
Internet locators can be transmitted from user to user (e.g, via e
mail) across Internet standard communications protocols without
or corruption of information
4.6 Locators are human transcribable
Users can copy Internet locators from one medium to another (such
voice to paper, or paper to keyboard) without loss or corruption
information. This process is not required to be comfortable
Kunze [Page 7]
RFC 1736 Recommendations for IRLs February 1995
4.7 An Internet locator consists of a service and an opaque
package
The parameter package has meaning only to the service with which
is paired, where a service is an abstract access method. An
access method might be a software tool, an institution, or a
protocol. The parameter package might be service-specific
instructions. In order to protect creative development of
services, there is an extensible class of services for which
parameter package semantics common across services may be assumed
4.8 The set of services is extensible
New services can be added over time
4.9 Locators contain no information about the resource other than
required by the access mechanism
The purpose of an Internet locator is only to describe the
of a resource, not other properties such as its type, size
modification date, etc. These and other properties belong in
resource description standard
5. Security
While the requirements have no direct security implications
applications based on standards that fulfill them may need
consider two potential vulnerabilities. First, because locators
transient, a client using an invalid locator might unwittingly
access to a resource that was not the intended target. For example
when a hostname becomes unregistered for a period of time and
re-registered, a locator that was no longer valid during that
might once again lead to a resource, but perhaps to one that
pretends to be the original resource
Second, because a locator consists of a service and a
package, potentially enormous processing freedom is allowed
depending on the individual service. A server is vulnerable
it suitably restricts its input parameters. For example, a
that advertizes locators for certain local filesystem objects
inadvertently open a door through which other filesystem objects
be accessed
A client is also vulnerable unless it understands the limitations
the service it is using. For example, a client trusting a
obtained from an uncertain source might inadvertently trigger
mechanism that applies charges to a user account. Having a
definition of service limitations could help alleviate some of
Kunze [Page 8]
RFC 1736 Recommendations for IRLs February 1995
concerns
For services that by nature offer a great deal of user
(remote login for example), the pre-specification of user
within a locator presents vulnerabilities. With careful
screening, the deleterious effects of unknowingly executing (at
client or server) an embedded command such as "rm -fr *" can
avoided
6.
Resource location standards, which define Internet resource locators
give providers the means to describe access information for
resources. They give client developers the ability to
disparate resources while hiding access details from users
Several minimum requirements distinguish an Internet locator from
general locator. Internet resource locators are impermanent
sufficiently qualified for resource access not to depend in
on client location. Locators can be recognized and parsed, and
be transmitted unscathed through a variety of human and
communication mechanisms
An Internet resource locator consists of a service and
parameters meaningful to that service. The form of the locator
not discourage the addition of new services or the migration to
resource identifiers. A clean distinction between resource location
resource naming, and resource description standards is preserved
limiting Internet locators to no more information than what
required by an access mechanism
7.
The core requirements of this document arose from a collaboration
the following people at the November 1993 IETF meeting in Houston
Texas
Farhad Ankelesaria, University of
John Curran,
Peter Deutsch,
Alan Emtage,
Jim Fullton,
Kevin Gamiel,
Joan Gargano, University of California at
John Kunze, University of California at
Clifford Lynch, University of
Lars-Gunnar Olson, Swedish University of
Mark McCahill, University of
Kunze [Page 9]
RFC 1736 Recommendations for IRLs February 1995
Michael Mealing, Georgia
Mitra, Pandora
Pete Percival, Indiana
Margaret St. Pierre, WAIS, Inc
Rickard Schoultz,
Janet Vratny, Apple Computer
Chris Weider,
8. Author's
John A.
Information Systems and
293 Evans
Berkeley, CA 94720
Phone: (510) 642-1530
Fax: (510) 643-5385
EMail: jak@violet.berkeley.
Kunze [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
