Subject: Ftp-WG: transfers of \r, \n, \r\n

From: Pat LaVarre <[email-masked]>
Date: Fri, 18 Jan 2002 19:01:11 -0500

> Ftp-WG: FEAT UTF8 does NOT mean \r and \n ok ...

I read the rfc's as saying an Ftp implementation
should pass \r, \n, \r\n thru the control connection
as \r\0, \n, and \r\n.  For control bytes, the issue
of what Eol is locally preferred does not arise.

But the rules for an "NVT-ASCII" DATA connection
appear less clear to me, in particular the rules for
the "TYPE A"scii transfer of NLST data that rfc959
recommends.

I think I see rfc959 [Ftp] says an \r appears on a
"TYPE A"scii data connection only as \r\0 or \r\n, by
way of rfc854 [Telnet].

I think I see rfc959 says the locally preferred Eol
passes thru a "TYPE A"scii data connection as \r\n.

I hear people vary greatly over how many things other
than the locally preferred Eol an Ftp implementation
should liberally accept as an Eol to be passed thru as
\r\n.

Specifically, I hear we see local \r, \n, \r\n pass
thru as:

        \r\n, \n, \r\n
        \r\0, \n, \r\n
        \r\n, \r\n, \r\n

On my own, I had read rfc1123 [Requirements] as
favouring the last: "be liberal in what you accept" as
a locally understood Eol.

But then on Usenet I hear I should disregard how many
Eol's in fact are understood locally.  I should "of
course" instead choose a behaviour by platform:

        \r\n, \n, \r\0\n
        \r\0, \r\n, \r\0\n
        \r\0, \n, \r\n

How clearly, specifically where, do the Ftp rfc's tell
us which of these people are wrong?

http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-14.txt
...
> all 256 possible octet values are permitted.
> as arguments ... and in responses
> both to the MLST and MLSD commands,
> and all other FTP commands
> which take pathnames as arguments.
...
> In all cases for MLST, a single set of fact lines
> (usually a single fact line) containing
> the information about the named file or directory
> shall be returned over the control connection,
> without opening a data connection.
...
> The data connection opened for a MLSD response
> shall be a connection as if the "TYPE L 8",
> "MODE S", and "STRU F" commands had been given,
> whatever FTP transfer type, mode and structure
> had actually been set, and without causing those
> settings to be altered for future commands.

I see mlst-14 plans for us to exchange pathnames via
the quasi-"TYPE A"scii of the control connection when
pathnames appear as command parameters, NLST data, or
mlsT reply text.

We will exchange them via a "TYPE L 8" data connection
only when pathnames appear as mlsD data.

That mixture of data connection TYPE's sounds like an
opportunity to fall into disagreement over what the
pathname truly is?  We cannot intend that the client
always disregard the SP pathname of an MLST response -
else why include it.

Could someone here easily fill me in on the history of
why we do not perpetuate the recommendation that any
FtpClient request either "TYPE A"scii or "TYPE E"bcdic
for MLST data, just as rfc959 recommends for NLST?

> > > P.S. As yet ... replies 500 to FEAT
> > Try anon login here: ftp://ftp.ipswitch.com 

        C> TYPE I
        s> 200 Type set to IMAGE.
        C> MLSD
        s> 150 Opening ASCII data connection for
directory listing
        ...

I find the choice of 150 reply text here confusing. 
I'd prefer to be told my MLSD connection is a "TYPE L
8, MODE S, STRU F" data connection, or a "binary" data
connection, or ... rather than an "ASCII" data
connection.

Thanks again in advance.    Pat LaVarre

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/