Hi -
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: "Carsten Bormann" <cabo(_at_)tzi(_dot_)org>
Cc: "John Levine" <johnl(_at_)taugh(_dot_)com>; <ietf(_at_)ietf(_dot_)org>;
<dean(_dot_)willis(_at_)softarmor(_dot_)com>
Sent: Wednesday, January 23, 2013 5:20 PM
Subject: Re: Vestigial Features (was Re: CRLF (was: Re: A modest proposal))
...
So, yes, some TTY units needed padding
characters or other delays and sometimes it varied depending on
the relationship between current carriage position and intended
one. But that was a device driver problem (and lots of the
device drivers ran on peripheral controllers, not the
mainframe)-- no CTSS or Multics program that used the system
device drivers ever had a NUL or character timing as part of its
application-level data stream.
It was messier than that in other environments. Yes, device drivers,
peripheral processors, or front ends commonly dealt with whether a
particular device needed CR, LF, NL, CRLF, or something else, and
how many NULs had to be sent in order to deal with device limitations
in processing those control codes. But the more "sophisticated"
controls, such as VT, FF, and so on, also required delays on some
devices. (I remember one device where VT would cause it to suck
paper back into the printer in order to return to the top of the current
page.) Sequences for line insert, line delete, and region clears / fills
on some CRTs also required padding delays. Some got seriously
confused if the padding was omitted. However, dealing with this
issue was put painfully close to the user application in Unix-land.
Look for "padding" in the documentation for termcap and terminfo
for a glimpse into how convoluted things became.
....
As I said, I wasn't part of the committee that did ASCII. I do
know that CR was extensively used, in both our terminal
environment and in a number of ones involving line printers
without LF as a way to arrange overstriking (for bold,
underlining, and composed characters) on line-oriented devices
that couldn't handle backspacing. Again, that was mostly in
the device drivers: an application program would see
xxxo<BS>'yyy
whether that was transmitted or
xxxoyyy<CR> '
or, as mentioned earlier, whatever the first-character-of-line
printer control sequence was that would yield the same result.
In our CDC shop, security was critically dependent on this.
Since the teletypes echoed everything typed locally, there needed
to be a way to prevent even a partially-typed password from
being visible. This was accomplished by sending a sequence
that was something like:
Password:<cr><lf>[[[[[[[[<cr>]]]]]]]]<cr>########<cr>XXXXXXXX<cr>
Randy