a)  Initiate TTY-like connection with HOST x.

   b)  Terminate connection.

   c)  Send/Receive character(s) over TTY-like connection.

   d)  Initiate file-like connection parallel to TTY-like connection.

   e)  Terminate file-like connection.

   f)  Send/Receive over file-like connection.

Error Checking

   We propose that each message carry a message number, bit count, and a
   checksum in its body, that is transparent to the IMP.  For a checksum
   we suggest a 16-bit end-around-carry sum computed on 1152 bits and
   then circularly shifted right one bit.  The right circular shift every
   1152 bits is designed to catch errors in message reassembly by the IMPs.

Closer Interaction

   The above described primitives suggest how a user can make simple use
   of a remote facility.  They shed no light on how much more intricate
   use of the network is to be carried out.  Specifically, we are
   concerned with the fact that as some sites a great deal of work has
   gone into making the computer highly responsive to a sophisticated
   console.  Culler's consoles at UCSB and Englebart's at SRI are at
   least two examples.  It is clear that delays of a half-second or so
   for trivial echo-like responses degrade the interaction to the point
   of making the sophistication of the console irrelevant.

   We believe that most console interaction can be divided into two




 
RFC 1                        Host Software                 7 April 1969


   parts, an essentially local, immediate and trivial part and a remote,
   more lengthy and significant part.  As a simple example, consider a
   user at a console consisting of a keyboard and refreshing display
   screen.  The program the user is talking typing into accumulates a
   string of characters until a carriage return is encountered and then
   it processes the string.  While characters are being typed, it
   displays the characters on the screen.  When a rubout character is
   typed, it deletes the previous non-rubout character.  If the user
   types H E L L O <- <- P  where <- is rubout and  is
   carriage-return, he has made nine keystrokes.  If each of these
   keystrokes causes a message to be sent which in return invokes
   instructions to our display station we will quickly become bored.

   A better solution would be to have the front-end of the remote program
   -- that is the part scanning for <- and  -- be resident in our
   computer.  In that case, only one five character message would be
   sent, i.e., H E L P , and the screen would be managed locally.

   We propose to implement this solution by creating a language for
   console control.  This language, current named DEL, would be used by
   subsystem designers to specify what components are needed in a
   terminal and how the terminal is to respond to inputs from its
   keyboard, Lincoln Wand, etc.  Then, as a part of the initial protocol,
   the remote HOST would send to the local HOST, the source language text
   of the program which controls the console.  This program would have
   been by the subsystem designer in DEL, but will be compiled locally.

   The specifications of DEL are under discussion.  The following
   diagrams show the sequence of actions.























 
RFC 1                        Host Software                 7 April 1969


A.  Before Link Establishment