What was your source for this information? Or
did you just make it up? Because it is faulty.
FTP did not "grow out of Telnet." The decision
to use Telnet was quite conscious for both FTP
and SMTP so that a human at a terminal on a TIP
could be FTP or SMTP user process and was hardly
vestigial in either case. Crude, yes. But
served a very distinct purpose.
John Day
At 11:29 PM +0100 1/23/13, Carsten Bormann wrote:
On Jan 23, 2013, at 20:56, John C Klensin <john-ietf(_at_)jck(_dot_)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