--On Wednesday, January 23, 2013 23:29 +0100 Carsten Bormann <cabo@xxxxxxx> wrote: > On Jan 23, 2013, at 20:56, John C Klensin <john-ietf@xxxxxxx> > wrote: > >> But having CR as an unambiguous "return to first >> character position on line" was important for overstriking >> (especially underlining) on a number of devices including line >> printers as well as TTY equipment. > > But John, on a TTY, you have to send CR NUL, or the first > character will smudge. The carriage is still in flight when > the next byte after it is processed, so it better not be a > printing character. Oh, my. This is getting to be interesting. I had no direct interaction with or insight into the ASA (later ANSI) committee that did ASCII so, while I heard some stories, I can't do more than speculate on why they made some of the decisions they did. But both Multics and CTSS supported a variety of terminal devices -- hardcopy and CRTs (storage tube and actively refreshed), wide and narrow, character and line-oriented, and so on. Between the mid-60s and the mid-70s, the devices on or next to my various MIT desks went from 1050, to 2741, to TTY 37, to Imlac PDS-1D, with some sort of storage tube "glass TTY" in between. The various hardcopy devices all had timing idiosyncrasies until they started acquiring significant local buffering. The Imlac was high enough resolution (2000 points square) that I could put it into 132 character mode, but the characters, while sharp, got pretty small. Those devices ran at transmission speeds from about 10cps up to 19.2kpbs and above. It is probably also relevant that CTSS and Multics both preferred "half-duplex" (really non-echoplex) operation in which there was no expectation that the remote host (or controller) would echo back the characters that the user typed and that a few of the relevant devices transmitted line-at-a-time rather than character-at-a-time. All of this led, very early, to the realization that one better have standard coding on the system so that programs that didn't have to be specialized to the output device for some other reason (hard to display 2000x2000 point dynamic vector graphics on a Teletype) operated in a device-independent way with device drivers that adapted between the standard coding to the particular terminal. 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. Those device drivers also did a lot of string canonicalization, eliminating problems with string comparison that we've reinvented with Unicode (see, e.g., the PRECIS WG for more discussion). If the device transmitted NULs, they would disappear before being delivered to the application. > (This is actually the real reason for CR LF: > CR needs 200 ms to execute because it takes time to move the > carriage, so you have to fill in a character to waste 100 ms. > So you might as well separate the CR and LF function, which is > what happened. Multiple newlines are sent as CR LF LF LF to a > real TTY because LF *does* execute in 100 ms -- moving the > paper is quicker.) 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. I don't know the history, but have always assumed that the experience above was one of the inputs to the development of NVT and other terminal abstractions on the ARPANET rather that using an "every machine needs to know the properties of every terminal" model. Sadly, we lost both of the people who would have been most likely to know last year. > Now the reason I'm writing this: > > SIP has CRLF because TTY carriages smudged. SIP has CRLF because every single application protocol we have that uses character-oriented commands is modeled on NVT, and NVT uses CRLF. You can theorize all you like about how NVT got that way (and might be right although given what I know of the way things unfolded, I'd be a little surprised). But it is NVT that is the issue. >... > CRLF was quite reasonable for Telnet, as this really was about > TTYs. FTP grew out of Telnet, so keeping it there was maybe >... Others have commented on the above statement, but the culprit is NVT and the decisions were very explicit, not accidents of "we did it that way the last time so should do it again without thinking", _especially_ after Unix became dominant on the network. john