RFC 686 (rfc686) - Page 1 of 9

Leaving well enough alone

Network Working Group                                       Brian Harvey
Request for Comments: 686                                          SU-AI
NIC 32481                                                    10 May 1975
References: 354, 385, 630, 542, 640.


                       Leaving Well Enough Alone

   I recently decided it was time for an overhaul of our FTP user and
   server programs.  This was my first venture into the world of network
   protocols, and I soon discovered that there was a lot we were doing
   wrong -- and a few things that everyone seemed to be doing
   differently from each other.  When I enquired about this, the
   response from some quarters was "Oh, you're running version 1!"

   Since, as far as I can tell, all but one network host are running
   version 1, and basically transferring files OK, it seems to me that
   the existence on paper of an unused protocol should not stand in the
   way of maintaining the current one unless there is a good reason to
   believe that the new one is either imminent or strongly superior or
   both. (I understand, by the way, that FTP-2 represents a lot of
   thought and effort by several people who are greater network experts
   than I, and that it isn't nice of me to propose junking all that
   work, and I hereby apologize for it.)  Let me list what strike me as
   the main differences in FTP-2 and examine their potential impact on
   the world.

      1. FTP-2 uses TELNET-2.  The main advantage of the new Telnet
      protocol is that it allows flexible negotiation about things like
      echoing.  But the communicators in the case of FTP are computer
      programs, not people, and don't want any echoing anyway.  The
      argument that new hosts might not know about old Telnet seems an
      unlikely one for quite some time to come if TELNET-2 ever does
      really take over the world, FTP-1 could be implemented in it.

      2. FTP-2 straightens out the "print file" mess.  This is more of a
      mess on paper than in practice, I think.  Although the protocol
      document is confusing on the subject, I think it is perfectly
      obvious what to do:  if the user specifies, and the server
      accepts, TYPE P (ASCII print file) or TYPE F (EBCDIC print file),
      then the data sent over the network should contain Fortran control
      characters.  That is, the source file should contain Fortran
      controls, and should be sent over the net as is, and reformatted
      if necessary not by the SERVER as the protocol says but by the
      RECIPIENT (server for STOR, user for RETR).  As a non-Fortran-user
      I may be missing something here but I don't think so; it is just
      like the well-understood TYPE E in which the data is sent in
      EBCDIC and the recipient can format it for local use as desired.



Harvey