RFC 96

RFC 96: An Interactive Network Experiment to Study Modes of Access the Network Information Center ✨

okay bestie, let's get the basics out of the way first 💅

• RFC number: 96
• Title: An Interactive Network Experiment to Study Modes of Access the Network Information Center
• Author: Richard W. Watson (SRI-ARC) 🦋
• Series: Network Working Group, listed as NIC 5739
• Category: Informational
• Date: 12 February 1971 🌸
• Obsoletes / Updates: the original header doesn't list either one, so this doc doesn't claim to replace or update anything 🙈

---

1. Introduction ✨

okay so this NWG/RFC lays out the framework for a simple interactive experiment 🧚 The goal is to figure out the different ways people can access the Network Information Center (NIC). The detailed specs for the initial access conventions live in NWG/RFC 97, NIC (5740,) 📖

The first online services at the NIC are built around the SRI-ARC (ARC) Online System, typewriter version, which is called NLS(T) 💖 These services are all about creating, manipulating, searching, and distributing symbolic material, which is mostly text to start. The original Online System was display oriented, and a ton of work went into making the user interface feel comfy. For the NIC, they built a typewriter oriented version instead. If the computer responds quickly and you're on a typewriter terminal running at 30 char/sec, it's genuinely powerful and comfy for handling structured text ✨

The big question the experiment tackles is how to stretch these features across the network to people at remote sites. Some of them might be on terminals running at 10 char/sec or faster, and they might be dealing with pretty heavily loaded systems 😭 The experiment also teaches us about how the network behaves interactively, and gives guidelines for designers building other interactive systems that run over the network 🔥

This is a two-site project, done with one other site, and we think it'll take about three calendar months ⏳ To keep resources low, we'll gather response time stats that are easy to grab with the metering tools already on the SRI and partner site systems, plus the network performance measuring tools. We're not running formal productivity studies with the users. Instead we'll collect their subjective vibes on each connection mode 🫶 The end result is data on the costs and benefits of each type of access. Sites can use that to decide how they want to set up access to the NIC and to other interactive sites 💜

While the experiment is running, other sites will want to access the NIC as they join the network. The recommendation is a simple approach, like the one described in Section 2b, to start with. It might change later if the experiment shows better response and/or human factors coupling with one of the other approaches. NWG/RFC 97, NIC (5740,) spells out this initial access approach in detail 🎀

2. Getting Connected to the Network 🌈

2a. Introduction

there are three basic approaches for remote sites to connect to the NIC through the network: User Program Telnet, NLS(T) Front End, and Monitor Telnet 🍓 We'll go through each one below. Every approach needs code that runs on the remote host 💅

we're assuming the Network Working Group will specify standard conventions for Telnet programs 🤓 The companion paper, NWG/RFC 97, NIC (5740,)), includes recommended conventions for some of the problems we know about with initial NIC access. We tried to make those conventions useful more broadly too. The NLS(T) Front End Program would interface with the Telnet Program 🧚

no matter which approach gets picked, the software at the ARC end is expected to use the info gathered during connection to log the remote terminal in under a general account. Then it drops the terminal user into the NIC version of NLS, which we call NLS(NIC) for short. NLS(NIC) asks the user for their initials, and after that they have access to all NIC facilities 👑

the initial typewriter oriented system takes commands in this general form:

<command words> <operand> <delimiter> ... <operand> <delimiter>

the <command words> are usually two words. The first one says what general operation class it is, and the second says which general data structure type to operate on. The <operand>s are either the specific data entities to act on, or instructions for adjusting NLS parameters ✨

the ARC system is full duplex. The user types the first character of the command words, and the system immediately echoes the rest of the characters back as feedback and support. Other feedback gets echoed wherever it makes sense 🦋 The question we need to answer is what changes this system needs to fit the network and the constraints at remote sites. So next we look at the problems that already exist at the remote sites 💖

to connect to the NIC, the user logs into their local system and calls up a subsystem, or cusp. This subsystem (or system program, the Telnet program) is also used to reach other sites 🌸 From the host subsystems' point of view, the remote terminal and its controlling software can run in three basic modes:

• Case 1 - Character at a time half duplex
• Case 2 - Character at a time full duplex
• Case 3 - Line at a time half duplex

technically, line at a time full duplex is a logical possibility, but nobody really uses that approach, so we're ignoring it in the rest of the discussion 🙈

in Sections 2b, 2c, and 2d, we describe the access modes we want to investigate experimentally. We want to see how users react on 10 char/sec, 15 char/sec, and 30 char/sec devices 🔥

2b. User Program Telnet 💜

let's look at each of the classes of terminal above, one at a time, and how the Telnet program might handle the communication between them and the NIC. The Telnet program might allow both full and half duplex communication, as the user specifies 🫶

2b1. Case 1 - Character at a Time Full Duplex 😭

the simplest approach is for the Telnet program to take each character it receives from the terminal, except for a special character or character sequence used to escape back to the terminal's host system. It converts the code to ASCII and sends it as a message to NLS(NIC). NLS(NIC) handles all the character echoing, and sends echo messages back to the Telnet program so they can be transmitted to the terminal in the appropriate terminal code ✨ this mode is full duplex from user to user, and it's probably the most brutal test of the interactive characteristics of the host-network-host system 💀

depending on the load on the remote host, on the network, and at ARC, the round trip delay for simple character echoing could be several seconds 😩 The old ARC 940 and a heavily loaded PDP-10 at Utah showed occasional delays of around 4 or 5 seconds, and even longer, for single character echoing. Human factors research on NLS(NIC) says delays like that would be frustrating for users 🙈 A more careful study of this mode should give us a baseline to measure the other modes against 🦋

2b2. Case 2 - Character at a Time Half Duplex 🍓

there are two subcases, and we treat them the same way:

1. The Telnet program sees a half duplex terminal.
2. The Telnet program sees a full duplex terminal, but it provides echoing so the terminal looks half duplex to the NIC.

with the character at a time half duplex case, the NIC program runs in two modes:

• a) short mode
• b) long mode

in short mode, the user types the command and only sees the characters their own system echoes, plus the NIC response to the command 💖

in long mode, the user gets feedback from the NIC at an appropriate point in the command. We want to find out how novice and experienced users feel about each of these two modes, given the delays in system response 🌈

2b3. Case 3 - Line at a Time Half Duplex 🎀

from the NIC's point of view, this case is basically the same as Case 2. From the network's point of view, it's a more efficient use of the network, because the messages are longer ✨ It's also more efficient for the user's host system, since it needs fewer calls to the Telnet subsystem. Response for Case 3 might even be better than Case 2 👑

2c. The NLS(T) Front End 🧚

in this mode, the subsystem that handles communication with the NIC takes over some of the interactive and other jobs that NLS(T) does right now. Those jobs are echoing the characters typed, giving extra feedback characters so the command words get fully spelled out, parsing the command string, handling errors where appropriate, and sending the parsed string as a message to NLS(T) 💅 If sites end up preferring this mode, we'd expect to supply an example version of the Front End program, written in some language, as a model for implementation. The Network Working Group may want to study a standard language for specifying programs like this, as mentioned in NWG/RFC 51, NIC (4752,) 🫶

2d. Monitor Telnet 🌸

a lot of the response delay in the Section 2b experiments is expected to come from the fact that the Telnet described there is a user program 😭 So we'll also run the Section 2b experiments with the Telnet routines living inside the user host monitor instead 💜

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Henrik Johansson 4/97 ]