On Jan 23, 2013, at 20:56, John C Klensin <john-i...@jck.com> 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. (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.) Now the reason I'm writing this: SIP has CRLF because TTY carriages smudged. Really. Please let that sink in a minute. I think in protocol evolution (as well as computer system evolution in general) we are missing triggers to get rid of vestigial features. CRLF was quite reasonable for Telnet, as this really was about TTYs. FTP grew out of Telnet, so keeping it there was maybe justifiable. For SMTP, CRLF already was vestigial; this should have been fixed when SMTP became separate from FTP, but maybe the separation was too gradual (it was too late to fix it 20 years later in 282x). Keeping CRLF for HTTP was a travesty (enjoy RFC 2616 section 19.3 para 3 for added pleasure). Keeping it in SIP was unspeakable. Grüße, Carsten
