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

This has nothing to do with client side TELNET protocol.  The reason
that some so called clients end commands with

  CR
  CR-LF
  LF
  FF
  EM

is because different operating systems use different end of line
indicators.  Therefore, when used with TELNET protocol these appear on
the wire as

  CR-NUL
  CR-LF
  LF
  FF
  EM

but are to be convered back to the original form before processing on
the server.  All TELNET servers will convert CR-NUL to CR.  Quoting
from RFC 854 "TELNET Protocol":

      The sequence "CR LF", as defined, will cause the NVT to be
      positioned at the left margin of the next print line (as would,
      for example, the sequence "LF CR").  However, many systems and
      terminals do not treat CR and LF independently, and will have to
      go to some effort to simulate their effect.  (For example, some
      terminals do not have a CR independent of the LF, but on such
      terminals it may be possible to simulate a CR by backspacing.)
      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; and the CR character must be
      avoided in other contexts.  This rule gives assurance to systems
      which must decide whether to perform a "new line" function or a
      multiple-backspace that the TELNET stream contains a character
      following a CR that will allow a rational decision.

         Note that "CR LF" or "CR NUL" is required in both directions
         (in the default ASCII mode), to preserve the symmetry of the
         NVT model.  Even though it may be known in some situations
         (e.g., with remote echo and suppress go ahead options in
         effect) that characters are not being sent to an actual
         printer, nonetheless, for the sake of consistency, the protocol
         requires that a NUL be inserted following a CR not followed by
         a LF in the data stream.  The converse of this is that a NUL
         received in the data stream after a CR (in the absence of
         options negotiations which explicitly specify otherwise) should
         be stripped out prior to applying the NVT to local character
         set mapping.




> Back at ya ..
> 
> The FTP specification states that the control connection operates using
> normal Telnet clients.
> 
> A normal Telnet client sends CR LF, or CR NUL, or LF, at the end-of-line.
> 
> We don't know which, so we must be prepared for all.
> 
> Now, if you want to DROP the requirement that FTP work with a normal Telnet
> client, that's fine.  But, if you do, expect inter-operation problems with
> existing implementations.
> 
> 
> 



 Jeffrey Altman * Sr.Software Designer      Kermit 95 1.1.21  available now!!!
 The Kermit Project @ Columbia University   SSH plus Telnet, FTP and HTTP
 http://www.kermit-project.org/             secured with Kerberos, SRP, and 
 [email protected]                OpenSSL.