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

> >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.
>
> I'm trying hard to find that requirement in the RFCs.  RFC 959 specifies
in
> several places that the control connection follows the Telnet protocol,
but
> it (and RFC 1123) further defines several places where behaviour is
> different.  Where there is such a contradiction, it would seem that the
> obvious conclusion is that RFC 959, and the FTP sections of RFC 1123, win
> out over Telnet.  Perhaps this deserves being stated somewhere, but I
don't
> think this is ambiguous.



RFC 959, page 1, paragraph 1 "INTRODUCTION" ...

   FTP, though usable directly by a user at a terminal, is
   designed mainly for use by programs.

The "terminal" being referred to here is the Telnet NVT.  This is
a "may" statement: "A Telnet user MAY directly use the FTP."


RFC 959, page 7, "TERMINOLOGY" ...

   user

   A person or a process on behalf of a person wishing to obtain
   file transfer service.  The human user may interact directly
   with a server-FTP process, but use of a user-FTP process is
   preferred since the protocol design is weighted towards
   automata.

This already is a "may" statement, followed by a "should": "A
human user MAY interact directly with a server-FTP process, but
SHOULD use a user-FTP process since the protocol design is
weighted towards automata."



RFC 959, page 8, paragraph 2, "THE FTP MODEL" ...

   The user may establish a direct control connection to the
   server-FTP, from a TAC terminal for example, and generate
   standard FTP commands independently, bypassing the user-
   FTP process.

The term "TAC terminal" here is historical and unfortunate.  It
owes to copying this section from older versions.  With the
advent of Telnet, the physical "TAC terminal" was replaced with
the NVT.

We cannot get must more clear than this.  The clear intention
is that the user-FTP process is OPTIONAL.

Interaction with the server-FTP is through the control
connection.  The control connection follows the Telnet
protocol.  Therefore, the tool to use to bypass the
user-FTP process is a user Telnet implementation.



RFC 959, page 9 ...

   The Relationship between FTP and Telnet:

   The FTP uses the Telnet protocol on the control connection.
   This can be achieved in two ways: first, the user-PI or the
   server-PI may implement the rules of the Telnet Protocol
   directly in their own procedures; or, second, the user-PI or
   the server-PI may make use of the existing Telnet module in the
   system.

   Ease of implementaion, sharing code, and modular programming
   argue for the second approach.  Efficiency and independence
   argue for the first approach.  In practice, FTP relies on very
   little of the Telnet Protocol, so the first approach does not
   necessarily involve a large amount of code.

This informs us that NOT ONLY can we bypass the user-FTP process,
but an FTP implementation (server- OR user-) MAY its own internal
implementation of the Telnet protocol, or it MAY use an existing
Telnet module provided by the host system.

While some hosts may provide a link-time module which an FTP
implementation can use, the most widely available Telnet module
is the user Telnet implementation.  On Unix, for example, this
module is generally called the 'telnet command'.

Given the relationship described here, a perfectly good (albeit
slow) server-FTP could be implemented using nothing more than
'expect' scripts and the 'telnet' command.  While doing a
server-FTP in 'expect' is probably something few have ever
considered, implementing a user-FTP in 'expect' and 'telnet' is
uncommon but has been done.  Implementing a user-FTP with 'shell'
scripts using the 'telnet' command is common enough that I get
several questions a year pertaining to it.



There are probably several more citations I could make, but I think these
are enough.  Besides, it's time to put the kids to bed, and I have a
contract out-of-town for the next few days so I need to get to bed early and
hit the road tomorrow ...