> On Monday, 09/22/2008 at 02:10 EDT, gah <[EMAIL PROTECTED]> wrote: > > In text mode (also called ASCII mode) the form on the TCP > > stream is CRLF terminated. It is the responsibility of > > both client and server to convert from native text form > > to that form.
Correct. (Haven't read the RFC for a while, but this is not something they would likely have taken out.) Internet "plain text" is ASCII (or a superset thereof) with CR/LF. On Mon, 22 Sep 2008, Alan Altmark wrote: > I'm not sure what you're getting at, Glen, but it has been alleged that > some systems do NOT convert LF to CRLF on ASCII/TEXT mode transmissions. > Looking at Debian's ftp client and vsftpd, it would appear they do the > right thing, but it would be great if a few folks would try various > clients and servers and confirm the behavior. Correct. Some servers (clients too?) do in fact NOT behave well in this regard. > The z/VM FTP client and server both look for CRLF to delimit the records. > The file format (F or V) is not relevant except that it affects the > maximum length of a record in a text transmission. And this has been VM TCP/IP's behaviour for lo these many years. There is no bug. When I find myself writing code to handle "plain text", I employ the internet rule of being liberal about what you accept and conservative about what you send. So I always put CR/LF on the wire but tolerate lack of CR for "plain text" that I get. This is terribly easy in Pipelines where I can split at LF and then discard any trailing CR. But if there is no trailing CR, then the pipeline does not care, and in the end I always get correct plain text. (PAD with one blank minimum for CMS files.) -- R; <><
