As per Relevance of the word resource, we have this rfc below:
Network Working Group C.
Request for Comments: 1728 Bunyip Information
Category: Informational December 1994
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
Although a number of systems have been created in the last
years to provide resource location and navigation on the Internet
the information contained in these systems must be maintained
updated by hand. This paper describes an automatic mechanism,
resource transponder, for maintaining resource location information
Author's Note
This document is being circulated as sort of a research paper
consequently there are no protocol specifications or anything of
sort. I hope that we can go from here and actually design them
there's consensus that they are potentially useful. Once we have
idea of the required functionality, we can then go out
standardize them
This paper represents only the opinions of the author; it does
represent the consensus of the IIIR Working Group, although it
recognized by them as one legitimate approach to a solution of
problem
1.
In the past few years, we've seen the invention and growth of
number of information location systems on the Internet, e.g., archie
Gopher, and WAIS. However, as these systems have become
deployed, a number of maintenance and security problems have
with them. Some of the major ones
1) Out of necessity, most of these systems contain pointers to
desired resources rather than the resources themselves. Therefore
if a resource becomes obsolete, is modified, or is moved,
Weider [Page 1]
RFC 1728 Resource Transponders December 1994
location system must be updated by hand. Some systems (archie
particular) proactively create updated indexes by contacting
resource on a certain time schedule (every 30 days or so) but
means that the system can be up to 30 days out of date, and
process can be highly inefficient depending on the percentage
information that has changed
2) Conversely, anyone who maintains a resource that they wish
must keep track of every directory which contains a pointer
that resource, so that if it is modified, all the directories
be updated. This obviously is an optimistic scenario
3) Many organizations which have installed these systems do not
the the available resources or expertise to maintain
information in the systems. Thus we have long periods where
information drifts, then a short period when the information
updated again
4) Even though these systems are almost always out of date today
this problem will become increasingly harder for humans to
by hand as everyone on the net becomes their own publisher. Also
as the net speeds up and people rely more and more on
information, human-induced delays in updates of these systems
become increasingly intolerable
5) Most, if not all, of these systems provide no security whatsoever
if a pointer to a resource appears in a locator system, then it
assumed to be meant for public consumption. There are
potential information providers who would like to use
deployed information systems to publish to a very
clientele, and do not wish to allow the whole net access to
resources
2. Requirements for a
There are several objectives which must be met by any
solution to these problems
1) We need to decrease the personnel resources needed for
and pointer maintenance
2) We need to increase the reliability and accuracy of
information held in resource location systems
3) We need to provide some mechanisms for security, particularly
mediating access to the resources
Weider [Page 2]
RFC 1728 Resource Transponders December 1994
4) We need to make it easy for non-experts, such as librarians
archivists, and database maintainers, to announce their
resources to the various resource location services
Many of these problems can be solved by a 'resource transponder
mechanism
3. Resource
The resource transponder system works by adding two new layers
every resource: metainformation and an agent to update a
location system (RLS) with that metainformation. The
layer is physically attached to every resource, so that when
resource is moved or altered, the metainformation is
available to update the RLS. The agent layer may also be attached
the resource or may not be; the implications of both of these
are discussed in detail below
3.1
The metainformation layer of a given resource contains
information which might be required to create a pointer to
resource, and any information which may be useful for indicating
to catalog or index the resource. For example, the
layer of a text document might contain such things as the
Resource Name (URN) of the document (this is sort of a ISBN
for electronic resources), the title of the document, a
Resource Locator (URL) for the document (this is a combination
address and access method indicator, used for retrieval), the size
the document, etc. Thus the metainformation layer contains data
the resource to which it is attached
This metainformation is expected to be modifiable. For example,
metainformation layer may contain a history of where this
copy of a resource has been. Let's say that a resource/
pair has been moved. When it gets to its new location, the agent
then attempt to contact the resource at its old location to
whether the resource is still there (in which case the agent
simply cause the new location to be added to the RLS) or whether
resource is not there (in which case the agent can tell the RLS
add the current pointer and delete the old one).
A number of other possibilities for the contents of
metainformation level are contained in section 4.1.
Weider [Page 3]
RFC 1728 Resource Transponders December 1994
3.2
The agent layer of a given resource contains an executable
which is responsible for reading the metainformation attached to
resource and using that information to update a RLS. It is
responsible for updating the metainformation where necessary and
running any indexing programs required by the RLS it is attempting
update
When the tools required to build agents are constructed and deployed
the author expects the agents to begin mediating access to
resource, particularly for agents attached to resources which are
currently considered active processes, such as text files
digitized images. In this futuristic model, someone wishing to
a given document would have to first negotiate access to the
with the agent; the agent would then be responsible for
the data to the client. However, it is expected that this type
agent will not be widely deployed for some time
Different ways of implementing agents are discussed in section 4.2.
4. Models for implementations of resource
4.1. Models for implementations of the metainformation
The metainformation layer can be impelemented in a number of ways
depending on the resource with which it is associated. For
'active' resource, such as an on-line catalog or a mail-
service, the metainformation can be stored in a file with a well
known name in the software distribution. Alternatively,
metainformation could be stored as a record in the data which
resource serves. For a text document, the metainformation could
stored as the first or last N bytes of the document (which
break a number of editors and file display techniques, but
guarantee that the metainformation is moved with the resource),
perhaps as a file with a logically associated name (paper2.
associated with paper2.txt, for example). The problem with
second approach is that the user must know that they have to move
metainformation with the file itself, or things will start breaking
If an agent is explicitly attached to the resource, the agent
contain the metainformation internally
In any case, the resource transponder system must be able
guarantee that the metainformation is moved when the resource
moved
Weider [Page 4]
RFC 1728 Resource Transponders December 1994
4.2 Models for implementations of the
The agent layer can also be implemented in a number of ways
depending on such things as system loads, desired sizes of resources
multitasking capabilities, etc
The easiest and for many unitasking systems the cleanest way
implementing an agent is to have one agent per computer. Then when
resource is moved onto that computer, the agent is
activated and notified where the new resource is. For example, let'
say that someone wishes to download a copy of a resource and then
the RLS know that that resource is available for public consumption
She would download the resource and then run the agent, which
then notify the RLS and update the metainformation attached to
resource. This model could also be used to track files on a LAN,
to provide local location services with no need to run a larger RLS
Another model for implementation of the agent is to have one
per resource. In this model, the agent would be moved along with
resource and the metainformation. The agent could be implemented in
file which would be associated with the resource; in that case
agent would have to be explicitly activated when the resource
moved. Alternatively, the agent/metainformation/resource system
be implemented as one system, or in one file. In this case, the
itself would always be active, and would be responsible for
access to the resource. When one did a 'telnet' to a resource
an active agent, the agent would accept the telnet connection and
responsible for providing security and translation for the data.
could provide great security for resources while still
pointers to them to be placed in public RLS's; the data in
resource could be encrypted, with the agent responsible
decrypting it
5. Security
Security issues are discussed throughout this memo
6. Author's
Chris
Bunyip Information Systems, Inc
2001 S. Huron Parkway, #12
Ann Arbor, MI 48104
Phone: +1 313-971-2223
Fax: +1 313-971-2223
EMail: clw@bunyip.
Weider [Page 5]
RFC 1728 Resource Transponders December 1994
Weider [Page 6]
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
