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

> >Bitch all you want, but we ALL support CR NUL as end-of-line.
>
> Does this mean that you feel you have lost the argument over standards,
and
> now you want to try and win it by pointing to implementations?

No, actually I think it's just more evidence that no matter how much you
don't like it, CR NUL does mean end-of-file.

As for the argument, no .. but

Here's my opinion in the argument: What the TRUE definition is does not
matter.

- The standards CAN be analyzed as written, without opinion, and if so, they
WILL show CR NUL to end-of-line.

- The real-world implementations show CR NUL to be end-of-line.

- But those who don't like the fact that CR NUL is end-of-line are so well
entrenched in their wrongheadedness that it appears fruitless to try to
change their minds.

Here's my take on it:

1) FTP is based on Telnet.

   This has not (yet) been disputed.

2) A server-FTP MUST interoperate with a user-Telnet.

   This is plain from the wording of RFC 959.  A user-FTP is OPTIONAL.

3) A user-Telnet SHOULD send CR LF for end-of-line;
   A user-Telnet SHOULD have an option to send other codes for end-of-line;
   That option MUST provide CR NUL as one of the other codes for
end-of-line.
   That option MAY allow other codes beyond CR NUL as alternatives.

   This is plain from the wording of RFC 1123.  In addition, real-world
tests show the authors of user-Telnet understand this and provide at least
the minimum requirement of CR NUL as an alternative for CR LF.

Therefore a server-FTP

 a) MUST accept CR LF as meaning end-of-line

    This is plain from the wording of RFC 959.

 b) SHOULD accept CR NUL as meaning end-of-line

 c) SHOULD provide an option allowing additional codes to be taken as
meaning end-of-line.

As a result of (b), there is no means to accept a bare CR (which MUST be
followed by a NUL, as is plain from the RFCs) as a "data" character.

As a result of (c), there MAY be no means to accept other characters from
the 7-bit ASCII character set (EM was given as an example) as a "data"
character.

Therefore, the FTP needs a method to "escape" any character from the 7-bit
ASCII character set so that the user-Telnet's "local convention" of using
some other character to mean end-of-line may be circumvented.

The arguments I've seen so far are:

1) FTP is not required to interoperate with user-Telnet.  Manifestly false.
The clear intention of the original FTP authors, from as far back as you
care to go, is that FTP interoperate with Telnet.

2) A user has no reason to change the default, therefore we don't need to
worry about those who did.  Violates the principles of robustness (see the
top of RFC 1123, just to name one place where this principle is stated.  I
believe you'll find it in RFC 959 as well).

3) Early RFCs should were intended to be taken as read and should not
require long discussions analyzing the intended meaning.  Obviously false.
Read RFC 1123 and it becomes clear that the oversights and inclear wording
in early RFCs caused a great deal of problems.

4) In matters where FTP and Telnet cover the same ground, the FTP should win
out.  False.  By extension, this faultly thinking would have the FTP rule
TCP and IP in matters where the requirements of those protocols differ from
the requirements of FTP.  Telnet defines Telnet.  If the FTP is at odds with
Telnet, either the FTP should make it clear it no longer users Telnet, or
the Telnet specification wins.

5) The Telnet implementation in the FTP is somehow "different" than the
Telnet implementation in Telnet.  Well, this _is_ true.  But not for
end-of-line.

The ONLY difference between the Telnet in Telnet and the Telnet in FTP is
the Telnet Go-Ahead function: A server-FTP MUST NOT send Telnet Go-Ahead
while a server-Telnet MUST send it until negotiated otherwise.  (Note this
has implications on HOW a server-FTP should "refuse to negotiate" concerning
the Telnet Suppress Go-Ahead Option; which I'm still trying to work out the
effects of.)