Hi - > From: "John C Klensin" <john-ietf@xxxxxxx> > To: "Carsten Bormann" <cabo@xxxxxxx> > Cc: "John Levine" <johnl@xxxxxxxxx>; <ietf@xxxxxxxx>; <dean.willis@xxxxxxxxxxxxx> > 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