rfc913.txt

RFC 相关的技术文档

               -invalid account

            Replies to PASS could be:

               !Changed working dir to <new-directory>

               +password ok, send account

               -invalid password

      KILL file-spec

         This will delete the file from the remote system.

         Replies are:

            +<file-spec> deleted

            -Not deleted because (reason)







Lottor                                                          [Page 8]



RFC 913                                                   September 1984
Simple File Transfer Protocol


      NAME old-file-spec

         Renames the old-file-spec to be new-file-spec on the remote
         system.

         Replies:

            +File exists

            -Can't find <old-file-spec>

               NAME command is aborted, don't send TOBE.

         If you receive a '+' you then send:

            TOBE new-file-spec

         The server replies with:

            +<old-file-spec> renamed to <new-file-spec>

            -File wasn't renamed because (reason)

      DONE

         Tells the remote system you are done.

         The remote system replies:

            +(the message may be charge/accounting info)

         and then both systems close the connection.

















Lottor                                                          [Page 9]



RFC 913                                                   September 1984
Simple File Transfer Protocol


      RETR file-spec

         Requests that the remote system send the specified file.

         Receiving a '-' from the server should abort the RETR command
         and the server will wait for another command.

         The reply from the remote system is:

             <number-of-bytes-that-will-be-sent> (as ascii digits)

            -File doesn't exist

         You then reply to the remote system with:

            SEND (ok, waiting for file)

               The file is then sent as a stream of exactly the number
               of 8-bit bytes specified.  When all bytes are received
               control passes back to you (the remote system is waiting
               for the next command).  If you don't receive a byte
               within a reasonable amount of time you should abort the
               file transfer by closing the connection.

            STOP (You don't have enough space to store file)

               Replies could be:

                  +ok, RETR aborted

         You are then ready to send another command to the remote host.


















Lottor                                                         [Page 10]



RFC 913                                                   September 1984
Simple File Transfer Protocol


      STOR { NEW | OLD | APP } file-spec

         Tells the remote system to receive the following file and save
         it under that name.

         Receiving a '-' should abort the STOR command sequence and the
         server should wait for the next command.

         NEW specifies it should create a new generation of the file and
         not delete the existing one.

            Replies could be:

               +File exists, will create new generation of file

               +File does not exist, will create new file

               -File exists, but system doesn't support generations

         OLD specifies it should write over the existing file, if any,
         or else create a new file with the specified name.

            Replies could be:

               +Will write over old file

               +Will create new file

               (OLD should always return a '+')

         APP specifies that what you send should be appended to the file
         on the remote site.  If the file doesn't exist it will be
         created.

            Replies could be:

               +Will append to file

               +Will create file

               (APP should always return a '+')








Lottor                                                         [Page 11]



RFC 913                                                   September 1984
Simple File Transfer Protocol


         You then send:

            SIZE <number-of-bytes-in-file> (as ASCII digits)

               where number-of-bytes-in-file

                  is the exact number of 8-bit bytes you will be
                  sending.

         The remote system replies:

            +ok, waiting for file

               You then send the file as exactly the number of bytes
               specified above.

               When you are done the remote system should reply:

                  +Saved <file-spec>

                  -Couldn't save because (reason)

            -Not enough room, don't send it

               This aborts the STOR sequence, the server is waiting for
               your next command.

         You are then ready to send another command to the remote host.





















Lottor                                                         [Page 12]



RFC 913                                                   September 1984
Simple File Transfer Protocol


AN EXAMPLE

   An example file transfer.  'S' is the sender, the user process.  'R'
   is the reply from the remote server.  Remember all server replies are
   terminated with <NULL>.  If the reply is more than one line each line
   ends with a <CRLF>.

      R: (listening for connection)
      S: (opens connection to R)
      R: +MIT-XX SFTP Service
      S: USER MKL
      R: +MKL ok, send password
      S: PASS foo
      R: ! MKL logged in
      S: LIST F PS: <MKL>
      R: +PS: <MKL>
         Small.File
         Large.File
      S: LIST V
      R: +PS: <MKL>
         Small.File  1        69(7)  P775240  2-Aug-84 20:08  MKL
         Large.File  100  255999(8)  P770000  9-Dec-84 06:04  MKL
      S: RETR SMALL.FILE
      R:  69
      S: SEND
      R: This is a small file, the file is sent without
         a terminating null.
      S: DONE
      R: +MIT-XX closing connection




















Lottor                                                         [Page 13]



RFC 913                                                   September 1984
Simple File Transfer Protocol


EDITORS NOTE

   Mark Lotter receives full credit for all the good ideas in this memo.
   As RFC editor, i have made an number of format changes, a few wording
   changes, and one or two technical changes (mostly in the TYPEs).  I
   accept full responsibility for any flaws i may have introduced.

   A draft form of this memo was circulated for comments.  I will
   attempt to list the issues raised and summarize the pros and cons,
   and resolution for each.

      ASCII Commands vs Binary Operation Codes

         The ASCII command style is easier to debug, the extra
         programming cost in minimal, the extra transmission cost is
         trivial.

         Binary operation codes are more efficient, and a few days of
         debugging should not out weigh years of use.

         Resolution:  I have kept the ASCII Commands.

      Additional Modes

         Pro:  For some machines you can't send all the bits in a word
         using this protocol.  There should be some additional mode to
         allow it.

         Con:  Forget it, this is supposed to be SIMPLE file transfer.
         If you need those complex modes use real FTP.

         Resolution:  I have added the Continuous mode.

















Lottor                                                         [Page 14]



RFC 913                                                   September 1984
Simple File Transfer Protocol


      CRLF Conversion

         Pro:  In ASCII type, convert the local end of line indicator to
         CRLF on the way out of the host and onto the network.

         Con:  If you require that you have to look at the bytes as you
         send them, otherwise you can just send them.  Most of the time
         both sides will have the same end of line convention anyway.
         If someone needs a conversion it can be done with a TECO macro
         separately.

         Resolution:  I have required CRLF conversion in ASCII type.  If
         you have the same kind of machines and the same end of line
         convention you can avoid the extra cost of conversion by using
         the binary or continuous type.

      TCP Urgent

         Pro:  Use TCP Urgent to abort a transfer, instead of aborting
         the connection.  Then one could retry the file, or try a
         different file without having to login again.

         Con:  That would couple SFTP to TCP too much.  SFTP is supposed
         to be able to be work over any reliable 8-bit data stream.

         Resolution:  I have not made use of TCP Urgent.

      Random Access

         Pro:  Wouldn't it be nice if (WIBNIF) SFTP had a way of
         accessing parts of a file?

         Con:  Forget it, this is supposed to be SIMPLE file transfer.
         If you need random access use real FTP (oops, real FTP doesn't
         have random access either -- invent another protocol?).

         Resolution:  I have not made any provision for Random Access.

   -- jon postel.










Lottor                                                         [Page 15]