Ftp-WG: Re: MLST draft - NUL CR LF again

At 01:26 AM 4/25/2002, Gregory A Lundberg wrote:
>Back at ya ..
>
>The FTP specification states that the control connection operates using
>normal Telnet clients.
>
>A normal Telnet client sends CR LF, or CR NUL, or LF, at the end-of-line.
>
>We don't know which, so we must be prepared for all.

RFC 959 also specifically states:
   The argument field consists of a variable length character string
   ending with the character sequence <CRLF> (Carriage Return, Line
   Feed) for NVT-ASCII representation; for other negotiated languages
   a different end of line character might be used.  It should be
   noted that the server is to take no action until the end of line
   code is received.

In the absence of any other negotiated language (and, per RFC 1123, the 
client MUST NOT negotiate a different language), this seems to be specific 
in that <CRLF> is required, not <CR><NUL> or <LF>.

>Now, if you want to DROP the requirement that FTP work with a normal Telnet
>client, that's fine.  But, if you do, expect inter-operation problems with
>existing implementations.

I'm trying hard to find that requirement in the RFCs.  RFC 959 specifies in 
several places that the control connection follows the Telnet protocol, but 
it (and RFC 1123) further defines several places where behaviour is 
different.  Where there is such a contradiction, it would seem that the 
obvious conclusion is that RFC 959, and the FTP sections of RFC 1123, win 
out over Telnet.  Perhaps this deserves being stated somewhere, but I don't 
think this is ambiguous.

Alun.
~~~~

--
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email [email protected]
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.