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

    Date:        Thu, 25 Apr 2002 07:10:51 -0500
    From:        "Gregory A Lundberg" <[email protected]>
    Message-ID:  <[email protected]>

  | OK.  Obviously we're reading different versions of RFC 1123.

No, same thing, just interpreting it differently...

  | The closest I see is the first sentance of the first paragraph,
  | which tells us that CR LF is one possible representation for end-of-
  | line.

no, it says "the sequence CR LF to mean "end-of-line"."

That is, if you mean end of line, CR LF is how it is represented.
Not that this is really very important, for us, as it is about telnet,
not FTP.

But note it also says: "The Telnet protocol defines" - it is clearly
just restating what RFC854 said - and if you look there you'll see
quite reasonably defined what CR, LF and CRLF achieve.  What wasn't
defined well, was what was supposed to happen when a telnet client
sends just CR (CR NUL of course) or LF to the server, whereas that was
defined from server to client (moving the carriage and all that).

That is what 1123 is fixing - making it clear that if the client happens
to send what the server system would treat as the end of command sequence,
then the that's how it should be treated.  Otherwise you get absurd
situations where I type

	DIR <cr><nl>

on a unix system, where I have mapping from CR to end of line disabled
(ie: the CR is just a character) - the telnet client correctly sends

	D I R SP CR NUL CR LF

to the server.  Assume that's a DOS type server, where EOL is <CR>.
Now the telnet server there would have (under some readings of 854)
been required to transfer the command "DIR <CR>" to the DOS "shell"
where the <CR> isn't supposed to represent end of line - which is simply
impossible (or impossible to do in any rational way).

The text in 1123 is all there to make it clear that the telnet server in
that case is allowed to (in fact, must) treat that CR as an end of line
(and the following CR LF as another).

See also, in 854:

      Therefore, the sequence "CR LF" must be treated as a single "new
      line" character and used whenever their combined action is
      intended; the sequence "CR NUL" must be used where a carriage
      return alone is actually desired;

That's the definition of the telnet "newline" character, which is
also called "end of line" in other places (in 854 only when discussing the
GA (go ahead) command), but FTP assumes it...).

Once again however, we're not concerned with Telnet here, but with FTP,
and in rfc959, what it says is ...

	    In accordance with the NVT standard, the <CRLF> sequence
            should be used where necessary to denote the end of a line
            of text.

(see page 11).   Not CR NUL, not LF, but CRLF.   For FTP, that is it.
Period.

See also ...

   The File Transfer Protocol follows the specifications of the Telnet
   protocol for all communications over the control connection.  Since
   the language used for Telnet communication may be a negotiated
   option, all references in the next two sections will be to the
   "Telnet language" and the corresponding "Telnet end-of-line code".
   Currently, one may take these to mean NVT-ASCII and <CRLF>.

Once again, CRLF, nothing else.

  | The second paragraph goes on to inform us that, when received via a
  | Telnet connection, the sequences CR LF and CR NUL are interchangable.

No, that's not what it says at all.   It says that "On server hosts that
use ASCII" (which seems to be some peculiar way to subset servers),
"receipt of the Telnet sequence CR LF must cause the same effect
as a local user pressing the CR key on a local terminal."

Now if that meant what it seems to say, then receiving CR LF on a unix
host with cr -> lf mapping turned off (which it would be if you were
using one of the terminals that actually had a "newline" key which
generated "lf" - which is the kind of terminal that gave unix its
LF==end of line characteristic) would simply cause a CR to be inserted
into the data stream, and wouldn't be an end of line at all.

But since everyone agrees that CR LF is end of line, that would be
nonsense.

So, instead read this so it makes sense - and assume that by "hosts thst
use ASCII" what they really mean is as defined in the previous paragraph...

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

That is, this there's an assumption that on an "ascii host" CR is the
normal terminal end of line character.

And there, we have exactly the situation described above - whether we
send the telnet end of line, or the host's native end of line, they both
have to have the same effect (for telnet) because anything else is absurd.

Note, this isn't a modification of NVT, where CR LF is end of line, but
a specific direction to the server to (in that circumstance) treat CR NUL
identically to end of line (they're different, but they both achieve the
same thing).

  | The third tells us that when sent over a Telnet connection from a
  | user-FTP (the only user-Telnet in the FTP), either CR LF or CR NUL
  | can be sent for the end-of-line, the choice is up to the user, and
  | the default is CR LF.

