NWG/RFC# 691                                    BH 6-JUN-75 23:15  32700
One More Try on the FTP



                                                        Brian Harvey
                                                               SU-AI
Re: File Transfer Protocol                              May 28, 1975
Ref: RFC 354, 385, 414, 448, 454, 630, 542, 640                        1

                       One More Try on the FTP                         2

   This is a slight revision of RFC 686, mainly differing in the
   discussion of print files.  Reading several RFCs that I (sigh)
   never heard of before writing 686 has convinced me that although
   I was right all along it was for the wrong reasons.  The list of
   reply codes is also slightly different to reflect the four lists
   in RFCs 354, 454, 542, and 640 more completely.  Let me also
   suggest that if there are no objections before June 1, everyone
   take it as official that HELP should return 200, that SRVR should
   be used as discussed below, and that "permanent" 4xx errors be
   changed to 5xx.  And thanks to Jon Postel who just spent all
   evening helping me straighten this all out.                        2a

   Aside from a cry of anguish by the site responsible for the
   security hassle described below, I've only had one comment on
   this, which was unfavorable but, alas, unspecific.  Let me just
   say, in the hopes of avoiding more such, that I am not just
   trying to step on toes for the fun of it, and that I don't think
   the positive changes to FTP-1 proposed here are necessarily the
   best possible thing.  What they are, I think, is easily doable.
   The great-FTP-in-the-sky isn't showing any signs of universal
   acceptability, and it shouldn't stand in the way of solving
   immediate problems.                                                2b

                      Leaving Well Enough Alone                        3

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!"        4

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





                                   1 

NWG/RFC# 691                                    BH 6-JUN-75 23:15  32700
One More Try on the FTP



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

   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.      5a

   2.  FTP-2 straightens out the "print file" mess.  First of all,
   there are two separate questions here: what command one ought to
   give to establish a print file transfer, and which end does what
   sort of conversion.  For the second question, although all of the
   FTP-1 documents are confusing on the subject, I think it is
   perfectly obvious what to do: if the user specifies, and the
   server accepts, an ASCII or EBCDIC print file transfer parameter
   sequence, 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). (The
   "Telnet print file" non-issue will be debunked below.)
   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.  One never reformats a file from ASCII to EBCDIC
   at the sending end.  Perhaps the confusion happened because the
   protocol authors had in mind using these types to send files
   directly to a line printer at the server end, and indeed maybe
   that's all it's good for and nobody's user program will implement
   TYPE P RETR.                                                       5b