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

OK.  Obviously we're reading different versions of RFC 1123.
I got mine from rfc-editor.org and here's what is says on page 21:

   3.3.1  Telnet End-of-Line Convention

      The Telnet protocol defines the sequence CR LF to mean "end-
      of-line".  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".

      When a Server Telnet receives the Telnet end-of-line sequence
      CR LF as input from a remote terminal, the effect MUST be the
      same as if the user had pressed the "end-of-line" key on a
      local terminal.  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.  Thus,
      CR LF and CR NUL MUST have the same effect on an ASCII server
      host when received as input over a Telnet connection.

      A User Telnet MUST be able to send any of the forms: CR LF, CR
      NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
      user-controllable mode to send either CR LF or CR NUL when the
      user presses the "end-of-line" key, and CR LF SHOULD be the
      default.

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

Nowhere in there does it make ANY requirement that end-of-line may
only be represented by CR LF.

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.  To arrive at the requirement you infer, the sentance would
have been worded as `The Telnet protocol defines "end-of-line" as
being the sequence CR LF.'

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

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.

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

In RFC 2119 terms:

   FTP implementations MUST interpret CR LF as marking the end-
   of-line.  [First paragraph, explicitly.]

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

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

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

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

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

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

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

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.

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.

2) You are correct, LF is not to be interpreted as the Telnet end-
   of line and does not require special escaping when intended as
   a character in a file, directory or path name.