doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc172.txt b/doc/rfc/rfc172.txt
new file mode 100644
index 0000000..e18c299
--- /dev/null
+++ b/doc/rfc/rfc172.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                           23 June 1971
+Request for Comments #172                       Abhay Bhushan, MIT
+NIC 6794                                        Bob Braden, UCLA
+Categories: D.4, D.5, and D.7                   Will Crowther, BBN
+Updates: 114                                    Eric Harslem, Rand
+Obsolete: None                                  John Heafner, Rand
+                                                Alex McKenzie, BBN
+                                                John Melvin, SRI
+                                                Bob Sundberg, Harvard
+                                                Dick Watson, SRI
+                                                Jim White, UCSB
+
+
+
+
+
+
+
+
+
+
+
+
+                    THE FILE TRANSFER PROTOCOL
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+NWG/RFC 172
+
+
+I. INTRODUCTION
+
+      The file transfer protocol (FTP) is a user-level protocol for file
+transfer between host computers (including terminal IMP's), on the ARPA
+computer network. The primary function of FTP is to facilitate transfer
+of files between hosts, and to allow convenient use of storage and file
+handling capabilities of other hosts. FTP uses the data transfer
+protocol described in RFC 171 to achieve transfer of data. This paper
+assumes knowledge of RFC 171.
+
+      The objectives of FTP are to promote sharing of files (computer
+programs and/or data), encourage indirect use (without login or
+implicit) of computers, and shield the user from variations in file and
+storage systems of different hosts, to the extent it is practical.
+These objectives are achieved by specifying a standard file transfer
+socket and initial connection protocol for indirect use, and using
+standard conventions for file transfer and related operations.
+
+II. DISCUSSION
+
+      A file is considered here to be an ordered set of arbitrary
+length, consisting of computer (including instructions) data. Files are
+uniquely identified in a system by their pathnames. A pathname is
+(loosely) defined to be the data string which must be input to the file
+system by a network user in order to identify a file. Pathname usually
+contains device and/or directory names, and file names in case of named
+files. FTP specifications provide standard file system commands, but do
+not provide standard naming convention at this time.  Each user must
+follow the naming convention of the file system he wishes to use. FTP
+may be extended later to include standard conventions for pathname
+structures.[1]
+
+      A file may or may not have access controls associated with it.
+The access controls designate the users' access privilege. In the
+absence of access controls, the files cannot be protected from
+accidental or unauthorized usage. It is the prerogative of a resident
+file system to provide protection, and selective access. FTP only
+provides identifier and password mechanisms for exchange of access
+control information. It should however be noted, that for file sharing,
+it is necessary that a user be allowed (subject to access controls) to
+access files not created by him.
+
+      FTP does not restrict the nature of information in the file. For
+example, a file could contain ASCII text, binary data computer program,
+or any other information. A provision for indicating data structure
+(type and byte size) exists in FTP to aid in parsing, interpretation,
+reconfiguration, and storage of data. To facilitate indirect usage, the
+cooperating file transfer processes may be disowned "daemon" processes
+
+
+
+                                                                [Page 2]
+
+NWG/RFC 172
+
+
+which "listen" to agreed-upon sockets, and follow the standard initial
+connection protocol for establishing a full-duplex connection. It should
+be noted that FTP could also used directly by logging into a remote
+host, and arranging for file transfer over specific sockets.
+
+      FTP is readily extensible, in that additional commands and data
+types may be defined by those agreeing to implement them.
+Implementation of a subset of commands is specifically permitted, and an
+initial subset for implementation is recommended.[2] The protocol may
+also be extended to enable remote execution of programs, but no standard
+procedure is suggested.
+
+      For transferring data, FTP uses the data transfer protocol
+specified in RFC 171. As the data transfer protocol does not specify the
+manner in which it is to be used by FTP, implementation may vary at
+different host sites. Hosts not wishing to separate the data transfer
+and file transfer functions, should take particular care in conforming
+to the data transfer protocol specifications of RFC 171.
+
+      It should be noted, that FTP specifications do not require
+knowledge of transfer modes used by data transfer protocol. However, as
+file transfer protocol requires the transfer of more than a single
+control transaction over the same connection, it is essential that hosts
+be able to send control transactions in either 'transparent block' (type
+B9) of 'descriptor and counts' (type BA) modes. (Type BB, the indefinite
+bit stream mode is not suitable as it limits transfer to singles
+transactions.).
+
+      The use of data transfer aborts (type B6) is neither required, nor
+defined in FTP. FTP has its own error terminate which may be used to
+abort a file transfer request. FTP also does not define the structure of
+files, and there are no conventions on the use of group, record and unit
+separators.[3] A file separator is, however, used to indicate the end of
+file. It is strongly recommended that default options be provided in
+implementation to facilitate use of file transfer service. For example,
+the main file directory on disk, a pool directory, user directory or
+directory last accessed could serve as standard pathname defaults.
+Default mechanisms are convenient, as the user doesn't have to specify
+the complete pathname each time he wishes to use the file transfer
+service.
+
+III. SPECIFICATIONS
+
+1.  Data Transfer
+
+   FTP uses the data transfer protocol described in RFC 171, for
+   transferring data and/or control transaction. Both data and control
+   transactions are communicated over the same connection.
+
+
+
+                                                                [Page 3]
+
+NWG/RFC 172
+
+
+2.  Data Transactions
+
+   Data transactions represent the data contained in a file. There is no
+   data type or byte size information contained in data transactions.
+   The structure of data is instead communicated via control
+   transactions. A file may be transferred as one or more data
+   transactions. The protocol neither specifies nor imposes any
+   limitations on the structure (record, group, etc) or length of file.
+   Such limitations may however be imposed by a serving host. The end of
+   a file may be indicated either by a file separator (as defined in
+   data transfer protocol), or by closing connection (in type B0). In
+   particular a serving or using host should not send the ETX, or other
+   end of file character, unless such a character is part of the data in
+   file (i.e., not provided by system).
+
+3.  Control Transactions
+
+   The control transactions may be typified as requests, identifiers,
+   and terminates.  A request fulfillment sequence begins with a request
+   and ends with receipt of data (followed by End-of-File) or a
+   terminate.
+
+3A. Op Codes
+
+   Control transactions are distinguished by their first byte referred
+   as op code. A standard set of opcodes is defined below.
+   Implementation of a workable[4] subset of opcodes is specifically
+   permitted. Additional standard opcodes may be assigned later. Opcodes
+   hex 5A (octal 100) through hex FF (octal 377) are for experimental
+   use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 4]
+
+NWG/RFC 172
+
+
+       Op Code                   Operation
+     Hex    Octal
+
+      00     000         Change data type identifier
+
+      01     001         Retrieve Request
+
+      02     002         Store request (replaced if file already
+                         exists)
+
+      03     003         Delete request
+
+      04     004         Rename_from request
+
+      05     005         Rename_to request
+
+      06     006         List_file_directory request
+
+      07     007         Username identifier
+
+      08     010         Password identifier
+
+      09     011         Error or unsuccessful terminate
+
+      04     012         Acknowledge or successful terminate
+
+      0B     013         Append request (add to existing file)
+
+
+      0C     014
+
+   through through       Reserved for standard assignment
+
+      4F     077
+
+
+      5A     100
+
+   through through       Reserved for experimental use
+
+      FF     377
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 5]
+
+NWG/RFC 172
+
+
+3B. Syntax and Semantics
+
+3B.1 Data Types
+
+   The 'change data type' control transactions identifies the structure
+   of data (data type and byte size) in succeeding data transactions.
+   This transaction shall contain two more bytes in addition to the
+   opcode byte. The first of these bytes shall convey a data type or
+   code information and the second byte may convey the data byte size,
+   where applicable. This information may be used to define the manner
+   in which data is to be parsed, interpreted, reconfigured or stored.
+   Change data type need be sent only when structure of data is changed
+   from the preceding.
+
+   Although, a number of data types are defined, specific
+   implementations may handle only limited data types or completely
+   ignore the data type and byte size descriptors. Even if a host
+   process does not "recognize" a data type, it must accept data (i.e.,
+   there is no such thing as a data type error.) These descriptors are
+   provided only for convenience, and it is not essential that they be
+   used. The standard default is to assume nothing about the information
+   and treat it as a bit stream (binary data, byte size 1)[5] whose
+   interpretation is left to a higher level process, or the user.
+
+   _________________________
+   * It is, however, possible that this bit stream is treated like
+   ASCII characters in specific instances such as transmitting a file
+   to a line printer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 6]
+
+NWG/RFC 172
+
+
+   The following data type codes are currently assigned. Where a
+   byte size is not implicit in data type, it may be provided by the
+   second byte.
+
+     Hex    Octal
+
+      00     000         1               Bit stream (standard default)
+
+      01     001       none              Binary data bytes
+
+      02     002         8               Network ASCII characters
+
+      03     003         8               EBCDIC characters
+
+      04     004        36               DEC-packed ASCII (five 7-bit
+                                         characters, 36th bit 1 or 0)
+
+      05     005         8               Decimal numbers, net. ASCII
+
+      06     006         8               Octal numbers, net. ASCII
+
+      07     007         8               Hexadecimal numbers, net. ASCII
+
+      08     010
+
+   through through                       Reserved for standard assignment
+
+      4F     077
+
+      5A     100
+
+   through through                       Reserved for experimental use
+
+      FF     377
+
+3B.2 Requests and Identifiers
+
+   Retrieve, delete, name_from, rename_t, and append requests contain a
+   pathname, following the op code, in the information field. A pathname
+   may also follow the opcode in list_file_directory request.
+
+   A pathname must uniquely identify a file in the serving host. The
+   syntax of pathnames and identifying information shall conform to
+   serving host conventions, except that standard network ASCII (as
+   defined in the TELNET protocol) shall be used.
+
+
+
+
+
+
+                                                                [Page 7]
+
+NWG/RFC 172
+
+
+   The store request has a 4-byte (32 bits) 'allocate size' field
+   followed by pathname. 'Allocate size' indicates the number of bits of
+   storage to be allocated to the file. A size of zero indicates that
+   server should use his default.
+
+   Retrieve request achieves the transfer of a copy of file specified in
+   pathname, from serving to using host. The status and contents of file
+   in serving host should be unaffected.
+
+   Store request achieves the transfer of a copy of file specified in
+   pathname, from using to serving host. If file specified in pathname
+   exists on serving hosts, then its contents shall be replaced by the
+   contents of the file being transferred. A new file is created at the
+   serving host, if the file specified in pathname does not exist.
+
+   Append request achieves the transfer of data from using to serving
+   host. The transferred data is appended to file specified in pathname,
+   at serving host.
+
+   Rename-from and rename-to requests cause the name of the file
+   specified in pathname of rename_from to be changed to the name
+   specified in pathname of rename_to. A rename_from must always be
+   followed by a rename_to request.
+
+   Delete request causes file specified in pathname to be deleted from
+   the serving host. If an extra level of protection is desired such as
+   the query "Do you really wish to delete this file?", it is to be a
+   local implementation in the using system. Such queries should not be
+   transmitted over network connections.
+
+   Username and password identifiers contain the respective identifying
+   information. Normally, the information will be supplied by the user
+   of the file transfer service. These identifiers are normally sent at
+   the start of connection.
+
+3B.3 Error and Acknowledge Terminates
+
+   The error transactions may have an error code indicated by the second
+   descriptor byte. Transmission of an error message in text is also
+   permitted. The following error codes are defined.
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 8]
+
+NWG/RFC 172
+
+
+     Error Code (2nd descriptor byte)           Meaning
+    Hex    Octal
+
+     00     000                 Error condition indicated by computer
+                                system (external to protocol)
+
+     01     001                 Name syntax error
+
+     02     003                 Access control violation
+
+     03     003                 Abort
+
+     04     004                 Allocate size too big
+
+     05     005                 Allocate size overflow
+
+     06     006                 Improper order for transactions
+
+     07     007                 Opcode not implemented
+
+     08     010                 File search failed
+
+     09     011                 Error described in text message
+                                (ASCII characters follow code)
+
+At present, no completion codes are defined for acknowledge. It is
+assumed that acknowledge refers to the current request being
+fulfilled.
+
+4. Order of Transactions
+
+4A. A certain order of transactions must be maintained in fulfilling
+    file transfer requests. The exact sequence in which transactions
+    occur depends on the type of request, as described in section
+    4B. The fulfilling of a request may be aborted anytime by either
+    host, as explained in section 4C.
+
+4B. Identifier transactions (change data type, username, and password)
+    may be sent by user at any time. The usual order would be a
+    username transaction followed by a password transaction at the
+    start of the connection. No acknowledge is required, or
+    permitted. The identifiers are to be used for default handling,
+    and access control.
+
+
+
+
+
+
+
+
+                                                                [Page 9]
+
+NWG/RFC 172
+
+
+    Retrieve and list_file_directory requests cause the transfer of
+    file from server to user. After a complete file has been
+    transferred, the server should indicate end-of-file (by sending
+    CLS or file separator) to complete the request fulfillment
+    sequence, as shown below.
+
+          Read / List_file_directory request
+         ------------------------------------->
+    User            <File -- data>              Server
+         <-------------------------------------
+                End of file indication
+         <-------------------------------------
+
+    Store and append requests cause the transfer of file from user to
+    server. After a complete file has been transferred, the user
+    should send an end-of-file indication. The receipt of the file
+    must be acknowledged by the server, as shown below.
+
+    User          Store / Append request        Server
+         ------------------------------------->
+                  <File -- data>
+         ------------------------------------->
+                  End of file indication
+         ------------------------------------->
+                  Acknowledge
+         <-------------------------------------
+
+    Rename_from request must be followed by a rename_to request. The
+    request must be acknowledged as shown below.
+
+    User          Rename_from request           Server
+         ------------------------------------->
+                  Rename_to request
+         ------------------------------------->
+                  Acknowledge
+         <-------------------------------------
+
+    The delete request requires the server to acknowledge it, as shown
+    below.
+
+    User              Delete                    Server
+         ------------------------------------->
+                    Acknowledge
+         <-------------------------------------
+
+    Error transactions may be sent by either host at any time, and
+    these terminate the current request fulfillment sequence.
+
+
+
+
+                                                               [Page 10]
+
+NWG/RFC 172
+
+
+4C. Aborts. Either host may abort a request fulfillment sequence at
+    any time by sending an error terminate, or by closing the
+    connection (NCP to transmit a CLS for the connection). CLS is a
+    more drastic type of abort and shall be used when there is a
+    catastrophic failure, or when abort is desired in the middle of a
+    long transaction. The abort indicates to the receiving host that
+    sender of abort wishes to terminate request fulfillment and is now
+    ready to initiate or fulfill new requests. When CLS is used to
+    abort, the using host will be responsible for reopening
+    connection. The file transfer abort described here is different
+    from the data transfer abort which is sent only by the sender of
+    data. The use of the data transfer abort is not defined in this
+    protocol.
+
+6.  Initial Connection, CLS, and Access Control
+
+6A. There will be a preassigned permanent socket number[6] for the
+    cooperating file transfer process at the serving host. The
+    connection establishment will be in accordance with the standard
+    initial connection protocol[7], establishing a full-duplex
+    connection.
+
+6B. The connection will be broken by trading a CLS between the NCP's
+    for each of the two connections. Normally, the user will initiate
+    CLS.
+
+    CLS may also be used by either user or server, to abort a
+    transaction in the middle. If CLS is received in the middle of
+    transaction, the current request fulfillment sequence will be
+    aborted. The using host will then reopen connection.
+
+6C. It is recommended that identifier (user name and password)
+    transactions be sent by user to server , at the start, as this
+    would facilitate default handling and access control for the
+    entire duration of connection. The identifier transactions do not
+    require or permit and acknowledge, and the user can proceed
+    directly with requests. If the identifier information is incorrect
+    or not received, the server may send an error transaction
+    indicating access control, violation, upon subsequent requests.
+
+NOTES
+
+[1] Alex McKenzie, BBN, is conducting a survey of network file systems
+to determine the practicality of standard pathname conventions, and to
+disseminate information to network users on host file systems.
+
+
+
+
+
+
+                                                               [Page 11]
+
+NWG/RFC 172
+
+
+[2] This initial subset represents control functions necessary for basic
+file transfer operations, and some elementary file manipulation
+operations. There is no attempt to provide a data management or complete
+file management capability.
+
+[3] It is possible that we may, at a later date, assign meaning to these
+information separators within FTP.
+
+[4] A workable subset is any request, plus terminates. Identifiers may
+be required in addition when using protected file systems.
+
+[5] It is, however, possible that this bit stream is treated like ASCII
+characters in specific instances such as transmitting a file to a line
+printer.
+
+[6] It seems that socket 1 has been assigned to logger. Socket 3 seems a
+reasonable choice for File Transfer.
+
+[7] RFC 165, or any subsequent standard applicable in initial connection
+to loggers.
+
+
+       [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Glenn Forbes Fleming Larratt 5/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 12]
+