no, that paragraph doesn't say that either.   What it says is that users
need to be able to send all 3 forms, and the telnet client must make a
mechanism available (to the end user) to send any of the three when the
user desires.   That's to allow for interoperability with broken servers,
or more likely, with systems that need to be able to receive any arbitrary
one of the three.   But CRLF is what gets sent unless the user specifically
changes things.

A user using telnet to talk to a FTP server would have no reason to alter
the default, as FTP servers only treat CRLF as end of line (and always
treat CRLF as end of line).   We don't need to do anything to cope with
users who decide to deliberately send something non-conformant.

  | The fourth tells us that when sent over a Telnet connection from a
  | server-FTP, only CR LF may be sent.

You didn't read that one either ...   I'll quote it again...

      The Telnet end-of-line sequence CR LF MUST be used to send
      Telnet data that is not terminal-to-computer (e.g., for Server
      Telnet sending output, or the Telnet protocol incorporated
      another application protocol).

Note the final clause in the parenthesised sentence.

	or the Telnet protocol incorporated another application protocol

That is exactly what we have here (and in SMTP, and others) - the Telnet
protocol incorporated in another application protocol.   And see what
1123 is telling you "The Telnet end-of-line sequence CR LF MUST be used".

Can it be any clearer?

The text that Alun Jones just sent is also directly on point.

So ...

  | In RFC 2119 terms:
  | 
  |    FTP implementations MUST interpret CR LF as marking the end-
  |    of-line.  [First paragraph, explicitly.]

yes.

  |    FTP implementations MAY interpret sequences other than CR LF
  |    as marking the end-of-line.  [First paragraph, by conversion.]

no.

  |    FTP implementations MUST interpret CR LF and CR NUL
  |    interchangably. [Second paragraph, explicitly.]

no.

  |    FTP implementations MUST therefore interpret CR NUL as marking
  |    the end-of-line. [Second paragraph, by deduction.]

no.

  |    The user-FTP, when implemented as a user-Telnet, MUST offer a
  |    configuration option allowing transmission of CR NUL to mark
  |    the end-of-line.  The default for this option MUST be to
  |    transmit CR LF to mark the end-of-line. [Third paragraph,
  |    explicitly.]

no.   If you happen to be using a telnet implementation to talk to
a ftp server, then the implementation must offer that option, but to
correctly interoperate with ftp, the user must not use it.   Just as
the user must not cause telnet option negotiation to be attempted,
though a telnet client would normally allow that as well.

  |    The user-FTP, when not implemented as a user-Telnet, MAY offer
  |    a configuration option allowing transmission CR NUL to mark
  |    the end-of-line.  The default for this option MUST be to 
  |    transmit CR LF to mark the end-of-line.  [Third paragraph,
  |    by conversion.]

no.

  |    The user-FTP, when not implemented as a user-Telnet and which
  |    does not offer a configuration option allowing transmission of
  |    CR NUL to mark the end-of-line, MUST transmit CR LF to mark
  |    the end-of-line.  [Third paragraph, also by conversion.]

just always send CRLF, no options, no choices.

  |    The server-FTP MUST transmit the sequence CR LF to mark the end-
  |    of-line.  [Fourth paragraph, explicitly.]

yes, though the part you're getting that from isn't the part of the
paragraph that is most on point.

  | While the server-FTP MAY interpret sequences other than CR LF and
  | CR NUL to mark the end-of-line, the user-FTP cannot send any others.

user FTp has to send CRLF, nothing else.

  | So, in answer to the points raised so far about my comments on the
  | MLST draft:
  | 
  | 1) You are incorrect.  CR NUL quite definitely MUST be interpreted
  |    as the Telnet end-of-line.  Therefore we have no alternate form
  |    for the "bare" CR to be used in a file, directory or path name.

No, that is simply wrong.    The fact that it takes such a convoluted
argument to arrive at this position should be a pretty good clue that
it isn't correct.   The early RFCs were not big on convoluted arguments.
Everything is meant to be interpreted in the obvious way.

kre