RFC 316

ARPA Network Data Management Working Group

πŸ“… published February 1972, from ietf

ARPA Network Data Management Working Group ✨

πŸŽ€ RFC 316 is by D. B. McKay and A. P. Mulleray, both from IBM, with NIC number 9346. It's dated February 23 & 24, 1972. The header doesn't list a category or status, and it doesn't list anything this RFC obsoletes or updates. 🧚

Okay so this meeting had two phases πŸ¦‹. Phase one was all about presentations on how networks are being used and the development work going on to let data get shared across a computer network. Phase two was a working meeting where people figured out what the data management working group should actually do πŸ’….

Phase I

JOHN SENIOR, Univ. of Penn. and National Board of Medical Examiners, Phila., PA., described using a network to get access to models that simulate medical behavior of patients 🩺. These models are mostly used for teaching and testing physicians. The network gives an interface so all kinds of terminals can connect and access them. Other data bases might be worth reaching over a network too, but there's a "polyglot" of organizations, so it's currently impossible to use foreign data bases πŸ’€.

HECTOR MAYNEZ, National Library of Medicine, described the MEDLINE system πŸ“š. It has 1000 journals on-line that you can access through a network. Just like the one above, this network gives various terminals an interface for access. In this network there are four or five computers running other applications, like CAI, clinical diagnosis, etc. 🌸

RAY BEVERIDGE, MITRE, presented the requirements for the WWMCCS (World Wide Military Command and Control System) Network 🫑. This network will have 25 nodes and a data exchange rate on the order of 10,000,000 characters per day. Three types of data were formulated: query data with a response on the order of seconds, daily exchange for updates and reports, and other data for weekly, monthly or as required reports. It's giving organized πŸ’œ.

ERICA PEREZ, MITRE, discussed data management for the WWMCCS Network πŸ”₯. There are two problems: figuring out where the desired data lives, and providing the proper security and reliability for vital data. The location of data bases will be indicated in directories, which may automatically determine which segment is applicable to a query. The directory will contain lists of data bases, files, users and programs.

The directory can be:

  • centralized: all at one location
  • distributed: split into pieces, where each piece resides at one location
  • partially replicated: split into pieces, but certain parts may be replicated at different locations
  • completely replicated: the complete directory at all locations

The data management system will have to deal with possibly different hardware systems and even different local data management systems 🌈. One solution is to have a standard data management and data description language for sending requests and data around the network. The system will also have to provide capabilities for file transfer, queries, remote batch, and user communication via a mail box πŸ“¬. Data security is maintained by checking user id, terminal authorization, process authorization and data authorization πŸ”.

BOB BROWN, General Motors Research Lab., described the network of computers at the General Motors Research Center πŸš—. Right now it consists of an IBM 360/67, a 360/65, a 370/165, three 1800's and a Sigma 5. All of these are primarily for graphics use, except the 67 and the 165. He gave an example of how data moves through the network: the styling department develops a design on an 1800, the data goes to the 67 for stress and shape analysis, and the results come back to the 1800 ✨. Once a design is developed, it's sent to the 65-1800 combination for detailed analysis for production. Many of the computers run GM's own operating systems, and the network control is made up of macros added to those operating systems. Interfacing is done by providing specific conversion modules to be called when a specific conversion is required. The 67 will eventually be replaced by a hierarchical multiprocessor based on the CDC Star-100 πŸ¦‹.

PHIL MESSING, MITRE, is setting up an experiment to test how practical it is to interface a network standard data management language with local data management systems πŸ§ͺ. In this experiment, a user makes a request in the network language, the request is transmitted to a node, and it's translated into the language of that local node. Three local systems have been selected: MADAM at MIT, LISTAR and Lincoln Labs., and NASIS at NASA/Ames πŸŽ€.

It is not expected that the common data language will be able to handle all possible requests. It should be able to handle the most common requests. Otherwise, some means of interaction may be set up to allow transmission of more information to the target system than the common language may allow. Or, finally, a user can utilize the local target language πŸ€·β€β™€οΈ.

At a later stage of the experiment, a user will input a query. The local host will determine where the query is to be sent, the transmission takes place, it's accepted by the target node, translated into the target node's local language, and processed πŸš€.

ERNIE FORMAN, MITRE, is developing a special, simple data management system just for measuring and testing organizational techniques for control, directories and files 🧠. The question to answer is whether each of these three functions should be centralized or distributed, how, and where. The initial experimental arrangement has the control and directory centralized at the Rand node, with the files distributed at UCSB, Rand and BBN. The files are each split vertically and distributed, and this organization was chosen to present the more difficult case πŸ’–.

DICK WATSON, SRI, described some extensions of NIC (Network Information Center) that he'd like to see, which would involve network data management facilities 🌟. The first would be the ability to process text from one text processor by another. Second, it would eventually be desirable to distribute the NIC journals. A first stage of this would be to have several NLS (Network Library System) systems around the network, each with its own journal. The problems with this first stage would be coordinating numbering and organizing the directory πŸ™ˆ. A second stage would be one where the journal might reside, in part, on systems other than NLS.

A third extension is to enable the NLS system to use the results of some other cataloging or citation and bibliographic referencing systems as input to the NLS catalogs πŸ“–. The fourth extension would be to enable other data management systems to generate data of a more general type that the NLS can use πŸ‘‘.

Phase II ✨

okay bestie, phase II was the working meeting where everyone tried to get the committee organized and set up an active working interest group 🫢

the people who had shown real interest and were already doing related work formed the committee πŸ’…

