rfc454.txt

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

                       2) a site where a user-FTP process is located, 3)
                       a site to which a data connection is made by a
                       server.  In the normal case, the sites defined by
                       1, 2, and 3 are the same site, but nothing in FTP
                       requires that this be so.

   user-FTP process    A process or set of processes which perform the
                       function of file transfer in cooperation with a
                       server-FTP process.  The user-FTP process 1)
                       initiates the ICP (via a user-TELNET), 2)
                       initiates FTP commands and 3) "listens" on the
                       data socket for the data connection.  In some
                       obvious cases (use from TIPs and other mini-
                       HOSTs) a user-FTP process will be subsumed under
                       the term "user".

   user-TELNET         A TELNET process which initiates an ICP to a
                       specified server-TELNET socket, and performs in
                       accordance with the ARPANET TELNET protocol.

II.B  The FTP Model

   With the above definitions in mind, the following model (shown in
   Figure 1) may be diagramed for an FTP service.

   In the model described in Figure 1, the user-TELNET initiates the
   TELNET connections.  Standard FTP commands are then generated by the
   user and transmitted to the server site via the TELNET connections.
   FTP commands are in ASCII, in accordance with NVT conventions and the
   TELNET protocol.  Note that commands may be initiated by the user
   directly through the user-TELNET or via a user-FTP process.  Standard
   replies are sent from the server to the user in response to the
   commands over the TELNET connections.






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


   The FTP commands specify the parameters for the data connection (data
   socket, byte size, transfer mode, representation type, and format)
   and the nature of file system operation (store, retrieve, append,
   delete, etc.). The user-FTP process or its designate should "listen"
   on the specified data socket, and it is the server's responsibility
   to initiate the data connection and data transfer in accordance with
   the specified data connection parameters.  It should be noted that
   the data socket need not be in the same HOST that initiates the FTP
   commands via the TELNET connections, but the user or his user-FTP
   process must ensure a "listen" on the specified data socket.  A
   practical example of such file transfer to third HOSTs is a maxi-HOST
   user (who may actually be a TIP user) wishing to transmit a file to
   or from an I/O device attached to a TIP.  It should also be noted
   that two data connections, one for send and the other for receive,
   may exist simultaneously.

                                TELNET
                              Connections
+-----+   +-------+   +------+           +------+   +-------+   +-----+
| File|<->|Server-|<->|Server|<----------|User  |<->|User-  |<->|File |
|Sys  |   |FTP    |   |TELNET|  FTP Cmds |TELNET|   |FTP    |   |Sys- |
| -tem|   |Process|   |      |---------->|      |   |Process|   | tem |
+-----+   |       |   +------+FTP Replies+------+   |       |   +-----+
          |       |                                 |       |
          |       |<------------------------------->|Data   |
          |       |         Data Connection(s)      |Socket |
          +-------+                                 +-------+
                                                        |
                                                        |
                                                    +------+
                                                    |      |
                                                    | USER |
                                                    |      |
                                                    +------+

   Notes:  1.  The data connection may be in either direction.

           2. The data connection need not exist all of the time.

           3. The distinctions between user-FTP and user-TELNET, and
               between server-FTP and server-TELNET may not be as
               clear-cut as shown above.  For example, a user-TELNET may
               be directly driven by the user.

               FIGURE 1  Model for FTP Use






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


   The protocol requires that the TELNET connections be open while data
   transfer is in progress.  It is the responsibility of the user to
   close the TELNET connections when finished using the FTP service.
   The server may abort data transfer if the TELNET connections are
   closed.

III.  DATA TRANSFER FUNCTIONS

   Data and files are transferred only via the data connection.  The
   transfer of data is governed by FTP data transfer commands received
   on the TELNET connections.  The data transfer functions include
   establishing the data connection to the specified data socket in the
   specified HOST (using the specified byte size), transmitting and
   receiving data in the specified representation type and transfer
   mode, handling EOR and EOF conditions, and error recovery (where
   applicable).

III.A  Establishing Data Connection

   The user site shall "listen" on the specified data socket, prior to
   sending a transfer request command.  The FTP request command
   determines the direction of data transfer, and the socket number (odd
   or even) which is to be used in establishing the data connection.
   The server on receiving the appropriate store or retrieve request
   shall initiate the data connection to the specified user data socket
   in the specified byte size (default byte size is 8 bits), and send a
   reply indicating that file transfer may proceed.  Prior to this
   reply, the server should send a reply indicating the server socket
   for the data connection.  The user may use this server socket
   information to ensure the security of his data transfer.  The server
   may send this reply either before or after initiating the data
   connection.

   The byte size for the data connection is specified by the BYTE
   command.  It is not required by the protocol that servers accept all
   possible byte sizes.  The use of various byte sizes is for efficiency
   in data transfer and servers may implement only those byte sizes for
   which their data transfer is efficient.  It is, however, required
   that servers implement at least the byte size of 8 bits.

   After the data transfer is completed, it is the server's
   responsibility to close the data connection, except when the user is
   sending the data.  In stream mode the sender must close the data
   connection to indicate EOF, i.e., completion of the transfer.
   Closing the connection is a server option except under the following
   conditions:





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


   1)       The server receives an abort command from the user.

   2)       The socket or the byte size specification is changed by the
            user.

   3)       The TELNET connections are closed.

   4)       An irrecoverable error condition occurs.

   It should be noted that if none of the above conditions occur it is
   possible to maintain two simultaneous data connections, for send and
   receive.

