2004/id/draft-ietf-uri-irl-fun-req-01.txt

IETF URI Working Group                                      John A. Kunze
Internet-Draft                                          IS&T, UC Berkeley
27 July 1994                                        Expires in six months


          Functional Requirements for Internet Resource Locators
               <draft-ietf-uri-irl-fun-req-01.txt>

1. Status of this Document

This document is an Internet-Draft.  Internet-Drafts are working documents
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.
Internet-Drafts may be updated, replaced, or obsoleted by other documents
at any time.  It is not appropriate to use Internet-Drafts as reference
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
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
author at jak@violet.berkeley.edu or to the discussion list uri@bunyip.com.


2. 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.


3. 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 their 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.


3.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.

3.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.

3.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.

3.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.

3.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.


3.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.

3.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 be 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.

3.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 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

The topic of a "uniqueness" requirement for resource locators has been
discussed a great deal.  This document recognizes several aspects of
uniqueness, but deliberately makes few requirements regarding them.
It is incumbent upon a resource location standard that takes on this
topic to be clear about which aspects it addresses.  Some of them follow.

3.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.

3.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.

3.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 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.


4. 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.

Resource access can fail for many reasons.  Providers fundamentally affect
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
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.

In general, the probability with which a given resource locator leads
to successful access decreases over time, and depends on conditions such as
the nature of the resource, support policies of the provider, and loading
of the network.


5. Requirements List for Internet Resource Locators

This list of requirements is applied to the set of general locators
defined in section 3.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.

One requirement from the original draft list was dropped after extensive
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.

The probability with which a given Internet resource locator leads to
successful access decreases over time.  More stable resource identifier
schemes are addressed in resource naming standards and are outside
the scope of a resource location standard.

5.2 Locators have global scope.

The name space of resource locators includes the entire world.
The probability of successful access using an Internet locator
depends in no way, modulo resource availability, on the geographical
or Internet location of the client.

5.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:

5.3.1  A given kind of locator may still be parsable even if a given
       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
    identifiers that may occupy the same name space.

During a transition period (of possibly indefinite length), other kinds
of resource identifier are expected to co-exist in data structures along
with Internet locators.

5.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 loss or
corruption of information.

5.6 Locators are human transcribable.

Users can copy Internet locators from one medium to another (such as
voice to paper, or paper to keyboard) without loss or corruption of
information.  This process is not required to be comfortable.

5.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
paired, where a service is an abstract access method.  An abstract access
method might be a software tool, an institution, or a network protocol.
The parameter package might be service-specific access instructions.
In order to protect creative development of new services, there is an
extensible class of services for which no parameter package semantics
common across services may be assumed.

5.8 The set of services is extensible.

New services can be added over time.

5.9 Locators contain no information about the resource other than that
    required by the access mechanism.

The purpose of an Internet locator is only to describe the location of
a resource, not other properties such as its type, size, modification
date, etc.  These and other properties belong in a resource description
standard.


6. Conclusion

Resource location standards, which define Internet resource locators,
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
locator.  Internet resource locators are impermanent handles sufficiently
qualified for resource access not to depend in general on client location.
Locators can be recognized and parsed, and can be transmitted unscathed
through a variety of human and Internet communication mechanisms.

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.


7. Acknowledgements

The core requirements of this document arose from a collaboration of the
following people at the November 1993 IETF meeting in Houston, Texas.

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, Merit Network

