As per Relevance of the word services, we have this rfc below:
Network Working Group C.
Request for Comments: 1727 P.
Category: Informational Bunyip Information
December 1994
A Vision of an Integrated Internet Information
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
This paper lays out a vision of how Internet information
might be integrated over the next few years, and discusses in
detail what steps will be needed to achieve this integration
Thanks to the whole gang of information service wonks who
wrangled with us about the future of information services
countless bar bofs (in no particular order): Cliff Lynch,
Neuman, Alan Emtage, Jim Fullton, Joan Gargano, Mike Schwartz,
Kunze, Janet Vratny, Mark McCahill, Tim Berners-Lee, John Curran
Jill Foster, and many others. Extra special thanks to George Brett
CNIDR and Anders Gillner of RARE, who have given us the
to start tying together the networking community and the
community
1.
This paper represents only the opinions of its authors; it is not
official policy statement of the IIIR Working Group of the IETF,
does not represent an official consensus
2.
The current landscape in information tools is much the same as
landscape in communications networks in the early 1980's. In
early 80's, there were a number of proprietary networking
that connected large but autonomous regions of computers, and it
difficult to coalesce these regions into a unified network. Today,
have a number of large but autonomous regions of
information. We have a vast set of FTPable files, a budding
network, a budding GOPHER network, a budding World Wide Web network
Weider & Deutsch [Page 1]
RFC 1727 Resource Transponders December 1994
etc. Although there are a number of gateways between
protocols, and information service providers are starting to
GOPHER to provide a glue between various services, we are not yet
that golden age when all human information is at our fingertips. (
we're even farther from that platinum age when the computer
what we're looking for and retrieves it before we even touch
keyboard.)
In this paper, we'll propose one possible vision of the
services landscape of the near future, and lay out a plan to get
there from here
3. Axioms of information
There are a number of unspoken assumptions that we've used in
discussions. It might be useful to lay them out explicitly before
start our exploration
The first is that there is no unique information protocol that
provide the flexibility, scale, responsiveness, worldview, and mix
services that every information consumer wants. A protocol
to give quick and meaningful access to a collection of stock
might look functionally very different from one which will
digitized music for a particular musical phrase and deliver it
your workstation. So, rather than design the information protocol
end all information protocols, we will always need to integrate
search engines, new clients, and new delivery paradigms into
grand information service
The second is that distributed systems are a better solution
large-scale information systems than centralized systems. If
million people are publishing electronic papers to the net,
they all have to log on to a single machine to modify the
archives? What kind of bandwidth would be required to that
machine to serve a billion papers a day? If we replicate the
archives, what sort of maintenance problems would be encountered
These questions and a host of others make it seem more profitable
the moment to investigate distributed systems
The third is that users don't want to be bothered with the details
the underlying protocols used to provide a given service. Just
most people don't care whether their e-mail message gets split
into 20 packets and routed through Tokyo to get to its destination
information service users don't care whether the GOPHER server
telnet to get to a WAIS database back-ended by an SQL database.
just want the information. In short, they care very much about
they interact with the client; they just don't want to know what
on behind
Weider & Deutsch [Page 2]
RFC 1727 Resource Transponders December 1994
These axioms force us to look at solutions which are distributed
support multiple access paradigms, and allow information
resources to be handed off from one system (say Gopher) to
(say WWW).
4. An architecture to provide interoperability and integration
The basic architecture outlined in this paper splits up into 4
[Fig. 1].
At the lowest level, we have the resources themselves. These are
things as files, telnet sessions, online library catalogs, etc.
resource can have a resource transponder attached [Weider 94a],
should have a Uniform Resource Name (URN) [Weider 94b]
with it to uniquely identify its contents. If a resource
is attached, it will help maintain the information required by
next level up
At the next level, we have a 'directory service' that takes a URN
returns Uniform Resource Locators (URLs) [Berners-Lee 94] for
resource. The URL is a string which contains location information
and can be used by a client to access the resource pointed to by
URL. It is expected that a given resource may be replicated
times across the net, and thus the client would get a number of
for a given resource, and could choose between them based on
other criteria
Weider & Deutsch [Page 3]
RFC 1727 Resource Transponders December 1994
______________________________________________________________
| | | | |
| | | | |
| Gopher | WAIS | WWW | Archie | Others ...
| | | | |
|___________|______________|_______|_______________|___________
| |
| _________|____________
| | |
| | Resource Discovery |
| | System (perhaps |
| | based on whois++) |
| |______________________|
| |
| |
_____|________________________________|____
| |
| Uniform resource name to uniform resource |
| locator mapping system (perhaps based on |
| whois++ or X.500) |
|___________________________________________|
|
|
________________|______________________________________
| | | |
______|______ _______|_____ ______|______ ______|______
| | | | | | | |
| Transponder | | Transponder | | Transponder | | Transponder |
|_____________| |_____________| |_____________| |_____________|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| Resource | | Resource | | Resource | | Resource |
| | | | | | | |
| | | | | | | |
|_____________| |_____________| |_____________| |_____________|
Figure 1: Proposed architecture of an integrated
The third level of the architecture is a resource discovery system
This would be a large, distributed system which would accept
criteria and return URNs and associated information for
resource which matched the criteria. This would provide a set of
which the information service providers (GOPHER servers, etc.)
then select among for incorporation
Weider & Deutsch [Page 4]
RFC 1727 Resource Transponders December 1994
The fourth level of the architecture is comprised of the
information delivery tools. These tools are responsible
collating pointers to resources, informing the user about
resources to which they contain pointers, and retrieving
resources when the user wishes
Let's take a look in greater detail at each of these levels
4.1 Resource
The resources at this layer can be any collection of data a
wishes to catalog. It might be an individual text file, a
database, the starting point for a hypertext web, or anything else
Each resource is assigned a URN by the publisher, and the URL
derived from the current location of the resource. The transponder
responsible for updating levels 2 and 3 with the
information as the resource is published and moves around
4.2 URN -> URL
This level takes a URN and returns a number of URLs for the
instantiations of that resource on the net. It will also
the URN space. Thus the only functionality required of this level
the ability to maintain a global namespace and to provide
from that namespace to the URLs. Consequently, any of the
'directory service' protocols would allow us to provide that service
However, there may be some benefit to collapsing levels 2 and 3
the same software, in which case we may need to select the
protocol more carefully. For example, X.500 provides exactly
functionality required by level 2, but does not (yet) have
functionality required to provide the level 3 service. In addition
the service at level 2 does not necessarily have to be provided by
monolithic system. It can be provided by any collection of
which can jointly satisfy the requirements and also interoperate,
that level 2 does appear to level 3 to be universal in scope
4.3 Resource
This is the level which requires the most work, and where
greatest traps lurk to entangle the unwary. This level needs to
as a giant repository of all information about every publication
except for that which is required for the URI -> URL mapping.
this part is the least filled in at the moment, we will propose
mechanism which may or may not be the one which is eventually used
When a new resource is created on the network, it is assigned a
determined by the publisher of the resource. Section 4.1 discusses
more detail the role of the publisher on the net, but at the
Weider & Deutsch [Page 5]
RFC 1727 Resource Transponders December 1994
we can consider only 2 of the publisher's functions. The publisher
responsible for assigning a URN out of the publishers namespace,
is responsible for notifying a publishing agent [Deutsch 92] that
new resource has been created; that agent will either be a part
the resource location service or will then take the
for notifying an external resource location service that the
has been created. Alternatively, the agent can use the
location service to find parts of the RLS which should be
that this resource has been created
To give a concrete example, let's say that Peter and Chris publish
multi- media document titled, "Chris and Peter's Bogus Journey",
which talks about our recent trip to the Antarctic, complete
video clips. P & C would then ask their publishing agent to
a URN for this document. They then ask their publishing agent
attach a transponder to the document, and to look around and see
anyone a) has asked that our agent notify them whenever anything
write comes out; or b) is running any kind of server of 'trips
Antarctica'. Janet has posted a request that she be notified, so
agent tells her that a new resource has been created. The agent
finds 3 servers which archive video clips of Antarctica, so the
notifies all three that a new resource on Antarctica has come out
and gives out the URN and a URL for the local copy
4.4 Information delivery
One of the primary functions of an information delivery tool is
collect and collate pointers to resources. A given tool may
mechanisms to group those pointers based on other information
the resource, e.g. a full-text index allows one to group pointers
resources based on their contents; archie can group pointers based
filenames, etc. The URLs which are being standardized in the IETF
directly based on the way World Wide Web built pointers to resources
by creating a uniform way to specify access information and
for a resource on the net. With just the URLs, however, it
impossible without much more extensive checking to tell whether
resources with different URLs have the same intellectual content
not. Consequently, the URN is designed to solve this problem
In this architecture, the pointers that a given information
tool would keep to a resource will be a URN and one or more
URLs. When a pointer to a resource is first required (i.e. when a
resource is linked in a Gopher server), level 2 will provide a set
URLs for that URN, and the creator of the tool can then select
of those will be used. As it is expected that the URLs
eventually become stale (the resource moves, the machine goes down
etc.) the URN can be used to get a set of current URLs for
resource and an appropriate one can then be selected. Since the
Weider & Deutsch [Page 6]
RFC 1727 Resource Transponders December 1994
of using the level 2 service is probably greater than the cost
simply resolving a URL, both the URN and the URL are cached
provide speedy access unless something has moved
4.5 Using the architecture to provide interoperability between
In the simplest sense, each interaction that we have with
information delivery service does one of two things: it either
a pointer to be resolved (a file to be retrieved, a telnet session
be initiated, etc.) or causes some set of the pointers available
the information service to be selected. At this level,
architecture outlined above provides the core implementation
interoperability. Once we have a means of mapping between names
pointers, and we have a standard method of specifying names
pointers, the interoperation problem becomes one of simply
names and pointers around between systems. Obviously with such
simplistic interoperability scheme much of the flavor
functionality of the various systems are lost in transition. But
given the pointers, a system can either a) present them to the
with no additional functionality or b) resolve the pointers,
the resources, and then run algorithms designed to tie
resources together into a structure appropriate for the
service. Let's look at one example (which just happens to be
easiest to resolve); interoperation between World Wide Web
Gopher
Displaying a Gopher screen as a WWW document is trivial with
pointers. Every Gopher screen is simply a list of menu items
pointers behind them (we'll ignore the other functionality
provides for a moment), so is an extremely simple form of a
document. Consequently with this architecture it is easy to show
resolve a Gopher screen in WWW. For a WWW to Gopher map,
simplest method would be that when one accesses a WWW document,
the pointers associated with links off to other documents are
in with the document. Gopher could then resolve the links and
the first line of each document to provide a Gopher style
which contains everything in the WWW document. When a link
selected, all of the WWW links for the new document are brought
and the process repeats. Obviously we're losing a lot with the WWW ->
Gopher mapping; some might argue that we are losing everything
However, this does provide a trivial interoperability capacity,
one can argue that the 'information content' has been
across the gateway
In addition, the whole purpose of gatewaying is to provide access
resources that lie outside the reach of your current client.
all resources are identifiable and accessible through layers 2 and 3,
it will be easy to copy resources from one protocol to another
Weider & Deutsch [Page 7]
RFC 1727 Resource Transponders December 1994
all we need to do is to move the pointers and reexpress
relationships between the pointers in the new paradigm
4.6 Other techniques for
One technique for interoperability which has recently received
serious attention is the technique of creating one client
speaks the protocols of all the information delivery tools.
approach has been taken in particular by the UNITE (User's
Interface To Everything) group in Europe. This client would sit
the top level of the architecture in Figure 1. This technique is
exemplified by the recent work which has gone into Mosaic, a
which can speak almost all of the major information
protocols. This technique has a lot of appeal and has enjoyed quite
bit of success; however, there are several practical
with this approach which may hinder its successful implementation
The first difficulty is one that is common to clients in general;
clients must be constantly updated to reflect changes in
underlying protocols and to accommodate new protocols. If
increase in the number of information services is very gradual, or
the underlying protocols do not change very rapidly, this may not
an insuperable difficulty. In addition, old clients must have
way of notifying their user that they are no longer current
otherwise they will no longer be able to access parts of
information mesh
The second problem is one which may prove more difficult. Each of
currently deployed information services provides information in
fundamentally different way. In addition, new information
are likely to use completely new paradigms for the organization
display of the information they provide. The various clients of
information services provide vastly different functionality from
other because the underlying protocols allow different techniques.
may very well prove impossible to create a single client which
access to the full functionality of each of the underlying
while presenting a consistent user interface to the user
Much of the success of Mosaic and other UNITE tools is due to
fact that Gopher, WWW, and other tools are still primarily
based. When new tools are deployed which depend more on visual
than textual cues, it may be substantially more difficult
integrate all these services into a single client
We will continue to follow this work and may include it in
revisions of this architecture if it bears fruit
Weider & Deutsch [Page 8]
RFC 1727 Resource Transponders December 1994
5. Human interactions with the
In this section we will look at how humans might interact with
information system based on the above architecture
5.1 Publishing in this
When we speak of publishing in this section, we are referring only
the limited process of creating a resource on the net, assigning it
URN, and spreading the information around that we have created a
resource
We start with the creation of a resource. Simple enough; a
thought, a couple of hours typing, and a few cups of coffee and
have a new resource. We then wish to assign it a URN. We can talk
whichever publishing agent we would like; whether it is our
personal publishing agent or some big organization that provides
and announcement services to a large number of authors. Once we
a URN, we can provide the publishing agent with a URL for our
copy of the resource and then let it do its thing. Alternatively,
can attach a transponder to the resource, let it determine a
URL for the resource, and let it contact the publishing agent and
up the announcement process. One would expect a publishing agent
prompt us for some information as to where it should announce our
resource
For example, we may just wish a local announcement, so that
people in our company can get a pointer to the resource. Or we
wish some sort of global announcement (but it will probably cost us
bit of money!)
Once the announcement has been made, the publishing agent will
contacted by a number of pieces of the resource location system.
example, someone running a WAIS server may decide to add the
to their index. So they can retrieve the resource, index it, and
the indexes to their tables along with a URI - URL combination.
when someone uses that WAIS server, it can go off and retrieve
resource if necessary. Or, the WAIS server could create a local
of the resource; if it wished other people to find their local
of the resource, it could provide the URI -> URL mapper with a
for the local copy. In any case, publication becomes a simple matter
So, where does this leave the traditional publisher? Well, there
a number of other functions which the traditional publisher
in addition to distribution. There are editorial services, layout
design, copyright negotiations, marketing, etc. The only part of
traditional role that this system changes is that of distributing
resource; this architecture may make it much cheaper for
Weider & Deutsch [Page 9]
RFC 1727 Resource Transponders December 1994
to distribute their wares to a much wider audience
Although copying of resources would be possible just as it is
paper format, it might be easier to detect republication of
resource in this system, and if most people use the original URN
the resource, there may be a reduced monetary risk to the publisher
5.2 A librarian role in this
We've been in a number of discussions with librarians over the
year, and one question that we're frequently asked is "Does
talk this rapidly all the time?". The answer to that question
"Yes". But another question we are frequently asked is "If all
electronic resources are going to be created, supplanting books
journals, what's left for the librarians?". The answer to that
slightly more complex, but just as straightforward. Librarians
excelled at obtaining resources, classifying them so that users
find them, weeding out resources that don't serve their communities
and helping users navigate the library itself. None of these
are supplanted by this architecture. The only differences are
instead of scanning publisher's announcements for new resources
users might be interested in, they will have to scan
announcements on the net. Once they see something interesting,
can retrieve it (perhaps buying a copy just as they do now),
it, set up a navigation system for their classification scheme,
users how to use it, and provide pointers (or actual copies) of
resource to their users. The classification and selection
in particular are services which will be badly needed on a net with
million new 'publications' a day, and many will be willing to pay
this highly value added service
5.3 Serving the
This architecture allows users to see the vast collection
networked resources in ways both familiar and unfamiliar. Bookstores
record shops, and libraries can all be constructed on top of
architecture, with a number of different access methods.
shops and research libraries can be easily built, and then
to a thousand different users. One never need worry that a book
been checked out, that a CD is out of stock, that a copy of
in the original Greek isn't available locally. In fact, a user
even engage a proxy server to translate resources into forms that
machine can use, for example to get a text version of a
document although her local machine has no Postscript viewer, or
obtain a translation of a sociology paper written in Chinese
In any case, however the system looks in three, five, or fifty years
we believe that the vision we've laid out above has the
Weider & Deutsch [Page 10]
RFC 1727 Resource Transponders December 1994
and functionality to start tying everything together without
everyone to use the same access methods or to look at the net
same way. It allows new views to evolve, new resources to be
out of old, and for people to move from today to tomorrow with
the comforts of home but all the excitement of exploring a new world
6.
[Berners-Lee 93] Berners-Lee, T., Masinter, L., and M. McCahill
Editors, "Universal Resource Locators", RFC 1738, CERN, The
Corporation, University of Minnesota, December 1994.
Deutsch, P., Master's Thesis, June 1992.
Available for anonymous FTP
.
[Weider 94a] Weider, C., "Resource Transponders", RFC 1728,
Information Systems, December 1994.
[Weider 94b] Weider, C. and P. Deutsch, "Uniform Resource Names",
Work in Progress
Security
Security issues are not discussed in this memo
7. Authors'
Chris
Bunyip Information Systems, Inc
2001 S. Huron Parkway #12
Ann Arbor, MI 48104
Phone: +1 313-971-2223
EMail: clw@bunyip.
Peter
Bunyip Information Systems, Inc
310 Ste. Catherine St. West, Suite 202
Montreal, Quebec,
Phone: +1 514-875-8611
EMail: peterd@bunyip.
Weider & Deutsch [Page 11]
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