III.B  Data Representation and Storage

   Data is transferred from a storage device in sending HOST to a
   storage device in receiving HOST.  Often it is necessary to perform
   certain transformations on the data because data storage representa-
   tions in the two systems are different.  For example, NVT-ASCII has
   different data storage representations in different systems.  PDP-10'
   s generally store NVT-ASCII as five 7-bit ASCII characters, left-
   justified in a 36-bit word. 360's store NVT-ASCII as 8-bit EBCDIC
   codes.  Multics stores NVT-ASCII as four 9-bit characters in a 36-bit
   word.  It may be desirable to convert characters into the standard
   NVT-ASCII representation when transmitting text between dissimilar
   systems.  The sending and receiving sites would have to perform the
   necessary transformations between the standard representation and
   their internal representations.

   A different problem in representation arises when transmitting binary
   data (not character codes) between HOST systems with different word
   lengths.  It is not always clear how the sender should send data, and
   the receiver store it.  For example, when transmitting 32-bit bytes
   from a 32-bit word-length system to a 36-bit word-length system, it
   may be desirable (for reasons of efficiency and usefulness) to store
   the 32-bit bytes right-justified in a 36-bit word in the latter sys-
   tem.  In any case, the user should have the option of specifying data
   representation and transformation functions.  It should be noted that
   FTP provides for very limited data type representations.  Transforma-
   tions desired beyond this limited capability should be performed by
   the user directly or via the use of the Data Reconfiguration (DRS,
   RFC #138, NIC #6715).  Additional representation types may be defined
   later if there is a demonstrable need.

   Data representations are handled in FTP by a user specifying a
   representation type.  The type may also imply a transfer byte size.
   For example, in ASCII representation, the transfer byte size should
   be 8 bits, and any other byte size specification will result in



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


   cancellation of the transfer request.  In image and Local Byte
   representations any byte size is possible.  The following data
   representation types are currently defined in FTP:

   1. ASCII        The sender converts data from its internal character
                   representation to the standard NVT ASCII form.  The
                   receiver converts the data from the standard form to
                   its own internal form.  The data is transferred in
                   the standard form.  The transfer byte size must be 8
                   bits.  This type would be used for transfer of text
                   files.  This is the default type, and it is recom-
                   mended that this type be implemented by all.

   2. EBCDIC       The sender transfers data using the EBCDIC character
                   code and 8-bit transfer byte size.  This type may be
                   used for efficient transfer of EBCDIC files between
                   systems which use EBCDIC for their internal character
                   representation.

   3. Image        The sender transforms data from contiguous bits to
                   bytes for transfer.  The receiver transforms the
                   bytes into bits, storing them contiguously indepen-
                   dent of the byte size chosen for data transfer.  With
                   record structure and block mode, the server might
                   need to pad each record for convenient storage.  This
                   padding is allowed at the end of a record, and should
                   be remembered by the server so it will be stripped
                   off when the file is retrieved by the user.  The pad-
                   ding transformation should be well publicized by the
                   server in case the user processes his file at the
                   server site.  Typical uses for the Image type are
                   transfer of executable programs between like
                   machines, and transfer of binary (non-text) data.  It
                   is recommended that this type be implemented by all
                   for some byte size, preferably including the 8 bit
                   byte size.

   4. Local Byte   This representation allows for efficient storage,
                   use, and retrieval of data.  The manner in which data
                   is to be transformed depends on the byte size for
                   data transfer, and the particular HOST being used.
                   The transformation scheme for different byte size is
                   to be well publicized by all server sites.  This
                   transformation shall be invertible (i.e., if a file
                   is stored using a certain transfer byte size, an
                   identical file must be retrievable using the same
                   byte size and representation type).  It is the user's
                   responsibility to keep track of the representation



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


                   type and byte size used for his transfer.  Typical
                   uses of the Local Byte type are in efficient storage
                   and retrieval of files, and transfer of structured
                   binary data.  This type may be identical to the Image
                   type for byte size which are integral multiples of or
                   factors of the computer word length.

   Representation type may also be affected by another attribute, the
   format.  For example, some printers can use ASA (Fortran) vertical
   format control procedures to transform printed data of type ASCII or
   EBCDIC.  Currently format may take one of two values.

   1. Unformatted  The representation type as specified is unaffected by
                   any format transformations.  This is the default
                   value.

   2. Printfile    The server is to transform data of either ASCII or
                   EBCDIC type in accordance with ASA (Fortran) vertical
                   format control standards.  The data is to be
                   transferred in 8-bit bytes.

   A discussion of the ASA vertical format control appears in NWG/RFC
   189, Appendix C, and in Communications of the ACM, Vol. 7, No. 10, p.
   606, October 1964.  According to the ASA vertical format control
   standards, the first character of a formatted record is not printed
   but determines vertical spacing as follow:

      Character                  Vertical Spacing before printing

       Blank                       One line