1	IETF URI Working Group John A. Kunze
2	Internet-Draft IS&T, UC Berkeley
3	27 July 1994 Expires in six months
4
5
6
7	Functional Requirements for Internet Resource Locators
8	<draft-ietf-uri-irl-fun-req-01.txt>
9
10	1. Status of this Document
11
12	This document is an Internet-Draft. Internet-Drafts are working documents
13	of the Internet Engineering Task Force (IETF), its Areas, and its Working
14	Groups. Note that other groups may also distribute working documents as
15	Internet-Drafts.
16
17	Internet-Drafts are working documents valid for a maximum of six months.
18	Internet-Drafts may be updated, replaced, or obsoleted by other documents
19	at any time. It is not appropriate to use Internet-Drafts as reference
20	material or to cite them other than as a ``working draft' or ``work in
21	progress.''
22
23	To learn the current status of any Internet-Draft, please check the
24	1id-abstracts.txt listing contained in the Internet-Drafts Shadow
25	Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
26	munnari.oz.au.
27
28	Distribution of this document is unlimited. Please send comments to the
29	author at jak@violet.berkeley.edu or to the discussion list uri@bunyip.com.
30
31
32	2. Introduction
33
34	This document specifies a minimum set of requirements for Internet
35	resource locators, which convey location and access information for
36	resources. Typical examples of resources include network accessible
37	documents, WAIS databases, FTP servers, and Telnet destinations.
38
39	Locators may apply to resources that are not always or not ever network
40	accessible. Examples of the latter include human beings and physical
41	objects that have no electronic instantiation (that is, objects without
42	an existence completely defined by digital objects such as disk files).
43
44	A resource locator is a kind of resource identifier. Other kinds of
45	resource identifiers allow names and descriptions to be associated with
46	resources. A resource name is intended to provide a stable handle
47	to refer to a resource long after the resource itself has moved or
48	perhaps gone out of existence. A resource description comprises a
49	body of meta-information to assist resource search and selection.
50
51	In this document, an Internet resource locator is a locator defined by
52	an Internet resource location standard. A resource location standard
53	in conjunction with resource description and resource naming standards
54	specifies a comprehensive infrastructure for network based information
55	dissemination. Mechanisms for mapping between locators, names, and
56	descriptive identifiers are beyond the scope of this document.
57
58
59	3. Overview of Problem
60
61	Network-based information resource providers require a method of describing
62	the location of and access to their resources. Information systems users
63	require a method whereby client software can interpret resource access and
64	location descriptions on their behalf in a relatively transparent way.
65	Without such a method, transparent and widely distributed, open information
66	access on the Internet would be difficult if not impossible.
67
68
69	3.1 Defining the General Resource Locator
70
71	The requirements listed in this document impose restrictions on the
72	general resource locator. To better understand what the Internet resource
73	locator is, the following general locator definition provides some contrast.
74
75	Definition: A general resource locator is an object
76	that describes the location of a resource.
77
78	This definition deliberately allows many degrees of freedom in order
79	to contain the furthest reaches of the wide-ranging debate on resource
80	location standards. Vast as it is, this problem space is a useful
81	backdrop for discussion of the requirements (later) that generate a
82	smaller, more manageable problem space. A resource location standard
83	shrinks the space again by applying additional requirements.
84
85	Consider the definition in four parts: (1) A general resource locator
86	is an object (2) that describes (3) the location of (4) a resource.
87
88	3.1.1. A general resource locator is an object...
89
90	The object could be a complex data structure. It could be a contiguous
91	sequence of bytes. It could be a pair of latitude-longitude coordinates,
92	or a three-color road map printed on paper. It could be a sequence of
93	characters that are capable of being printed on paper.
94
95	3.1.2. ...that describes
96
97	In the fully general case, there are many ways that a resource locator
98	could describe the location. It could employ a graphical or natural
99	language description. It could be heavily encoded or compressed. It
100	could be lightly encoded and readily understandable by human beings.
101	The description could be a multi-level hierarchy with common semantics
102	at each level. It could be a multi-level hierarchy with common semantics
103	at only the first two levels, where semantics below the second level
104	depend on the value given at the first level. These are just a few
105	possibilities.
106
107	3.1.3. ...the location of
108
109	A resource locator describes a location but never guarantees that access
110	may be established. While access is often desired when clients follow
111	location instructions given in a conformant resource locator, the resource
112	need not exist any longer or need not exist yet. Indeed it may never exist,
113	even though the locator continues to describe a location where a resource
114	might exist (e.g., it might be used as a placeholder with resource
115	availability contingent upon an event such as a payment).
116
117	Furthermore, the nature of certain potential resources, especially animate
118	beings or physical objects with no electronic instantiation, makes network
119	access meaningless in some cases; such resources have locators that would
120	imply non-networked access, but again, access is not guaranteed.
121
122	3.1.4. ...a resource.
123
124	A resource can be many things. Besides the non-networked or non-electronic
125	resources just mentioned, familiar examples are an electronic document,
126	an image, a server (e.g., FTP, Gopher, Telnet, HTTP), or a collection
127	of items (e.g., Gopher menu, FTP directory, HTML page). Other examples
128	accompany multi-function protocols such as Z39.50, which can perform
129	single round trip network access, session-oriented search refinement,
130	and index browsing.
131
132
133	3.2 Producers and Interpreters of Resource Locators
134
135	Central to the discussion of locator requirements is the issue of
136	parsability. This is the ability of an agent to recognize or understand
137	a locator in whole or in part. Discussion may be assisted by clearly
138	distinguishing the two main actions associated with locators.
139
140	Resource locators are both produced and interpreted. Producers are bound
141	by the resource location standards that are in turn bound by requirements
142	listed in this document. Interpreters of locators are not bound by the
143	requirements; they are beneficiaries of them.
144
145	3.2.1 Resource Locator Interpreters
146
147	A resource locator is interpreted by interpreting agents, which in this
148	document are simply called interpreters. Interpreters may be either
149	human beings or software. Along the way to establishing access based
150	on information in a locator, one or more interpreters may be employed.
151	Some examples of multiple interpreters processing a single locator
152	illustrate the concept that a resource locator may be understandable
153	only in part by each of several interpreters, but understandable in
154	its entirety by a combination of interpreters.
155
156	In the first example, a software interpreter recognizes enough of a
157	locator to understand to which external agent it needs to forward it.
158	Here, the external agent might be a user and the locator a library call
159	number; the software forwards the locator simply by displaying it. The
160	agent might be a network software layer specializing in a particular
161	communications protocol; once the service is recognized, the locator
162	is forwarded to it along with an access request.
163
164	In another example, a human interpreter might also recognize enough
165	of a locator to understand where to forward it. Here, the person might
166	be a user who recognizes a library call number as such but who does not
167	understand the location information encoded in it; the person forwards
168	it to a library employee (an external agent) who knows how to establish
169	access to the library resource.
170
171	A prerequisite to interpreting a locator is understanding when an object
172	in question actually is a locator, or contains one or more locators. Some
173	constrained environments make this question easy to answer, for example,
174	within HTML anchors or Gopher menu items. Less constrained environments,
175	such as within running text, make it more difficult to answer without
176	well-defined assumptions. A resource location standard needs to make any
177	such assumptions explicit.
178
179	3.2.2 Resource Locator Producers
180
181	Resource locators are produced in many ways, often by an agent that also
182	interprets them. The provider of a resource may produce a locator for it,
183	leaving the locator in places where it is intended to be discovered, such
184	as an HTML page, a Gopher menu, or an announcement to an e-mail list.
185
186	Non-providers of resources can be major producers of locators; for example,
187	WWW client software produces locators by translating foreign resource
188	locators (e.g., Gopher menu items) to its own format. Some locator
189	databases (e.g., Archie) have been maintained by automated processes that
190	produce locators for hundreds of thousands of FTP resources that they
191	"discover" on the Internet.
192
193	Users are major producers of resource locators. A user constructing one
194	to share with others is responsible for conformance with locator standards.
195	Sometimes a user composes a resource locator based on an educated guess
196	and submits it to client software with the intent of establishing access.
197	Such a user is a producer in a sense, but if the locator is purely for
198	personal consumption the user is not bound by the requirements. In fact,
199	some client software may offer as a service to translate abbreviated,
200	non-conformant locators entered by users into successful access
201	instructions or into conformant locators (e.g., by adding a domain name
202	to an unqualified hostname)
203
204
205	3.3 Uniqueness of Resource Locators
206
207	The topic of a "uniqueness" requirement for resource locators has been
208	discussed a great deal. This document recognizes several aspects of
209	uniqueness, but deliberately makes few requirements regarding them.
210	It is incumbent upon a resource location standard that takes on this
211	topic to be clear about which aspects it addresses. Some of them follow.
212
213	3.3.1. Uniqueness and Multiple Copies of a Resource
214	A uniqueness requirement might dictate that no identical copies of a
215	resource may exist. This document makes no such requirement.
216
217	3.3.2. Uniqueness and Deterministic Access
218	A uniqueness requirement might dictate that the same resource accessed
219	in one attempt will also be the result of any other successful attempt.
220	This document makes no such requirement, nor does it define "sameness".
221	It is inappropriate for a resource location standard to define "sameness"
222	among resources.
223
224	3.3.3. Uniqueness and Multiple Locators
225	A uniqueness requirement might dictate that a resource have no more than
226	one locator unless all such locators be the same. This document makes
227	no such requirement, nor does it define "sameness" among locators
228	(which a standard might do using, for example, canonicalization rules).
229
230	3.3.4. Uniqueness, Ambiguity, and Multiple Objects per Access
231	A uniqueness requirement might dictate that a resource locator identify
232	exactly one object as opposed to several objects. This document makes
233	no general definition of what constitutes one object, several objects,
234	or one object consisting of several objects.
235
236
237	4. Resource Access and Availability
238
239	A locator never guarantees access, but establishing access is by far the
240	most important intended application of a resource locator. While it is
241	considered ungracious to advertize a locator for a resource that will
242	never be accessible (whether a "networkable" resource or not), it is
243	normal for resource access to fail at a rate that increases with the
244	age of the locator used.
245
246	Resource access can fail for many reasons. Providers fundamentally affect
247	accessibility by moving, replacing, or deleting resources over time. The
248	frequency of such changes depends on the nature of the resource and provider
249	service practices, among other things. A locator that conforms to a
250	location standard but fails for one of these reasons is called "invalid"
251	for the purposes of this document; the term invalid locator does not apply
252	to malformed or non-conformant locators. Resource naming standards
253	address the problem of invalid locators.
254
255	Ordinary provider support policies may cause resources to be inaccessible
256	during predictable time periods (e.g., certain hours of the day, or days
257	of the year), or during periods of heavy system loading. Rights clearance
258	restrictions impossible to express in a locator also affect accessibility
259	for certain user populations. Heavy network load can also prevent access.
260	In such situations, this document calls a resource "unavailable".
261	A locator can both be valid and identify a resource that is unavailable.
262	Resource description standards address, among other things, some aspects
263	of resource availability.
264
265	In general, the probability with which a given resource locator leads
266	to successful access decreases over time, and depends on conditions such as
267	the nature of the resource, support policies of the provider, and loading
268	of the network.
269
270
271	5. Requirements List for Internet Resource Locators
272
273	This list of requirements is applied to the set of general locators
274	defined in section 3.1. The resulting subset, called Internet locators
275	in this document, is suitable for further refinement by an Internet
276	resource location standard. Some requirements concern locator encoding
277	while others concern locator function.
278
279	One requirement from the original draft list was dropped after extensive
280	discussion revealed it to be impractical to meet. It stated that with a
281	high degree of reliability, software can recognize Internet locators in
282	certain relatively unstructured environments, such as within running
283	ASCII text.
284
285	5.1 Locators are transient.
286
287	The probability with which a given Internet resource locator leads to
288	successful access decreases over time. More stable resource identifier
289	schemes are addressed in resource naming standards and are outside
290	the scope of a resource location standard.
291
292	5.2 Locators have global scope.
293
294	The name space of resource locators includes the entire world.
295	The probability of successful access using an Internet locator
296	depends in no way, modulo resource availability, on the geographical
297	or Internet location of the client.
298
299	5.3 Locators are parsable.
300
301	Internet locators can be broken down into complete constituent parts
302	sufficient for interpreters (software or human) to attempt access if
303	desired. While these requirements do not bind interpreters, three
304	points bear emphasizing:
305
306	5.3.1 A given kind of locator may still be parsable even if a given
307	interpreter cannot parse it.
308	5.3.2 Parsable by users does not imply readily parsable by untrained users.
309	5.3.3 A given locator need not be completely parsable by any one interpreter
310	as long as a combination of interpreters can parse it completely.
311
312	5.4 Locators can be readily distinguished from naming and descriptive
313	identifiers that may occupy the same name space.
314
315	During a transition period (of possibly indefinite length), other kinds
316	of resource identifier are expected to co-exist in data structures along
317	with Internet locators.
318
319	5.5 Locators are "transport-friendly".
320
321	Internet locators can be transmitted from user to user (e.g, via e-mail)
322	across Internet standard communications protocols without loss or
323	corruption of information.
324
325	5.6 Locators are human transcribable.
326
327	Users can copy Internet locators from one medium to another (such as
328	voice to paper, or paper to keyboard) without loss or corruption of
329	information. This process is not required to be comfortable.
330
331	5.7 An Internet locator consists of a service and an opaque parameter package.
332
333	The parameter package has meaning only to the service with which it is
334	paired, where a service is an abstract access method. An abstract access
335	method might be a software tool, an institution, or a network protocol.
336	The parameter package might be service-specific access instructions.
337	In order to protect creative development of new services, there is an
338	extensible class of services for which no parameter package semantics
339	common across services may be assumed.
340
341	5.8 The set of services is extensible.
342
343	New services can be added over time.
344
345	5.9 Locators contain no information about the resource other than that
346	required by the access mechanism.
347
348	The purpose of an Internet locator is only to describe the location of
349	a resource, not other properties such as its type, size, modification
350	date, etc. These and other properties belong in a resource description
351	standard.
352
353
354	6. Conclusion
355
356	Resource location standards, which define Internet resource locators,
357	give providers the means to describe access information for their
358	resources. They give client developers the ability to access disparate
359	resources while hiding access details from users.
360
361	Several minimum requirements distinguish an Internet locator from a general
362	locator. Internet resource locators are impermanent handles sufficiently
363	qualified for resource access not to depend in general on client location.
364	Locators can be recognized and parsed, and can be transmitted unscathed
365	through a variety of human and Internet communication mechanisms.
366
367	An Internet resource locator consists of a service and access parameters
368	meaningful to that service. The form of the locator does not discourage
369	the addition of new services or the migration to other resource identifiers.
370	A clean distinction between resource location, resource naming, and resource
371	description standards is preserved by limiting Internet locators to no more
372	information than what is required by an access mechanism.
373
374
375	7. Acknowledgements
376
377	The core requirements of this document arose from a collaboration of the
378	following people at the November 1993 IETF meeting in Houston, Texas.
379
380	Farhad Ankelesaria, University of Minnesota
381	John Curran, NEARNET
382	Peter Deutsch, Bunyip
383	Alan Emtage, Bunyip
384	Jim Fullton, CNIDR
385	Kevin Gamiel, CNIDR
386	Joan Gargano, University of California at Davis
387	John Kunze, University of California at Berkeley
388	Clifford Lynch, University of California
389	Lars-Gunnar Olson, Swedish University of Agriculture
390	Mark McCahill, University of Minnesota
391	Michael Mealing, Georgia Tech
392	Mitra, Pandora Systems
393	Pete Percival, Indiana University
394	Margaret St. Pierre, WAIS, Inc.
395	Rickard Schoultz, KTH
396	Janet Vratny, Apple Computer Library
397	Chris Weider, Merit Network
398