home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 100s / rfc172.txt < prev    next >
Text File  |  1997-05-21  |  21KB  |  676 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                           23 June 1971
  8. Request for Comments #172                       Abhay Bhushan, MIT
  9. NIC 6794                                        Bob Braden, UCLA
  10. Categories: D.4, D.5, and D.7                   Will Crowther, BBN
  11. Updates: 114                                    Eric Harslem, Rand
  12. Obsolete: None                                  John Heafner, Rand
  13.                                                 Alex McKenzie, BBN
  14.                                                 John Melvin, SRI
  15.                                                 Bob Sundberg, Harvard
  16.                                                 Dick Watson, SRI
  17.                                                 Jim White, UCSB
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.                     THE FILE TRANSFER PROTOCOL
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. NWG/RFC 172
  61.  
  62.  
  63. I. INTRODUCTION
  64.  
  65.       The file transfer protocol (FTP) is a user-level protocol for file
  66. transfer between host computers (including terminal IMP's), on the ARPA
  67. computer network. The primary function of FTP is to facilitate transfer
  68. of files between hosts, and to allow convenient use of storage and file
  69. handling capabilities of other hosts. FTP uses the data transfer
  70. protocol described in RFC 171 to achieve transfer of data. This paper
  71. assumes knowledge of RFC 171.
  72.  
  73.       The objectives of FTP are to promote sharing of files (computer
  74. programs and/or data), encourage indirect use (without login or
  75. implicit) of computers, and shield the user from variations in file and
  76. storage systems of different hosts, to the extent it is practical.
  77. These objectives are achieved by specifying a standard file transfer
  78. socket and initial connection protocol for indirect use, and using
  79. standard conventions for file transfer and related operations.
  80.  
  81. II. DISCUSSION
  82.  
  83.       A file is considered here to be an ordered set of arbitrary
  84. length, consisting of computer (including instructions) data. Files are
  85. uniquely identified in a system by their pathnames. A pathname is
  86. (loosely) defined to be the data string which must be input to the file
  87. system by a network user in order to identify a file. Pathname usually
  88. contains device and/or directory names, and file names in case of named
  89. files. FTP specifications provide standard file system commands, but do
  90. not provide standard naming convention at this time.  Each user must
  91. follow the naming convention of the file system he wishes to use. FTP
  92. may be extended later to include standard conventions for pathname
  93. structures.[1]
  94.  
  95.       A file may or may not have access controls associated with it.
  96. The access controls designate the users' access privilege. In the
  97. absence of access controls, the files cannot be protected from
  98. accidental or unauthorized usage. It is the prerogative of a resident
  99. file system to provide protection, and selective access. FTP only
  100. provides identifier and password mechanisms for exchange of access
  101. control information. It should however be noted, that for file sharing,
  102. it is necessary that a user be allowed (subject to access controls) to
  103. access files not created by him.
  104.  
  105.       FTP does not restrict the nature of information in the file. For
  106. example, a file could contain ASCII text, binary data computer program,
  107. or any other information. A provision for indicating data structure
  108. (type and byte size) exists in FTP to aid in parsing, interpretation,
  109. reconfiguration, and storage of data. To facilitate indirect usage, the
  110. cooperating file transfer processes may be disowned "daemon" processes
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. NWG/RFC 172
  117.  
  118.  
  119. which "listen" to agreed-upon sockets, and follow the standard initial
  120. connection protocol for establishing a full-duplex connection. It should
  121. be noted that FTP could also used directly by logging into a remote
  122. host, and arranging for file transfer over specific sockets.
  123.  
  124.       FTP is readily extensible, in that additional commands and data
  125. types may be defined by those agreeing to implement them.
  126. Implementation of a subset of commands is specifically permitted, and an
  127. initial subset for implementation is recommended.[2] The protocol may
  128. also be extended to enable remote execution of programs, but no standard
  129. procedure is suggested.
  130.  
  131.       For transferring data, FTP uses the data transfer protocol
  132. specified in RFC 171. As the data transfer protocol does not specify the
  133. manner in which it is to be used by FTP, implementation may vary at
  134. different host sites. Hosts not wishing to separate the data transfer
  135. and file transfer functions, should take particular care in conforming
  136. to the data transfer protocol specifications of RFC 171.
  137.  
  138.       It should be noted, that FTP specifications do not require
  139. knowledge of transfer modes used by data transfer protocol. However, as
  140. file transfer protocol requires the transfer of more than a single
  141. control transaction over the same connection, it is essential that hosts
  142. be able to send control transactions in either 'transparent block' (type
  143. B9) of 'descriptor and counts' (type BA) modes. (Type BB, the indefinite
  144. bit stream mode is not suitable as it limits transfer to singles
  145. transactions.).
  146.  
  147.       The use of data transfer aborts (type B6) is neither required, nor
  148. defined in FTP. FTP has its own error terminate which may be used to
  149. abort a file transfer request. FTP also does not define the structure of
  150. files, and there are no conventions on the use of group, record and unit
  151. separators.[3] A file separator is, however, used to indicate the end of
  152. file. It is strongly recommended that default options be provided in
  153. implementation to facilitate use of file transfer service. For example,
  154. the main file directory on disk, a pool directory, user directory or
  155. directory last accessed could serve as standard pathname defaults.
  156. Default mechanisms are convenient, as the user doesn't have to specify
  157. the complete pathname each time he wishes to use the file transfer
  158. service.
  159.  
  160. III. SPECIFICATIONS
  161.  
  162. 1.  Data Transfer
  163.  
  164.    FTP uses the data transfer protocol described in RFC 171, for
  165.    transferring data and/or control transaction. Both data and control
  166.    transactions are communicated over the same connection.
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. NWG/RFC 172
  173.  
  174.  
  175. 2.  Data Transactions
  176.  
  177.    Data transactions represent the data contained in a file. There is no
  178.    data type or byte size information contained in data transactions.
  179.    The structure of data is instead communicated via control
  180.    transactions. A file may be transferred as one or more data
  181.    transactions. The protocol neither specifies nor imposes any
  182.    limitations on the structure (record, group, etc) or length of file.
  183.    Such limitations may however be imposed by a serving host. The end of
  184.    a file may be indicated either by a file separator (as defined in
  185.    data transfer protocol), or by closing connection (in type B0). In
  186.    particular a serving or using host should not send the ETX, or other
  187.    end of file character, unless such a character is part of the data in
  188.    file (i.e., not provided by system).
  189.  
  190. 3.  Control Transactions
  191.  
  192.    The control transactions may be typified as requests, identifiers,
  193.    and terminates.  A request fulfillment sequence begins with a request
  194.    and ends with receipt of data (followed by End-of-File) or a
  195.    terminate.
  196.  
  197. 3A. Op Codes
  198.  
  199.    Control transactions are distinguished by their first byte referred
  200.    as op code. A standard set of opcodes is defined below.
  201.    Implementation of a workable[4] subset of opcodes is specifically
  202.    permitted. Additional standard opcodes may be assigned later. Opcodes
  203.    hex 5A (octal 100) through hex FF (octal 377) are for experimental
  204.    use.
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228. NWG/RFC 172
  229.  
  230.  
  231.        Op Code                   Operation
  232.      Hex    Octal
  233.  
  234.       00     000         Change data type identifier
  235.  
  236.       01     001         Retrieve Request
  237.  
  238.       02     002         Store request (replaced if file already
  239.                          exists)
  240.  
  241.       03     003         Delete request
  242.  
  243.       04     004         Rename_from request
  244.  
  245.       05     005         Rename_to request
  246.  
  247.       06     006         List_file_directory request
  248.  
  249.       07     007         Username identifier
  250.  
  251.       08     010         Password identifier
  252.  
  253.       09     011         Error or unsuccessful terminate
  254.  
  255.       04     012         Acknowledge or successful terminate
  256.  
  257.       0B     013         Append request (add to existing file)
  258.  
  259.  
  260.       0C     014
  261.  
  262.    through through       Reserved for standard assignment
  263.  
  264.       4F     077
  265.  
  266.  
  267.       5A     100
  268.  
  269.    through through       Reserved for experimental use
  270.  
  271.       FF     377
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.                                                                 [Page 5]
  283.  
  284. NWG/RFC 172
  285.  
  286.  
  287. 3B. Syntax and Semantics
  288.  
  289. 3B.1 Data Types
  290.  
  291.    The 'change data type' control transactions identifies the structure
  292.    of data (data type and byte size) in succeeding data transactions.
  293.    This transaction shall contain two more bytes in addition to the
  294.    opcode byte. The first of these bytes shall convey a data type or
  295.    code information and the second byte may convey the data byte size,
  296.    where applicable. This information may be used to define the manner
  297.    in which data is to be parsed, interpreted, reconfigured or stored.
  298.    Change data type need be sent only when structure of data is changed
  299.    from the preceding.
  300.  
  301.    Although, a number of data types are defined, specific
  302.    implementations may handle only limited data types or completely
  303.    ignore the data type and byte size descriptors. Even if a host
  304.    process does not "recognize" a data type, it must accept data (i.e.,
  305.    there is no such thing as a data type error.) These descriptors are
  306.    provided only for convenience, and it is not essential that they be
  307.    used. The standard default is to assume nothing about the information
  308.    and treat it as a bit stream (binary data, byte size 1)[5] whose
  309.    interpretation is left to a higher level process, or the user.
  310.  
  311.    _________________________
  312.    * It is, however, possible that this bit stream is treated like
  313.    ASCII characters in specific instances such as transmitting a file
  314.    to a line printer.
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.                                                                 [Page 6]
  339.  
  340. NWG/RFC 172
  341.  
  342.  
  343.    The following data type codes are currently assigned. Where a
  344.    byte size is not implicit in data type, it may be provided by the
  345.    second byte.
  346.  
  347.      Hex    Octal
  348.  
  349.       00     000         1               Bit stream (standard default)
  350.  
  351.       01     001       none              Binary data bytes
  352.  
  353.       02     002         8               Network ASCII characters
  354.  
  355.       03     003         8               EBCDIC characters
  356.  
  357.       04     004        36               DEC-packed ASCII (five 7-bit
  358.                                          characters, 36th bit 1 or 0)
  359.  
  360.       05     005         8               Decimal numbers, net. ASCII
  361.  
  362.       06     006         8               Octal numbers, net. ASCII
  363.  
  364.       07     007         8               Hexadecimal numbers, net. ASCII
  365.  
  366.       08     010
  367.  
  368.    through through                       Reserved for standard assignment
  369.  
  370.       4F     077
  371.  
  372.       5A     100
  373.  
  374.    through through                       Reserved for experimental use
  375.  
  376.       FF     377
  377.  
  378. 3B.2 Requests and Identifiers
  379.  
  380.    Retrieve, delete, name_from, rename_t, and append requests contain a
  381.    pathname, following the op code, in the information field. A pathname
  382.    may also follow the opcode in list_file_directory request.
  383.  
  384.    A pathname must uniquely identify a file in the serving host. The
  385.    syntax of pathnames and identifying information shall conform to
  386.    serving host conventions, except that standard network ASCII (as
  387.    defined in the TELNET protocol) shall be used.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.                                                                 [Page 7]
  395.  
  396. NWG/RFC 172
  397.  
  398.  
  399.    The store request has a 4-byte (32 bits) 'allocate size' field
  400.    followed by pathname. 'Allocate size' indicates the number of bits of
  401.    storage to be allocated to the file. A size of zero indicates that
  402.    server should use his default.
  403.  
  404.    Retrieve request achieves the transfer of a copy of file specified in
  405.    pathname, from serving to using host. The status and contents of file
  406.    in serving host should be unaffected.
  407.  
  408.    Store request achieves the transfer of a copy of file specified in
  409.    pathname, from using to serving host. If file specified in pathname
  410.    exists on serving hosts, then its contents shall be replaced by the
  411.    contents of the file being transferred. A new file is created at the
  412.    serving host, if the file specified in pathname does not exist.
  413.  
  414.    Append request achieves the transfer of data from using to serving
  415.    host. The transferred data is appended to file specified in pathname,
  416.    at serving host.
  417.  
  418.    Rename-from and rename-to requests cause the name of the file
  419.    specified in pathname of rename_from to be changed to the name
  420.    specified in pathname of rename_to. A rename_from must always be
  421.    followed by a rename_to request.
  422.  
  423.    Delete request causes file specified in pathname to be deleted from
  424.    the serving host. If an extra level of protection is desired such as
  425.    the query "Do you really wish to delete this file?", it is to be a
  426.    local implementation in the using system. Such queries should not be
  427.    transmitted over network connections.
  428.  
  429.    Username and password identifiers contain the respective identifying
  430.    information. Normally, the information will be supplied by the user
  431.    of the file transfer service. These identifiers are normally sent at
  432.    the start of connection.
  433.  
  434. 3B.3 Error and Acknowledge Terminates
  435.  
  436.    The error transactions may have an error code indicated by the second
  437.    descriptor byte. Transmission of an error message in text is also
  438.    permitted. The following error codes are defined.
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.                                                                 [Page 8]
  451.  
  452. NWG/RFC 172
  453.  
  454.  
  455.      Error Code (2nd descriptor byte)           Meaning
  456.     Hex    Octal
  457.  
  458.      00     000                 Error condition indicated by computer
  459.                                 system (external to protocol)
  460.  
  461.      01     001                 Name syntax error
  462.  
  463.      02     003                 Access control violation
  464.  
  465.      03     003                 Abort
  466.  
  467.      04     004                 Allocate size too big
  468.  
  469.      05     005                 Allocate size overflow
  470.  
  471.      06     006                 Improper order for transactions
  472.  
  473.      07     007                 Opcode not implemented
  474.  
  475.      08     010                 File search failed
  476.  
  477.      09     011                 Error described in text message
  478.                                 (ASCII characters follow code)
  479.  
  480. At present, no completion codes are defined for acknowledge. It is
  481. assumed that acknowledge refers to the current request being
  482. fulfilled.
  483.  
  484. 4. Order of Transactions
  485.  
  486. 4A. A certain order of transactions must be maintained in fulfilling
  487.     file transfer requests. The exact sequence in which transactions
  488.     occur depends on the type of request, as described in section
  489.     4B. The fulfilling of a request may be aborted anytime by either
  490.     host, as explained in section 4C.
  491.  
  492. 4B. Identifier transactions (change data type, username, and password)
  493.     may be sent by user at any time. The usual order would be a
  494.     username transaction followed by a password transaction at the
  495.     start of the connection. No acknowledge is required, or
  496.     permitted. The identifiers are to be used for default handling,
  497.     and access control.
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.                                                                 [Page 9]
  507.  
  508. NWG/RFC 172
  509.  
  510.  
  511.     Retrieve and list_file_directory requests cause the transfer of
  512.     file from server to user. After a complete file has been
  513.     transferred, the server should indicate end-of-file (by sending
  514.     CLS or file separator) to complete the request fulfillment
  515.     sequence, as shown below.
  516.  
  517.           Read / List_file_directory request
  518.          ------------------------------------->
  519.     User            <File -- data>              Server
  520.          <-------------------------------------
  521.                 End of file indication
  522.          <-------------------------------------
  523.  
  524.     Store and append requests cause the transfer of file from user to
  525.     server. After a complete file has been transferred, the user
  526.     should send an end-of-file indication. The receipt of the file
  527.     must be acknowledged by the server, as shown below.
  528.  
  529.     User          Store / Append request        Server
  530.          ------------------------------------->
  531.                   <File -- data>
  532.          ------------------------------------->
  533.                   End of file indication
  534.          ------------------------------------->
  535.                   Acknowledge
  536.          <-------------------------------------
  537.  
  538.     Rename_from request must be followed by a rename_to request. The
  539.     request must be acknowledged as shown below.
  540.  
  541.     User          Rename_from request           Server
  542.          ------------------------------------->
  543.                   Rename_to request
  544.          ------------------------------------->
  545.                   Acknowledge
  546.          <-------------------------------------
  547.  
  548.     The delete request requires the server to acknowledge it, as shown
  549.     below.
  550.  
  551.     User              Delete                    Server
  552.          ------------------------------------->
  553.                     Acknowledge
  554.          <-------------------------------------
  555.  
  556.     Error transactions may be sent by either host at any time, and
  557.     these terminate the current request fulfillment sequence.
  558.  
  559.  
  560.  
  561.  
  562.                                                                [Page 10]
  563.  
  564. NWG/RFC 172
  565.  
  566.  
  567. 4C. Aborts. Either host may abort a request fulfillment sequence at
  568.     any time by sending an error terminate, or by closing the
  569.     connection (NCP to transmit a CLS for the connection). CLS is a
  570.     more drastic type of abort and shall be used when there is a
  571.     catastrophic failure, or when abort is desired in the middle of a
  572.     long transaction. The abort indicates to the receiving host that
  573.     sender of abort wishes to terminate request fulfillment and is now
  574.     ready to initiate or fulfill new requests. When CLS is used to
  575.     abort, the using host will be responsible for reopening
  576.     connection. The file transfer abort described here is different
  577.     from the data transfer abort which is sent only by the sender of
  578.     data. The use of the data transfer abort is not defined in this
  579.     protocol.
  580.  
  581. 6.  Initial Connection, CLS, and Access Control
  582.  
  583. 6A. There will be a preassigned permanent socket number[6] for the
  584.     cooperating file transfer process at the serving host. The
  585.     connection establishment will be in accordance with the standard
  586.     initial connection protocol[7], establishing a full-duplex
  587.     connection.
  588.  
  589. 6B. The connection will be broken by trading a CLS between the NCP's
  590.     for each of the two connections. Normally, the user will initiate
  591.     CLS.
  592.  
  593.     CLS may also be used by either user or server, to abort a
  594.     transaction in the middle. If CLS is received in the middle of
  595.     transaction, the current request fulfillment sequence will be
  596.     aborted. The using host will then reopen connection.
  597.  
  598. 6C. It is recommended that identifier (user name and password)
  599.     transactions be sent by user to server , at the start, as this
  600.     would facilitate default handling and access control for the
  601.     entire duration of connection. The identifier transactions do not
  602.     require or permit and acknowledge, and the user can proceed
  603.     directly with requests. If the identifier information is incorrect
  604.     or not received, the server may send an error transaction
  605.     indicating access control, violation, upon subsequent requests.
  606.  
  607. NOTES
  608.  
  609. [1] Alex McKenzie, BBN, is conducting a survey of network file systems
  610. to determine the practicality of standard pathname conventions, and to
  611. disseminate information to network users on host file systems.
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.                                                                [Page 11]
  619.  
  620. NWG/RFC 172
  621.  
  622.  
  623. [2] This initial subset represents control functions necessary for basic
  624. file transfer operations, and some elementary file manipulation
  625. operations. There is no attempt to provide a data management or complete
  626. file management capability.
  627.  
  628. [3] It is possible that we may, at a later date, assign meaning to these
  629. information separators within FTP.
  630.  
  631. [4] A workable subset is any request, plus terminates. Identifiers may
  632. be required in addition when using protected file systems.
  633.  
  634. [5] It is, however, possible that this bit stream is treated like ASCII
  635. characters in specific instances such as transmitting a file to a line
  636. printer.
  637.  
  638. [6] It seems that socket 1 has been assigned to logger. Socket 3 seems a
  639. reasonable choice for File Transfer.
  640.  
  641. [7] RFC 165, or any subsequent standard applicable in initial connection
  642. to loggers.
  643.  
  644.  
  645.        [ This RFC was put into machine readable form for entry ]
  646.  [ into the online RFC archives by Glenn Forbes Fleming Larratt 5/97 ]
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.                                                                [Page 12]
  675.  
  676.