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

    Date:        Wed, 24 Apr 2002 22:34:33 -0500
    From:        "Gregory A Lundberg" <[email protected]>
    Message-ID:  <[email protected]>

  | RFC 1123 *REQUIRES* the TELNET implementation to accept CR NUL as equivalent
  | to CR LF.

You are misinterpreting 1123, that would make no sense at all.

What 1123 is trying to say (perhaps not as well in this instance as it
does in most others), is that the telnet server must treat a received
CR over the telnet connection the same as it treats a CR from a local
keyboard.

That is, if CR ends a command, then CR over a telnet connection ends a
command - as does end of line.   So sending CR NULL or CR LF should be
treated the same way - but that applies only if CR is normally treated
as an "end of line" at the telnet server.

Note, the wording ...

	On server hosts that use ASCII, in particular,
        receipt of the Telnet sequence CR LF must cause the same effect
        as a local user pressing the CR key on a local terminal.

That is a reference to ...

	For terminal input, this corresponds to a command-
        terminal; on an ASCII terminal, this is the CR key, but it may
        also be labelled "Return" or "Enter".

That is, the "ASCII terminal" or host, being assumed, is one where CR
means "end of line".    Note this isn't true of unix hosts, on unix, CR
is just another character (the fact that the keyboard driver takes the
button labelled "CR" (or similar) and generates from it the character that
is the end of line indicator is irrelevant - that can easily be turned off
if you want to investigate what really happens).

For FTP none of this is relevant.   CR by itself is never an end of line
terminator.   Ever.   (Buggy implementations ignored).   If you want to
put a CR in a file name, you so it exactly as Pat LaVarre suggested.
If you happen to be talking to a broken implementation, then you might not
be able to put a CR in a file name - the answer is to fix the implementation,
not to change the way FTP is defined.   And it is irrelevant how common such
broken implementations might be (creating some new method to encode CR isn't
going to work on any existing implementation anyway - it is just as easy, if
not easier, to simply fix the bug as it is to support something new).

I will look at the rest of the comments later, but I rather suspect (or
perhaps even hope) that they're really too late now for this draft.

kre