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

At 03:18 PM 4/27/2002, you wrote:
>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 the developer of an FTP server that accepts CR NUL as an end of line 
sequence, I can tell you that I consciously made the decision to allow CR, 
LF, or CR LF to act as end-of-line sequences, not because of any reading of 
the RFCs, but because I saw requests coming from clients that contained 
those sequences.  Originally, I had set the program up to only accept CR LF 
as an end-of-line sequence, but had received a few reports of 
incompatibilities (often with user-written clients).

Hang the RFC compliance, I thought at the time, nobody's going to actually 
_want_ a CR or LF in a file name, and if they do, then I can wave the 
compliance flag at the broken clients, because by that time I'll be more 
established.

>As for the argument, no .. but
>
>Here's my opinion in the argument: What the TRUE definition is does not
>matter.

So in other words, it doesn't matter whether anyone else agrees with you or 
not, your opinion is absolute.

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

Analysing the standards as written, without opinion, demonstrates that 
there is contradiction and confusion.

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

The real-world implementations _treat_ CR NUL as if it were 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.

Those of us who persist in our "wrongheadedness" are convinced that the 
RFCs are confused and contradictory, and that the FTP RFC outranks the 
Telnet RFC in describing what behaviour FTP implementations should adhere 
to.  You appear to be of the opinion that Telnet outranks FTP in describing 
FTP.

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

And yet... you point so frequently to "real implementations" - how many 
real implementations of FTP clients rely on Telnet client code as their 
base?  How many real implementations of FTP servers rely on Telnet server 
code as their base?

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

I believe that it is a mistake to apply the Telnet updates in RFC 1123 as 
if they were an update to the FTP specifications in RFC 959.  If the 
authors of the FTP section of RFC1123 had meant to include such additions, 
they surely would have - after all, they even went so far as to note that 
TCP is a stream-based protocol, and that you shouldn't make assumptions 
otherwise; surely if they had anything to say about including Telnet 
updates since RFC 854, they would have.

>Therefore a server-FTP
>
>  a) MUST accept CR LF as meaning end-of-line
>
>     This is plain from the wording of RFC 959.

Nobody is disputing that.

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

Most implementations, if not all, do that at present, but not because of 
any reading of the RFC, so much as out of a desire to cope with 
poorly-ported FTP clients on the Macintosh (where CR _is_ the line terminator).

Today, when file names with CR in them are more common, and Macintosh 
client code better written, the desire to support such file names appears 
stronger than the desire to support poor FTP clients, and thus server 
implementors seem willing, perhaps eager, to drop the use of CR NUL as EOL.

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

Good grief, I'm not sure where I could imagine reading that in to 
being.  Such an option would have to be negotiated with a connecting 
client, surely, using the forbidden Telnet option negotiation.

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

So why not make it explicit that CR NUL is not acceptable as an EOL?

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

Hell, why not decide on a client-server combination that uses 'q' as an 
end-of-line sequence?  By that argument, surely any character should be 
forbidden from file names?

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

You're heading towards arguing that FTP can't use any 7-bit ASCII character 
to represent anything other than EOL.

>The arguments I've seen so far are:
>
>1) FTP is not required to interoperate with user-Telnet.  Manifestly false.

And yet, holding FTP back to its "every user is TCP savvy, and is 
comfortable typing bare protocol" roots would seem to be stifling its 
future development.

>The clear intention of the original FTP authors, from as far back as you
>care to go, is that FTP interoperate with Telnet.

The clear intention of the original FTP authors is that it support EBCDIC 
to ASCII translation, and that it handle mail and Instant Messaging as 
well.  Times change, people change, hair styles change.

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

However, new features often kill off old and unused functionality.  Yes, 
accepting CR NUL as indicative of a CR in a file name would lead to people 
using poorly written FTP clients, or poorly configured Telnet clients 
(really, how many people are you talking about) being unable to continue to 
use such an FTP server.  But it would benefit by granting the ability to 
put a CR into a file name transferred by FTP.

Are you so in awe of the original authors of RFC 959 that you believe that 
it is written in stone tablets by the hand of ghod?  Did you join this 
working group mailing list to suggest that nothing ever be changed?

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

And they still do.  But I didn't see anyone arguing that they don't.

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

FTP uses almost nothing of Telnet.  Modern FTP implementations, at least as 
far as I have seen, have no use of Telnet code base.  The original reasons 
for using Telnet as an under-layer for FTP are almost entirely gone.

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

The Telnet in FTP should also not try any option negotiation.  The Telnet 
in FTP is also not designed to be character-based or provide any 
line-editing facilities.  In fact, there's so little of Telnet in FTP that 
it's strange that it was required to be included.

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.