summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc172.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc172.txt')
-rw-r--r--doc/rfc/rfc172.txt675
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]
+