There was a mechancal reason for both and not just an EOL (End of Line) concept. As you point out, it was the original way to get an emulation of BOLD characters on print devices. You control the print head and when this emulation moved to 80x25 screens, the cursor was the carriage head. Some "Smart" terminals had a 132 columns mode to help with the emulation of Punch Cards which has 132 columns. But to me, overall, it would of been difficult to design the interactive I/O spftware and both modem and internet hosting protocols, overall telecommunications applications without the proper translations of CR/LF simply for proper visual operations. It was either hardware or software driven. For example, hitting the Carriage Return key <CR>, either the device was set to also send the <LF> or the receiver did the translation and with an echo back of <LF>, the sender (now the receiver) will react to the control character. All to make sure the visual (or print) was correct. I'm sure with SIP the same interactive I/O translation, telecomputing, full versus half duples issues are present. It would be been very difficult for SIP developers to do all this (text based Command/Response protocol ) in the blind and in an <LF> EOL world - something would have to be doing the translation, the device, the sender and/or receiver simply visual/print effects. -- HLS ----- Original Message ----- From: "John C Klensin" <john-ietf@xxxxxxx> To: "John Levine" <johnl@xxxxxxxxx>; <ietf@xxxxxxxx> Cc: <dean.willis@xxxxxxxxxxxxx> Sent: Wednesday, January 23, 2013 2:56 PM Subject: CRLF (was: Re: A modest proposal) > > > --On Wednesday, January 23, 2013 06:15 +0000 John Levine > <johnl@xxxxxxxxx> wrote: > >>>> Additionally, I can't understand why each line is terminated >>>> with <CR><LF>, why use two characters when one will do. >>> >>> Microsoft-OS text editors. Seriously. >> >> My, what a bunch of parvenus. SIP got it from SMTP, SMTP got >> it from Telnet. Back in the 1960s we all used <CR><LF> >> because on a mechanical model 33 or 35 Teletype, CR really >> returned the carriage, LF really advanced the platen, and you >> needed both. I first ran into CR/LF on a PDP-6 in about 1968, >> but I know it wasn't new then. >>... > > Right. And the relationships between the standards and the > equipment was a little obscure (at least to me) in terms of what > came first. 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. A number of systems of the > mid-1960s even had device drivers that would canonicalize lines > with non-destructive backspaces into lines with CR or vice > versa, depending on the needs of the particular device. > > The first version of ASCII was very specific that CR was "move > to first character position on current line" and LF was a > vertical index function. Then the confusion began with some > company (where I was at the time, the finger was pointed at > Digital Equipment, but I have no first hand information or > documentation) who started using CR as "new line". That left us > with systems in the wild that used LF (only) internally, ones > that used CR (only), ones that used CRLF (always the safe choice > because it worked whether LF was an index function or a new line > one), and equipment that often required the latter. Subsequent > versions of ASCII solved the incompatibility the same way the > FORTRAN standard (this was a bit before _that_ standards > committee decided the language was named "Fortran") solved > zero-iteration loops -- by fuzzy language that made both > one-traversal and zero-traversal valid in the FORTRAN case and > that made either interpretation of LF valid. > >> A single LF to start a new line arrived with the model 37 >> Teletype, and Unix was, as far as I know, the first system to >> use just \n as the line terminator starting in the early >> 1970s. > > IIR, Multics from several years earlier. I'd have to dig > through old manuals to remember what CTSS did, but that system > (and the IBM Model 1050 and 2741 devices often used as terminals > with it) were somewhat pre-ASCII (and long before ECMA-48/ ANSI > X3.64 and the VT100 and friends) and, IIR, sent and received > shift and rotate codes rather than what we would normally > consider character codes today. The character codes were just > input to device drivers that dealt with device characteristics > >> But by then the Arpanet protocols were designed, and >> the hassle of changing wasn't (and still isn't) worth it. > > Again, the key useful property of CRLF on the wire is that the > combination is fairly insensitive to the various interpretations > of CR and LF. > > john > >