rfc765.txt

中、英文RFC文档大全打包下载完全版 .

June 1980                                                        IEN 149
File Transfer Protocol                                           RFC 765



            difference in byte sizes, then the logical bytes should be
            packed contiguously, disregarding transfer byte boundaries
            and with any necessary padding at the end.

            When the data reaches the receiving Host it will be
            transformed in a manner dependent on the logical byte size
            and the particular Host.  This transformation must be
            invertible (that is an identical file can be retrieved if
            the same parameters are used) and should be well publicized
            by the FTP implementors.

            For example, a user sending 36-bit floating-point numbers to
            a Host with a 32-bit word could send his data as Local byte
            with a logical byte size of 36.  The receiving Host would
            then be expected to store the logical bytes so that they
            could be easily manipulated; in this example putting the
            36-bit logical bytes into 64-bit double words should
            suffice.

            Another example, a pair of hosts with a 36-bit word size may
            send data to one another in words by using TYPE L 36.  The
            data would be sent in the 8-bit transmission bytes packed so
            that 9 transmission bytes carried two host words.

      A note of caution about parameters:  a file must be stored and
      retrieved with the same parameters if the retrieved version is to
      be identical to the version originally transmitted.  Conversely,
      FTP implementations must return a file identical to the original
      if the parameters used to store and retrieve a file are the same.

      In addition to different representation types, FTP allows the
      structure of a file to be specified.  Three file structures are
      defined in FTP:

         file-structure, where there is no internal structure and the
                           file is considered to be a continuous
                           sequence of data bytes,

         record-structure, where the file is made up of sequential
                           records,

         and page-structure, where the file is made up of independent
                           indexed pages.

      File-structure is the default, to be assumed if the STRUcture
      command has not been used but both file and record structures must




                                   12


                                                                        
IEN 149                                                        June 1980
RFC 765                                           File Transfer Protocol



      be accepted for "text" files (i.e., files with TYPE ASCII or
      EBCDIC) by all FTP implementations.  The structure of a file will
      affect both the transfer mode of a file (see the Section on
      Transmission Modes) and the interpretation and storage of the
      file.

      The "natural" structure of a file will depend on which Host stores
      the file.  A source-code file will usually be stored on an IBM 360
      in fixed length records but on a PDP-10 as a stream of characters
      partitioned into lines, for example by <CRLF>.  If the transfer of
      files between such disparate sites is to be useful, there must be
      some way for one site to recognize the other's assumptions about
      the file.

      With some sites being naturally file-oriented and others naturally
      record-oriented there may be problems if a file with one structure
      is sent to a Host oriented to the other.  If a text file is sent
      with record-structure to a Host which is file oriented, then that
      Host should apply an internal transformation to the file based on
      the record structure.  Obviously this transformation should be
      useful but it must also be invertible so that an identical file
      may be retrieved using record structure.

      In the case of a file being sent with file-structure to a
      record-oriented Host, there exists the question of what criteria
      the Host should use to divide the file into records which can be
      processed locally.  If this division is necessary the FTP
      implementation should use the end-of-line sequence, <CRLF> for
      ASCII, or <NL> for EBCDIC text files, as the delimiter.  If an FTP
      implementation adopts this technique, it must be prepared to
      reverse the transformation if the file is retrieved with
      file-structure.

      Page Structure

         To transmit files that are discontinuous FTP defines a page
         structure.  Files of this type are sometimes know as "random
         access files" or even as "holey files".  In these files there
         is sometimes other information associated with the file as a
         whole (e.g., a file descriptor), or with a section of the file
         (e.g., page access controls), or both.  In FTP, the sections of
         the file are called pages.

         To provide for various page sizes and associated information
         each page is sent with a page header.  The page header has the
         following defined fields:




                                   13


                                                                        
June 1980                                                        IEN 149
File Transfer Protocol                                           RFC 765



            Header Length

               The number of logical bytes in the page header including
               this byte.  The minimum header length is 4.

            Page Index

               The logical page number of this section of the file.
               This is not the transmission sequence number of this
               page, but the index used to identify this page of the
               file.

            Data Length

               The number of logical bytes in the page data.  The
               minimum data length is 0.

            Page Type

               The type of page this is.  The following page types are
               defined:

                  0 = Last Page

                     This is used to indicate the end of a paged
                     structured transmission.  The header length must be
                     4, and the data length must be 0.

                  1 = Simple Page

                     This is the normal type for simple paged files with
                     no page level associated control information.  The
                     header length must be 4.

                  2 = Descriptor Page

                     This type is used to transmit the descriptive
                     information for the file as a whole.

                  3 = Access Controled Page

                     This is type includes an additional header field
                     for paged files with page level access control
                     information.  The header length must be 5.






                                   14


                                                                        
