As per Relevance of the word resource, we have this rfc below:
Network Working Group K.
Request for Comments: 1737 MIT/
Category: Informational L.
Xerox
December 1994
Functional Requirements for Uniform Resource
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
1.
This document specifies a minimum set of requirements for a kind
Internet resource identifier known as Uniform Resource Names (URNs).
URNs fit within a larger Internet information architecture, which
turn is composed of, additionally, Uniform Resource
(URCs), and Uniform Resource Locators (URLs). URNs are used
identification, URCs for including meta-information, and URLs
locating or finding resources. It is provided as a basis
evaluating standards for URNs. The discussions of this work
occurred on the mailing list uri@bunyip.com and at the URI
Group sessions of the IETF
The requirements described here are not necessarily exhaustive;
example, there are several issues dealing with support
replication of resources and with security that have been discussed
however, the problems are not well enough understood at this time
include specific requirements in those areas here
Within the general area of distributed object systems design,
are many concepts and designs that are discussed under the
topic of "naming". The URN requirements here are for a facility
addresses a different (and, in general, more stringent) set of
than are frequently the domain of general object naming
The requirements for Uniform Resource Names fit within the
architecture of Uniform Resource Identification. In order to
applications in the most general case, the user must be able
discover and identify the information, objects, or what we will
in this architecture resources, on which the application is
operate. Beyond this statement, the URI architecture does not
"resource." As the network and interconnectivity grow, the
to make use of remote, perhaps independently managed, resources
Sollins & Masinter [Page 1]
RFC 1737 Requirements for Uniform Resource Names December 1994
become more and more important. This activity of discovering
utilizing resources can be broken down into those activities
one of the primary constraints is human utility and facility
those in which human involvement is small or nonexistent.
naming must have such characteristics as being both mnemonic
short. Humans, in contrast with computers, are good at
disambiguation and wide variability in structure. In order
computer and network based systems to support global naming
access to resources that have perhaps an indeterminate lifetime,
flexibility and attendant unreliability of human-friendly
should be translated into a naming infrastructure more
for the underlying support system. It is this underlying
system that the Internet Information Infrastructure
(IIIA) is addressing
Within the IIIA, several sorts of information about resources
specified and divided among different sorts of structures,
functional lines. In order to access information, one must be
to discover or identify the particular information desired
determined both how and where it might be used or accessed.
partitioning of the functionality in this architecture is
uniform resource names (URN), uniform resource characteristics (URC),
and uniform resource locators (URL). A URN identifies a resource
unit of information. It may identify, for example,
content, a particular presentation of intellectual content,
whatever a name assignment authority determines is a
namable entity. A URL identifies the location or a container for
instance of a resource identified by a URN. The resource
by a URN may reside in one or more locations at any given time,
move, or may not be available at all. Of course, not all
will move during their lifetimes, and not all resources,
identifiable and identified by a URN will be instantiated at
given time. As such a URL is identifying a place where a
may reside, or a container, as distinct from the resource
identified by the URN. A URC is a set of meta-level
about a resource. Some examples of such meta-information are: owner
encoding, access restrictions (perhaps for particular instances),
cost
With this in mind, we can make the following statement
o The purpose or function of a URN is to provide a globally unique
persistent identifier used for recognition, for access
characteristics of the resource or for access to the
itself
Sollins & Masinter [Page 2]
RFC 1737 Requirements for Uniform Resource Names December 1994
More specifically, there are two kinds of requirements on URNs
requirements on the functional capabilities of URNs, and
on the way URNs are encoded in data streams and
communications
2. Requirements for functional
These are the requirements for URNs' functional capabilities
o Global scope: A URN is a name with global scope which does
imply a location. It has the same meaning everywhere
o Global uniqueness: The same URN will never be assigned to
different resources
o Persistence: It is intended that the lifetime of a URN
permanent. That is, the URN will be globally unique forever,
may well be used as a reference to a resource well beyond
lifetime of the resource it identifies or of any naming
involved in the assignment of its name
o Scalability: URNs can be assigned to any resource that
conceivably be available on the network, for hundreds of years
o Legacy support: The scheme must permit the support of
legacy naming systems, insofar as they satisfy the
requirements described here. For example, ISBN numbers,
public identifiers, and UPC product codes seem to satisfy
functional requirements, and allow an embedding that
the syntactic requirements described here
o Extensibility: Any scheme for URNs must permit future extensions
the scheme
o Independence: It is solely the responsibility of a name
authority to determine the conditions under which it will issue
name
o Resolution: A URN will not impede resolution (translation into
URL, q.v.). To be more specific, for URNs that have
URLs, there must be some feasible mechanism to translate a URN to
URL
3. Requirements for URN
In addition to requirements on the functional elements of the URNs
there are requirements for how they are encoded in a string
Sollins & Masinter [Page 3]
RFC 1737 Requirements for Uniform Resource Names December 1994
o Single encoding: The encoding for presentation for people in
text, electronic mail and the like is the same as the encoding
other transmissions
o Simple comparison: A comparison algorithm for URNs is simple
local, and deterministic. That is, there is a single algorithm
comparing two URNs that does not require contacting any
server, is well specified and simple
o Human transcribability: For URNs to be easily transcribable
humans without error, they should be short, use a minimum
special characters, and be case insensitive. (There is no
requirement that it be easy for a human to generate or interpret
URN; explicit human-accessible semantics of the names is not
requirement.) For this reason, URN comparison is insensitive
case, and probably white space and some punctuation marks
o Transport friendliness: A URN can be transported unmodified in
common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc.,
well as printed paper
o Machine consumption: A URN can be parsed by a computer
o Text recognition: The encoding of a URN should enhance
ability to find and parse URNs in free text
4.
For a URN specification to be acceptible, it must meet the
requirements. We draw a set of conclusions, listed below, from
requirements; a specification that satisfies the requirments
meetings these conclusions is deemed acceptable, although unlikely
occur
o To satisfy the requirements of uniqueness and scalability,
assignment is delegated to naming authorities, who may then
names directly or delegate that authority to sub-authorities
Uniqueness is guaranteed by requiring each naming authority
guarantee uniqueness. The names of the naming
themselves are persistent and globally unique and top
authorities will be centrally registered
o Naming authorities that support scalable naming are encouraged,
not required. Scalability implies that a scheme for devising
may be scalable both at its terminators as well as within
structure; e.g., in a hierarchical naming scheme, a
authority might have an extensible mechanism for adding
sub-registries
Sollins & Masinter [Page 4]
RFC 1737 Requirements for Uniform Resource Names December 1994
o It is strongly recommended that there be a mapping between
names generated by each naming authority and URLs. At any
time there will be zero or more URLs into which a particular
can be mapped. The naming authority itself need not provide
mapping from URN to URL
o For URNs to be transcribable and transported in mail, it
necessary to limit the character set usable in URNs, although
is not yet consensus on what the limit might be
In assigning names, a name assignment authority must abide by
preceding constraints, as well as defining its own criteria
determining the necessity or indication of a new name assignment
5. Other
There are three issues about which this document has
not taken a position, because it is believed that these are issues
be decided by local determination or other services within
information infrastructure. These issues are equality of resources
reflection of visible semantics in a URN, and name resolution
One of the ways in which naming authorities, the assigners of names
may choose to make themselves distinctive is by the algorithms
which they distinguish or do not distinguish resources from
other. For example, a publisher may choose to distinguish
multiple printings of a book, in which minor spelling
typographical mistakes have been made, but a library may prefer
to make that distinction. Furthermore, no one algorithm for
for equality is likely to applicable to all sorts of information
For example, an algorithm based on testing the equality of two
is unlikely to be useful when testing the equality of
spreadsheets. Thus, although this document requires that
particular naming authority use one algorithm for determining
two resources it is comparing are the same or different, each
authority can use a different such algorithm and a naming
may restrict the set of resources it chooses to identify in any
at all
A naming authority will also have some algorithm for
choosing a name within its namespace. It may have an algorithm
actually embeds in some way some knowledge about the resource.
turn, that embedding may or may not be made public, and may or
not be visible to potential clients. For example, an
URN, simply provides monotonically increasing serial numbers
resources. This conveys nothing other than the identity
by the equality testing algorithm and an ordering of name
by this server. It carries no information about the resource itself
Sollins & Masinter [Page 5]
RFC 1737 Requirements for Uniform Resource Names December 1994
An MD5 of the resource at some point, in and of itself may
reflective of its contents, and, in fact, the naming authority may
perfectly willing to publish the fact that it is using MD5, but
the resource is mutable, it still will be the case that any
client cannot do much with the URN other than check for equality
If, in contrast, a URN scheme has much in common with the
ISBN numbers, the algorithm for assigning them is public and
knowing it, given a particular ISBN number, one can learn
more about the resource in question. This full range
possibilities is allowed according to this requirements document
although it is intended that naming authorities be discouraged
making accessible to clients semantic information about the resource
on the assumption that that may change with time and therefore it
unwise to encourage people in any way to depend on that
being valid
Last, this document intentionally does not address the problem
name resolution, other than to recommend that for each
authority a name translation mechanism exist. Naming
assign names, while resolvers or location services of some
assist or provide URN to URL mapping. There may be one or many
services for the resources named by a particular naming authority
It may also be the case that there are generic ones providing
for many resources of differing naming authorities. Some may
authoritative and others not. Some may be highly reliable or
available or highly responsive to updates or highly focussed by
criteria such as subject matter. Of course, it is also possible
some naming authorities will also act as resolvers for the
they have named. This document supports and encourages third
and distributed services in this area, and therefore
makes no statements about requirements of URNs or naming
on resolvers
Security
Applications that require translation from names to locations,
the resources themselves may require the resources to
authenticated. It seems generally that the information about
authentication of either the name or the resource to which it
should be carried by separate information passed along with the
rather than in the URN itself
Sollins & Masinter [Page 6]
RFC 1737 Requirements for Uniform Resource Names December 1994
Authors'
Larry
Xerox Palo Alto Research
3333 Coyote Hill
Palo Alto, CA 94304
Phone: (415) 812-4365
Fax: (415) 812-4333
EMail: masinter@parc.xerox.
Karen
MIT Laboratory for Computer
545 Technology
Cambridge, MA 02139
Voice: (617) 253-6006
Phone: (617) 253-2673
EMail: sollins@lcs.mit.
Sollins & Masinter [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
