rfc454.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   time are record structures.  However, the use of record structures is
   not mandatory.  A user with no record structure in his file should be



McKenzie                                                       [Page 11]

RFC 454                  File Transfer Protocol                July 1972


   able to store and retrieve his file at any HOST.  A user wishing to
   transmit a record structured file must send the appropriate FTP
   'STRU' command (the default assumption is no record structure).  A
   serving HOST need not accept record structures, but it must inform
   the user of this fact by sending an appropriate reply.  Any record
   structure information in the data stream may subsequently be dis-
   carded by the receiver.

   All data transfers must end with an EOF.  The EOF is defined by the
   data transfer mode.  For files that have record structures, an EOR is
   also defined by the transfer mode.  Only the transfer modes and
   representation type combinations that have EOR defined may be used
   for transfer of files with record structures.  Records may be of zero
   length but they must be contained in file boundaries.  The relation-
   ship between files and records is hierarchical but an EOF does not
   imply an EOR.

   The following data transfer modes are defined in FTP:

   1. Stream       The file is transmitted as a stream of bytes of the
                   specified byte size.  The EOF is signaled by closing
                   the data connection.  Any representation type and
                   byte size may be used in the stream mode with file
                   structure, but use of record structure limits the
                   type to ASCII or EBCDIC with or without Printfile
                   format.  The convention is that the ASCII character
                   CR (Carriage Return, Code 15 (octal)) followed by LF
                   (Line Feed, Code 12 (octal)) indicates an EOR for
                   ASCII representation type, and the EBCDIC character
                   NL (New Line, Code 15 (hex)) indicates an EOR for
                   EBCDIC type.  This is the default mode, and it is
                   recommended that this mode be implemented by all.

   2. Text         The file is ASCII text transmitted as a sequence of
                   8-bit bytes in the ASCII representation type, and
                   optional Printfile format.  Record structures are
                   allowed in this mode.  The EOR and EOF are defined by
                   the presence of special "TELNET-control" codes (,ost
                   significant bit set to one) in the data stream.  The
                   EOR code is 192 (octal 300, hex CO).  The EOF code is
                   193 (octal 301, hex C1).  The byte size for transfer
                   is 8 bits.

   (For ASCII type, text and stream modes are almost identical.)







McKenzie                                                       [Page 12]

RFC 454                  File Transfer Protocol                July 1972


   Comparing the two, the advantages of "stream" mode are:

      1) The receiver need not scan the incoming bytes.

      2) It is usable with all data types.

   and the disadvantages are:
      1) Closing the data connection under error conditions can be
         misconstrued as an EOF in stream mode when in fact the data
         transfer was interrupted.  In text mode the EOF is sent expli-
         citly.

      2) If record structure is specified in stream mode then CRLF
         implies EOR, and in order for CRLF to be sent as valid data it
         must be transformed, e.g., into CR NUL LF or LF CR.

   3. Block        The file is transmitted as a series of data blocks
                   preceded by one or more header bytes.  The header
                   bytes contain a count field, and descriptor code.
                   The count field indicates the total length of the
                   data block in bytes, thus marking the beginning of
                   the next data block (there are no filler bits).  The
                   descriptor code defines last file block (EOF), last
                   record block (EOR), restart marker (see Section
                   III.D), or suspect data (i.e., the data being
                   transferred is suspected of errors and is not reli-
                   able).  Record structures are allowed in this mode,
                   and any representation type or byte size may be used.

                   The header consists of the smallest integral number
                   of bytes whose length is greater than or equal to 24
                   bits.  Only the _least_ significant 24 bits (right-
                   justified) of header shall have information; the
                   remaining most significant bits are "don't care"
                   bits.  Of the 24 bits of header information, the 16
                   low order bits shall represent byte count, and the 8
                   high order bits shall represent descriptor codes as
                   shown below.

                            Integral data bytes >= 24
                   +---------------+---------------+--------------+
                   | Don't care    |   Descriptor  |  Byte Count  |
                   | 0 to 231 bits |     8 bits    |    16 bits   |
                   +---------------+---------------+--------------+







McKenzie                                                       [Page 13]

RFC 454                  File Transfer Protocol                July 1972


                   The following descriptor codes are assigned:

                   Code       Meaning
                   ----       -------
                    0         An ordinary block of data.
                    1         End of data block is EOR.
                    2         End of data block is EOF.
                    3         Suspected errors in data block.
                    4         Data block is a restart marker.

                   In the use of block mode it is possible for two or
                   more conditions requiring different descriptor codes
                   (suspected errors and either end of record or end of
                   file) to exist simultaneously.  Such a possibility
                   may be handled by sending a separate EOR or EOF block
                   with a zero byte count. (This is allowed by the pro-
                   tocol.)

                   The restart marker is embedded in the data stream as
                   an integral number of 8-bit bytes (representing
                   printable ASCII characters) right-justified in an
                   integral number of data bytes greater than 8 bits.
                   For example if the byte size is 7 bits, the restart
                   marker byte would be one byte right-justified per two
                   7-bit bytes as shown below:

                        Two 7-bit bytes
                   +----------+------------+
                   |          | Marker Char|
                   |          |    8 bits  |
                   +----------+------------+

                   For byte size of 16 bits or more, two or more marker
                   bytes shall be packed right-justified.  The end of
                   the marker may be delimited by the character SP (code
                   32.).  If marker characters do not exactly fit an
                   integral byte, the unused character slots should con-
                   tain the ASCII character SP (code 32.).  For example,
                   to transmit a six character marker in a 36-bit byte
                   size, the following three 36-bit bytes would be sent:











McKenzie                                                       [Page 14]

RFC 454                  File Transfer Protocol                July 1972


                   +-------------+-------------+---------------+
                   | Don't care  | Descriptor  |               |
                   |    12 bits  |  code=4     | Byte count=2  |
                   +-------------+-------------+---------------+

                   +----+---------+---------+--------+---------+
                   |    | Marker  | Marker  | Marker | Marker  |
                   |    | 8 bits  | 8 bits  | 8 bits | 8 bits  |
                   +----+---------+---------+--------+---------+

                   +----+---------+---------+--------+---------+
                   |    | Marker  | Marker  | SP     | SP      |
                   |    | 8 bits  | 8 bits  | 8 bits | 8 bits  |
                   +----+---------+---------+--------+---------+

   4. Hasp

                   The file is transmitted as a sequence of 8-bit bytes
                   in the standard Hasp-compressed data format (document
                   to be issued by Bob Braden, UCLA).  This mode
                   achieves considerable compression of data for print
                   files.  Record structures are allowed in the Hasp
                   mode.

   The following matrix summarizes the legal combinations of file
   transfer parameters.  The decimal integers represent legal byte sizes
   for each particular STRU-MODE-TYPE-FORM grouping absence of a number
   implies illegality.  Note that HASP mode is not included since it has
   never been defined.

           STRU           F               |        R
          +-------------------------------+-----+-----+------+
   TYPE   |\ MODE                         |     |     |      |
          |  \                            |     |     |      |
          |    \     S       T       B    |  S  |   T |   B  |
          | FORM +--------+-----+---------+-----+-----+------+
       A  |   U  |   8    |  8  |    8    |  8  |   8 |   8  |
          |      +--------+-----+---------+-----+-----+------+
          |   P  |   8    |  8  |    8    |  8  |   8 |   8  |
      ----+------+--------+-----+---------+-----+-----+------+
      E   |   U  |   8    |     |    8    |  8  |     |   8  |
          |      +--------+-----+---------+-----+-----+------+
          |   P  |   8    |     |    8    |  8  |     |   8  |
      ----+------+--------+-----+---------+-----+-----+------+
      I   |   U  | 1-255  |     | 1-255   |     |     |1-255 |
      ----+------+--------+-----+---------+-----+-----+------+
      L   |   U  | 1-255  |     | 1-255   |     |     |1-255 |
      ----+------+--------+-----+---------+-----+-----+------+



McKenzie                                                       [Page 15]

RFC 454                  File Transfer Protocol                July 1972


III.D  Error Recovery and Restart

   There is no provision for detecting bits lost or scrambled in data
   transfer.  This issue is perhaps handled best at the NCP level where
   it benefits most users.  However, a restart procedure is provided to
   protect user from system failures (such as failure of either HOST,
   FTP-process, or the IMP subnet).

   The restart procedure is defined only for the block mode of data
   transfer.  It requires the sender of data to insert a special marker
   code in the data stream with some marker information.  The marker
   information has meaning only to the sender, but must consist of
   printable ASCII characters.  The printable ASCII characters are
   defined to be octal codes 41 through 176 (i.e., not including codes 0
   through 37 and the characters SP and DEL).  The marker could
   represent a bit-count, a record-count, or any other information by
   which a system may identify a data checkpoint.  The receiver of data,
   if it implements the restart procedure, would then mark the
   corresponding position of this marker in the receiving system, and
   return this information to the user.

   In the event of a system failure, the user can restart the data
   transfer by identifying the marker point with the FTP restart pro-
   cedure.  The following examples illustrate the use of the restart
   procedure.

1.     When server is the sender of data, the server-FTP process inserts
       an appropriate marker block in the data stream at a convenient
       data point.  The user-FTP process, receiving the data, marks the
       corresponding data point in its file system and conveys the last
       known sender and receiver marker information to the user.  In the
       event of system failure, the user or user-FTP process restarts
       the server at the last server marker by sending a restart command
       with the server's marker code as its argument.  The restart com-
       mand is transmitted over the TELNET connection and is immediately
       followed by the command (such as store or retrieve) which was
       being executed when the system failure occurred.

2.     When user is the sender of data, the user-FTP process inserts the
       appropriate marker block in the data stream.  The server-FTP pro-
       cess, receiving the data, marks the corresponding data point in
       its file system.  The server does not store this marker but con-
       veys the last known sender and receiver marker information to the
       user over the TELNET connections by appropriate reply codes.  The
       user or the user-FTP process then restarts transfer in a manner
       identical to that described in the first example.





McKenzie                                                       [Page 16]

RFC 454                  File Transfer Protocol                July 1972


IV.  FILE TRANSFER FUNCTIONS

   The TELNET connections on which FTP commands and replies are
   transmitted are initiated by the user-FTP process via an ICP to a
   standard server socket.  FTP commands are then transmitted from user
   to server, and replies are transmitted from server to user.  The user
   file transfer functions involve sending the FTP commands, interpret-
   ing the replies received and transferring data over the data connec-
   tion in the specified manner.  The server file transfer functions
   involve accepting and interpreting FTP commands, sending replies,
   setting up the data connection, and transferring data.