summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc265.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc265.txt')
-rw-r--r--doc/rfc/rfc265.txt675
1 files changed, 675 insertions, 0 deletions
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 <File --- Data> 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]
+