Douglas B. McKay        IBM Research (Chairman)
Abhay Bhushan           MIT
Ernie Forman            MITRE
Dorothy Hopkin          University of Illinois
Phil Messing            MITRE
A.P. Mullery            IBM Research
Erika Perez             MITRE
A. Shoshani             SDC
S. Taylor               MITRE
Bob Thomas              BBN
Frank Ulmer             NBS
Dick Watson             SRI
Dick Winter             CCA

it would be SO useful to have a representative from the Form Machine group at the follow-on meetings 🧚 the way people are going to want to use the Form Machine for a Network Data Management facility is bound to come up later, so having someone who knows it is giving main character energy πŸ‘‘

a member of the Form Machine group would honestly be an asset to the Data Management Committee πŸ’–

the discussion covered a lot of ground, with a big general chat about what people actually want to be able to do with a network data facility πŸ¦‹

the group put together this list of possible stages of development from the discussion 🌈

  1. Transmission Facility - the Network Data Control Facility (DCF) can route requests for files to the right node. You have to specify the location and the name πŸš€
  2. Location Catalog - the DCF now has a catalog of where the data sets live in the network. Requests can be made by name only, and the DCF figures out the location πŸ—ΊοΈ
  3. Description Catalog - descriptions can be sent through the network along with data sets. These descriptions are assumed to exist as files at local nodes, and a target node can use the description to convert the data set into its own format πŸ“š
  4. Data Conversion Modules - this module of the DCF receives the data descriptions. Based on them, conversion programs get called or generated to transform a file into the form the target node needs πŸ”§
  5. File Access Command Interface - this module converts a file request from the network data language into the local language where the file lives πŸ’¬
  6. Data Access - an extension of the network data language and the interface modules. It lets you access pieces of data as specified in the data language and generates the right local access commands 🎯
  7. Data Management Interface - the final stage, where general types of commands can be hooked up to local data management systems. That gives general interaction between different data management systems at different nodes 🌸

everyone agreed that being able to access all data and all different databases is a goal worth chasing πŸ”₯ there was lots of debate about the best way to get there and what implementation techniques could actually work. it was agreed that the database interfacing problem needs more detailed study, and a few people said they'd be happy to write up reports on a representative problem once they had more results πŸ“


the Datalanguage was also up for discussion, including whether it's suitable at all πŸ€” one thing needed to be super clear: the results of this committee should NOT rise or fall based on the answer to the data language question. the initial proposal suggests the Datalanguage as a de facto standard that gets adopted across the network because it has good support and is widely available. the group should be able to recommend changes whenever they're shown to be necessary πŸ’…

the Datalanguage discussion also highlighted the need for data set descriptions to be cataloged and referable by name. D. Winter said he would look into this problem 🫢

the proposal (RFC 304) for a network data facility should be read again and talked through in more detail at the next meeting πŸ“– the proposal says a stage 3 capability can be implemented and achieved with what we know today, and that it would be a useful stepping stone toward stage 5 and stage 6 capabilities ✨


these studies are already in progress, related to the stages above, and they'll help us answer the pressing questions πŸ”

  • A. Bhushan is studying a stage 1 type of network operation. It extends local catalogs so they hold entries for network data sets of local interest, which enables automatic calls to foreign data sets 🧚
  • E. Perez will study the network catalog structure in more detail and will publish an RFC on her work πŸ’œ
  • Many questions came up about using the data language as a network standard, and two people volunteered to write up their investigations of this important study πŸŽ€
    • Frank Ulmer will look at various data management systems to see whether their data structures can be described in terms of the Datalanguage. The NIC is also one important network database that could be distributed through the network 🌈
    • Dick Watson will try to describe the NLS Journal structure in terms of the Datalanguage πŸ¦‹

and if anyone else in the ARPA network, or outside it within hearing distance of this memo, knows about any real or potential applications of data sharing in a network, please submit an RFC in a letter to someone associated with the Data Management committee describing it πŸ’Œ we want ALL the ideas, periodt πŸ’…


Appendix -- Meeting Attendees πŸŽ€

William Benedict     USAFETAC Bldg. 159 Navy Yard Annex Wash. D.C.

Roy Beveridge        MITRE

Abhay Bhushan        MIT, Project Mac, Cambridge, Mass.

Bob Brown            General Motors Research Lab.

Elizabeth Fong       National Bureau of Standards, Wash. D.C.

Ernie Forman         MITRE

Glen Grazier         USAFETAC Bldg. 159 Navy Yard Annex Wash. D.C.

Dorothy Hopkin       U. of Ill., Adv. Comp. Bldg., Urbana, Ill.

Hector S. Maynez     National Library of Medicine

Doug B. McKay        IBM Research Center

Phil Messing         MITRE

Al Mullery           IBM Research Center

Erika Perez          MITRE
John Senior          Univ. of Penn. and National Board of Medical
                     Examiners, Phila. PA.

Arie Shoshani        SDC, 2500 Colorado Ave., Santa Monica, Cal.

Martin Snyderman     Smithsonian Science Info. Exch., Wash. D.C.

Eric Swarthe         National Bureau of Standards, Wash. D.C.

Suzanne Taylor       MITRE

Bob Thomas           BBN

Frank Ulmer          National Bureau of Standards, Wash. D.C.

Dick Watson          SRI

Richard Winter       Computer Corporation of America

        [This RFC was put into machine readable form for entry]
     [into the online RFC archives by HοΏ½lοΏ½ne Morin, ViagοΏ½nie 10/99]
πŸ“¦ where this page comes from