draft-ietf-uri-irl-fun-req-01.txt   draft-ietf-uri-irl-fun-req-02.txt 
IETF URI Working Group John A. Kunze IETF URI Working Group John A. Kunze
Internet-Draft IS&T, UC Berkeley Internet-Draft IS&T, UC Berkeley
27 July 1994 Expires in six months 28 November 1994 Expires in six months
Functional Requirements for Internet Resource Locators Functional Requirements for Internet Resource Locators
<draft-ietf-uri-irl-fun-req-01.txt> <draft-ietf-uri-irl-fun-req-02.txt>
1. Status of this Document 1. Status of this Document
This document is an Internet-Draft. Internet-Drafts are working documents This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its Areas, and its Working of the Internet Engineering Task Force (IETF), its Areas, and its Working
Groups. Note that other groups may also distribute working documents as Groups. Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are working documents valid for a maximum of six months. Internet-Drafts are working documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or obsoleted by other documents Internet-Drafts may be updated, replaced, or obsoleted by other documents
skipping to change at line 201 skipping to change at line 201
Such a user is a producer in a sense, but if the locator is purely for 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, personal consumption the user is not bound by the requirements. In fact,
some client software may offer as a service to translate abbreviated, some client software may offer as a service to translate abbreviated,
non-conformant locators entered by users into successful access non-conformant locators entered by users into successful access
instructions or into conformant locators (e.g., by adding a domain name instructions or into conformant locators (e.g., by adding a domain name
to an unqualified hostname) to an unqualified hostname)
3.3 Uniqueness of Resource Locators 3.3 Uniqueness of Resource Locators
The topic of a "uniqueness" requirement for resource locators has been The topic of a "uniqueness" requirement for resource locators has been
discussed a great deal. This document recognizes several aspects of discussed a great deal. This document considers the following aspects
uniqueness, but deliberately makes few requirements regarding them. of uniqueness, but deliberately rejects them as requirements. It is
It is incumbent upon a resource location standard that takes on this incumbent upon a resource location standard that takes on this topic
topic to be clear about which aspects it addresses. Some of them follow. to be clear about which aspects it addresses.
3.3.1. Uniqueness and Multiple Copies of a Resource 3.3.1. Uniqueness and Multiple Copies of a Resource
A uniqueness requirement might dictate that no identical copies of a A uniqueness requirement might dictate that no identical copies of a
resource may exist. This document makes no such requirement. resource may exist. This document makes no such requirement.
3.3.2. Uniqueness and Deterministic Access 3.3.2. Uniqueness and Deterministic Access
A uniqueness requirement might dictate that the same resource accessed A uniqueness requirement might dictate that the same resource accessed
in one attempt will also be the result of any other successful attempt. in one attempt will also be the result of any other successful attempt.
This document makes no such requirement, nor does it define "sameness". This document makes no such requirement, nor does it define "sameness".
It is inappropriate for a resource location standard to define "sameness" It is inappropriate for a resource location standard to define "sameness"
skipping to change at line 344 skipping to change at line 344
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 5.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 of
a resource, not other properties such as its type, size, modification a resource, not other properties such as its type, size, modification
date, etc. These and other properties belong in a resource description date, etc. These and other properties belong in a resource description
standard. standard.
6. Conclusion 6. Security Considerations
While the requirements have no direct security implications, applications
based on standards that fulfill them may need to consider two potential
vulnerabilities. First, because locators are transient, a client using an
invalid locator might unwittingly gain access to a resource that was not
the intended target. For example, when a hostname becomes unregistered
for a period of time and then re-registered, a locator that was no longer
valid during that period 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,
potentially enormous processing freedom is allowed, depending on the
individual service. A server is vulnerable unless it suitably restricts
its input parameters. For example, a server that advertizes locators for
certain local filesystem objects may inadvertently open a door through
which other filesystem objects can be accessed.
A client is also vulnerable unless it understands the limitations of the
service it is using. For example, a client trusting a locator obtained
from an uncertain source might inadvertently trigger a mechanism that
applies charges to a user account. Having a clear definition of service
limitations could help alleviate some of these concerns.
7. Conclusion
Resource location standards, which define Internet resource locators, Resource location standards, which define Internet resource locators,
give providers the means to describe access information for their give providers the means to describe access information for their
resources. They give client developers the ability to access disparate resources. They give client developers the ability to access disparate
resources while hiding access details from users. resources while hiding access details from users.
Several minimum requirements distinguish an Internet locator from a general Several minimum requirements distinguish an Internet locator from a general
locator. Internet resource locators are impermanent handles sufficiently locator. Internet resource locators are impermanent handles sufficiently
qualified for resource access not to depend in general on client location. qualified for resource access not to depend in general on client location.
Locators can be recognized and parsed, and can be transmitted unscathed Locators can be recognized and parsed, and can be transmitted unscathed
through a variety of human and Internet communication mechanisms. through a variety of human and Internet communication mechanisms.
An Internet resource locator consists of a service and access parameters An Internet resource locator consists of a service and access parameters
meaningful to that service. The form of the locator does not discourage meaningful to that service. The form of the locator does not discourage
the addition of new services or the migration to other resource identifiers. the addition of new services or the migration to other resource identifiers.
A clean distinction between resource location, resource naming, and resource A clean distinction between resource location, resource naming, and resource
description standards is preserved by limiting Internet locators to no more description standards is preserved by limiting Internet locators to no more
information than what is required by an access mechanism. information than what is required by an access mechanism.
7. Acknowledgements 8. Acknowledgements
The core requirements of this document arose from a collaboration of the The core requirements of this document arose from a collaboration of the
following people at the November 1993 IETF meeting in Houston, Texas. following people at the November 1993 IETF meeting in Houston, Texas.
Farhad Ankelesaria, University of Minnesota Farhad Ankelesaria, University of Minnesota
John Curran, NEARNET John Curran, NEARNET
Peter Deutsch, Bunyip Peter Deutsch, Bunyip
Alan Emtage, Bunyip Alan Emtage, Bunyip
Jim Fullton, CNIDR Jim Fullton, CNIDR
Kevin Gamiel, CNIDR Kevin Gamiel, CNIDR
skipping to change at line 387 skipping to change at line 411
Clifford Lynch, University of California Clifford Lynch, University of California
Lars-Gunnar Olson, Swedish University of Agriculture Lars-Gunnar Olson, Swedish University of Agriculture
Mark McCahill, University of Minnesota Mark McCahill, University of Minnesota
Michael Mealing, Georgia Tech Michael Mealing, Georgia Tech
Mitra, Pandora Systems Mitra, Pandora Systems
Pete Percival, Indiana University Pete Percival, Indiana University
Margaret St. Pierre, WAIS, Inc. Margaret St. Pierre, WAIS, Inc.
Rickard Schoultz, KTH Rickard Schoultz, KTH
Janet Vratny, Apple Computer Library Janet Vratny, Apple Computer Library
Chris Weider, Merit Network Chris Weider, Merit Network
9. Author's Address
John A. Kunze
Information Systems and Technology
293 Evans Hall
Berkeley, CA 94720
jak@violet.berkeley.edu
Voice: (510) 642-1530
Fax: (510) 643-5385
 End of changes. 6 change blocks. 
8 lines changed or deleted 32 lines changed or added

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