From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc265.txt | 675 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc265.txt (limited to 'doc/rfc/rfc265.txt') diff --git a/doc/rfc/rfc265.txt b/doc/rfc/rfc265.txt new file mode 100644 index 0000000..0df8d26 --- /dev/null +++ b/doc/rfc/rfc265.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group 17 November 1971 +Request for Comments #265 Abbay Bhushan, MIT +NIC 781 Bob Braden, UCLA +Categories D.4, D.5, and D.7 Will Crowther, BBN + Eric Narslem, Rand +Obsoletes: 172 John Heafner, Rand + Alex McKenzie, BBH + John Melvin, SRI + Bob Sundberg, Harvard + Dick Watson, SRI + Jim White, UOSB + + + THE FILE TRANSFER PROTOCOL + + This Paper is a revision of RF 172, Mic 6794. The changes +to RFC 172 are given below. The protocol is then restated for +your ocnvenience. + + CHANGES TO RFC 172 + +1) Two new file transfer requests have been added. These are + +2) The op code assignements in control transactions have been +changed to include the above requests. + +3) Two new error codes indicating 'incorrect or missing +indentifier' and 'file already exists' have been added. New error +code assignements reflect this change. + +4) Editorial changes to clarify specifications. + + + + + + + + + + + + + + + + + + + + + [Page 1] + +File Transfer Protocol RFC 265 17 November 1971 + + +I. INTRODUCTION + + The file transfer protocol (FTP) is a userlevel procotocol for +file transfer between host computers (including terminal IMPs), on the +ARPA computer network (ARPANET). 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 remote hosts. FTP uses +the Data Transfer Protocol described in RFC 264 to achieve transfer of +data. This paper assumes knowledge of RFC 264. + + The objectives of FTP are to promote sharing of files (computer +programs and/or data) encourage implicit (without explicit login) use +of computers, and shield the user from variations in file and storage +systems of different hosts. These objetives are achieved by specifying +a standard file transfer socket and initial connection protocol for +implicit 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 data (including programs). 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 name. 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 be wishing to use. FTP may be +extended later to include standard conventions of pathname structures. + + A file may or may not have access control associated with it The +access controls designate users access privileges. In absence of +access controls, files cannot be protected from accidental or +unauthorized usage. It is the prerogative of a serving file system to +provide protection, and selective access. FTP provides identifier and +password mechanisms for exchange of access control information. it +should however ve 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 files. 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, and storage of data. + + + + + + [Page 2] + +File Transfer Protocol RFC 265 17 November 1971 + + + To facilitate impliict usage, a serving file transfer process my +be a disowned "demon" process which "listens" to an agreed-upon +socket, and follows the standard initial connection protocol for +establishing a fill-duplex connection. It should be noted that FTP my +also be used directly by logging into a remote host, and arranging for +file transfer over specific sockets. + + FTP is readily extendable, 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. (*)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 264. As the data transfer protool 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 data transfer +and file transfer functions, should take particular care in conforming +to the data transfer protocol specifications of RFC 264. + + 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) or 'descriptor and counts' (type BA) modes. (Type BS, +the indefinite bit stream mode is not suitable as it limits transfer +to single transactions.). + + The use of data transfer aborts (type B6) is neither required, nor +defined in FTP. FTP has its own error terminate wich may be used to +abort a file transfer request. FTP also does not define to structure +of files, and there are no conventions on the use of group, record and +unit separators. (*)A file separator however, indicates the end of a +file. + + It is strongly recommended that default options be provided in +implementation to facilitate use of file transfer service. For +example, the main file directora on disk, a pool directory, user +directory of diretory 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 ve wishes to use the file +transfer service. No standard default procedures are specified by FTP. + +-------------------------------- +(*) + This initial subset represents control functions necessary for + + + + [Page 3] + +File Transfer Protocol RFC 265 17 November 1971 + + +basic file transfer and "mail" operations, and some elementary file +manipulation operations. There is no attempt to provide a data +management or complete file management cpability. +(*) + It is possible that wi may, at a later date, assign meaning to +these information separators within FTP. + +III. SPECIFICATIONS + +1. Data Transfer + + FTP uses the Data Transfer Protocol (described in RFC 264) + for transferring data and/or control transaction. Both data + and control transactions are communicated over the same + connection. + +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 communicated via + control transactions. A file may be transferred as one or + more data transactions. The protocol neither specifies nor + impose 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 by a + file separator (as defined in data transfer protocol). In + the special case of indefinite bit-stream transfer mode (Type + B0), the end of file is indicated by closing connection. In + particular, a serving or usin 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. The user side initiates the + connections as well as the request. The server side "listens" + and complies with the request. + +3A. Op Codes + + The first information (i.e., not descriptor) byte or control + transactions indicates the control function. This byte is + referred to as "opcode". A standard set of opcodes are + defined below. The operations are discussed in Section 2B.2. + + + + [Page 4] + +File Transfer Protocol RFC 265 17 November 1971 + + + Implementation of a workable 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. + + Op Code Operation + Hex Octal + + 00 000 Set data type identifier + + 01 001 Retrieve Request + + 02 002 Create request (write file; error ir + file already exits) + + 03 003 Store request (write file; replace + if file already exists) + + 04 004 Append request (add to existing file; + error if file does not exist) + + 05 005 Append_with_create request (add to + file; create if file does not exist) + + 06 006 Delete request (delete file) + + 07 007 Rename_from request (change file name) + + 08 010 Rename_to request (the new file name) + + 09 011 List request (list information) + + 0A 012 Username identifier (for access control) + + 0B 013 Password identifier (for access control) + + 0C 014 Error of unsuccessful terminate + + 0D 015 Acknowledge or successful terminate + + 0E 016 +through through Reserved for standard assignment + 4F 077 + + 5A 100 +through through Assigned for experimental use + FF 377 + + + + + [Page 5] + +File Transfer Protocol RFC 265 17 November 1971 + + +------------------------------------ +(*) + A workable subset is any request, plus terminates. Indentifiers +may be required in addition for usin "protected" file systems. + +3B. Syntax and Semantics + +3B.1 Data Types + + The 'set data type' control transactions indentifies the structure + of data (data type and byte size) is succeeding data transactions. + The 'set data type' 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. Set 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 data type error.) These descriptors are + provided only for convenience, and it es 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)(*)whose interpretation is left to a higher level process, or the + user. + + 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. + +----------------------------------- + (*) + 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] + +File Transfer Protocol RFC 265 17 November 1971 + + + Code Implicit Data Type + Hex Octal Byte Size + + 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 assignemt + 4f 077 + + 5A 100 +through through Assigned for experimental use + FF 377 + +3B.2 Requests and Identifiers + + Retrieve, create, append, append_with_create, delete, rename_from, + and rename_to requests must contain a pathname specifying a file, + following the opcode in the information field. In the list request a + pathname may or may not follow the opcode. If present, the pathname + may specify either a file or a directory. + + A file 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 (7-bit + ASCII right justified in 8-bit) field with most signifcant bit as + zero) shall be used. + + The store request has a 4-byte (32 bits) 'allocate size' field + followed by a pathname specifying a file. 'Allocate size' indicates + the number of bits of storage to be allocated to the file. An + allocate size of zero indicates that server should use his default. + + + + + + [Page 7] + +File Transfer Protocol RFC 265 17 November 1971 + + + 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. + + Create request causes a file to be created at the serving host as + specified in pathname, A copy of the file is transferred from the + using to the serving host. If the file specified in pathname already + exists at the serving host, an error terminate should be sent by the + server. + + Store request achieves the transfer of copy of file 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. If the specified file does not exist at + serving host, an error terminate should be sent by the server. + + Append with create request achieves the transfer of data from using + to serving host. If file specified is pathname exists at serving + host, then the transferred data is appended to that file, otherwise + the file specified in pathname is created at the 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 request 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 option in the using system. Such queries should + not be transmitted over network connections. + + List request causes a list to be sent from the serving to using + host. If there is no pathname of if pathname is a directory, the + server should send a file directory list. If the pathname specifies + a file then server should send current information on the file. + + 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 will normally be + sent at the start of connetion for access control. + + + + + + [Page 8] + +File Transfer Protocol RFC 265 17 November 1971 + + +3B.3 Error and Acknowledge Terminates + + The error transactions may have an error code indicated by the + second information byte. Transmission of an ASCII error message in + subsequent bytes is permitted with all error codes, except that with + Hex '0A' error code, ASCII text is required. The errors here relate + to file transfer functions only. Data synchronization and related + errors in data transfer are to be handled at the DTP level. The + following error codes are currently defined: + + Error Code (2nd descriptor byte) Meaning + Hex Octal + 00 000 Error condition indicated by + computer system (external to protocol) + 01 001 Name syntay error + 02 002 Access control violation + 03 003 Abort (by user) + 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 Incorrect or missing identifier + 0A 012 Error described in text message + (ASCII characters follow code) + 0B 013 File already exists (in create request) + + 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 + wich transactions occur depends on the type of request, as + described in action 4B. The fullfillment of a request may be + aborted anytime by either host, as explained in section 4C. + +4B. Identifier transactions (set 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] + +File Transfer Protocol RFC 265 17 November 1971 + + + Retrieve and list requests cause 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. + + Retrieve / List requests + -----------------------------> + + User < File -- Data> Server + <----------------------------- + End of file indication + <----------------------------- + + Store, create, append, and append_with_create 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. + + Create / Store / Append / Append_with_create requests + -----------------------------> + User Server + -----------------------------> + 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_ro request + -----------------------------> + Acknowledge + <----------------------------- + + The delete request requires the server to acknowledge it, as + shown below. + + + + + + + + + + + [Page 10] + +File Transfer Protocol RFC 265 17 November 1971 + + + User Delete Server + -----------------------------> + Acknowledge + <----------------------------- + + Error transactions my be sent by either host at any time, + and these terminate the current request fulfillment sequence. + +4C. Aborts. Eithe host may abort a request fulfillment sequence + at any time by sending an error terminate, or by closing the + connection (NCP to transmit a CCLS 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 ar fulfill + new requests. When CLS is used to abort, the using host will + he responsible for reopening connection. The file transfer + abort described here is different form data transfer + abort which is sent only by the sender of data. The use of + the data transfer is not defined in this protocol. + +5. Initial Connection, CLS, and Access Control + +5A. Socket 3 is the standard preassigned socket number on which + the cooperating file transfer process at the serving host + should "listen". (*)The connection establishment will be in + accordance with the standard initial connection + protocol, (*)establishing a full-duplex connection. + +5B. 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 + transation 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. + +5C. It is recommended that identifier (user name and password) + transactions be sent by user to server, at the start, as this + would facilitate default handline and access control for the + entire duration of connection. Some service sites may + require the indentifier transactions. The identifier + transactions do not require or permit an 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, + + + + [Page 11] + +File Transfer Protocol RFC 265 17 November 1971 + + + upon subsequent requests. + + --------------------------------- + (*) + Socket 1 has been assigned to logger, socket 3 seems a + reasonable choice for File Transfer. + + (*) + 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 Gottfried Janik 7/97 ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 12] + -- cgit v1.2.3