RFC 89 (rfc89) - Page 2 of 7
Some historic moments in networking
Alternative Format: Original Text Document
RFC 89 SOME HISTORIC MOMENTS IN NETWORKING 19 January 1971 Brodie, Knight, Metcalfe, Meyer, Padlipsky and Skinner) was commissioned to establish a 'polite conversation' between a Multics terminal and an MITDG terminal. It was agreed that messages would be what we call 'network ASCII messages': 7-bit ASCII characters right-adjusted in 8-bit fields having the most significant bit set, marking, and padding. In that Multics is presently predisposed toward line-oriented half-duplex terminals, it was decided that all transmissions would end with the Multics EOL character (ASCII). To avoid duplicating much of the INCP in our experiment, the PDP-10 side of the connection was freed by convention from arbitrary bit-stream concatenation requirements and was permitted to associate logical message boundaries with network message boundaries (sic). The 'polite conversation' was thus established and successful. Multics, then, connected the conversation to its command processor and the PDP-10 terminal suddenly became a Multics terminal. But, not quite: First, in the resulting MITDG-Multics connection there was no provision for a remote QUIT, which in Multics is not an ASCII character. This is a problem for Multics. It would seem that an ASCII character or the network's own interrupt control message could be given QUIT significance. Second, our initial driver program did not provide for RUBOUT. Because the Multics network input stream bypassed the typewriter device interface module (TTYDIM), line canonicalization was not performed. In a more elegant implementation, line canonicalization could be done at Multics, providing the type-in editing conventions familiar to Multics users. We fixed this problem hastily by having our driver program do local RUBOUT editing during line assembly, thus providing type-in editing conventions familiar to MITDG users. It is clearly possible to do both local type-in editing and distant-host type-in editing. Third, we found that because of the manner in which our type-in entered the Multics system under the current network interface (i.e. not through TTYDIM), our remotely controlled processes were classified 'non-interactive' and thus fell to the bottom of Multics queues giving us slow response. This problem can be easily fixed. The Harvard Connection Connecting MITDG terminals to Multics proved to be easy in that the character-oriented MITDG system easily assembled lines for the Multics line-oriented system. We (Messrs. Barker, Metcalfe) decided, Metcalff
