On Thu March 31 2005 14:30, Dave Crocker wrote:
If you have a document with CRLF line endings on a UNIX or Linux system,
it is likely to be transmitted over the wire with CRCRLF and stored
(inappropriately) on other UNIX/Linux systems with CRLF endings.
Yes, that is one of a number of plausible scenarios.
Supported by the difference in Content-Length reported by your server,
as mentioned this morning.
However the fact that my windows system sees bare line-feeds from documents
sent by the ietf server suggest that, instead, bare linefeeds are being sent,
contrary to internet standards.
That would depend on whether you're using HTTP or FTP, and if FTP
whether transfer mode is set to type I or type A (RFC 959).
HTTP (as previously mentioned) lacks such fine control; RFC 1945
section 3.6.1 does not require CRLF on-the-wire (so one cannot
justifiably claim "contrary to internet standards" if HTTP is
For all of the above reasons, FTP is preferable for transfer of
plain text (as type A transfers) where practical.
If you retrieve (for example)
in ASCII mode on your "windows system" (in between BSODs), you should
have whatever local line endings you expect on that system (assuming
you're using an ftp client designed for that system). If you transfer
in IMAGE mode, you should get precisely what is stored on the ISI.EDU
server (newline as line endings).
Use of FTP in IMAGE mode intentionally transfers content as stored on
the server, so again one cannot justifiably claim "contrary to internet
standards" in that case.
Now, if you're claiming that the ISI.EDU FTP server is not correctly
converting to NVT-ASCII (CRLF line endings) on-the-wire for type A
transfers, that's another matter (and I would dispute that claim, as I
just completed a test capturing packets with Ethereal and verified that
with type ascii ftp.isi.edu sends with CRLF line endings).
Bottom line: with all due respect, the "contrary to internet standards"
claim doesn't seem to hold water.