On Thursday, 07/24/2008 at 01:29 EDT, Alan Ackerman 
<[EMAIL PROTECTED]> wrote:

> The Internet has a standard record separator of CRLF. In theory, that
> should avoid all these incompatibilities. However, if you use Binary
> FTP transfer, then all bets are off. And some Unix programs use LF
> instead of CRLF, on the assumption that everything in the
> Internet is Unix.
> 
> It sure would have been nice if the ASCII "Standard" had specified what
> to do with the darn control characters.

Hey, now.  'Dems fightin' woyds.  This has to do with OS architecture, not 
ASCII standards.  You know that a Unix printer or old-school terminal 
driver has to add the CR to the LF to make the data look right.  DOS took 
the approach that that is the responsibility of the application and that 
the drivers would recognize EOF and CRLF as end-of-line, if such 
recognition is needed by the driver.

What I have never been able to fathom is the toleration for Unix's lack of 
adherence to a standard that was written in *1985*.  23 years ago.  It is 
the responsibility of the FTP client and server, not the operating system, 
to use CRLF on the wire.   And while I'm certain FTP on Unix pre-dated the 
RFC (that's how many early standards were developed), there's not even a 
provision to make Unix operate according to the standard.  I would have 
thought that the Unix camp (esp. Linux) would have developed an RFC 
wherein there would be negotiation on the line-end sequence in order to 
avoid the overhead of conversion.  But no.

Unix's assumption is not that everything is Unix, but that there is no 
difference between binary files and text files.  And this attitude isn't 
limited to Unix.  We saw this vividly with ftp .  We had to add some 
special support in our FTP server (AUTOTRANS) because some browsers would 
ASSUME that it could transfer a file in binary (image mode) even when that 
file would be treated as text by the browser. AUTOTRANS lets the server's 
filetype-based automatic EBCDIC-ASCII conversion override the "image" 
specification by the client.  Sickening.

Perhaps, in the future, when the sun grows dim and the earth begins to 
cool, knowledgable users will open defect reports with their operating 
system vendors.

Alan Altmark
z/VM Development
IBM Endicott

Reply via email to