RFC 1727 (rfc1727) - Page 2 of 11

A Vision of an Integrated Internet Information Service

RFC 1727                 Resource Transponders             December 1994


   etc.  Although there are a number of gateways between various
   protocols, and information service providers are starting to use
   GOPHER to provide a glue between various services, we are not yet in
   that golden age when all human information is at our fingertips. (And
   we're even farther from that platinum age when the computer knows
   what we're looking for and retrieves it before we even touch the
   keyboard.)

   In this paper, we'll propose one possible vision of the information
   services landscape of the near future, and lay out a plan to get us
   there from here.

3. Axioms of information services

   There are a number of unspoken assumptions that we've used in our
   discussions.  It might be useful to lay them out explicitly before we
   start our exploration.

   The first is that there is no unique information protocol that will
   provide the flexibility, scale, responsiveness, worldview, and mix of
   services that every information consumer wants.  A protocol designed
   to give quick and meaningful access to a collection of stock prices
   might look functionally very different from one which will search
   digitized music for a particular musical phrase and deliver it to
   your workstation. So, rather than design the information protocol to
   end all information protocols, we will always need to integrate new
   search engines, new clients, and new delivery paradigms into our
   grand information service.

   The second is that distributed systems are a better solution to
   large-scale information systems than centralized systems.  If one
   million people are publishing electronic papers to the net, should
   they all have to log on to a single machine to modify the central
   archives? What kind of bandwidth would be required to that central
   machine to serve a billion papers a day?  If we replicate the central
   archives, what sort of maintenance problems would be encountered?
   These questions and a host of others make it seem more profitable at
   the moment to investigate distributed systems.

   The third is that users don't want to be bothered with the details of
   the underlying protocols used to provide a given service. Just as
   most people don't care whether their e-mail message gets split up
   into 20 packets and routed through Tokyo to get to its destination,
   information service users don't care whether the GOPHER server used
   telnet to get to a WAIS database back-ended by an SQL database.  They
   just want the information. In short, they care very much about how
   they interact with the client; they just don't want to know what goes
   on behind.



Weider & Deutsch