Data Management System Proposal for the ARPA Network
RFC 304

Document Type RFC - Unknown (February 1972; 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 304 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        D. B. McKay
Request for Comments: 304                                            IBM
NIC: 9077                                              February 17, 1972
Categories: D3, D4, D7
Obsoletes: none
Updates:   none

                   A Data Management System Proposal
                          for the ARPA Network


   This proposal is being written to facilitate discussions on a design
   for a network Data Management System.  It is not intended to be a
   complete and exhaustive design for the ultimate protocol allowing
   users to share data easily, but a frame work that will allow us to
   recognize and develop the necessary tools in a unified manner
   enabling the network to manage its resources to the best advantage to
   the user.

   The fundamental intent here is not to try and solve an impossible
   problem, but to bring a necessary service capability to the user that
   will enable him to carry out applications that hitherto he has not
   been able to do.  The intent is to be consistent with every other
   major function that has been developed in the network, i.e., NCP -
   2nd level protocol, Telnet, and the Form Machine.  The Data
   Management Service or Data Control Facility (DCF) will do the same
   thing only on a high level of application building on those tools
   that have already been developed in the network.

   Data that is referred to and transmitted in this System will be
   considered a special class of data that is called network data.  That
   is, it is named and characterized through a network datalanguage and
   all pertinent information as to where it can be located and what its
   structure is kept in a network catalog.  Access to the data for its
   actual transmission will be done through NCP socket addressable
   routines in a manner similar to the way in which the SMFS at Santa
   Barbara works.  It is feasible that the SMFS will become an active
   resource utilized by the DCF.

System Overview

   There are six functionally and logically distinct areas that are
   identifiable in the Network Data Service (Figure 1), with
   subfunctions that can be categorized and discussed.

McKay                                                           [Page 1]
RFC 304        A Data Management System Proposal for ARPA  February 1972

      1. The user interface to the DCF.  In an interactive environment
         such as the ARPA network, this interface would be serviced by
         Telnet supporting the local user at his terminal directing the
         request to the DCF.  The DCF in this case would be a
         specialized server task.
      2. The DCF or that functional unit responsible for coordinating
         all the activity of the Network Data Service.  It also houses
         the interfaces to all other functions.
      3. The Network Catalog or Directory which contains all information
         about network data.
      4. The Data Reconfiguration Service or Form Machine that would be
         called on when data translation or reconfiguration is needed.
         This would be invoked automatically, when possible, by the DCF
         and would remove this responsibility from the user.  For more
         specialize translation, however, the user will still be able to
         write programs for, and execute them on, the Form Machine.
      5. The remote DCF or DCF' would contain enough function to
         recognize the request being made of it by the DCF It would be a
         server task to the DCF.
      6. File xfer protocol would be a function that the DCF and the
         DCF' would initiate as the means to control data transfer in
         the network.

   A more detailed discussion of each of these areas appears in the
   following sections.

User Interface

   It was stated in RFC146 that the DCF should handle all network
   resources as a single resource and utilize it as best it can.  This
   statement was also meant to incorporate the Data Computer and Unicon
   storage as part of this resource.  The extent to which this can be
   done is an open question but the use of the Data Language developed
   by CCA would provide a consistent interface to the user utilizing
   these network services and possibly facilitate the use of the Data
   Compiler by the DCF.

   It should be pointed out at this time that the DCF is a logical
   function that can reside anywhere including on the Data Computer.

   The user should be allowed to enter all command and updates
   interactively to the DCF.  The DCF will be a serving user process
   that will interface to the Telnet Server routine.  The actual data of
   the terminal transmissions will be the commands and data the user
   will be transmitting to the DCF.  By adopting the Telnet protocol as
   the initial user interface, the DCF can be accessed by all the users
   with Telnet.

McKay                                                           [Page 2]
Show full document text