Some thoughts on system design to facilitate resource sharing
RFC 592

Document Type RFC - Unknown (November 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 592 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          R. Watson
Request for Comments: 592                                            SRI
NIC 20391                                                  November 1973

     Some Thoughts on System Design to Facilitate Resource Sharing

INTRODUCTION

   There is a growing interest in moving toward more resource sharing on
   the ARPANET.  Some resource sharing has been taking place by having
   systems open TELNET connections and generating user command strings.
   I think that this is fine for experimental use, but is not the way we
   want to operate in real usage.  What I believe network system
   builders should do is to develop mechanisms appropriately designed
   for computer-computer communication.

SYSTEM INTERCONNECTION, AN APPROACH

   The goal I would like to see us move toward is to view all systems on
   the network as offering certain service modules, any subset of which
   can be combined in building other systems.  Each service module would
   have a well advertised set of primitive service capabilities that it
   could provide.  It would have documented commands at the level of
   present Telnet or FTP commands for gaining access to its services.
   It would also have a defined network connection procedure.  Then any
   system builder wanting to avail himself of these services could do so
   and integrate them into his own user interface environment.

   At the present time when a system is built, the system builders tend
   to see it as a stand alone thing or at most something to be used
   within a specific environment.  What I would like to see fostered is
   the idea that any system built is not only a stand alone environment
   but also a network service or set of services.  The builders would
   define not only a user interface for their environment, but also a
   set of primitives and primitive commands that can be accessed by
   other systems around the network to get that service performed.

      For example, we are redesigning the NLS Journal in light of our
      experience and that of Network Mail as a set of protocols and
      services.  If one looks at the processes of the NLS Journal one
      can see a number of separate services that could be provided by
      different network sites or combined in varying combinations by a
      single site.  These being:

         Distribution (identification of addressees and maintainance of
         the required data bases being a related service), recording
         (numbering and storing of items), cataloging, and retrieval.

Watson                                                          [Page 1]
RFC 592            System Design for Resource Sharing      November 1973

   At the moment these services are fairly tightly interconnected in the
   NLS Journal and what we want to do is to decouple them and define
   their intercommunication by protocols that would allow them to be
   distributed in different hosts on the network.  Mechanisms would also
   be defined for the several hosts performing similar services around
   the network to work together cooperatively.

   As a further example, there are also other services that NLS could
   probably provide such as structured file creation and manipulation;
   information portrayal online or in hardcopy; database querying etc.
   However, at the moment the system is not explicitly structured from
   the point of view that outside systems could come into it anywhere
   but at the human user interface even though internally it is quite
   modular.  It would be straightforward for us to identify those NLS
   services that other system builders might possibly be interested in
   incorporating into their systems with their own user interface and
   then to do the restructuring and primitive command definition
   necessary.  Other groups building systems on the network could
   perform a similar examination.

   CCA, on the other hand as I understand it, has taken this point of
   view from the beginning, namely building the Datacomputer on the
   assumption that it is primarily a network resource and is to be used
   by other systems.  BBN is also moving in this direction in the design
   of Distributed TENEX.

   There is nothing new in the above ideas; they come from generalizing
   past successes we have all had with network protocol development and
   with good software engineering practices.  It will, however, take a
   change in the thinking of system designers, some concrete examples,
   and ongoing dialog to make such a design philosophy the normal
   network way of life.

SOME FUNCTIONS READY FOR INTERCONNECTION

   The area of dialog support may be the first area ripe to create such
   a synthesis with the several systems in or coming into existence,
   each solves part of the problem (with some overlap).  The dialog
   support systems on the network known to me are:

      The NLS Journal (supports recorded and cataloged dialog and linked
Show full document text