On 12/1/20 12:22 PM, John Levine wrote:
As Carsten said, trying to fix up line endings on the fly causes more problems that it solves which is why no modern protocol tries to do it.
The reason no "modern" protocol tries to do format conversion is that the computing industry has more-or-less standardized on a "paper tape" model of files being streams of octets, as opposed to the "punched card" model of files consisting of fixed or variable-length "records" where the file system and operating system deal with those records explicitly. There are efficiency advantages to the latter - the record size or an upper bound for that size is generally known before you read the next record, so you never have to handle a record that needs an arbitrarily long read buffer - but from an evolutionary perspective the paper tape model seems to have won (for now).
In addition, there have been enough exchanges between "paper tape" systems with different styles of line ending (CR, LF, or CR LF) that by now many tools that deal with text - editors, compilers, interpreters, etc.- just deal with whatever kinds of line endings they find. That's a relatively recent change, and it didn't happen all at once. But these days conversion during file transfer is necessary less often than it once was. The differences in format do still cause problems, though, so a truly reliable automatic format conversion would be a blessing, IMO.
Keith
