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

    Date:        Thu, 25 Apr 2002 01:26:56 -0500
    From:        "Gregory A Lundberg" <[email protected]>
    Message-ID:  <[email protected]>

  | The FTP specification states that the control connection operates using
  | normal Telnet clients.

yes.

  | A normal Telnet client sends CR LF, or CR NUL, or LF, at the end-of-line.

If it is working correctly, it sends CRLF - nothing else is a telnet end of
line.

A telnet client on the other hand needs to be able to (somehow) generate
all 3 (1123 does say that) in case the user wants to send them - but neither
CR NUL nor LF are end of line in telnet.

  | We don't know which, so we must be prepared for all.

not in FTP we don't.   The telnet client sends CRLF or it isn't sending
end of line.

A telnet server needs to treat both CRLF and whatever sequence would be
its normal direct connect end of line marker (which might be CR (transmitted
as CR NUL) or LF, or conceivably ETX or something) as "end of command" and
pass that to the command interpreter (with CRLF replaced by whatever is the
appropriate local end of command indicator).   But FTP servers aren't
telnet servers, and they don't pass commands to command interpreters, and
so don't have to deal with that.

  | 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.

No, I don't want to drop that at all.   FTP servers should work fine with
any correct telnet client.   A telnet client that sends anything other than
CRLF when it receives the local user's "end of line" indicator is horribly
broken though, we don't need to support those.

kre