draft-ietf-uri-irl-fun-req-02.txt   rfc1736.txt 
IETF URI Working Group John A. Kunze
Internet-Draft IS&T, UC Berkeley
28 November 1994 Expires in six months
Functional Requirements for Internet Resource Locators Network Working Group J. Kunze
<draft-ietf-uri-irl-fun-req-02.txt> Request for Comments: 1736 IS&T, UC Berkeley
Category: Informational February 1995
1. Status of this Document Functional Recommendations for Internet Resource Locators
This document is an Internet-Draft. Internet-Drafts are working documents Status of this Memo
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 working documents valid for a maximum of six months. This memo provides information for the Internet community. This memo
Internet-Drafts may be updated, replaced, or obsoleted by other documents does not specify an Internet standard of any kind. Distribution of
at any time. It is not appropriate to use Internet-Drafts as reference this memo is unlimited.
material or to cite them other than as a ``working draft' or ``work in
progress.''
To learn the current status of any Internet-Draft, please check the 1. Introduction
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
Distribution of this document is unlimited. Please send comments to the This document specifies a minimum set of requirements for Internet
author at jak@violet.berkeley.edu or to the discussion list uri@bunyip.com. 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.
2. Introduction 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).
This document specifies a minimum set of requirements for Internet A resource locator is a kind of resource identifier. Other kinds of
resource locators, which convey location and access information for resource identifiers allow names and descriptions to be associated
resources. Typical examples of resources include network accessible with resources. A resource name is intended to provide a stable
documents, WAIS databases, FTP servers, and Telnet destinations. 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.
Locators may apply to resources that are not always or not ever network In this document, an Internet resource locator is a locator defined
accessible. Examples of the latter include human beings and physical by an Internet resource location standard. A resource location
objects that have no electronic instantiation (that is, objects without standard in conjunction with resource description and resource naming
an existence completely defined by digital objects such as disk files). 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.
A resource locator is a kind of resource identifier. Other kinds of 2. Overview of Problem
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 Network-based information resource providers require a method of
an Internet resource location standard. A resource location standard describing the location of and access to their resources.
in conjunction with resource description and resource naming standards Information systems users require a method whereby client software
specifies a comprehensive infrastructure for network based information can interpret resource access and location descriptions on their
dissemination. Mechanisms for mapping between locators, names, and behalf in a relatively transparent way. Without such a method,
descriptive identifiers are beyond the scope of this document. transparent and widely distributed, open information access on the
Internet would be difficult if not impossible.
3. Overview of Problem 2.1 Defining the General Resource Locator
Network-based information resource providers require a method of describing The requirements listed in this document impose restrictions on the
the location of and access to their resources. Information systems users general resource locator. To better understand what the Internet
require a method whereby client software can interpret resource access and resource locator is, the following general locator definition
location descriptions on their behalf in a relatively transparent way. provides some contrast.
Without such a method, transparent and widely distributed, open information
access on the Internet would be difficult if not impossible.
3.1 Defining the General Resource Locator Definition: A general resource locator is an object
that describes the location of a resource.
The requirements listed in this document impose restrictions on the This definition deliberately allows many degrees of freedom in order
general resource locator. To better understand what the Internet resource to contain the furthest reaches of the wide-ranging debate on
locator is, the following general locator definition provides some contrast. 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.
Definition: A general resource locator is an object Consider the definition in four parts: (1) A general resource locator
that describes the location of a resource. is an object (2) that describes (3) the location of (4) a resource.
This definition deliberately allows many degrees of freedom in order 2.1.1. A general resource locator is an object...
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 The object could be a complex data structure. It could be a
is an object (2) that describes (3) the location of (4) a resource. 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.
3.1.1. A general resource locator is an object... 2.1.2. ...that describes
The object could be a complex data structure. It could be a contiguous In the fully general case, there are many ways that a resource
sequence of bytes. It could be a pair of latitude-longitude coordinates, locator could describe the location. It could employ a graphical or
or a three-color road map printed on paper. It could be a sequence of natural language description. It could be heavily encoded or
characters that are capable of being printed on paper. 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.
3.1.2. ...that describes 2.1.3. ...the location of
In the fully general case, there are many ways that a resource locator A resource locator describes a location but never guarantees that
could describe the location. It could employ a graphical or natural access may be established. While access is often desired when
language description. It could be heavily encoded or compressed. It clients follow location instructions given in a conformant resource
could be lightly encoded and readily understandable by human beings. locator, the resource need not exist any longer or need not exist
The description could be a multi-level hierarchy with common semantics yet. Indeed it may never exist, even though the locator continues to
at each level. It could be a multi-level hierarchy with common semantics describe a location where a resource might exist (e.g., it might be
at only the first two levels, where semantics below the second level used as a placeholder with resource availability contingent upon an
depend on the value given at the first level. These are just a few event such as a payment).
possibilities.
3.1.3. ...the location of 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.
A resource locator describes a location but never guarantees that access 2.1.4. ...a resource.
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 A resource can be many things. Besides the non-networked or non-
beings or physical objects with no electronic instantiation, makes network electronic resources just mentioned, familiar examples are an
access meaningless in some cases; such resources have locators that would electronic document, an image, a server (e.g., FTP, Gopher, Telnet,
imply non-networked access, but again, access is not guaranteed. 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.
3.1.4. ...a resource. 2.2 Producers and Interpreters of Resource Locators
A resource can be many things. Besides the non-networked or non-electronic Central to the discussion of locator requirements is the issue of
resources just mentioned, familiar examples are an electronic document, parsability. This is the ability of an agent to recognize or
an image, a server (e.g., FTP, Gopher, Telnet, HTTP), or a collection understand a locator in whole or in part. Discussion may be assisted
of items (e.g., Gopher menu, FTP directory, HTML page). Other examples by clearly distinguishing the two main actions associated with
accompany multi-function protocols such as Z39.50, which can perform locators.
single round trip network access, session-oriented search refinement,
and index browsing.
3.2 Producers and Interpreters of Resource 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.
Central to the discussion of locator requirements is the issue of 2.2.1 Resource Locator Interpreters
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 A resource locator is interpreted by interpreting agents, which in
by the resource location standards that are in turn bound by requirements this document are simply called interpreters. Interpreters may be
listed in this document. Interpreters of locators are not bound by the either human beings or software. Along the way to establishing
requirements; they are beneficiaries of them. 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 be
understandable only in part by each of several interpreters, but
understandable in its entirety by a combination of interpreters.
3.2.1 Resource Locator 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.
A resource locator is interpreted by interpreting agents, which in this In another example, a human interpreter might also recognize enough
document are simply called interpreters. Interpreters may be either of a locator to understand where to forward it. Here, the person
human beings or software. Along the way to establishing access based might be a user who recognizes a library call number as such but who
on information in a locator, one or more interpreters may be employed. does not understand the location information encoded in it; the
Some examples of multiple interpreters processing a single locator person forwards it to a library employee (an external agent) who
illustrate the concept that a resource locator may be understandable knows how to establish access to the library resource.
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 A prerequisite to interpreting a locator is understanding when an
locator to understand to which external agent it needs to forward it. object in question actually is a locator, or contains one or more
Here, the external agent might be a user and the locator a library call locators. Some constrained environments make this question easy to
number; the software forwards the locator simply by displaying it. The answer, for example, within HTML anchors or Gopher menu items. Less
agent might be a network software layer specializing in a particular constrained environments, such as within running text, make it more
communications protocol; once the service is recognized, the locator difficult to answer without well-defined assumptions. A resource
is forwarded to it along with an access request. location standard needs to make any such assumptions explicit.
In another example, a human interpreter might also recognize enough 2.2.2 Resource Locator Producers
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 Resource locators are produced in many ways, often by an agent that
in question actually is a locator, or contains one or more locators. Some also interprets them. The provider of a resource may produce a
constrained environments make this question easy to answer, for example, locator for it, leaving the locator in places where it is intended to
within HTML anchors or Gopher menu items. Less constrained environments, be discovered, such as an HTML page, a Gopher menu, or an
such as within running text, make it more difficult to answer without announcement to an e-mail list.
well-defined assumptions. A resource location standard needs to make any
such assumptions explicit.
3.2.2 Resource Locator Producers 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.
Resource locators are produced in many ways, often by an agent that also Users are major producers of resource locators. A user constructing
interprets them. The provider of a resource may produce a locator for it, one to share with others is responsible for conformance with locator
leaving the locator in places where it is intended to be discovered, such standards. Sometimes a user composes a resource locator based on an
as an HTML page, a Gopher menu, or an announcement to an e-mail list. 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 a
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)
Non-providers of resources can be major producers of locators; for example, 2.3 Uniqueness of Resource Locators
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 The topic of a "uniqueness" requirement for resource locators has
to share with others is responsible for conformance with locator standards. been discussed a great deal. This document considers the following
Sometimes a user composes a resource locator based on an educated guess aspects of uniqueness, but deliberately rejects them as requirements.
and submits it to client software with the intent of establishing access. It is incumbent upon a resource location standard that takes on this
Such a user is a producer in a sense, but if the locator is purely for topic to be clear about which aspects it addresses.
personal consumption the user is not bound by the requirements. In fact,
some client software may offer as a 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)
3.3 Uniqueness of Resource Locators 2.3.1. Uniqueness and Multiple Copies of a Resource
The topic of a "uniqueness" requirement for resource locators has been A uniqueness requirement might dictate that no identical copies of a
discussed a great deal. This document considers the following aspects resource may exist. This document makes no such requirement.
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.
3.3.1. Uniqueness and Multiple Copies of a Resource 2.3.2. Uniqueness and Deterministic Access
A uniqueness requirement might dictate that no identical copies of a
resource may exist. This document makes no such requirement.
3.3.2. Uniqueness and Deterministic Access A uniqueness requirement might dictate that the same resource
A uniqueness requirement might dictate that the same resource accessed accessed in one attempt will also be the result of any other
in one attempt will also be the result of any other successful attempt. successful attempt. This document makes no such requirement, nor
This document makes no such requirement, nor does it define "sameness". does it define "sameness". It is inappropriate for a resource
It is inappropriate for a resource location standard to define "sameness" location standard to define "sameness" among resources.
among resources.
3.3.3. Uniqueness and Multiple Locators 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).
3.3.4. Uniqueness, Ambiguity, and Multiple Objects per Access A uniqueness requirement might dictate that a resource have no more
A uniqueness requirement might dictate that a resource locator identify than one locator unless all such locators be the same. This document
exactly one object as opposed to several objects. This document makes makes no such requirement, nor does it define "sameness" among
no general definition of what constitutes one object, several objects, locators (which a standard might do using, for example,
or one object consisting of several objects. canonicalization rules).
4. Resource Access and Availability 2.3.4. Uniqueness, Ambiguity, and Multiple Objects per Access
A locator never guarantees access, but establishing access is by far the A uniqueness requirement might dictate that a resource locator
most important intended application of a resource locator. While it is identify exactly one object as opposed to several objects. This
considered ungracious to advertize a locator for a resource that will document makes no general definition of what constitutes one object,
never be accessible (whether a "networkable" resource or not), it is several objects, or one object consisting of several objects.
normal for resource access to fail at a rate that increases with the
age of the locator used.
Resource access can fail for many reasons. Providers fundamentally affect 3. Resource Access and Availability
accessibility by moving, replacing, or deleting resources over time. The
frequency of such changes depends on the nature of the resource and provider
service practices, among other things. A locator that conforms to a
location standard but fails for one of 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 problem of invalid locators.
Ordinary provider support policies may cause resources to be inaccessible A locator never guarantees access, but establishing access is by far
during predictable time periods (e.g., certain hours of the day, or days the most important intended application of a resource locator. While
of the year), or during periods of heavy system loading. Rights clearance it is considered ungracious to advertize a locator for a resource
restrictions impossible to express in a locator also affect accessibility that will never be accessible (whether a "networkable" resource or
for certain user populations. Heavy network load can also prevent access. not), it is normal for resource access to fail at a rate that
In such situations, this document calls a resource "unavailable". increases with the age of the locator used.
A locator can both be valid and identify a resource that is unavailable.
Resource description standards address, among other things, some aspects
of resource availability.
In general, the probability with which a given resource locator leads Resource access can fail for many reasons. Providers fundamentally
to successful access decreases over time, and depends on conditions such as affect accessibility by moving, replacing, or deleting resources over
the nature of the resource, support policies of the provider, and loading time. The frequency of such changes depends on the nature of the
of the network. resource and provider service practices, among other things. A
locator that conforms to a location standard but fails for one of
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 problem
of invalid locators.
5. Requirements List for Internet Resource Locators Ordinary provider support policies may cause resources to be
inaccessible during predictable time periods (e.g., certain hours of
the day, or days of the year), or during periods of heavy system
loading. Rights clearance restrictions impossible to express in a
locator also affect accessibility for certain user populations.
Heavy network load can also prevent access. In such situations, this
document calls a resource "unavailable". A locator can both be valid
and identify a resource that is unavailable. Resource description
standards address, among other things, some aspects of resource
availability.
This list of requirements is applied to the set of general locators In general, the probability with which a given resource locator leads
defined in section 3.1. The resulting subset, called Internet locators to successful access decreases over time, and depends on conditions
in this document, is suitable for further refinement by an Internet such as the nature of the resource, support policies of the provider,
resource location standard. Some requirements concern locator encoding and loading of the network.
while others concern locator function.
One requirement from the original draft list was dropped after extensive 4. Requirements List for Internet Resource Locators
discussion revealed it to be impractical to meet. It stated that with a
high degree of reliability, software can recognize Internet locators in
certain relatively unstructured environments, such as within running
ASCII text.
5.1 Locators are transient. This list of requirements is applied to the set of general locators
defined in section 2.1. The resulting subset, called Internet
locators in this document, is suitable for further refinement by an
Internet resource location standard. Some requirements concern
locator encoding while others concern locator function.
The probability with which a given Internet resource locator leads to One requirement from the original draft list was dropped after
successful access decreases over time. More stable resource identifier extensive discussion revealed it to be impractical to meet. It
schemes are addressed in resource naming standards and are outside stated that with a high degree of reliability, software can recognize
the scope of a resource location standard. Internet locators in certain relatively unstructured environments,
such as within running ASCII text.
5.2 Locators have global scope. 4.1 Locators are transient.
The name space of resource locators includes the entire world. The probability with which a given Internet resource locator leads to
The probability of successful access using an Internet locator successful access decreases over time. More stable resource
depends in no way, modulo resource availability, on the geographical identifier schemes are addressed in resource naming standards and are
or Internet location of the client. outside the scope of a resource location standard.
5.3 Locators are parsable. 4.2 Locators have global scope.
Internet locators can be broken down into complete constituent parts The name space of resource locators includes the entire world. The
sufficient for interpreters (software or human) to attempt access if probability of successful access using an Internet locator depends in
desired. While these requirements do not bind interpreters, three no way, modulo resource availability, on the geographical or Internet
points bear emphasizing: location of the client.
5.3.1 A given kind of locator may still be parsable even if a given 4.3 Locators are parsable.
Internet locators can be broken down into complete constituent parts
sufficient for interpreters (software or human) to attempt access if
desired. While these requirements do not bind interpreters, three
points bear emphasizing:
4.3.1 A given kind of locator may still be parsable even if a given
interpreter cannot parse it. interpreter cannot parse it.
5.3.2 Parsable by users does not imply readily parsable by untrained users.
5.3.3 A given locator need not be completely parsable by any one interpreter
as long as a combination of interpreters can parse it completely.
5.4 Locators can be readily distinguished from naming and descriptive 4.3.2 Parsable by users does not imply readily parsable by untrained
users.
4.3.3 A given locator need not be completely parsable by any one
interpreter as long as a combination of interpreters can parse
it completely.
4.4 Locators can be readily distinguished from naming and descriptive
identifiers that may occupy the same name space. identifiers that may occupy the same name space.
During a transition period (of possibly indefinite length), other kinds During a transition period (of possibly indefinite length), other
of resource identifier are expected to co-exist in data structures along kinds of resource identifier are expected to co-exist in data
with Internet locators. structures along with Internet locators.
5.5 Locators are "transport-friendly". 4.5 Locators are "transport-friendly".
Internet locators can be transmitted from user to user (e.g, via e-mail) Internet locators can be transmitted from user to user (e.g, via e-
across Internet standard communications protocols without loss or mail) across Internet standard communications protocols without loss
corruption of information. or corruption of information.
5.6 Locators are human transcribable. 4.6 Locators are human transcribable.
Users can copy Internet locators from one medium to another (such as Users can copy Internet locators from one medium to another (such as
voice to paper, or paper to keyboard) without loss or corruption of voice to paper, or paper to keyboard) without loss or corruption of
information. This process is not required to be comfortable. information. This process is not required to be comfortable.
5.7 An Internet locator consists of a service and an opaque parameter package. 4.7 An Internet locator consists of a service and an opaque parameter
package.
The parameter package has meaning only to the service with which it is The parameter package has meaning only to the service with which it
paired, where a service is an abstract access method. An abstract access is paired, where a service is an abstract access method. An abstract
method might be a software tool, an institution, or a network protocol. access method might be a software tool, an institution, or a network
The parameter package might be service-specific access instructions. protocol. The parameter package might be service-specific access
In order to protect creative development of new services, there is an instructions. In order to protect creative development of new
extensible class of services for which no parameter package semantics services, there is an extensible class of services for which no
common across services may be assumed. parameter package semantics common across services may be assumed.
5.8 The set of services is extensible. 4.8 The set of services is extensible.
New services can be added over time. New services can be added over time.
5.9 Locators contain no information about the resource other than that 4.9 Locators contain no information about the resource other than that
required by the access mechanism. required by the access mechanism.
The purpose of an Internet locator is only to describe the location of The purpose of an Internet locator is only to describe the location
a resource, not other properties such as its type, size, modification of a resource, not other properties such as its type, size,
date, etc. These and other properties belong in a resource description modification date, etc. These and other properties belong in a
standard. resource description standard.
6. Security Considerations 5. Security Considerations
While the requirements have no direct security implications, applications While the requirements have no direct security implications,
based on standards that fulfill them may need to consider two potential applications based on standards that fulfill them may need to
vulnerabilities. First, because locators are transient, a client using an consider two potential vulnerabilities. First, because locators are
invalid locator might unwittingly gain access to a resource that was not transient, a client using an invalid locator might unwittingly gain
the intended target. For example, when a hostname becomes unregistered access to a resource that was not the intended target. For example,
for a period of time and then re-registered, a locator that was no longer when a hostname becomes unregistered for a period of time and then
valid during that period might once again lead to a resource, but perhaps re-registered, a locator that was no longer valid during that period
to one that only pretends to be the original resource. might once again lead to a resource, but perhaps to one that only
pretends to be the original resource.
Second, because a locator consists of a service and a parameter package, Second, because a locator consists of a service and a parameter
potentially enormous processing freedom is allowed, depending on the package, potentially enormous processing freedom is allowed,
individual service. A server is vulnerable unless it suitably restricts depending on the individual service. A server is vulnerable unless
its input parameters. For example, a server that advertizes locators for it suitably restricts its input parameters. For example, a server
certain local filesystem objects may inadvertently open a door through that advertizes locators for certain local filesystem objects may
which other filesystem objects can be accessed. inadvertently open a door through which other filesystem objects can
be accessed.
A client is also vulnerable unless it understands the limitations of the A client is also vulnerable unless it understands the limitations of
service it is using. For example, a client trusting a locator obtained the service it is using. For example, a client trusting a locator
from an uncertain source might inadvertently trigger a mechanism that obtained from an uncertain source might inadvertently trigger a
applies charges to a user account. Having a clear definition of service mechanism that applies charges to a user account. Having a clear
limitations could help alleviate some of these concerns. definition of service limitations could help alleviate some of these
concerns.
7. Conclusion For services that by nature offer a great deal of user freedom
(remote login for example), the pre-specification of user commands
within a locator presents vulnerabilities. With careful command
screening, the deleterious effects of unknowingly executing (at the
client or server) an embedded command such as "rm -fr *" can be
avoided.
Resource location standards, which define Internet resource locators, 6. Conclusion
give providers the means to describe access information for their
resources. They give client developers the ability to access disparate
resources while hiding access details from users.
Several minimum requirements distinguish an Internet locator from a general Resource location standards, which define Internet resource locators,
locator. Internet resource locators are impermanent handles sufficiently give providers the means to describe access information for their
qualified for resource access not to depend in general on client location. resources. They give client developers the ability to access
Locators can be recognized and parsed, and can be transmitted unscathed disparate resources while hiding access details from users.
through a variety of human and Internet communication mechanisms.
An Internet resource locator consists of a service and access parameters Several minimum requirements distinguish an Internet locator from a
meaningful to that service. The form of the locator does not discourage general locator. Internet resource locators are impermanent handles
the addition of new services or the migration to other resource identifiers. sufficiently qualified for resource access not to depend in general
A clean distinction between resource location, resource naming, and resource on client location. Locators can be recognized and parsed, and can
description standards is preserved by limiting Internet locators to no more be transmitted unscathed through a variety of human and Internet
information than what is required by an access mechanism. communication mechanisms.
8. Acknowledgements An Internet resource locator consists of a service and access
parameters meaningful to that service. The form of the locator does
not discourage the addition of new services or the migration to other
resource identifiers. A clean distinction between resource location,
resource naming, and resource description standards is preserved by
limiting Internet locators to no more information than what is
required by an access mechanism.
The core requirements of this document arose from a collaboration of the 7. Acknowledgements
following people at the November 1993 IETF meeting in Houston, Texas.
Farhad Ankelesaria, University of Minnesota The core requirements of this document arose from a collaboration of
John Curran, NEARNET the following people at the November 1993 IETF meeting in Houston,
Peter Deutsch, Bunyip Texas.
Alan Emtage, Bunyip
Jim Fullton, CNIDR
Kevin Gamiel, CNIDR
Joan Gargano, University of California at Davis
John Kunze, University of California at Berkeley
Clifford Lynch, University of California
Lars-Gunnar Olson, Swedish University of Agriculture
Mark McCahill, University of Minnesota
Michael Mealing, Georgia Tech
Mitra, Pandora Systems
Pete Percival, Indiana University
Margaret St. Pierre, WAIS, Inc.
Rickard Schoultz, KTH
Janet Vratny, Apple Computer Library
Chris Weider, Merit Network
9. Author's Address Farhad Ankelesaria, University of Minnesota
John Curran, NEARNET
Peter Deutsch, Bunyip
Alan Emtage, Bunyip
Jim Fullton, CNIDR
Kevin Gamiel, CNIDR
Joan Gargano, University of California at Davis
John Kunze, University of California at Berkeley
Clifford Lynch, University of California
Lars-Gunnar Olson, Swedish University of Agriculture
Mark McCahill, University of Minnesota
Michael Mealing, Georgia Tech
Mitra, Pandora Systems
Pete Percival, Indiana University
Margaret St. Pierre, WAIS, Inc.
Rickard Schoultz, KTH
Janet Vratny, Apple Computer Library
Chris Weider, Bunyip
John A. Kunze 8. Author's Address
Information Systems and Technology
293 Evans Hall John A. Kunze
Berkeley, CA 94720 Information Systems and Technology
jak@violet.berkeley.edu 293 Evans Hall
Voice: (510) 642-1530 Berkeley, CA 94720
Fax: (510) 643-5385
Phone: (510) 642-1530
Fax: (510) 643-5385
EMail: jak@violet.berkeley.edu
 End of changes. 87 change blocks. 
325 lines changed or deleted 344 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/