IEN 149                                                        June 1980
RFC 765                                           File Transfer Protocol



            Optional Fields

               Further header fields may be used to supply per page
               control information, for example, per page access
               control.

         All fields are one logical byte in length.  The logical byte
         size is specified by the TYPE command.

   ESTABLISHING DATA CONNECTIONS

      The mechanics of transferring data consists of setting up the data
      connection to the appropriate ports and choosing the parameters
      for transfer.  Both the user and the server-DTPs have a default
      data port.  The user-process default data port is the same as the
      control connection port, i.e., U.  The server-process default data
      port is the port adjacent to the control connection port, i.e.,
      L-1.

      The transfer byte size is 8-bit bytes.  This byte size is relevant
      only for the actual transfer of the data; it has no bearing on
      representation of the data within a Host's file system.

      The passive data transfer process (this may be a user-DTP or a
      second server-DTP) shall "listen" on the data port prior to
      sending a transfer request command.  The FTP request command
      determines the direction of the data transfer.  The server, upon
      receiving the transfer request, will initiate the data connection
      to the port.  When the connection is established, the data
      transfer begins between DTP's, and the server-PI sends a
      confirming reply to the user-PI.

      It is possible for the user to specify an alternate data port by
      use of the PORT command.  He might want a file dumped on a TIP
      line printer or retrieved from a third party Host.  In the latter
      case the user-PI sets up TELNET connections with both server-PI's.
      One server is then told (by an FTP command) to "listen" for a
      connection which the other will initiate.  The user-PI sends one
      server-PI a PORT command indicating the data port of the other.
      Finally both are sent the appropriate transfer commands.  The
      exact sequence of commands and replies sent between the
      user-controller and the servers is defined in the Section on FTP
      Replies.

      In general it is the server's responsibility to maintain the data
      connection--to initiate it and to close it.  The exception to this




                                   15


                                                                        
June 1980                                                        IEN 149
File Transfer Protocol                                           RFC 765



      is when the user-DTP is sending the data in a transfer mode that
      requires the connection to be closed to indicate EOF.  The server
      MUST close the data connection under the following conditions:

         1. The server has completed sending data in a transfer mode
            that requires a close to indicate EOF.

         2. The server receives an ABORT command from the user.

         3. The port specification is changed by a command from the
            user.

         4. The TELNET connection is closed legally or otherwise.

         5. An irrecoverable error condition occurs.

      Otherwise the close is a server option, the exercise of which he
      must indicate to the user-process by an appropriate reply.

   TRANSMISSION MODES

      The next consideration in transferring data is choosing the
      appropriate transmission mode.  There are three modes: one which
      formats the data and allows for restart procedures; one which also
      compresses the data for efficient transfer; and one which passes
      the data with little or no processing.  In this last case the mode
      interacts with the structure attribute to determine the type of
      processing.  In the compressed mode the representation type
      determines the filler byte.

      All data transfers must be completed with an end-of-file (EOF)
      which may be explicitly stated or implied by the closing of the
      data connection.  For files with record structure, all the
      end-of-record markers (EOR) are explicit, including the final one.
      For files transmitted in page structure a "last-page" page type is
      used.

      NOTE:  In the rest of this section, byte means "transfer byte"
      except where explicitly stated otherwise.

      For the purpose of standardized transfer, the sending Host will
      translate his internal end of line or end of record denotation
      into the representation prescribed by the transfer mode and file
      structure, and the receiving Host will perform the inverse
      translation to his internal denotation.  An IBM 360 record count
      field may not be recognized at another Host, so the end of record




                                   16


                                                                        
IEN 149                                                        June 1980
RFC 765                                           File Transfer Protocol



      information may be transferred as a two byte control code in
      Stream mode or as a flagged bit in a Block or Compressed mode
      descriptor. End of line in an ASCII or EBCDIC file with no record
      structure should be indicated by <CRLF> or <NL>, respectively.
      Since these transformations imply extra work for some systems,
      identical systems transferring non-record structured text files
      might wish to use a binary representation and stream mode for the
      transfer.

      The following transmission modes are defined in FTP:

         STREAM

            The data is transmitted as a stream of bytes.  There is no
            restriction on the representation type used; record
            structures are allowed.

            In a record structured file EOR and EOF will each be
            indicated by a two-byte control code.  The first byte of the
            control code will be all ones, the escape character.  The
            second byte will have the low order bit on and zeros
            elsewhere for EOR and the second low order bit on for EOF;
            that is, the byte will have value 1 for EOR and value 2 for
            EOF.  EOR and EOF may be indicated together on the last byte
            transmitted by turning both low order bits on, i.e., the
            value 3.  If a byte of all ones was intended to be sent as