RFC 592

Some Thoughts on System Design to Facilitate Resource Sharing 💖

RFC 592 🎀 by R. Watson (SRI), NIC 20391, dated November 1973. The header doesn't list anything it obsoletes or updates, and it doesn't give a category. 🧚

INTRODUCTION ✨

okay so there's a growing interest in moving toward more resource sharing on the ARPANET 🦋 Right now, some sharing happens when systems open TELNET connections and generate user command strings. ngl that's fine for experimental use, but it's not how we want to operate in real usage 💅 What network system builders should do instead is develop mechanisms designed specifically for computer-computer communication 🫶

SYSTEM INTERCONNECTION, AN APPROACH 🌸

the goal is to view every system on the network as offering certain service modules, and any subset of those can be combined to build other systems 🔥 Each service module would have a well advertised set of primitive service capabilities it could provide. It would have documented commands at the level of present Telnet or FTP commands for getting access to its services, plus a defined network connection procedure. Then any system builder who wants these services can use them and integrate them into their own user interface environment 💜

right now, when a system gets built, builders tend to see it as a stand alone thing, or at most something for one specific environment 🙈 What I want to see is the idea that any system built is not only a stand alone environment but also a network service or set of services 👑 Builders would define not just a user interface for their environment, but also a set of primitives and primitive commands that other systems around the network can access to get that service performed ✨

For example, we are redesigning the NLS Journal based on our experience and on Network Mail, as a set of protocols and services 🍓 If you look at the processes of the NLS Journal, you can see a bunch of separate services that different network sites could provide, or that a single site could combine in different ways. These are: Distribution (identification of addressees and maintainance of the required data bases being a related service), recording (numbering and storing of items), cataloging, and retrieval.

at the moment these services are pretty tightly interconnected in the NLS Journal 😭 What we want is to decouple them and define how they talk to each other with protocols, so they can be distributed across different hosts on the network. Mechanisms would also be defined so several hosts doing similar services around the network can work together cooperatively 🌈

there are other services NLS could probably provide too, like structured file creation and manipulation, information portrayal online or in hardcopy, and database querying, etc. 🦋 But right now the system isn't explicitly structured so outside systems could come in anywhere except the human user interface, even though internally it's pretty modular. It would be straightforward for us to identify the NLS services other system builders might want to bring into their own systems with their own user interface, and then do the restructuring and primitive command definition needed. Other groups building systems on the network could do a similar examination 💅

CCA, as I understand it, has taken this point of view from the beginning 💖 They built the Datacomputer on the assumption that it's primarily a network resource and is meant to be used by other systems. BBN is also moving in this direction with the design of Distributed TENEX 🧚

none of the above is new ✨ It comes from generalizing past successes we've all had with network protocol development and good software engineering practices. It will, however, take a change in how system designers think, some concrete examples, and ongoing dialog to make this design philosophy the normal network way of life 🫶

SOME FUNCTIONS READY FOR INTERCONNECTION 🎀

dialog support might be the first area ripe for this kind of synthesis 🔥 Several systems exist, or are coming into existence, and each solves part of the problem (with some overlap). The dialog support systems on the network that I know of are:

• The NLS Journal (supports recorded and cataloged dialog and linked networks of documents and messages).
• NLS Screen linking and splitting (supports close collaboration of two or more people working together in real time in NLS)
• The network wide linking of terminals through BBN's RSEXEC.
• Tenex Sndmsg and Readmail and other mail systems support nonrecorded dialog and further manipulation of received messages. (Some interconnection between NLS and these facilities has been established).
• The communication system under design at USC-ISI to support a range of message services.
• The online conferencing system being built by Jim Calvin of Case, John Iseli of Mitre and others supports online conferencing of several members and has facilities to utilize various Tenex subsystems such as TECO and NLS to support conferees.
• The Hack system of CASE offers a bulletin board service.
• The Forum system of IFF supports online and distributed in time conferencing and other features.

other areas possibly ripe for synthesis are 1) file and data management, and information retrieval services; 2) editing and hardcopy portrayal with systems like Tenex RUNOFF, SU-AI's PUB and SRI-ARC's Output Processor. 🌸

if the salient service features, concepts, and goals of each could be clearly defined, and appropriate service primitives (like other ARPANET protocols) could be defined for each, then anyone who wants to bring that service in with a user interface that suits their environment or philosophy could do it 👑

SYSTEM INTERCONNECTION ISSUES RELATED TO THE ABOVE PROPOSAL 💅

there are a lot of detailed issues tied to system interconnection as proposed above 😭 A few seem worth mentioning here:

1) Types of Network Connections 🦋

the number and type of network connections opened between classes of cooperating processes can probably be systematized 🧚 One important part of the FTP and Graphics protocol efforts was defining the number and type of connections needed for these classes of transaction. Similar classification and connection definition will be needed for other types of processes ✨

2) Data Structure Translation 🌈

the whole area of translating and transferring data structures more complicated than sequential files needs serious thought and protocol development 🔥

systems built around sequential files are dominant on the ARPANET right now, and they provide a base for simple, useful, economical tools 💖 I don't, however, believe that longer run tool sharing can depend on communication between sequential files. It needs structured files 🎀 Experience with NLS tree structured files shows that even this level of structuring may not be enough for many uses, and more sophistication may be needed 🙈 A similar trend exists in work with computer graphics and generalized data management systems. Developing protocols for handling structured data bases, or agreeing on common structuring characteristics, seems like an important need 👑

3) Responsiveness 🌸

the factors that influence responsiveness to users in an environment of heavy, geographically separated resource sharing need to be determined and discussed ⭐

4) Documentation of System Interfaces 🍓

it's probably reasonably straightforward to define service interfaces, but they'll be useless unless their activating command languages and other conventions are well documented, and that documentation is kept up to date 📝

5) Accounting 💜

once you interconnect systems at lower levels, a very difficult problem is designing an appropriate network accounting and banking system that won't cause undue delays in accessing distributed resources 😭

6) Error Handling 🫶

we need mechanisms for passing error signals around when system environments cross machine boundaries 🚨

7) Standard Parameter Formats 🧚

data types like strings, integers, floating point numbers, arrays, pointers, etc. need standard representations defined for passing parameters back and forth between machines 💅

8) HELP at the Procedure Call Level 🌈

a HELP mechanism needs to be defined in the protocols to provide information that each designer can translate into their own user interface ✨ Standards for requesting HELP information and structuring HELP data bases need agreement 🎀

ACKNOWLEDGEMENT 🫶

I want to thank Charles Irby and Jim White for their useful suggestions on the thoughts above 💖