rfc765.txt

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

      NOTES: 1. The data connection may be used in either direction.
             2. The data connection need not exist all of the time.

                      Figure 1  Model for FTP Use

      In the model described in Figure 1, the user-protocol interpreter
      initiates the TELNET connection. At the initiation of the user,
      standard FTP commands are generated by the user-PI and transmitted
      to the server process via the TELNET connection.  (The user may
      establish a direct TELNET connection to the server-FTP, from a TIP
      terminal for example, and generate standard FTP commands himself,
      bypassing the user-FTP process.) Standard replies are sent from
      the server-PI to the user-PI over the TELNET connection in
      response to the commands.

      The FTP commands specify the parameters for the data connection
      (data port, transfer mode, representation type, and structure) and
      the nature of file system operation (store, retrieve, append,
      delete, etc.).  The user-DTP or its designate should "listen" on
      the specified data port, and the server initiate the data
      connection and data transfer in accordance with the specified
      parameters.  It should be noted that the data port need not be in




                                   6


                                                                        
IEN 149                                                        June 1980
RFC 765                                           File Transfer Protocol



      the same Host that initiates the FTP commands via the TELNET
      connection, but the user or his user-FTP process must ensure a
      "listen" on the specified data port.  It should also be noted that
      the data connection may be used for simultaneous sending and
      receiving.

      In another situation a user might wish to transfer files between
      two Hosts, neither of which is his local Host. He sets up TELNET
      connections to the two servers and then arranges for a data
      connection between them.  In this manner control information is
      passed to the user-PI but data is transferred between the server
      data transfer processes.  Following is a model of this
      server-server interaction.

      
                    TELNET     ------------    TELNET
                    ---------->| User-FTP |<-----------
                    |          | User-PI  |           |
                    |          |   "C"    |           |
                    V          ------------           V
            --------------                        --------------
            | Server-FTP |   Data Connection      | Server-FTP |
            |    "A"     |<---------------------->|    "B"     |
            --------------  Port (A)     Port (B) --------------
      

                                 Figure 2

      The protocol requires that the TELNET connections be open while
      data transfer is in progress.  It is the responsibility of the
      user to request the closing of the TELNET connections when
      finished using the FTP service, while it is the server who takes
      the action.  The server may abort data transfer if the TELNET
      connections are closed without command.

DATA TRANSFER FUNCTIONS

   Files are transferred only via the data connection.  The TELNET
   connection is used for the transfer of commands, which describe the
   functions to be performed, and the replies to these commands (see the
   Section on FTP Replies).  Several commands are concerned with the
   transfer of data between Hosts.  These data transfer commands include
   the MODE command which specify how the bits of the data are to be
   transmitted, and the STRUcture and TYPE commands, which are used to
   define the way in which the data are to be represented. The
   transmission and representation are basically independent but




                                   7


                                                                        
June 1980                                                        IEN 149
File Transfer Protocol                                           RFC 765



   "Stream" transmission mode is dependent on the file structure
   attribute and if "Compressed" transmission mode is used the nature of
   the filler byte depends on the representation type.

   DATA REPRESENTATION AND STORAGE

      Data is transferred from a storage device in the sending Host to a
      storage device in the receiving Host.  Often it is necessary to
      perform certain transformations on the data because data storage
      representations 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 system.  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.
      Transformations desired beyond this limited capability should be
      performed by the user directly.

      Data representations are handled in FTP by a user specifying a
      representation type.  This type may implicitly (as in ASCII or
      EBCDIC) or explicitly (as in Local byte) define a byte size for
      interpretation which is referred to as the "logical byte size."
      This has nothing to do with the byte size used for transmission
      over the data connection, called the "transfer byte size", and the
      two should not be confused.  For example, NVT-ASCII has a logical
      byte size of 8 bits.  If the type is Local byte, then the TYPE
      command has an obligatory second parameter specifying the logical
      byte size.  The transfer byte size is always 8 bits.





                                   8


                                                                        
