rfc691.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 715 行 · 第 1/3 页


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

   As for the specific commands used to negotiate such a transfer,
   there may currently be some confusion because the most recent
   FTP-1 document on the subject (RFC 454) invents a new command,
   FORM, which is not in general use as far as I know.  (Most of my





                                   2

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



   experiments have been on PDP-10s; perhaps other systems have
   adopted this command.)  FTP-2 puts the format argument in the
   TYPE command as a second argument. Either way, using a
   two-dimensional scheme to specify the combinations of
   ASCII/EBCDIC and ASA/normal conveys no more information than the
   present A-P-E-F scheme.  FTP-2 also introduces the notion of
   Telnet formatted vs. non-print files.  These types are used when
   a Telnet format oriented system is sending a file to an ASA
   oriented one, and the recipient needs to know, not what is coming
   over the net, but how to solve a local file storage problem.  It
   is unnecessary and unfair for hosts to have to negotiate
   something which does not acttually affect what gets sent over the
   net.  It is unnecessary because the sending user process (there
   is no problem if the user process is receiving) need not
   understand what the issue is, it need only make the server
   understand by transmitting a message from the human user to the
   server process.  Any TYPE parameter must be understood by both
   processes even if the user treats it just like some other type.    5c

   To take a specific example, if I want to send an ASCII file to a
   360, my FTP user program needs to have built into it the
   knowledge that there are two TYPEs which are really the same, AN
   and AT in the FTP-2 notation. If tomorrow someone needs to know
   the ultimate use of a binary file (for instance, the old PDP-6
   DECtape format stores dump files differently from ordinary data
   files), I will have to add another piece of information to my FTP
   user and server (maybe they try to read such a file from me).
   Instead, information which affects only the RECIPIENT of a file,
   and not the format AS SENT OVER THE NET, should be specified in
   some form which the sending process can ignore.  This is what the
   SRVR command should be used for.                                   5d

   If a user at a 360 wants to retrieve a "Telnet print file" from
   another system, he might tell his FTP user process something like  5e

      TYPE A
      DISP PRINT
      RETR FOO etc.                                                  5e1

   (or whatever syntax they use in their FTP).  If a user at a 10
   wants to send such a file to a 360, he would say                   5f

      TYPE A





                                   3

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



      SRVR PRINT
      STOR FOO etc.                                                  5f1

   His FTP user program would send on the SRVR command without
   comment. Suppose that the transformation is one which might be
   used in either direction between the same two hosts.  (This is
   not the case for the Telnet print file thing because two 360s
   would be using ASA format.)  Then the user process could accept
   the equivalent of DISP PRINT from the user, and if the transfer
   turned out to be a STOR it would decide to send SRVR PRINT first.
   In this way the FTP user program can be written so that the human
   user types the same command regardless of the direction of
   transfer.                                                          5g

   Thus, FTP servers which care about the distinction between Telnet
   print and non-print could implement SRVR N and SRVR T.  Ideally
   the SRVR parameters should be registered with Jon Postel to avoid
   conflicts, although it is not a disaster if two sites use the
   same parameter for different things.  I suggest that parameters
   be allowed to be more than one letter, and that an initial letter
   X be used for really local idiosyncracies.  The following should
   be considered as registered:                                       5h

      T - Telnet print file                                          5h1

      N - Normal.                                                    5h2

         Means to turn off any previous SRVR in effect. (This makes
         "non-print" the default case, rather than
         making "Telnet print" and "non-print" equal.  It is
         probably a good idea if a user program can count on
         being able to turn off an earlier SRVR without having
         to know a specific inverse for it.  Servers which do not
         implement any other SRVR parameters need not implement
         SRVR N either; user processes shouldn't send SRVR N
         just for the hell of it.)

   3.  FTP-2 reshuffles reply codes somewhat.  There have been four
   attempts altogether, that I know of, at specifying a list of
   reply codes: RFCs 354 and 454 for FTP-1, and RFCs 542 and 640 for
   FTP-2. There is not much to choose from among the first three of
   these, which are basically the same, except for a slight increase
   in specificity each time through, e.g., the introduction of reply





                                   4

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



   code 456 for a rename which fails because a file of the same
   (new) name already exists.  This increased specificity of reply
   codes doesn't seem to be much of a virtue; if a rename operation
   fails, it is the human user, not the FTP user program, who needs
   to know that it was because of a name conflict rather than some
   other file system error.  I am all for putting such information
   in the text part of FTP replies.  Some real problems are actually
   addressed in the reply code revision of RFC 640, in which the
   basic scheme for assigning reply code numbers is more rational
   than either the FTP-1 scheme or the original FTP-2 scheme.
   However, I think that most of the benefits of RFC 640 can be
   obtained in a way which does not require cataclysmic
   reprogramming.  More on this below.                                5i