< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/