IEN 149                                                        June 1980
RFC 765                                           File Transfer Protocol



      The types ASCII and EBCDIC also take a second (optional)
      parameter; this is to indicate what kind of vertical format
      control, if any, is associated with a file.  The following data
      representation types are defined in FTP:

         ASCII Format

            This is the default type and must be accepted by all FTP
            implementations.  It is intended primarily for the transfer
            of text files, except when both Hosts would find the EBCDIC
            type more convenient.

            The sender converts the data from his internal character
            representation to the standard 8-bit NVT-ASCII
            representation (see the TELNET specification).  The receiver
            will convert the data from the standard form to his own
            internal form.

            In accordance with the NVT standard, the <CRLF> sequence
            should be used, where necessary, to denote the end of a line
            of text.  (See the discussion of file structure at the end
            of the Section on Data Representation and Storage).

            Using the standard NVT-ASCII representation means that data
            must be interpreted as 8-bit bytes.

            The Format parameter for ASCII and EBCDIC types is discussed
            below.

         EBCDIC Format

            This type is intended for efficient transfer between Hosts
            which use EBCDIC for their internal character
            representation.

            For transmission the data are represented as 8-bit EBCDIC
            characters.  The character code is the only difference
            between the functional specifications of EBCDIC and ASCII
            types.

            End-of-line (as opposed to end-of-record--see the discussion
            of structure) will probably be rarely used with EBCDIC type
            for purposes of denoting structure, but where it is
            necessary the <NL> character should be used.






                                   9


                                                                        
June 1980                                                        IEN 149
File Transfer Protocol                                           RFC 765



      A character file may be transferred to a Host for one of three
      purposes: for printing, for storage and later retrieval, or for
      processing.  If a file is sent for printing, the receiving Host
      must know how the vertical format control is represented.  In the
      second case, it must be possible to store a file at a Host and
      then retrieve it later in exactly the same form.  Finally, it
      ought to be possible to move a file from one Host to another and
      process the file at the second Host without undue trouble.  A
      single ASCII or EBCDIC format does not satisfy all these
      conditions and so these types have a second parameter specifying
      one of the following three formats:

         Non-print

            This is the default format to be used if the second (format)
            parameter is omitted.  Non-print format must be accepted by
            all FTP implementations.

            The file need contain no vertical format information.  If it
            is passed to a printer process, this process may assume
            standard values for spacing and margins.

            Normally, this format will be used with files destined for
            processing or just storage.

         TELNET Format Controls

            The file contains ASCII/EBCDIC vertical format controls
            (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer
            process will interpret appropriately.  <CRLF>, in exactly
            this sequence, also denotes end-of-line.

         Carriage Control (ASA)

            The file contains ASA (FORTRAN) vertical format control
            characters.  (See RFC 740 Appendix C and Communications of
            the ACM, Vol. 7, No. 10, 606 (Oct. 1964)).  In a line or a
            record, formatted according to the ASA Standard, the first
            character is not to be printed.  Instead it should be used
            to determine the vertical movement of the paper which should
            take place before the rest of the record is printed.









                                   10


                                                                        
IEN 149                                                        June 1980
RFC 765                                           File Transfer Protocol



            The ASA Standard specifies the following control characters:

               Character     Vertical Spacing

               blank         Move paper up one line
               0             Move paper up two lines
               1             Move paper to top of next page
               +             No movement, i.e., overprint

            Clearly there must be some way for a printer process to
            distinguish the end of the structural entity.  If a file has
            record structure (see below) this is no problem; records
            will be explicitly marked during transfer and storage.  If
            the file has no record structure, the <CRLF> end-of-line
            sequence is used to separate printing lines, but these
            format effectors are overridden by the ASA controls.

         Image

            The data are sent as contiguous bits which, for transfer,
            are packed into the 8-bit transfer bytes.  The receiving
            site must store the data as contiguous bits.  The structure
            of the storage system might necessitate the padding of the
            file (or of each record, for a record-structured file) to
            some convenient boundary (byte, word or block).  This
            padding, which must be all zeros, may occur only at the end
            of the file (or at the end of each record) and there must be
            a way of identifying the padding bits so that they may be
            stripped off if the file is retrieved.  The padding
            transformation should be well publicized to enable a user to
            process a file at the storage site.

            Image type is intended for the efficient storage and
            retrieval of files and for the transfer of binary data.  It
            is recommended that this type be accepted by all FTP
            implementations.

         Local byte Byte size

            The data is transferred in logical bytes of the size
            specified by the obligatory second parameter, Byte size.
            The value of Byte size must be a decimal integer; there is
            no default value.  The logical byte size is not necessarily
            the same as the transfer byte size.  If there is a






                                   11