mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-30 21:55:31 +00:00
3934 lines
144 KiB
Plaintext
3934 lines
144 KiB
Plaintext
|
||
|
||
Network Working Group J. Postel
|
||
Request for Comments: 959 J. Reynolds
|
||
ISI
|
||
Obsoletes RFC: 765 (IEN 149) October 1985
|
||
|
||
FILE TRANSFER PROTOCOL (FTP)
|
||
|
||
|
||
Status of this Memo
|
||
|
||
This memo is the official specification of the File Transfer
|
||
Protocol (FTP). Distribution of this memo is unlimited.
|
||
|
||
The following new optional commands are included in this edition of
|
||
the specification:
|
||
|
||
CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU
|
||
(Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD
|
||
(Print Directory), and SYST (System).
|
||
|
||
Note that this specification is compatible with the previous edition.
|
||
|
||
1. INTRODUCTION
|
||
|
||
The objectives of FTP are 1) to promote sharing of files (computer
|
||
programs and/or data), 2) to encourage indirect or implicit (via
|
||
programs) use of remote computers, 3) to shield a user from
|
||
variations in file storage systems among hosts, and 4) to transfer
|
||
data reliably and efficiently. FTP, though usable directly by a user
|
||
at a terminal, is designed mainly for use by programs.
|
||
|
||
The attempt in this specification is to satisfy the diverse needs of
|
||
users of maxi-hosts, mini-hosts, personal workstations, and TACs,
|
||
with a simple, and easily implemented protocol design.
|
||
|
||
This paper assumes knowledge of the Transmission Control Protocol
|
||
(TCP) [2] and the Telnet Protocol [3]. These documents are contained
|
||
in the ARPA-Internet protocol handbook [1].
|
||
|
||
2. OVERVIEW
|
||
|
||
In this section, the history, the terminology, and the FTP model are
|
||
discussed. The terms defined in this section are only those that
|
||
have special significance in FTP. Some of the terminology is very
|
||
specific to the FTP model; some readers may wish to turn to the
|
||
section on the FTP model while reviewing the terminology.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 1]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
2.1. HISTORY
|
||
|
||
FTP has had a long evolution over the years. Appendix III is a
|
||
chronological compilation of Request for Comments documents
|
||
relating to FTP. These include the first proposed file transfer
|
||
mechanisms in 1971 that were developed for implementation on hosts
|
||
at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
|
||
|
||
RFC 172 provided a user-level oriented protocol for file transfer
|
||
between host computers (including terminal IMPs). A revision of
|
||
this as RFC 265, restated FTP for additional review, while RFC 281
|
||
suggested further changes. The use of a "Set Data Type"
|
||
transaction was proposed in RFC 294 in January 1982.
|
||
|
||
RFC 354 obsoleted RFCs 264 and 265. The File Transfer Protocol
|
||
was now defined as a protocol for file transfer between HOSTs on
|
||
the ARPANET, with the primary function of FTP defined as
|
||
transfering files efficiently and reliably among hosts and
|
||
allowing the convenient use of remote file storage capabilities.
|
||
RFC 385 further commented on errors, emphasis points, and
|
||
additions to the protocol, while RFC 414 provided a status report
|
||
on the working server and user FTPs. RFC 430, issued in 1973,
|
||
(among other RFCs too numerous to mention) presented further
|
||
comments on FTP. Finally, an "official" FTP document was
|
||
published as RFC 454.
|
||
|
||
By July 1973, considerable changes from the last versions of FTP
|
||
were made, but the general structure remained the same. RFC 542
|
||
was published as a new "official" specification to reflect these
|
||
changes. However, many implementations based on the older
|
||
specification were not updated.
|
||
|
||
In 1974, RFCs 607 and 614 continued comments on FTP. RFC 624
|
||
proposed further design changes and minor modifications. In 1975,
|
||
RFC 686 entitled, "Leaving Well Enough Alone", discussed the
|
||
differences between all of the early and later versions of FTP.
|
||
RFC 691 presented a minor revision of RFC 686, regarding the
|
||
subject of print files.
|
||
|
||
Motivated by the transition from the NCP to the TCP as the
|
||
underlying protocol, a phoenix was born out of all of the above
|
||
efforts in RFC 765 as the specification of FTP for use on TCP.
|
||
|
||
This current edition of the FTP specification is intended to
|
||
correct some minor documentation errors, to improve the
|
||
explanation of some protocol features, and to add some new
|
||
optional commands.
|
||
|
||
|
||
Postel & Reynolds [Page 2]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
In particular, the following new optional commands are included in
|
||
this edition of the specification:
|
||
|
||
CDUP - Change to Parent Directory
|
||
|
||
SMNT - Structure Mount
|
||
|
||
STOU - Store Unique
|
||
|
||
RMD - Remove Directory
|
||
|
||
MKD - Make Directory
|
||
|
||
PWD - Print Directory
|
||
|
||
SYST - System
|
||
|
||
This specification is compatible with the previous edition. A
|
||
program implemented in conformance to the previous specification
|
||
should automatically be in conformance to this specification.
|
||
|
||
2.2. TERMINOLOGY
|
||
|
||
ASCII
|
||
|
||
The ASCII character set is as defined in the ARPA-Internet
|
||
Protocol Handbook. In FTP, ASCII characters are defined to be
|
||
the lower half of an eight-bit code set (i.e., the most
|
||
significant bit is zero).
|
||
|
||
access controls
|
||
|
||
Access controls define users' access privileges to the use of a
|
||
system, and to the files in that system. Access controls are
|
||
necessary to prevent unauthorized or accidental use of files.
|
||
It is the prerogative of a server-FTP process to invoke access
|
||
controls.
|
||
|
||
byte size
|
||
|
||
There are two byte sizes of interest in FTP: the logical byte
|
||
size of the file, and the transfer byte size used for the
|
||
transmission of the data. The transfer byte size is always 8
|
||
bits. The transfer byte size is not necessarily the byte size
|
||
in which data is to be stored in a system, nor the logical byte
|
||
size for interpretation of the structure of the data.
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 3]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
control connection
|
||
|
||
The communication path between the USER-PI and SERVER-PI for
|
||
the exchange of commands and replies. This connection follows
|
||
the Telnet Protocol.
|
||
|
||
data connection
|
||
|
||
A full duplex connection over which data is transferred, in a
|
||
specified mode and type. The data transferred may be a part of
|
||
a file, an entire file or a number of files. The path may be
|
||
between a server-DTP and a user-DTP, or between two
|
||
server-DTPs.
|
||
|
||
data port
|
||
|
||
The passive data transfer process "listens" on the data port
|
||
for a connection from the active transfer process in order to
|
||
open the data connection.
|
||
|
||
DTP
|
||
|
||
The data transfer process establishes and manages the data
|
||
connection. The DTP can be passive or active.
|
||
|
||
End-of-Line
|
||
|
||
The end-of-line sequence defines the separation of printing
|
||
lines. The sequence is Carriage Return, followed by Line Feed.
|
||
|
||
EOF
|
||
|
||
The end-of-file condition that defines the end of a file being
|
||
transferred.
|
||
|
||
EOR
|
||
|
||
The end-of-record condition that defines the end of a record
|
||
being transferred.
|
||
|
||
error recovery
|
||
|
||
A procedure that allows a user to recover from certain errors
|
||
such as failure of either host system or transfer process. In
|
||
FTP, error recovery may involve restarting a file transfer at a
|
||
given checkpoint.
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 4]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
FTP commands
|
||
|
||
A set of commands that comprise the control information flowing
|
||
from the user-FTP to the server-FTP process.
|
||
|
||
file
|
||
|
||
An ordered set of computer data (including programs), of
|
||
arbitrary length, uniquely identified by a pathname.
|
||
|
||
mode
|
||
|
||
The mode in which data is to be transferred via the data
|
||
connection. The mode defines the data format during transfer
|
||
including EOR and EOF. The transfer modes defined in FTP are
|
||
described in the Section on Transmission Modes.
|
||
|
||
NVT
|
||
|
||
The Network Virtual Terminal as defined in the Telnet Protocol.
|
||
|
||
NVFS
|
||
|
||
The Network Virtual File System. A concept which defines a
|
||
standard network file system with standard commands and
|
||
pathname conventions.
|
||
|
||
page
|
||
|
||
A file may be structured as a set of independent parts called
|
||
pages. FTP supports the transmission of discontinuous files as
|
||
independent indexed pages.
|
||
|
||
pathname
|
||
|
||
Pathname is defined to be the character string which must be
|
||
input to a file system by a user in order to identify a file.
|
||
Pathname normally contains device and/or directory names, and
|
||
file name specification. FTP does not yet specify a standard
|
||
pathname convention. Each user must follow the file naming
|
||
conventions of the file systems involved in the transfer.
|
||
|
||
PI
|
||
|
||
The protocol interpreter. The user and server sides of the
|
||
protocol have distinct roles implemented in a user-PI and a
|
||
server-PI.
|
||
|
||
|
||
Postel & Reynolds [Page 5]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
record
|
||
|
||
A sequential file may be structured as a number of contiguous
|
||
parts called records. Record structures are supported by FTP
|
||
but a file need not have record structure.
|
||
|
||
reply
|
||
|
||
A reply is an acknowledgment (positive or negative) sent from
|
||
server to user via the control connection in response to FTP
|
||
commands. The general form of a reply is a completion code
|
||
(including error codes) followed by a text string. The codes
|
||
are for use by programs and the text is usually intended for
|
||
human users.
|
||
|
||
server-DTP
|
||
|
||
The data transfer process, in its normal "active" state,
|
||
establishes the data connection with the "listening" data port.
|
||
It sets up parameters for transfer and storage, and transfers
|
||
data on command from its PI. The DTP can be placed in a
|
||
"passive" state to listen for, rather than initiate a
|
||
connection on the data port.
|
||
|
||
server-FTP process
|
||
|
||
A process or set of processes which perform the function of
|
||
file transfer in cooperation with a user-FTP process and,
|
||
possibly, another server. The functions consist of a protocol
|
||
interpreter (PI) and a data transfer process (DTP).
|
||
|
||
server-PI
|
||
|
||
The server protocol interpreter "listens" on Port L for a
|
||
connection from a user-PI and establishes a control
|
||
communication connection. It receives standard FTP commands
|
||
from the user-PI, sends replies, and governs the server-DTP.
|
||
|
||
type
|
||
|
||
The data representation type used for data transfer and
|
||
storage. Type implies certain transformations between the time
|
||
of data storage and data transfer. The representation types
|
||
defined in FTP are described in the Section on Establishing
|
||
Data Connections.
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 6]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
user
|
||
|
||
A person or a process on behalf of a person wishing to obtain
|
||
file transfer service. The human user may interact directly
|
||
with a server-FTP process, but use of a user-FTP process is
|
||
preferred since the protocol design is weighted towards
|
||
automata.
|
||
|
||
user-DTP
|
||
|
||
The data transfer process "listens" on the data port for a
|
||
connection from a server-FTP process. If two servers are
|
||
transferring data between them, the user-DTP is inactive.
|
||
|
||
user-FTP process
|
||
|
||
A set of functions including a protocol interpreter, a data
|
||
transfer process and a user interface which together perform
|
||
the function of file transfer in cooperation with one or more
|
||
server-FTP processes. The user interface allows a local
|
||
language to be used in the command-reply dialogue with the
|
||
user.
|
||
|
||
user-PI
|
||
|
||
The user protocol interpreter initiates the control connection
|
||
from its port U to the server-FTP process, initiates FTP
|
||
commands, and governs the user-DTP if that process is part of
|
||
the file transfer.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 7]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
2.3. THE FTP MODEL
|
||
|
||
With the above definitions in mind, the following model (shown in
|
||
Figure 1) may be diagrammed for an FTP service.
|
||
|
||
-------------
|
||
|/---------\|
|
||
|| User || --------
|
||
||Interface|<--->| User |
|
||
|\----^----/| --------
|
||
---------- | | |
|
||
|/------\| FTP Commands |/----V----\|
|
||
||Server|<---------------->| User ||
|
||
|| PI || FTP Replies || PI ||
|
||
|\--^---/| |\----^----/|
|
||
| | | | | |
|
||
-------- |/--V---\| Data |/----V----\| --------
|
||
| File |<--->|Server|<---------------->| User |<--->| File |
|
||
|System| || DTP || Connection || DTP || |System|
|
||
-------- |\------/| |\---------/| --------
|
||
---------- -------------
|
||
|
||
Server-FTP USER-FTP
|
||
|
||
NOTES: 1. The data connection may be used in either direction.
|
||
2. The data connection need not exist all of the time.
|
||
|
||
Figure 1 Model for FTP Use
|
||
|
||
In the model described in Figure 1, the user-protocol interpreter
|
||
initiates the control connection. The control connection follows
|
||
the Telnet protocol. At the initiation of the user, standard FTP
|
||
commands are generated by the user-PI and transmitted to the
|
||
server process via the control connection. (The user may
|
||
establish a direct control connection to the server-FTP, from a
|
||
TAC terminal for example, and generate standard FTP commands
|
||
independently, bypassing the user-FTP process.) Standard replies
|
||
are sent from the server-PI to the user-PI over the control
|
||
connection in response to the commands.
|
||
|
||
The FTP commands specify the parameters for the data connection
|
||
(data port, transfer mode, representation type, and structure) and
|
||
the nature of file system operation (store, retrieve, append,
|
||
delete, etc.). The user-DTP or its designate should "listen" on
|
||
the specified data port, and the server initiate the data
|
||
connection and data transfer in accordance with the specified
|
||
parameters. It should be noted that the data port need not be in
|
||
|
||
|
||
Postel & Reynolds [Page 8]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
the same host that initiates the FTP commands via the control
|
||
connection, but the user or the user-FTP process must ensure a
|
||
"listen" on the specified data port. It ought to also be noted
|
||
that the data connection may be used for simultaneous sending and
|
||
receiving.
|
||
|
||
In another situation a user might wish to transfer files between
|
||
two hosts, neither of which is a local host. The user sets up
|
||
control connections to the two servers and then arranges for a
|
||
data connection between them. In this manner, control information
|
||
is passed to the user-PI but data is transferred between the
|
||
server data transfer processes. Following is a model of this
|
||
server-server interaction.
|
||
|
||
|
||
Control ------------ Control
|
||
---------->| User-FTP |<-----------
|
||
| | User-PI | |
|
||
| | "C" | |
|
||
V ------------ V
|
||
-------------- --------------
|
||
| Server-FTP | Data Connection | Server-FTP |
|
||
| "A" |<---------------------->| "B" |
|
||
-------------- Port (A) Port (B) --------------
|
||
|
||
|
||
Figure 2
|
||
|
||
The protocol requires that the control connections be open while
|
||
data transfer is in progress. It is the responsibility of the
|
||
user to request the closing of the control connections when
|
||
finished using the FTP service, while it is the server who takes
|
||
the action. The server may abort data transfer if the control
|
||
connections are closed without command.
|
||
|
||
The Relationship between FTP and Telnet:
|
||
|
||
The FTP uses the Telnet protocol on the control connection.
|
||
This can be achieved in two ways: first, the user-PI or the
|
||
server-PI may implement the rules of the Telnet Protocol
|
||
directly in their own procedures; or, second, the user-PI or
|
||
the server-PI may make use of the existing Telnet module in the
|
||
system.
|
||
|
||
Ease of implementaion, sharing code, and modular programming
|
||
argue for the second approach. Efficiency and independence
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 9]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
argue for the first approach. In practice, FTP relies on very
|
||
little of the Telnet Protocol, so the first approach does not
|
||
necessarily involve a large amount of code.
|
||
|
||
3. DATA TRANSFER FUNCTIONS
|
||
|
||
Files are transferred only via the data connection. The control
|
||
connection is used for the transfer of commands, which describe the
|
||
functions to be performed, and the replies to these commands (see the
|
||
Section on FTP Replies). Several commands are concerned with the
|
||
transfer of data between hosts. These data transfer commands include
|
||
the MODE command which specify how the bits of the data are to be
|
||
transmitted, and the STRUcture and TYPE commands, which are used to
|
||
define the way in which the data are to be represented. The
|
||
transmission and representation are basically independent but the
|
||
"Stream" transmission mode is dependent on the file structure
|
||
attribute and if "Compressed" transmission mode is used, the nature
|
||
of the filler byte depends on the representation type.
|
||
|
||
3.1. DATA REPRESENTATION AND STORAGE
|
||
|
||
Data is transferred from a storage device in the sending host to a
|
||
storage device in the receiving host. Often it is necessary to
|
||
perform certain transformations on the data because data storage
|
||
representations in the two systems are different. For example,
|
||
NVT-ASCII has different data storage representations in different
|
||
systems. DEC TOPS-20s's generally store NVT-ASCII as five 7-bit
|
||
ASCII characters, left-justified in a 36-bit word. IBM Mainframe's
|
||
store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-ASCII
|
||
as four 9-bit characters in a 36-bit word. It is desirable to
|
||
convert characters into the standard NVT-ASCII representation when
|
||
transmitting text between dissimilar systems. The sending and
|
||
receiving sites would have to perform the necessary
|
||
transformations between the standard representation and their
|
||
internal representations.
|
||
|
||
A different problem in representation arises when transmitting
|
||
binary data (not character codes) between host systems with
|
||
different word lengths. It is not always clear how the sender
|
||
should send data, and the receiver store it. For example, when
|
||
transmitting 32-bit bytes from a 32-bit word-length system to a
|
||
36-bit word-length system, it may be desirable (for reasons of
|
||
efficiency and usefulness) to store the 32-bit bytes
|
||
right-justified in a 36-bit word in the latter system. In any
|
||
case, the user should have the option of specifying data
|
||
representation and transformation functions. It should be noted
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 10]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
that FTP provides for very limited data type representations.
|
||
Transformations desired beyond this limited capability should be
|
||
performed by the user directly.
|
||
|
||
3.1.1. DATA TYPES
|
||
|
||
Data representations are handled in FTP by a user specifying a
|
||
representation type. This type may implicitly (as in ASCII or
|
||
EBCDIC) or explicitly (as in Local byte) define a byte size for
|
||
interpretation which is referred to as the "logical byte size."
|
||
Note that this has nothing to do with the byte size used for
|
||
transmission over the data connection, called the "transfer
|
||
byte size", and the two should not be confused. For example,
|
||
NVT-ASCII has a logical byte size of 8 bits. If the type is
|
||
Local byte, then the TYPE command has an obligatory second
|
||
parameter specifying the logical byte size. The transfer byte
|
||
size is always 8 bits.
|
||
|
||
3.1.1.1. ASCII TYPE
|
||
|
||
This is the default type and must be accepted by all FTP
|
||
implementations. It is intended primarily for the transfer
|
||
of text files, except when both hosts would find the EBCDIC
|
||
type more convenient.
|
||
|
||
The sender converts the data from an internal character
|
||
representation to the standard 8-bit NVT-ASCII
|
||
representation (see the Telnet specification). The receiver
|
||
will convert the data from the standard form to his own
|
||
internal form.
|
||
|
||
In accordance with the NVT standard, the <CRLF> sequence
|
||
should be used where necessary to denote the end of a line
|
||
of text. (See the discussion of file structure at the end
|
||
of the Section on Data Representation and Storage.)
|
||
|
||
Using the standard NVT-ASCII representation means that data
|
||
must be interpreted as 8-bit bytes.
|
||
|
||
The Format parameter for ASCII and EBCDIC types is discussed
|
||
below.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 11]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
3.1.1.2. EBCDIC TYPE
|
||
|
||
This type is intended for efficient transfer between hosts
|
||
which use EBCDIC for their internal character
|
||
representation.
|
||
|
||
For transmission, the data are represented as 8-bit EBCDIC
|
||
characters. The character code is the only difference
|
||
between the functional specifications of EBCDIC and ASCII
|
||
types.
|
||
|
||
End-of-line (as opposed to end-of-record--see the discussion
|
||
of structure) will probably be rarely used with EBCDIC type
|
||
for purposes of denoting structure, but where it is
|
||
necessary the <NL> character should be used.
|
||
|
||
3.1.1.3. IMAGE TYPE
|
||
|
||
The data are sent as contiguous bits which, for transfer,
|
||
are packed into the 8-bit transfer bytes. The receiving
|
||
site must store the data as contiguous bits. The structure
|
||
of the storage system might necessitate the padding of the
|
||
file (or of each record, for a record-structured file) to
|
||
some convenient boundary (byte, word or block). This
|
||
padding, which must be all zeros, may occur only at the end
|
||
of the file (or at the end of each record) and there must be
|
||
a way of identifying the padding bits so that they may be
|
||
stripped off if the file is retrieved. The padding
|
||
transformation should be well publicized to enable a user to
|
||
process a file at the storage site.
|
||
|
||
Image type is intended for the efficient storage and
|
||
retrieval of files and for the transfer of binary data. It
|
||
is recommended that this type be accepted by all FTP
|
||
implementations.
|
||
|
||
3.1.1.4. LOCAL TYPE
|
||
|
||
The data is transferred in logical bytes of the size
|
||
specified by the obligatory second parameter, Byte size.
|
||
The value of Byte size must be a decimal integer; there is
|
||
no default value. The logical byte size is not necessarily
|
||
the same as the transfer byte size. If there is a
|
||
difference in byte sizes, then the logical bytes should be
|
||
packed contiguously, disregarding transfer byte boundaries
|
||
and with any necessary padding at the end.
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 12]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
When the data reaches the receiving host, it will be
|
||
transformed in a manner dependent on the logical byte size
|
||
and the particular host. This transformation must be
|
||
invertible (i.e., an identical file can be retrieved if the
|
||
same parameters are used) and should be well publicized by
|
||
the FTP implementors.
|
||
|
||
For example, a user sending 36-bit floating-point numbers to
|
||
a host with a 32-bit word could send that data as Local byte
|
||
with a logical byte size of 36. The receiving host would
|
||
then be expected to store the logical bytes so that they
|
||
could be easily manipulated; in this example putting the
|
||
36-bit logical bytes into 64-bit double words should
|
||
suffice.
|
||
|
||
In another example, a pair of hosts with a 36-bit word size
|
||
may send data to one another in words by using TYPE L 36.
|
||
The data would be sent in the 8-bit transmission bytes
|
||
packed so that 9 transmission bytes carried two host words.
|
||
|
||
3.1.1.5. FORMAT CONTROL
|
||
|
||
The types ASCII and EBCDIC also take a second (optional)
|
||
parameter; this is to indicate what kind of vertical format
|
||
control, if any, is associated with a file. The following
|
||
data representation types are defined in FTP:
|
||
|
||
A character file may be transferred to a host for one of
|
||
three purposes: for printing, for storage and later
|
||
retrieval, or for processing. If a file is sent for
|
||
printing, the receiving host must know how the vertical
|
||
format control is represented. In the second case, it must
|
||
be possible to store a file at a host and then retrieve it
|
||
later in exactly the same form. Finally, it should be
|
||
possible to move a file from one host to another and process
|
||
the file at the second host without undue trouble. A single
|
||
ASCII or EBCDIC format does not satisfy all these
|
||
conditions. Therefore, these types have a second parameter
|
||
specifying one of the following three formats:
|
||
|
||
3.1.1.5.1. NON PRINT
|
||
|
||
This is the default format to be used if the second
|
||
(format) parameter is omitted. Non-print format must be
|
||
accepted by all FTP implementations.
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 13]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
The file need contain no vertical format information. If
|
||
it is passed to a printer process, this process may
|
||
assume standard values for spacing and margins.
|
||
|
||
Normally, this format will be used with files destined
|
||
for processing or just storage.
|
||
|
||
3.1.1.5.2. TELNET FORMAT CONTROLS
|
||
|
||
The file contains ASCII/EBCDIC vertical format controls
|
||
(i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer
|
||
process will interpret appropriately. <CRLF>, in exactly
|
||
this sequence, also denotes end-of-line.
|
||
|
||
3.1.1.5.2. CARRIAGE CONTROL (ASA)
|
||
|
||
The file contains ASA (FORTRAN) vertical format control
|
||
characters. (See RFC 740 Appendix C; and Communications
|
||
of the ACM, Vol. 7, No. 10, p. 606, October 1964.) In a
|
||
line or a record formatted according to the ASA Standard,
|
||
the first character is not to be printed. Instead, it
|
||
should be used to determine the vertical movement of the
|
||
paper which should take place before the rest of the
|
||
record is printed.
|
||
|
||
The ASA Standard specifies the following control
|
||
characters:
|
||
|
||
Character Vertical Spacing
|
||
|
||
blank Move paper up one line
|
||
0 Move paper up two lines
|
||
1 Move paper to top of next page
|
||
+ No movement, i.e., overprint
|
||
|
||
Clearly there must be some way for a printer process to
|
||
distinguish the end of the structural entity. If a file
|
||
has record structure (see below) this is no problem;
|
||
records will be explicitly marked during transfer and
|
||
storage. If the file has no record structure, the <CRLF>
|
||
end-of-line sequence is used to separate printing lines,
|
||
but these format effectors are overridden by the ASA
|
||
controls.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 14]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
3.1.2. DATA STRUCTURES
|
||
|
||
In addition to different representation types, FTP allows the
|
||
structure of a file to be specified. Three file structures are
|
||
defined in FTP:
|
||
|
||
file-structure, where there is no internal structure and
|
||
the file is considered to be a
|
||
continuous sequence of data bytes,
|
||
|
||
record-structure, where the file is made up of sequential
|
||
records,
|
||
|
||
and page-structure, where the file is made up of independent
|
||
indexed pages.
|
||
|
||
File-structure is the default to be assumed if the STRUcture
|
||
command has not been used but both file and record structures
|
||
must be accepted for "text" files (i.e., files with TYPE ASCII
|
||
or EBCDIC) by all FTP implementations. The structure of a file
|
||
will affect both the transfer mode of a file (see the Section
|
||
on Transmission Modes) and the interpretation and storage of
|
||
the file.
|
||
|
||
The "natural" structure of a file will depend on which host
|
||
stores the file. A source-code file will usually be stored on
|
||
an IBM Mainframe in fixed length records but on a DEC TOPS-20
|
||
as a stream of characters partitioned into lines, for example
|
||
by <CRLF>. If the transfer of files between such disparate
|
||
sites is to be useful, there must be some way for one site to
|
||
recognize the other's assumptions about the file.
|
||
|
||
With some sites being naturally file-oriented and others
|
||
naturally record-oriented there may be problems if a file with
|
||
one structure is sent to a host oriented to the other. If a
|
||
text file is sent with record-structure to a host which is file
|
||
oriented, then that host should apply an internal
|
||
transformation to the file based on the record structure.
|
||
Obviously, this transformation should be useful, but it must
|
||
also be invertible so that an identical file may be retrieved
|
||
using record structure.
|
||
|
||
In the case of a file being sent with file-structure to a
|
||
record-oriented host, there exists the question of what
|
||
criteria the host should use to divide the file into records
|
||
which can be processed locally. If this division is necessary,
|
||
the FTP implementation should use the end-of-line sequence,
|
||
|
||
|
||
Postel & Reynolds [Page 15]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
<CRLF> for ASCII, or <NL> for EBCDIC text files, as the
|
||
delimiter. If an FTP implementation adopts this technique, it
|
||
must be prepared to reverse the transformation if the file is
|
||
retrieved with file-structure.
|
||
|
||
3.1.2.1. FILE STRUCTURE
|
||
|
||
File structure is the default to be assumed if the STRUcture
|
||
command has not been used.
|
||
|
||
In file-structure there is no internal structure and the
|
||
file is considered to be a continuous sequence of data
|
||
bytes.
|
||
|
||
3.1.2.2. RECORD STRUCTURE
|
||
|
||
Record structures must be accepted for "text" files (i.e.,
|
||
files with TYPE ASCII or EBCDIC) by all FTP implementations.
|
||
|
||
In record-structure the file is made up of sequential
|
||
records.
|
||
|
||
3.1.2.3. PAGE STRUCTURE
|
||
|
||
To transmit files that are discontinuous, FTP defines a page
|
||
structure. Files of this type are sometimes known as
|
||
"random access files" or even as "holey files". In these
|
||
files there is sometimes other information associated with
|
||
the file as a whole (e.g., a file descriptor), or with a
|
||
section of the file (e.g., page access controls), or both.
|
||
In FTP, the sections of the file are called pages.
|
||
|
||
To provide for various page sizes and associated
|
||
information, each page is sent with a page header. The page
|
||
header has the following defined fields:
|
||
|
||
Header Length
|
||
|
||
The number of logical bytes in the page header
|
||
including this byte. The minimum header length is 4.
|
||
|
||
Page Index
|
||
|
||
The logical page number of this section of the file.
|
||
This is not the transmission sequence number of this
|
||
page, but the index used to identify this page of the
|
||
file.
|
||
|
||
|
||
Postel & Reynolds [Page 16]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
Data Length
|
||
|
||
The number of logical bytes in the page data. The
|
||
minimum data length is 0.
|
||
|
||
Page Type
|
||
|
||
The type of page this is. The following page types
|
||
are defined:
|
||
|
||
0 = Last Page
|
||
|
||
This is used to indicate the end of a paged
|
||
structured transmission. The header length must
|
||
be 4, and the data length must be 0.
|
||
|
||
1 = Simple Page
|
||
|
||
This is the normal type for simple paged files
|
||
with no page level associated control
|
||
information. The header length must be 4.
|
||
|
||
2 = Descriptor Page
|
||
|
||
This type is used to transmit the descriptive
|
||
information for the file as a whole.
|
||
|
||
3 = Access Controlled Page
|
||
|
||
This type includes an additional header field
|
||
for paged files with page level access control
|
||
information. The header length must be 5.
|
||
|
||
Optional Fields
|
||
|
||
Further header fields may be used to supply per page
|
||
control information, for example, per page access
|
||
control.
|
||
|
||
All fields are one logical byte in length. The logical byte
|
||
size is specified by the TYPE command. See Appendix I for
|
||
further details and a specific case at the page structure.
|
||
|
||
A note of caution about parameters: a file must be stored and
|
||
retrieved with the same parameters if the retrieved version is to
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 17]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
be identical to the version originally transmitted. Conversely,
|
||
FTP implementations must return a file identical to the original
|
||
if the parameters used to store and retrieve a file are the same.
|
||
|
||
3.2. ESTABLISHING DATA CONNECTIONS
|
||
|
||
The mechanics of transferring data consists of setting up the data
|
||
connection to the appropriate ports and choosing the parameters
|
||
for transfer. Both the user and the server-DTPs have a default
|
||
data port. The user-process default data port is the same as the
|
||
control connection port (i.e., U). The server-process default
|
||
data port is the port adjacent to the control connection port
|
||
(i.e., L-1).
|
||
|
||
The transfer byte size is 8-bit bytes. This byte size is relevant
|
||
only for the actual transfer of the data; it has no bearing on
|
||
representation of the data within a host's file system.
|
||
|
||
The passive data transfer process (this may be a user-DTP or a
|
||
second server-DTP) shall "listen" on the data port prior to
|
||
sending a transfer request command. The FTP request command
|
||
determines the direction of the data transfer. The server, upon
|
||
receiving the transfer request, will initiate the data connection
|
||
to the port. When the connection is established, the data
|
||
transfer begins between DTP's, and the server-PI sends a
|
||
confirming reply to the user-PI.
|
||
|
||
Every FTP implementation must support the use of the default data
|
||
ports, and only the USER-PI can initiate a change to non-default
|
||
ports.
|
||
|
||
It is possible for the user to specify an alternate data port by
|
||
use of the PORT command. The user may want a file dumped on a TAC
|
||
line printer or retrieved from a third party host. In the latter
|
||
case, the user-PI sets up control connections with both
|
||
server-PI's. One server is then told (by an FTP command) to
|
||
"listen" for a connection which the other will initiate. The
|
||
user-PI sends one server-PI a PORT command indicating the data
|
||
port of the other. Finally, both are sent the appropriate
|
||
transfer commands. The exact sequence of commands and replies
|
||
sent between the user-controller and the servers is defined in the
|
||
Section on FTP Replies.
|
||
|
||
In general, it is the server's responsibility to maintain the data
|
||
connection--to initiate it and to close it. The exception to this
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 18]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
is when the user-DTP is sending the data in a transfer mode that
|
||
requires the connection to be closed to indicate EOF. The server
|
||
MUST close the data connection under the following conditions:
|
||
|
||
1. The server has completed sending data in a transfer mode
|
||
that requires a close to indicate EOF.
|
||
|
||
2. The server receives an ABORT command from the user.
|
||
|
||
3. The port specification is changed by a command from the
|
||
user.
|
||
|
||
4. The control connection is closed legally or otherwise.
|
||
|
||
5. An irrecoverable error condition occurs.
|
||
|
||
Otherwise the close is a server option, the exercise of which the
|
||
server must indicate to the user-process by either a 250 or 226
|
||
reply only.
|
||
|
||
3.3. DATA CONNECTION MANAGEMENT
|
||
|
||
Default Data Connection Ports: All FTP implementations must
|
||
support use of the default data connection ports, and only the
|
||
User-PI may initiate the use of non-default ports.
|
||
|
||
Negotiating Non-Default Data Ports: The User-PI may specify a
|
||
non-default user side data port with the PORT command. The
|
||
User-PI may request the server side to identify a non-default
|
||
server side data port with the PASV command. Since a connection
|
||
is defined by the pair of addresses, either of these actions is
|
||
enough to get a different data connection, still it is permitted
|
||
to do both commands to use new ports on both ends of the data
|
||
connection.
|
||
|
||
Reuse of the Data Connection: When using the stream mode of data
|
||
transfer the end of the file must be indicated by closing the
|
||
connection. This causes a problem if multiple files are to be
|
||
transfered in the session, due to need for TCP to hold the
|
||
connection record for a time out period to guarantee the reliable
|
||
communication. Thus the connection can not be reopened at once.
|
||
|
||
There are two solutions to this problem. The first is to
|
||
negotiate a non-default port. The second is to use another
|
||
transfer mode.
|
||
|
||
A comment on transfer modes. The stream transfer mode is
|
||
|
||
|
||
Postel & Reynolds [Page 19]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
inherently unreliable, since one can not determine if the
|
||
connection closed prematurely or not. The other transfer modes
|
||
(Block, Compressed) do not close the connection to indicate the
|
||
end of file. They have enough FTP encoding that the data
|
||
connection can be parsed to determine the end of the file.
|
||
Thus using these modes one can leave the data connection open
|
||
for multiple file transfers.
|
||
|
||
3.4. TRANSMISSION MODES
|
||
|
||
The next consideration in transferring data is choosing the
|
||
appropriate transmission mode. There are three modes: one which
|
||
formats the data and allows for restart procedures; one which also
|
||
compresses the data for efficient transfer; and one which passes
|
||
the data with little or no processing. In this last case the mode
|
||
interacts with the structure attribute to determine the type of
|
||
processing. In the compressed mode, the representation type
|
||
determines the filler byte.
|
||
|
||
All data transfers must be completed with an end-of-file (EOF)
|
||
which may be explicitly stated or implied by the closing of the
|
||
data connection. For files with record structure, all the
|
||
end-of-record markers (EOR) are explicit, including the final one.
|
||
For files transmitted in page structure a "last-page" page type is
|
||
used.
|
||
|
||
NOTE: In the rest of this section, byte means "transfer byte"
|
||
except where explicitly stated otherwise.
|
||
|
||
For the purpose of standardized transfer, the sending host will
|
||
translate its internal end of line or end of record denotation
|
||
into the representation prescribed by the transfer mode and file
|
||
structure, and the receiving host will perform the inverse
|
||
translation to its internal denotation. An IBM Mainframe record
|
||
count field may not be recognized at another host, so the
|
||
end-of-record information may be transferred as a two byte control
|
||
code in Stream mode or as a flagged bit in a Block or Compressed
|
||
mode descriptor. End-of-line in an ASCII or EBCDIC file with no
|
||
record structure should be indicated by <CRLF> or <NL>,
|
||
respectively. Since these transformations imply extra work for
|
||
some systems, identical systems transferring non-record structured
|
||
text files might wish to use a binary representation and stream
|
||
mode for the transfer.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 20]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
The following transmission modes are defined in FTP:
|
||
|
||
3.4.1. STREAM MODE
|
||
|
||
The data is transmitted as a stream of bytes. There is no
|
||
restriction on the representation type used; record structures
|
||
are allowed.
|
||
|
||
In a record structured file EOR and EOF will each be indicated
|
||
by a two-byte control code. The first byte of the control code
|
||
will be all ones, the escape character. The second byte will
|
||
have the low order bit on and zeros elsewhere for EOR and the
|
||
second low order bit on for EOF; that is, the byte will have
|
||
value 1 for EOR and value 2 for EOF. EOR and EOF may be
|
||
indicated together on the last byte transmitted by turning both
|
||
low order bits on (i.e., the value 3). If a byte of all ones
|
||
was intended to be sent as data, it should be repeated in the
|
||
second byte of the control code.
|
||
|
||
If the structure is a file structure, the EOF is indicated by
|
||
the sending host closing the data connection and all bytes are
|
||
data bytes.
|
||
|
||
3.4.2. BLOCK MODE
|
||
|
||
The file is transmitted as a series of data blocks preceded by
|
||
one or more header bytes. The header bytes contain a count
|
||
field, and descriptor code. The count field indicates the
|
||
total length of the data block in bytes, thus marking the
|
||
beginning of the next data block (there are no filler bits).
|
||
The descriptor code defines: last block in the file (EOF) last
|
||
block in the record (EOR), restart marker (see the Section on
|
||
Error Recovery and Restart) or suspect data (i.e., the data
|
||
being transferred is suspected of errors and is not reliable).
|
||
This last code is NOT intended for error control within FTP.
|
||
It is motivated by the desire of sites exchanging certain types
|
||
of data (e.g., seismic or weather data) to send and receive all
|
||
the data despite local errors (such as "magnetic tape read
|
||
errors"), but to indicate in the transmission that certain
|
||
portions are suspect). Record structures are allowed in this
|
||
mode, and any representation type may be used.
|
||
|
||
The header consists of the three bytes. Of the 24 bits of
|
||
header information, the 16 low order bits shall represent byte
|
||
count, and the 8 high order bits shall represent descriptor
|
||
codes as shown below.
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 21]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
Block Header
|
||
|
||
+----------------+----------------+----------------+
|
||
| Descriptor | Byte Count |
|
||
| 8 bits | 16 bits |
|
||
+----------------+----------------+----------------+
|
||
|
||
|
||
The descriptor codes are indicated by bit flags in the
|
||
descriptor byte. Four codes have been assigned, where each
|
||
code number is the decimal value of the corresponding bit in
|
||
the byte.
|
||
|
||
Code Meaning
|
||
|
||
128 End of data block is EOR
|
||
64 End of data block is EOF
|
||
32 Suspected errors in data block
|
||
16 Data block is a restart marker
|
||
|
||
With this encoding, more than one descriptor coded condition
|
||
may exist for a particular block. As many bits as necessary
|
||
may be flagged.
|
||
|
||
The restart marker is embedded in the data stream as an
|
||
integral number of 8-bit bytes representing printable
|
||
characters in the language being used over the control
|
||
connection (e.g., default--NVT-ASCII). <SP> (Space, in the
|
||
appropriate language) must not be used WITHIN a restart marker.
|
||
|
||
For example, to transmit a six-character marker, the following
|
||
would be sent:
|
||
|
||
+--------+--------+--------+
|
||
|Descrptr| Byte count |
|
||
|code= 16| = 6 |
|
||
+--------+--------+--------+
|
||
|
||
+--------+--------+--------+
|
||
| Marker | Marker | Marker |
|
||
| 8 bits | 8 bits | 8 bits |
|
||
+--------+--------+--------+
|
||
|
||
+--------+--------+--------+
|
||
| Marker | Marker | Marker |
|
||
| 8 bits | 8 bits | 8 bits |
|
||
+--------+--------+--------+
|
||
|
||
|
||
Postel & Reynolds [Page 22]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
3.4.3. COMPRESSED MODE
|
||
|
||
There are three kinds of information to be sent: regular data,
|
||
sent in a byte string; compressed data, consisting of
|
||
replications or filler; and control information, sent in a
|
||
two-byte escape sequence. If n>0 bytes (up to 127) of regular
|
||
data are sent, these n bytes are preceded by a byte with the
|
||
left-most bit set to 0 and the right-most 7 bits containing the
|
||
number n.
|
||
|
||
Byte string:
|
||
|
||
1 7 8 8
|
||
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
||
|0| n | | d(1) | ... | d(n) |
|
||
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
||
^ ^
|
||
|---n bytes---|
|
||
of data
|
||
|
||
String of n data bytes d(1),..., d(n)
|
||
Count n must be positive.
|
||
|
||
To compress a string of n replications of the data byte d, the
|
||
following 2 bytes are sent:
|
||
|
||
Replicated Byte:
|
||
|
||
2 6 8
|
||
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
||
|1 0| n | | d |
|
||
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
||
|
||
A string of n filler bytes can be compressed into a single
|
||
byte, where the filler byte varies with the representation
|
||
type. If the type is ASCII or EBCDIC the filler byte is <SP>
|
||
(Space, ASCII code 32, EBCDIC code 64). If the type is Image
|
||
or Local byte the filler is a zero byte.
|
||
|
||
Filler String:
|
||
|
||
2 6
|
||
+-+-+-+-+-+-+-+-+
|
||
|1 1| n |
|
||
+-+-+-+-+-+-+-+-+
|
||
|
||
The escape sequence is a double byte, the first of which is the
|
||
|
||
|
||
Postel & Reynolds [Page 23]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
escape byte (all zeros) and the second of which contains
|
||
descriptor codes as defined in Block mode. The descriptor
|
||
codes have the same meaning as in Block mode and apply to the
|
||
succeeding string of bytes.
|
||
|
||
Compressed mode is useful for obtaining increased bandwidth on
|
||
very large network transmissions at a little extra CPU cost.
|
||
It can be most effectively used to reduce the size of printer
|
||
files such as those generated by RJE hosts.
|
||
|
||
3.5. ERROR RECOVERY AND RESTART
|
||
|
||
There is no provision for detecting bits lost or scrambled in data
|
||
transfer; this level of error control is handled by the TCP.
|
||
However, a restart procedure is provided to protect users from
|
||
gross system failures (including failures of a host, an
|
||
FTP-process, or the underlying network).
|
||
|
||
The restart procedure is defined only for the block and compressed
|
||
modes of data transfer. It requires the sender of data to insert
|
||
a special marker code in the data stream with some marker
|
||
information. The marker information has meaning only to the
|
||
sender, but must consist of printable characters in the default or
|
||
negotiated language of the control connection (ASCII or EBCDIC).
|
||
The marker could represent a bit-count, a record-count, or any
|
||
other information by which a system may identify a data
|
||
checkpoint. The receiver of data, if it implements the restart
|
||
procedure, would then mark the corresponding position of this
|
||
marker in the receiving system, and return this information to the
|
||
user.
|
||
|
||
In the event of a system failure, the user can restart the data
|
||
transfer by identifying the marker point with the FTP restart
|
||
procedure. The following example illustrates the use of the
|
||
restart procedure.
|
||
|
||
The sender of the data inserts an appropriate marker block in the
|
||
data stream at a convenient point. The receiving host marks the
|
||
corresponding data point in its file system and conveys the last
|
||
known sender and receiver marker information to the user, either
|
||
directly or over the control connection in a 110 reply (depending
|
||
on who is the sender). In the event of a system failure, the user
|
||
or controller process restarts the server at the last server
|
||
marker by sending a restart command with server's marker code as
|
||
its argument. The restart command is transmitted over the control
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 24]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
connection and is immediately followed by the command (such as
|
||
RETR, STOR or LIST) which was being executed when the system
|
||
failure occurred.
|
||
|
||
4. FILE TRANSFER FUNCTIONS
|
||
|
||
The communication channel from the user-PI to the server-PI is
|
||
established as a TCP connection from the user to the standard server
|
||
port. The user protocol interpreter is responsible for sending FTP
|
||
commands and interpreting the replies received; the server-PI
|
||
interprets commands, sends replies and directs its DTP to set up the
|
||
data connection and transfer the data. If the second party to the
|
||
data transfer (the passive transfer process) is the user-DTP, then it
|
||
is governed through the internal protocol of the user-FTP host; if it
|
||
is a second server-DTP, then it is governed by its PI on command from
|
||
the user-PI. The FTP replies are discussed in the next section. In
|
||
the description of a few of the commands in this section, it is
|
||
helpful to be explicit about the possible replies.
|
||
|
||
4.1. FTP COMMANDS
|
||
|
||
4.1.1. ACCESS CONTROL COMMANDS
|
||
|
||
The following commands specify access control identifiers
|
||
(command codes are shown in parentheses).
|
||
|
||
USER NAME (USER)
|
||
|
||
The argument field is a Telnet string identifying the user.
|
||
The user identification is that which is required by the
|
||
server for access to its file system. This command will
|
||
normally be the first command transmitted by the user after
|
||
the control connections are made (some servers may require
|
||
this). Additional identification information in the form of
|
||
a password and/or an account command may also be required by
|
||
some servers. Servers may allow a new USER command to be
|
||
entered at any point in order to change the access control
|
||
and/or accounting information. This has the effect of
|
||
flushing any user, password, and account information already
|
||
supplied and beginning the login sequence again. All
|
||
transfer parameters are unchanged and any file transfer in
|
||
progress is completed under the old access control
|
||
parameters.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 25]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
PASSWORD (PASS)
|
||
|
||
The argument field is a Telnet string specifying the user's
|
||
password. This command must be immediately preceded by the
|
||
user name command, and, for some sites, completes the user's
|
||
identification for access control. Since password
|
||
information is quite sensitive, it is desirable in general
|
||
to "mask" it or suppress typeout. It appears that the
|
||
server has no foolproof way to achieve this. It is
|
||
therefore the responsibility of the user-FTP process to hide
|
||
the sensitive password information.
|
||
|
||
ACCOUNT (ACCT)
|
||
|
||
The argument field is a Telnet string identifying the user's
|
||
account. The command is not necessarily related to the USER
|
||
command, as some sites may require an account for login and
|
||
others only for specific access, such as storing files. In
|
||
the latter case the command may arrive at any time.
|
||
|
||
There are reply codes to differentiate these cases for the
|
||
automation: when account information is required for login,
|
||
the response to a successful PASSword command is reply code
|
||
332. On the other hand, if account information is NOT
|
||
required for login, the reply to a successful PASSword
|
||
command is 230; and if the account information is needed for
|
||
a command issued later in the dialogue, the server should
|
||
return a 332 or 532 reply depending on whether it stores
|
||
(pending receipt of the ACCounT command) or discards the
|
||
command, respectively.
|
||
|
||
CHANGE WORKING DIRECTORY (CWD)
|
||
|
||
This command allows the user to work with a different
|
||
directory or dataset for file storage or retrieval without
|
||
altering his login or accounting information. Transfer
|
||
parameters are similarly unchanged. The argument is a
|
||
pathname specifying a directory or other system dependent
|
||
file group designator.
|
||
|
||
CHANGE TO PARENT DIRECTORY (CDUP)
|
||
|
||
This command is a special case of CWD, and is included to
|
||
simplify the implementation of programs for transferring
|
||
directory trees between operating systems having different
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 26]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
syntaxes for naming the parent directory. The reply codes
|
||
shall be identical to the reply codes of CWD. See
|
||
Appendix II for further details.
|
||
|
||
STRUCTURE MOUNT (SMNT)
|
||
|
||
This command allows the user to mount a different file
|
||
system data structure without altering his login or
|
||
accounting information. Transfer parameters are similarly
|
||
unchanged. The argument is a pathname specifying a
|
||
directory or other system dependent file group designator.
|
||
|
||
REINITIALIZE (REIN)
|
||
|
||
This command terminates a USER, flushing all I/O and account
|
||
information, except to allow any transfer in progress to be
|
||
completed. All parameters are reset to the default settings
|
||
and the control connection is left open. This is identical
|
||
to the state in which a user finds himself immediately after
|
||
the control connection is opened. A USER command may be
|
||
expected to follow.
|
||
|
||
LOGOUT (QUIT)
|
||
|
||
This command terminates a USER and if file transfer is not
|
||
in progress, the server closes the control connection. If
|
||
file transfer is in progress, the connection will remain
|
||
open for result response and the server will then close it.
|
||
If the user-process is transferring files for several USERs
|
||
but does not wish to close and then reopen connections for
|
||
each, then the REIN command should be used instead of QUIT.
|
||
|
||
An unexpected close on the control connection will cause the
|
||
server to take the effective action of an abort (ABOR) and a
|
||
logout (QUIT).
|
||
|
||
4.1.2. TRANSFER PARAMETER COMMANDS
|
||
|
||
All data transfer parameters have default values, and the
|
||
commands specifying data transfer parameters are required only
|
||
if the default parameter values are to be changed. The default
|
||
value is the last specified value, or if no value has been
|
||
specified, the standard default value is as stated here. This
|
||
implies that the server must "remember" the applicable default
|
||
values. The commands may be in any order except that they must
|
||
precede the FTP service request. The following commands
|
||
specify data transfer parameters:
|
||
|
||
|
||
Postel & Reynolds [Page 27]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
DATA PORT (PORT)
|
||
|
||
The argument is a HOST-PORT specification for the data port
|
||
to be used in data connection. There are defaults for both
|
||
the user and server data ports, and under normal
|
||
circumstances this command and its reply are not needed. If
|
||
this command is used, the argument is the concatenation of a
|
||
32-bit internet host address and a 16-bit TCP port address.
|
||
This address information is broken into 8-bit fields and the
|
||
value of each field is transmitted as a decimal number (in
|
||
character string representation). The fields are separated
|
||
by commas. A port command would be:
|
||
|
||
PORT h1,h2,h3,h4,p1,p2
|
||
|
||
where h1 is the high order 8 bits of the internet host
|
||
address.
|
||
|
||
PASSIVE (PASV)
|
||
|
||
This command requests the server-DTP to "listen" on a data
|
||
port (which is not its default data port) and to wait for a
|
||
connection rather than initiate one upon receipt of a
|
||
transfer command. The response to this command includes the
|
||
host and port address this server is listening on.
|
||
|
||
REPRESENTATION TYPE (TYPE)
|
||
|
||
The argument specifies the representation type as described
|
||
in the Section on Data Representation and Storage. Several
|
||
types take a second parameter. The first parameter is
|
||
denoted by a single Telnet character, as is the second
|
||
Format parameter for ASCII and EBCDIC; the second parameter
|
||
for local byte is a decimal integer to indicate Bytesize.
|
||
The parameters are separated by a <SP> (Space, ASCII code
|
||
32).
|
||
|
||
The following codes are assigned for type:
|
||
|
||
\ /
|
||
A - ASCII | | N - Non-print
|
||
|-><-| T - Telnet format effectors
|
||
E - EBCDIC| | C - Carriage Control (ASA)
|
||
/ \
|
||
I - Image
|
||
|
||
L <byte size> - Local byte Byte size
|
||
|
||
|
||
Postel & Reynolds [Page 28]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
The default representation type is ASCII Non-print. If the
|
||
Format parameter is changed, and later just the first
|
||
argument is changed, Format then returns to the Non-print
|
||
default.
|
||
|
||
FILE STRUCTURE (STRU)
|
||
|
||
The argument is a single Telnet character code specifying
|
||
file structure described in the Section on Data
|
||
Representation and Storage.
|
||
|
||
The following codes are assigned for structure:
|
||
|
||
F - File (no record structure)
|
||
R - Record structure
|
||
P - Page structure
|
||
|
||
The default structure is File.
|
||
|
||
TRANSFER MODE (MODE)
|
||
|
||
The argument is a single Telnet character code specifying
|
||
the data transfer modes described in the Section on
|
||
Transmission Modes.
|
||
|
||
The following codes are assigned for transfer modes:
|
||
|
||
S - Stream
|
||
B - Block
|
||
C - Compressed
|
||
|
||
The default transfer mode is Stream.
|
||
|
||
4.1.3. FTP SERVICE COMMANDS
|
||
|
||
The FTP service commands define the file transfer or the file
|
||
system function requested by the user. The argument of an FTP
|
||
service command will normally be a pathname. The syntax of
|
||
pathnames must conform to server site conventions (with
|
||
standard defaults applicable), and the language conventions of
|
||
the control connection. The suggested default handling is to
|
||
use the last specified device, directory or file name, or the
|
||
standard default defined for local users. The commands may be
|
||
in any order except that a "rename from" command must be
|
||
followed by a "rename to" command and the restart command must
|
||
be followed by the interrupted service command (e.g., STOR or
|
||
RETR). The data, when transferred in response to FTP service
|
||
|
||
|
||
Postel & Reynolds [Page 29]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
commands, shall always be sent over the data connection, except
|
||
for certain informative replies. The following commands
|
||
specify FTP service requests:
|
||
|
||
RETRIEVE (RETR)
|
||
|
||
This command causes the server-DTP to transfer a copy of the
|
||
file, specified in the pathname, to the server- or user-DTP
|
||
at the other end of the data connection. The status and
|
||
contents of the file at the server site shall be unaffected.
|
||
|
||
STORE (STOR)
|
||
|
||
This command causes the server-DTP to accept the data
|
||
transferred via the data connection and to store the data as
|
||
a file at the server site. If the file specified in the
|
||
pathname exists at the server site, then its contents shall
|
||
be replaced by the data being transferred. A new file is
|
||
created at the server site if the file specified in the
|
||
pathname does not already exist.
|
||
|
||
STORE UNIQUE (STOU)
|
||
|
||
This command behaves like STOR except that the resultant
|
||
file is to be created in the current directory under a name
|
||
unique to that directory. The 250 Transfer Started response
|
||
must include the name generated.
|
||
|
||
APPEND (with create) (APPE)
|
||
|
||
This command causes the server-DTP to accept the data
|
||
transferred via the data connection and to store the data in
|
||
a file at the server site. If the file specified in the
|
||
pathname exists at the server site, then the data shall be
|
||
appended to that file; otherwise the file specified in the
|
||
pathname shall be created at the server site.
|
||
|
||
ALLOCATE (ALLO)
|
||
|
||
This command may be required by some servers to reserve
|
||
sufficient storage to accommodate the new file to be
|
||
transferred. The argument shall be a decimal integer
|
||
representing the number of bytes (using the logical byte
|
||
size) of storage to be reserved for the file. For files
|
||
sent with record or page structure a maximum record or page
|
||
size (in logical bytes) might also be necessary; this is
|
||
indicated by a decimal integer in a second argument field of
|
||
|
||
|
||
Postel & Reynolds [Page 30]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
the command. This second argument is optional, but when
|
||
present should be separated from the first by the three
|
||
Telnet characters <SP> R <SP>. This command shall be
|
||
followed by a STORe or APPEnd command. The ALLO command
|
||
should be treated as a NOOP (no operation) by those servers
|
||
which do not require that the maximum size of the file be
|
||
declared beforehand, and those servers interested in only
|
||
the maximum record or page size should accept a dummy value
|
||
in the first argument and ignore it.
|
||
|
||
RESTART (REST)
|
||
|
||
The argument field represents the server marker at which
|
||
file transfer is to be restarted. This command does not
|
||
cause file transfer but skips over the file to the specified
|
||
data checkpoint. This command shall be immediately followed
|
||
by the appropriate FTP service command which shall cause
|
||
file transfer to resume.
|
||
|
||
RENAME FROM (RNFR)
|
||
|
||
This command specifies the old pathname of the file which is
|
||
to be renamed. This command must be immediately followed by
|
||
a "rename to" command specifying the new file pathname.
|
||
|
||
RENAME TO (RNTO)
|
||
|
||
This command specifies the new pathname of the file
|
||
specified in the immediately preceding "rename from"
|
||
command. Together the two commands cause a file to be
|
||
renamed.
|
||
|
||
ABORT (ABOR)
|
||
|
||
This command tells the server to abort the previous FTP
|
||
service command and any associated transfer of data. The
|
||
abort command may require "special action", as discussed in
|
||
the Section on FTP Commands, to force recognition by the
|
||
server. No action is to be taken if the previous command
|
||
has been completed (including data transfer). The control
|
||
connection is not to be closed by the server, but the data
|
||
connection must be closed.
|
||
|
||
There are two cases for the server upon receipt of this
|
||
command: (1) the FTP service command was already completed,
|
||
or (2) the FTP service command is still in progress.
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 31]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
In the first case, the server closes the data connection
|
||
(if it is open) and responds with a 226 reply, indicating
|
||
that the abort command was successfully processed.
|
||
|
||
In the second case, the server aborts the FTP service in
|
||
progress and closes the data connection, returning a 426
|
||
reply to indicate that the service request terminated
|
||
abnormally. The server then sends a 226 reply,
|
||
indicating that the abort command was successfully
|
||
processed.
|
||
|
||
DELETE (DELE)
|
||
|
||
This command causes the file specified in the pathname to be
|
||
deleted at the server site. If an extra level of protection
|
||
is desired (such as the query, "Do you really wish to
|
||
delete?"), it should be provided by the user-FTP process.
|
||
|
||
REMOVE DIRECTORY (RMD)
|
||
|
||
This command causes the directory specified in the pathname
|
||
to be removed as a directory (if the pathname is absolute)
|
||
or as a subdirectory of the current working directory (if
|
||
the pathname is relative). See Appendix II.
|
||
|
||
MAKE DIRECTORY (MKD)
|
||
|
||
This command causes the directory specified in the pathname
|
||
to be created as a directory (if the pathname is absolute)
|
||
or as a subdirectory of the current working directory (if
|
||
the pathname is relative). See Appendix II.
|
||
|
||
PRINT WORKING DIRECTORY (PWD)
|
||
|
||
This command causes the name of the current working
|
||
directory to be returned in the reply. See Appendix II.
|
||
|
||
LIST (LIST)
|
||
|
||
This command causes a list to be sent from the server to the
|
||
passive DTP. If the pathname specifies a directory or other
|
||
group of files, the server should transfer a list of files
|
||
in the specified directory. If the pathname specifies a
|
||
file then the server should send current information on the
|
||
file. A null argument implies the user's current working or
|
||
default directory. The data transfer is over the data
|
||
connection in type ASCII or type EBCDIC. (The user must
|
||
|
||
|
||
Postel & Reynolds [Page 32]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
ensure that the TYPE is appropriately ASCII or EBCDIC).
|
||
Since the information on a file may vary widely from system
|
||
to system, this information may be hard to use automatically
|
||
in a program, but may be quite useful to a human user.
|
||
|
||
NAME LIST (NLST)
|
||
|
||
This command causes a directory listing to be sent from
|
||
server to user site. The pathname should specify a
|
||
directory or other system-specific file group descriptor; a
|
||
null argument implies the current directory. The server
|
||
will return a stream of names of files and no other
|
||
information. The data will be transferred in ASCII or
|
||
EBCDIC type over the data connection as valid pathname
|
||
strings separated by <CRLF> or <NL>. (Again the user must
|
||
ensure that the TYPE is correct.) This command is intended
|
||
to return information that can be used by a program to
|
||
further process the files automatically. For example, in
|
||
the implementation of a "multiple get" function.
|
||
|
||
SITE PARAMETERS (SITE)
|
||
|
||
This command is used by the server to provide services
|
||
specific to his system that are essential to file transfer
|
||
but not sufficiently universal to be included as commands in
|
||
the protocol. The nature of these services and the
|
||
specification of their syntax can be stated in a reply to
|
||
the HELP SITE command.
|
||
|
||
SYSTEM (SYST)
|
||
|
||
This command is used to find out the type of operating
|
||
system at the server. The reply shall have as its first
|
||
word one of the system names listed in the current version
|
||
of the Assigned Numbers document [4].
|
||
|
||
STATUS (STAT)
|
||
|
||
This command shall cause a status response to be sent over
|
||
the control connection in the form of a reply. The command
|
||
may be sent during a file transfer (along with the Telnet IP
|
||
and Synch signals--see the Section on FTP Commands) in which
|
||
case the server will respond with the status of the
|
||
operation in progress, or it may be sent between file
|
||
transfers. In the latter case, the command may have an
|
||
argument field. If the argument is a pathname, the command
|
||
is analogous to the "list" command except that data shall be
|
||
|
||
|
||
Postel & Reynolds [Page 33]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
transferred over the control connection. If a partial
|
||
pathname is given, the server may respond with a list of
|
||
file names or attributes associated with that specification.
|
||
If no argument is given, the server should return general
|
||
status information about the server FTP process. This
|
||
should include current values of all transfer parameters and
|
||
the status of connections.
|
||
|
||
HELP (HELP)
|
||
|
||
This command shall cause the server to send helpful
|
||
information regarding its implementation status over the
|
||
control connection to the user. The command may take an
|
||
argument (e.g., any command name) and return more specific
|
||
information as a response. The reply is type 211 or 214.
|
||
It is suggested that HELP be allowed before entering a USER
|
||
command. The server may use this reply to specify
|
||
site-dependent parameters, e.g., in response to HELP SITE.
|
||
|
||
NOOP (NOOP)
|
||
|
||
This command does not affect any parameters or previously
|
||
entered commands. It specifies no action other than that the
|
||
server send an OK reply.
|
||
|
||
The File Transfer Protocol follows the specifications of the Telnet
|
||
protocol for all communications over the control connection. Since
|
||
the language used for Telnet communication may be a negotiated
|
||
option, all references in the next two sections will be to the
|
||
"Telnet language" and the corresponding "Telnet end-of-line code".
|
||
Currently, one may take these to mean NVT-ASCII and <CRLF>. No other
|
||
specifications of the Telnet protocol will be cited.
|
||
|
||
FTP commands are "Telnet strings" terminated by the "Telnet end of
|
||
line code". The command codes themselves are alphabetic characters
|
||
terminated by the character <SP> (Space) if parameters follow and
|
||
Telnet-EOL otherwise. The command codes and the semantics of
|
||
commands are described in this section; the detailed syntax of
|
||
commands is specified in the Section on Commands, the reply sequences
|
||
are discussed in the Section on Sequencing of Commands and Replies,
|
||
and scenarios illustrating the use of commands are provided in the
|
||
Section on Typical FTP Scenarios.
|
||
|
||
FTP commands may be partitioned as those specifying access-control
|
||
identifiers, data transfer parameters, or FTP service requests.
|
||
Certain commands (such as ABOR, STAT, QUIT) may be sent over the
|
||
control connection while a data transfer is in progress. Some
|
||
|
||
|
||
Postel & Reynolds [Page 34]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
servers may not be able to monitor the control and data connections
|
||
simultaneously, in which case some special action will be necessary
|
||
to get the server's attention. The following ordered format is
|
||
tentatively recommended:
|
||
|
||
1. User system inserts the Telnet "Interrupt Process" (IP) signal
|
||
in the Telnet stream.
|
||
|
||
2. User system sends the Telnet "Synch" signal.
|
||
|
||
3. User system inserts the command (e.g., ABOR) in the Telnet
|
||
stream.
|
||
|
||
4. Server PI, after receiving "IP", scans the Telnet stream for
|
||
EXACTLY ONE FTP command.
|
||
|
||
(For other servers this may not be necessary but the actions listed
|
||
above should have no unusual effect.)
|
||
|
||
4.2. FTP REPLIES
|
||
|
||
Replies to File Transfer Protocol commands are devised to ensure
|
||
the synchronization of requests and actions in the process of file
|
||
transfer, and to guarantee that the user process always knows the
|
||
state of the Server. Every command must generate at least one
|
||
reply, although there may be more than one; in the latter case,
|
||
the multiple replies must be easily distinguished. In addition,
|
||
some commands occur in sequential groups, such as USER, PASS and
|
||
ACCT, or RNFR and RNTO. The replies show the existence of an
|
||
intermediate state if all preceding commands have been successful.
|
||
A failure at any point in the sequence necessitates the repetition
|
||
of the entire sequence from the beginning.
|
||
|
||
The details of the command-reply sequence are made explicit in
|
||
a set of state diagrams below.
|
||
|
||
An FTP reply consists of a three digit number (transmitted as
|
||
three alphanumeric characters) followed by some text. The number
|
||
is intended for use by automata to determine what state to enter
|
||
next; the text is intended for the human user. It is intended
|
||
that the three digits contain enough encoded information that the
|
||
user-process (the User-PI) will not need to examine the text and
|
||
may either discard it or pass it on to the user, as appropriate.
|
||
In particular, the text may be server-dependent, so there are
|
||
likely to be varying texts for each reply code.
|
||
|
||
A reply is defined to contain the 3-digit code, followed by Space
|
||
|
||
|
||
Postel & Reynolds [Page 35]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
<SP>, followed by one line of text (where some maximum line length
|
||
has been specified), and terminated by the Telnet end-of-line
|
||
code. There will be cases however, where the text is longer than
|
||
a single line. In these cases the complete text must be bracketed
|
||
so the User-process knows when it may stop reading the reply (i.e.
|
||
stop processing input on the control connection) and go do other
|
||
things. This requires a special format on the first line to
|
||
indicate that more than one line is coming, and another on the
|
||
last line to designate it as the last. At least one of these must
|
||
contain the appropriate reply code to indicate the state of the
|
||
transaction. To satisfy all factions, it was decided that both
|
||
the first and last line codes should be the same.
|
||
|
||
Thus the format for multi-line replies is that the first line
|
||
will begin with the exact required reply code, followed
|
||
immediately by a Hyphen, "-" (also known as Minus), followed by
|
||
text. The last line will begin with the same code, followed
|
||
immediately by Space <SP>, optionally some text, and the Telnet
|
||
end-of-line code.
|
||
|
||
For example:
|
||
123-First line
|
||
Second line
|
||
234 A line beginning with numbers
|
||
123 The last line
|
||
|
||
The user-process then simply needs to search for the second
|
||
occurrence of the same reply code, followed by <SP> (Space), at
|
||
the beginning of a line, and ignore all intermediary lines. If
|
||
an intermediary line begins with a 3-digit number, the Server
|
||
must pad the front to avoid confusion.
|
||
|
||
This scheme allows standard system routines to be used for
|
||
reply information (such as for the STAT reply), with
|
||
"artificial" first and last lines tacked on. In rare cases
|
||
where these routines are able to generate three digits and a
|
||
Space at the beginning of any line, the beginning of each
|
||
text line should be offset by some neutral text, like Space.
|
||
|
||
This scheme assumes that multi-line replies may not be nested.
|
||
|
||
The three digits of the reply each have a special significance.
|
||
This is intended to allow a range of very simple to very
|
||
sophisticated responses by the user-process. The first digit
|
||
denotes whether the response is good, bad or incomplete.
|
||
(Referring to the state diagram), an unsophisticated user-process
|
||
will be able to determine its next action (proceed as planned,
|
||
|
||
|
||
Postel & Reynolds [Page 36]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
redo, retrench, etc.) by simply examining this first digit. A
|
||
user-process that wants to know approximately what kind of error
|
||
occurred (e.g. file system error, command syntax error) may
|
||
examine the second digit, reserving the third digit for the finest
|
||
gradation of information (e.g., RNTO command without a preceding
|
||
RNFR).
|
||
|
||
There are five values for the first digit of the reply code:
|
||
|
||
1yz Positive Preliminary reply
|
||
|
||
The requested action is being initiated; expect another
|
||
reply before proceeding with a new command. (The
|
||
user-process sending another command before the
|
||
completion reply would be in violation of protocol; but
|
||
server-FTP processes should queue any commands that
|
||
arrive while a preceding command is in progress.) This
|
||
type of reply can be used to indicate that the command
|
||
was accepted and the user-process may now pay attention
|
||
to the data connections, for implementations where
|
||
simultaneous monitoring is difficult. The server-FTP
|
||
process may send at most, one 1yz reply per command.
|
||
|
||
2yz Positive Completion reply
|
||
|
||
The requested action has been successfully completed. A
|
||
new request may be initiated.
|
||
|
||
3yz Positive Intermediate reply
|
||
|
||
The command has been accepted, but the requested action
|
||
is being held in abeyance, pending receipt of further
|
||
information. The user should send another command
|
||
specifying this information. This reply is used in
|
||
command sequence groups.
|
||
|
||
4yz Transient Negative Completion reply
|
||
|
||
The command was not accepted and the requested action did
|
||
not take place, but the error condition is temporary and
|
||
the action may be requested again. The user should
|
||
return to the beginning of the command sequence, if any.
|
||
It is difficult to assign a meaning to "transient",
|
||
particularly when two distinct sites (Server- and
|
||
User-processes) have to agree on the interpretation.
|
||
Each reply in the 4yz category might have a slightly
|
||
different time value, but the intent is that the
|
||
|
||
|
||
Postel & Reynolds [Page 37]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
user-process is encouraged to try again. A rule of thumb
|
||
in determining if a reply fits into the 4yz or the 5yz
|
||
(Permanent Negative) category is that replies are 4yz if
|
||
the commands can be repeated without any change in
|
||
command form or in properties of the User or Server
|
||
(e.g., the command is spelled the same with the same
|
||
arguments used; the user does not change his file access
|
||
or user name; the server does not put up a new
|
||
implementation.)
|
||
|
||
5yz Permanent Negative Completion reply
|
||
|
||
The command was not accepted and the requested action did
|
||
not take place. The User-process is discouraged from
|
||
repeating the exact request (in the same sequence). Even
|
||
some "permanent" error conditions can be corrected, so
|
||
the human user may want to direct his User-process to
|
||
reinitiate the command sequence by direct action at some
|
||
point in the future (e.g., after the spelling has been
|
||
changed, or the user has altered his directory status.)
|
||
|
||
The following function groupings are encoded in the second
|
||
digit:
|
||
|
||
x0z Syntax - These replies refer to syntax errors,
|
||
syntactically correct commands that don't fit any
|
||
functional category, unimplemented or superfluous
|
||
commands.
|
||
|
||
x1z Information - These are replies to requests for
|
||
information, such as status or help.
|
||
|
||
x2z Connections - Replies referring to the control and
|
||
data connections.
|
||
|
||
x3z Authentication and accounting - Replies for the login
|
||
process and accounting procedures.
|
||
|
||
x4z Unspecified as yet.
|
||
|
||
x5z File system - These replies indicate the status of the
|
||
Server file system vis-a-vis the requested transfer or
|
||
other file system action.
|
||
|
||
The third digit gives a finer gradation of meaning in each of
|
||
the function categories, specified by the second digit. The
|
||
list of replies below will illustrate this. Note that the text
|
||
|
||
|
||
Postel & Reynolds [Page 38]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
associated with each reply is recommended, rather than
|
||
mandatory, and may even change according to the command with
|
||
which it is associated. The reply codes, on the other hand,
|
||
must strictly follow the specifications in the last section;
|
||
that is, Server implementations should not invent new codes for
|
||
situations that are only slightly different from the ones
|
||
described here, but rather should adapt codes already defined.
|
||
|
||
A command such as TYPE or ALLO whose successful execution
|
||
does not offer the user-process any new information will
|
||
cause a 200 reply to be returned. If the command is not
|
||
implemented by a particular Server-FTP process because it
|
||
has no relevance to that computer system, for example ALLO
|
||
at a TOPS20 site, a Positive Completion reply is still
|
||
desired so that the simple User-process knows it can proceed
|
||
with its course of action. A 202 reply is used in this case
|
||
with, for example, the reply text: "No storage allocation
|
||
necessary." If, on the other hand, the command requests a
|
||
non-site-specific action and is unimplemented, the response
|
||
is 502. A refinement of that is the 504 reply for a command
|
||
that is implemented, but that requests an unimplemented
|
||
parameter.
|
||
|
||
4.2.1 Reply Codes by Function Groups
|
||
|
||
200 Command okay.
|
||
500 Syntax error, command unrecognized.
|
||
This may include errors such as command line too long.
|
||
501 Syntax error in parameters or arguments.
|
||
202 Command not implemented, superfluous at this site.
|
||
502 Command not implemented.
|
||
503 Bad sequence of commands.
|
||
504 Command not implemented for that parameter.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 39]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
110 Restart marker reply.
|
||
In this case, the text is exact and not left to the
|
||
particular implementation; it must read:
|
||
MARK yyyy = mmmm
|
||
Where yyyy is User-process data stream marker, and mmmm
|
||
server's equivalent marker (note the spaces between markers
|
||
and "=").
|
||
211 System status, or system help reply.
|
||
212 Directory status.
|
||
213 File status.
|
||
214 Help message.
|
||
On how to use the server or the meaning of a particular
|
||
non-standard command. This reply is useful only to the
|
||
human user.
|
||
215 NAME system type.
|
||
Where NAME is an official system name from the list in the
|
||
Assigned Numbers document.
|
||
|
||
120 Service ready in nnn minutes.
|
||
220 Service ready for new user.
|
||
221 Service closing control connection.
|
||
Logged out if appropriate.
|
||
421 Service not available, closing control connection.
|
||
This may be a reply to any command if the service knows it
|
||
must shut down.
|
||
125 Data connection already open; transfer starting.
|
||
225 Data connection open; no transfer in progress.
|
||
425 Can't open data connection.
|
||
226 Closing data connection.
|
||
Requested file action successful (for example, file
|
||
transfer or file abort).
|
||
426 Connection closed; transfer aborted.
|
||
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
|
||
|
||
230 User logged in, proceed.
|
||
530 Not logged in.
|
||
331 User name okay, need password.
|
||
332 Need account for login.
|
||
532 Need account for storing files.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 40]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
150 File status okay; about to open data connection.
|
||
250 Requested file action okay, completed.
|
||
257 "PATHNAME" created.
|
||
350 Requested file action pending further information.
|
||
450 Requested file action not taken.
|
||
File unavailable (e.g., file busy).
|
||
550 Requested action not taken.
|
||
File unavailable (e.g., file not found, no access).
|
||
451 Requested action aborted. Local error in processing.
|
||
551 Requested action aborted. Page type unknown.
|
||
452 Requested action not taken.
|
||
Insufficient storage space in system.
|
||
552 Requested file action aborted.
|
||
Exceeded storage allocation (for current directory or
|
||
dataset).
|
||
553 Requested action not taken.
|
||
File name not allowed.
|
||
|
||
|
||
4.2.2 Numeric Order List of Reply Codes
|
||
|
||
110 Restart marker reply.
|
||
In this case, the text is exact and not left to the
|
||
particular implementation; it must read:
|
||
MARK yyyy = mmmm
|
||
Where yyyy is User-process data stream marker, and mmmm
|
||
server's equivalent marker (note the spaces between markers
|
||
and "=").
|
||
120 Service ready in nnn minutes.
|
||
125 Data connection already open; transfer starting.
|
||
150 File status okay; about to open data connection.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 41]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
200 Command okay.
|
||
202 Command not implemented, superfluous at this site.
|
||
211 System status, or system help reply.
|
||
212 Directory status.
|
||
213 File status.
|
||
214 Help message.
|
||
On how to use the server or the meaning of a particular
|
||
non-standard command. This reply is useful only to the
|
||
human user.
|
||
215 NAME system type.
|
||
Where NAME is an official system name from the list in the
|
||
Assigned Numbers document.
|
||
220 Service ready for new user.
|
||
221 Service closing control connection.
|
||
Logged out if appropriate.
|
||
225 Data connection open; no transfer in progress.
|
||
226 Closing data connection.
|
||
Requested file action successful (for example, file
|
||
transfer or file abort).
|
||
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
|
||
230 User logged in, proceed.
|
||
250 Requested file action okay, completed.
|
||
257 "PATHNAME" created.
|
||
|
||
331 User name okay, need password.
|
||
332 Need account for login.
|
||
350 Requested file action pending further information.
|
||
|
||
421 Service not available, closing control connection.
|
||
This may be a reply to any command if the service knows it
|
||
must shut down.
|
||
425 Can't open data connection.
|
||
426 Connection closed; transfer aborted.
|
||
450 Requested file action not taken.
|
||
File unavailable (e.g., file busy).
|
||
451 Requested action aborted: local error in processing.
|
||
452 Requested action not taken.
|
||
Insufficient storage space in system.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 42]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
500 Syntax error, command unrecognized.
|
||
This may include errors such as command line too long.
|
||
501 Syntax error in parameters or arguments.
|
||
502 Command not implemented.
|
||
503 Bad sequence of commands.
|
||
504 Command not implemented for that parameter.
|
||
530 Not logged in.
|
||
532 Need account for storing files.
|
||
550 Requested action not taken.
|
||
File unavailable (e.g., file not found, no access).
|
||
551 Requested action aborted: page type unknown.
|
||
552 Requested file action aborted.
|
||
Exceeded storage allocation (for current directory or
|
||
dataset).
|
||
553 Requested action not taken.
|
||
File name not allowed.
|
||
|
||
|
||
5. DECLARATIVE SPECIFICATIONS
|
||
|
||
5.1. MINIMUM IMPLEMENTATION
|
||
|
||
In order to make FTP workable without needless error messages, the
|
||
following minimum implementation is required for all servers:
|
||
|
||
TYPE - ASCII Non-print
|
||
MODE - Stream
|
||
STRUCTURE - File, Record
|
||
COMMANDS - USER, QUIT, PORT,
|
||
TYPE, MODE, STRU,
|
||
for the default values
|
||
RETR, STOR,
|
||
NOOP.
|
||
|
||
The default values for transfer parameters are:
|
||
|
||
TYPE - ASCII Non-print
|
||
MODE - Stream
|
||
STRU - File
|
||
|
||
All hosts must accept the above as the standard defaults.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 43]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
5.2. CONNECTIONS
|
||
|
||
The server protocol interpreter shall "listen" on Port L. The
|
||
user or user protocol interpreter shall initiate the full-duplex
|
||
control connection. Server- and user- processes should follow the
|
||
conventions of the Telnet protocol as specified in the
|
||
ARPA-Internet Protocol Handbook [1]. Servers are under no
|
||
obligation to provide for editing of command lines and may require
|
||
that it be done in the user host. The control connection shall be
|
||
closed by the server at the user's request after all transfers and
|
||
replies are completed.
|
||
|
||
The user-DTP must "listen" on the specified data port; this may be
|
||
the default user port (U) or a port specified in the PORT command.
|
||
The server shall initiate the data connection from his own default
|
||
data port (L-1) using the specified user data port. The direction
|
||
of the transfer and the port used will be determined by the FTP
|
||
service command.
|
||
|
||
Note that all FTP implementation must support data transfer using
|
||
the default port, and that only the USER-PI may initiate the use
|
||
of non-default ports.
|
||
|
||
When data is to be transferred between two servers, A and B (refer
|
||
to Figure 2), the user-PI, C, sets up control connections with
|
||
both server-PI's. One of the servers, say A, is then sent a PASV
|
||
command telling him to "listen" on his data port rather than
|
||
initiate a connection when he receives a transfer service command.
|
||
When the user-PI receives an acknowledgment to the PASV command,
|
||
which includes the identity of the host and port being listened
|
||
on, the user-PI then sends A's port, a, to B in a PORT command; a
|
||
reply is returned. The user-PI may then send the corresponding
|
||
service commands to A and B. Server B initiates the connection
|
||
and the transfer proceeds. The command-reply sequence is listed
|
||
below where the messages are vertically synchronous but
|
||
horizontally asynchronous:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 44]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
User-PI - Server A User-PI - Server B
|
||
------------------ ------------------
|
||
|
||
C->A : Connect C->B : Connect
|
||
C->A : PASV
|
||
A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
|
||
C->B : PORT A1,A2,A3,A4,a1,a2
|
||
B->C : 200 Okay
|
||
C->A : STOR C->B : RETR
|
||
B->A : Connect to HOST-A, PORT-a
|
||
|
||
Figure 3
|
||
|
||
The data connection shall be closed by the server under the
|
||
conditions described in the Section on Establishing Data
|
||
Connections. If the data connection is to be closed following a
|
||
data transfer where closing the connection is not required to
|
||
indicate the end-of-file, the server must do so immediately.
|
||
Waiting until after a new transfer command is not permitted
|
||
because the user-process will have already tested the data
|
||
connection to see if it needs to do a "listen"; (remember that the
|
||
user must "listen" on a closed data port BEFORE sending the
|
||
transfer request). To prevent a race condition here, the server
|
||
sends a reply (226) after closing the data connection (or if the
|
||
connection is left open, a "file transfer completed" reply (250)
|
||
and the user-PI should wait for one of these replies before
|
||
issuing a new transfer command).
|
||
|
||
Any time either the user or server see that the connection is
|
||
being closed by the other side, it should promptly read any
|
||
remaining data queued on the connection and issue the close on its
|
||
own side.
|
||
|
||
5.3. COMMANDS
|
||
|
||
The commands are Telnet character strings transmitted over the
|
||
control connections as described in the Section on FTP Commands.
|
||
The command functions and semantics are described in the Section
|
||
on Access Control Commands, Transfer Parameter Commands, FTP
|
||
Service Commands, and Miscellaneous Commands. The command syntax
|
||
is specified here.
|
||
|
||
The commands begin with a command code followed by an argument
|
||
field. The command codes are four or fewer alphabetic characters.
|
||
Upper and lower case alphabetic characters are to be treated
|
||
identically. Thus, any of the following may represent the
|
||
retrieve command:
|
||
|
||
|
||
Postel & Reynolds [Page 45]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
RETR Retr retr ReTr rETr
|
||
|
||
This also applies to any symbols representing parameter values,
|
||
such as A or a for ASCII TYPE. The command codes and the argument
|
||
fields are separated by one or more spaces.
|
||
|
||
The argument field consists of a variable length character string
|
||
ending with the character sequence <CRLF> (Carriage Return, Line
|
||
Feed) for NVT-ASCII representation; for other negotiated languages
|
||
a different end of line character might be used. It should be
|
||
noted that the server is to take no action until the end of line
|
||
code is received.
|
||
|
||
The syntax is specified below in NVT-ASCII. All characters in the
|
||
argument field are ASCII characters including any ASCII
|
||
represented decimal integers. Square brackets denote an optional
|
||
argument field. If the option is not taken, the appropriate
|
||
default is implied.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 46]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
5.3.1. FTP COMMANDS
|
||
|
||
The following are the FTP commands:
|
||
|
||
USER <SP> <username> <CRLF>
|
||
PASS <SP> <password> <CRLF>
|
||
ACCT <SP> <account-information> <CRLF>
|
||
CWD <SP> <pathname> <CRLF>
|
||
CDUP <CRLF>
|
||
SMNT <SP> <pathname> <CRLF>
|
||
QUIT <CRLF>
|
||
REIN <CRLF>
|
||
PORT <SP> <host-port> <CRLF>
|
||
PASV <CRLF>
|
||
TYPE <SP> <type-code> <CRLF>
|
||
STRU <SP> <structure-code> <CRLF>
|
||
MODE <SP> <mode-code> <CRLF>
|
||
RETR <SP> <pathname> <CRLF>
|
||
STOR <SP> <pathname> <CRLF>
|
||
STOU <CRLF>
|
||
APPE <SP> <pathname> <CRLF>
|
||
ALLO <SP> <decimal-integer>
|
||
[<SP> R <SP> <decimal-integer>] <CRLF>
|
||
REST <SP> <marker> <CRLF>
|
||
RNFR <SP> <pathname> <CRLF>
|
||
RNTO <SP> <pathname> <CRLF>
|
||
ABOR <CRLF>
|
||
DELE <SP> <pathname> <CRLF>
|
||
RMD <SP> <pathname> <CRLF>
|
||
MKD <SP> <pathname> <CRLF>
|
||
PWD <CRLF>
|
||
LIST [<SP> <pathname>] <CRLF>
|
||
NLST [<SP> <pathname>] <CRLF>
|
||
SITE <SP> <string> <CRLF>
|
||
SYST <CRLF>
|
||
STAT [<SP> <pathname>] <CRLF>
|
||
HELP [<SP> <string>] <CRLF>
|
||
NOOP <CRLF>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 47]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
5.3.2. FTP COMMAND ARGUMENTS
|
||
|
||
The syntax of the above argument fields (using BNF notation
|
||
where applicable) is:
|
||
|
||
<username> ::= <string>
|
||
<password> ::= <string>
|
||
<account-information> ::= <string>
|
||
<string> ::= <char> | <char><string>
|
||
<char> ::= any of the 128 ASCII characters except <CR> and
|
||
<LF>
|
||
<marker> ::= <pr-string>
|
||
<pr-string> ::= <pr-char> | <pr-char><pr-string>
|
||
<pr-char> ::= printable characters, any
|
||
ASCII code 33 through 126
|
||
<byte-size> ::= <number>
|
||
<host-port> ::= <host-number>,<port-number>
|
||
<host-number> ::= <number>,<number>,<number>,<number>
|
||
<port-number> ::= <number>,<number>
|
||
<number> ::= any decimal integer 1 through 255
|
||
<form-code> ::= N | T | C
|
||
<type-code> ::= A [<sp> <form-code>]
|
||
| E [<sp> <form-code>]
|
||
| I
|
||
| L <sp> <byte-size>
|
||
<structure-code> ::= F | R | P
|
||
<mode-code> ::= S | B | C
|
||
<pathname> ::= <string>
|
||
<decimal-integer> ::= any decimal integer
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 48]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
5.4. SEQUENCING OF COMMANDS AND REPLIES
|
||
|
||
The communication between the user and server is intended to be an
|
||
alternating dialogue. As such, the user issues an FTP command and
|
||
the server responds with a prompt primary reply. The user should
|
||
wait for this initial primary success or failure response before
|
||
sending further commands.
|
||
|
||
Certain commands require a second reply for which the user should
|
||
also wait. These replies may, for example, report on the progress
|
||
or completion of file transfer or the closing of the data
|
||
connection. They are secondary replies to file transfer commands.
|
||
|
||
One important group of informational replies is the connection
|
||
greetings. Under normal circumstances, a server will send a 220
|
||
reply, "awaiting input", when the connection is completed. The
|
||
user should wait for this greeting message before sending any
|
||
commands. If the server is unable to accept input right away, a
|
||
120 "expected delay" reply should be sent immediately and a 220
|
||
reply when ready. The user will then know not to hang up if there
|
||
is a delay.
|
||
|
||
Spontaneous Replies
|
||
|
||
Sometimes "the system" spontaneously has a message to be sent
|
||
to a user (usually all users). For example, "System going down
|
||
in 15 minutes". There is no provision in FTP for such
|
||
spontaneous information to be sent from the server to the user.
|
||
It is recommended that such information be queued in the
|
||
server-PI and delivered to the user-PI in the next reply
|
||
(possibly making it a multi-line reply).
|
||
|
||
The table below lists alternative success and failure replies for
|
||
each command. These must be strictly adhered to; a server may
|
||
substitute text in the replies, but the meaning and action implied
|
||
by the code numbers and by the specific command reply sequence
|
||
cannot be altered.
|
||
|
||
Command-Reply Sequences
|
||
|
||
In this section, the command-reply sequence is presented. Each
|
||
command is listed with its possible replies; command groups are
|
||
listed together. Preliminary replies are listed first (with
|
||
their succeeding replies indented and under them), then
|
||
positive and negative completion, and finally intermediary
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 49]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
replies with the remaining commands from the sequence
|
||
following. This listing forms the basis for the state
|
||
diagrams, which will be presented separately.
|
||
|
||
Connection Establishment
|
||
120
|
||
220
|
||
220
|
||
421
|
||
Login
|
||
USER
|
||
230
|
||
530
|
||
500, 501, 421
|
||
331, 332
|
||
PASS
|
||
230
|
||
202
|
||
530
|
||
500, 501, 503, 421
|
||
332
|
||
ACCT
|
||
230
|
||
202
|
||
530
|
||
500, 501, 503, 421
|
||
CWD
|
||
250
|
||
500, 501, 502, 421, 530, 550
|
||
CDUP
|
||
200
|
||
500, 501, 502, 421, 530, 550
|
||
SMNT
|
||
202, 250
|
||
500, 501, 502, 421, 530, 550
|
||
Logout
|
||
REIN
|
||
120
|
||
220
|
||
220
|
||
421
|
||
500, 502
|
||
QUIT
|
||
221
|
||
500
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 50]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
Transfer parameters
|
||
PORT
|
||
200
|
||
500, 501, 421, 530
|
||
PASV
|
||
227
|
||
500, 501, 502, 421, 530
|
||
MODE
|
||
200
|
||
500, 501, 504, 421, 530
|
||
TYPE
|
||
200
|
||
500, 501, 504, 421, 530
|
||
STRU
|
||
200
|
||
500, 501, 504, 421, 530
|
||
File action commands
|
||
ALLO
|
||
200
|
||
202
|
||
500, 501, 504, 421, 530
|
||
REST
|
||
500, 501, 502, 421, 530
|
||
350
|
||
STOR
|
||
125, 150
|
||
(110)
|
||
226, 250
|
||
425, 426, 451, 551, 552
|
||
532, 450, 452, 553
|
||
500, 501, 421, 530
|
||
STOU
|
||
125, 150
|
||
(110)
|
||
226, 250
|
||
425, 426, 451, 551, 552
|
||
532, 450, 452, 553
|
||
500, 501, 421, 530
|
||
RETR
|
||
125, 150
|
||
(110)
|
||
226, 250
|
||
425, 426, 451
|
||
450, 550
|
||
500, 501, 421, 530
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 51]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
LIST
|
||
125, 150
|
||
226, 250
|
||
425, 426, 451
|
||
450
|
||
500, 501, 502, 421, 530
|
||
NLST
|
||
125, 150
|
||
226, 250
|
||
425, 426, 451
|
||
450
|
||
500, 501, 502, 421, 530
|
||
APPE
|
||
125, 150
|
||
(110)
|
||
226, 250
|
||
425, 426, 451, 551, 552
|
||
532, 450, 550, 452, 553
|
||
500, 501, 502, 421, 530
|
||
RNFR
|
||
450, 550
|
||
500, 501, 502, 421, 530
|
||
350
|
||
RNTO
|
||
250
|
||
532, 553
|
||
500, 501, 502, 503, 421, 530
|
||
DELE
|
||
250
|
||
450, 550
|
||
500, 501, 502, 421, 530
|
||
RMD
|
||
250
|
||
500, 501, 502, 421, 530, 550
|
||
MKD
|
||
257
|
||
500, 501, 502, 421, 530, 550
|
||
PWD
|
||
257
|
||
500, 501, 502, 421, 550
|
||
ABOR
|
||
225, 226
|
||
500, 501, 502, 421
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 52]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
Informational commands
|
||
SYST
|
||
215
|
||
500, 501, 502, 421
|
||
STAT
|
||
211, 212, 213
|
||
450
|
||
500, 501, 502, 421, 530
|
||
HELP
|
||
211, 214
|
||
500, 501, 502, 421
|
||
Miscellaneous commands
|
||
SITE
|
||
200
|
||
202
|
||
500, 501, 530
|
||
NOOP
|
||
200
|
||
500 421
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 53]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
6. STATE DIAGRAMS
|
||
|
||
Here we present state diagrams for a very simple minded FTP
|
||
implementation. Only the first digit of the reply codes is used.
|
||
There is one state diagram for each group of FTP commands or command
|
||
sequences.
|
||
|
||
The command groupings were determined by constructing a model for
|
||
each command then collecting together the commands with structurally
|
||
identical models.
|
||
|
||
For each command or command sequence there are three possible
|
||
outcomes: success (S), failure (F), and error (E). In the state
|
||
diagrams below we use the symbol B for "begin", and the symbol W for
|
||
"wait for reply".
|
||
|
||
We first present the diagram that represents the largest group of FTP
|
||
commands:
|
||
|
||
|
||
1,3 +---+
|
||
----------->| E |
|
||
| +---+
|
||
|
|
||
+---+ cmd +---+ 2 +---+
|
||
| B |---------->| W |---------->| S |
|
||
+---+ +---+ +---+
|
||
|
|
||
| 4,5 +---+
|
||
----------->| F |
|
||
+---+
|
||
|
||
|
||
This diagram models the commands:
|
||
|
||
ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
|
||
QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 54]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
The other large group of commands is represented by a very similar
|
||
diagram:
|
||
|
||
|
||
3 +---+
|
||
----------->| E |
|
||
| +---+
|
||
|
|
||
+---+ cmd +---+ 2 +---+
|
||
| B |---------->| W |---------->| S |
|
||
+---+ --->+---+ +---+
|
||
| | |
|
||
| | | 4,5 +---+
|
||
| 1 | ----------->| F |
|
||
----- +---+
|
||
|
||
|
||
This diagram models the commands:
|
||
|
||
APPE, LIST, NLST, REIN, RETR, STOR, and STOU.
|
||
|
||
Note that this second model could also be used to represent the first
|
||
group of commands, the only difference being that in the first group
|
||
the 100 series replies are unexpected and therefore treated as error,
|
||
while the second group expects (some may require) 100 series replies.
|
||
Remember that at most, one 100 series reply is allowed per command.
|
||
|
||
The remaining diagrams model command sequences, perhaps the simplest
|
||
of these is the rename sequence:
|
||
|
||
|
||
+---+ RNFR +---+ 1,2 +---+
|
||
| B |---------->| W |---------->| E |
|
||
+---+ +---+ -->+---+
|
||
| | |
|
||
3 | | 4,5 |
|
||
-------------- ------ |
|
||
| | | +---+
|
||
| ------------->| S |
|
||
| | 1,3 | | +---+
|
||
| 2| --------
|
||
| | | |
|
||
V | | |
|
||
+---+ RNTO +---+ 4,5 ----->+---+
|
||
| |---------->| W |---------->| F |
|
||
+---+ +---+ +---+
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 55]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
The next diagram is a simple model of the Restart command:
|
||
|
||
|
||
+---+ REST +---+ 1,2 +---+
|
||
| B |---------->| W |---------->| E |
|
||
+---+ +---+ -->+---+
|
||
| | |
|
||
3 | | 4,5 |
|
||
-------------- ------ |
|
||
| | | +---+
|
||
| ------------->| S |
|
||
| | 3 | | +---+
|
||
| 2| --------
|
||
| | | |
|
||
V | | |
|
||
+---+ cmd +---+ 4,5 ----->+---+
|
||
| |---------->| W |---------->| F |
|
||
+---+ -->+---+ +---+
|
||
| |
|
||
| 1 |
|
||
------
|
||
|
||
|
||
Where "cmd" is APPE, STOR, or RETR.
|
||
|
||
We note that the above three models are similar. The Restart differs
|
||
from the Rename two only in the treatment of 100 series replies at
|
||
the second stage, while the second group expects (some may require)
|
||
100 series replies. Remember that at most, one 100 series reply is
|
||
allowed per command.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 56]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
The most complicated diagram is for the Login sequence:
|
||
|
||
|
||
1
|
||
+---+ USER +---+------------->+---+
|
||
| B |---------->| W | 2 ---->| E |
|
||
+---+ +---+------ | -->+---+
|
||
| | | | |
|
||
3 | | 4,5 | | |
|
||
-------------- ----- | | |
|
||
| | | | |
|
||
| | | | |
|
||
| --------- |
|
||
| 1| | | |
|
||
V | | | |
|
||
+---+ PASS +---+ 2 | ------>+---+
|
||
| |---------->| W |------------->| S |
|
||
+---+ +---+ ---------->+---+
|
||
| | | | |
|
||
3 | |4,5| | |
|
||
-------------- -------- |
|
||
| | | | |
|
||
| | | | |
|
||
| -----------
|
||
| 1,3| | | |
|
||
V | 2| | |
|
||
+---+ ACCT +---+-- | ----->+---+
|
||
| |---------->| W | 4,5 -------->| F |
|
||
+---+ +---+------------->+---+
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 57]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
Finally, we present a generalized diagram that could be used to model
|
||
the command and reply interchange:
|
||
|
||
|
||
------------------------------------
|
||
| |
|
||
Begin | |
|
||
| V |
|
||
| +---+ cmd +---+ 2 +---+ |
|
||
-->| |------->| |---------->| | |
|
||
| | | W | | S |-----|
|
||
-->| | -->| |----- | | |
|
||
| +---+ | +---+ 4,5 | +---+ |
|
||
| | | | | | |
|
||
| | | 1| |3 | +---+ |
|
||
| | | | | | | | |
|
||
| | ---- | ---->| F |-----
|
||
| | | | |
|
||
| | | +---+
|
||
-------------------
|
||
|
|
||
|
|
||
V
|
||
End
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 58]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
7. TYPICAL FTP SCENARIO
|
||
|
||
User at host U wanting to transfer files to/from host S:
|
||
|
||
In general, the user will communicate to the server via a mediating
|
||
user-FTP process. The following may be a typical scenario. The
|
||
user-FTP prompts are shown in parentheses, '---->' represents
|
||
commands from host U to host S, and '<----' represents replies from
|
||
host S to host U.
|
||
|
||
LOCAL COMMANDS BY USER ACTION INVOLVED
|
||
|
||
ftp (host) multics<CR> Connect to host S, port L,
|
||
establishing control connections.
|
||
<---- 220 Service ready <CRLF>.
|
||
username Doe <CR> USER Doe<CRLF>---->
|
||
<---- 331 User name ok,
|
||
need password<CRLF>.
|
||
password mumble <CR> PASS mumble<CRLF>---->
|
||
<---- 230 User logged in<CRLF>.
|
||
retrieve (local type) ASCII<CR>
|
||
(local pathname) test 1 <CR> User-FTP opens local file in ASCII.
|
||
(for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
|
||
<---- 150 File status okay;
|
||
about to open data
|
||
connection<CRLF>.
|
||
Server makes data connection
|
||
to port U.
|
||
|
||
<---- 226 Closing data connection,
|
||
file transfer successful<CRLF>.
|
||
type Image<CR> TYPE I<CRLF> ---->
|
||
<---- 200 Command OK<CRLF>
|
||
store (local type) image<CR>
|
||
(local pathname) file dump<CR> User-FTP opens local file in Image.
|
||
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
|
||
<---- 550 Access denied<CRLF>
|
||
terminate QUIT <CRLF> ---->
|
||
Server closes all
|
||
connections.
|
||
|
||
8. CONNECTION ESTABLISHMENT
|
||
|
||
The FTP control connection is established via TCP between the user
|
||
process port U and the server process port L. This protocol is
|
||
assigned the service port 21 (25 octal), that is L=21.
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 59]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
APPENDIX I - PAGE STRUCTURE
|
||
|
||
The need for FTP to support page structure derives principally from
|
||
the need to support efficient transmission of files between TOPS-20
|
||
systems, particularly the files used by NLS.
|
||
|
||
The file system of TOPS-20 is based on the concept of pages. The
|
||
operating system is most efficient at manipulating files as pages.
|
||
The operating system provides an interface to the file system so that
|
||
many applications view files as sequential streams of characters.
|
||
However, a few applications use the underlying page structures
|
||
directly, and some of these create holey files.
|
||
|
||
A TOPS-20 disk file consists of four things: a pathname, a page
|
||
table, a (possibly empty) set of pages, and a set of attributes.
|
||
|
||
The pathname is specified in the RETR or STOR command. It includes
|
||
the directory name, file name, file name extension, and generation
|
||
number.
|
||
|
||
The page table contains up to 2**18 entries. Each entry may be
|
||
EMPTY, or may point to a page. If it is not empty, there are also
|
||
some page-specific access bits; not all pages of a file need have the
|
||
same access protection.
|
||
|
||
A page is a contiguous set of 512 words of 36 bits each.
|
||
|
||
The attributes of the file, in the File Descriptor Block (FDB),
|
||
contain such things as creation time, write time, read time, writer's
|
||
byte-size, end-of-file pointer, count of reads and writes, backup
|
||
system tape numbers, etc.
|
||
|
||
Note that there is NO requirement that entries in the page table be
|
||
contiguous. There may be empty page table slots between occupied
|
||
ones. Also, the end of file pointer is simply a number. There is no
|
||
requirement that it in fact point at the "last" datum in the file.
|
||
Ordinary sequential I/O calls in TOPS-20 will cause the end of file
|
||
pointer to be left after the last datum written, but other operations
|
||
may cause it not to be so, if a particular programming system so
|
||
requires.
|
||
|
||
In fact, in both of these special cases, "holey" files and
|
||
end-of-file pointers NOT at the end of the file, occur with NLS data
|
||
files.
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 60]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
The TOPS-20 paged files can be sent with the FTP transfer parameters:
|
||
TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
|
||
|
||
Each page of information has a header. Each header field, which is a
|
||
logical byte, is a TOPS-20 word, since the TYPE is L 36.
|
||
|
||
The header fields are:
|
||
|
||
Word 0: Header Length.
|
||
|
||
The header length is 5.
|
||
|
||
Word 1: Page Index.
|
||
|
||
If the data is a disk file page, this is the number of that
|
||
page in the file's page map. Empty pages (holes) in the file
|
||
are simply not sent. Note that a hole is NOT the same as a
|
||
page of zeros.
|
||
|
||
Word 2: Data Length.
|
||
|
||
The number of data words in this page, following the header.
|
||
Thus, the total length of the transmission unit is the Header
|
||
Length plus the Data Length.
|
||
|
||
Word 3: Page Type.
|
||
|
||
A code for what type of chunk this is. A data page is type 3,
|
||
the FDB page is type 2.
|
||
|
||
Word 4: Page Access Control.
|
||
|
||
The access bits associated with the page in the file's page
|
||
map. (This full word quantity is put into AC2 of an SPACS by
|
||
the program reading from net to disk.)
|
||
|
||
After the header are Data Length data words. Data Length is
|
||
currently either 512 for a data page or 31 for an FDB. Trailing
|
||
zeros in a disk file page may be discarded, making Data Length less
|
||
than 512 in that case.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 61]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
APPENDIX II - DIRECTORY COMMANDS
|
||
|
||
Since UNIX has a tree-like directory structure in which directories
|
||
are as easy to manipulate as ordinary files, it is useful to expand
|
||
the FTP servers on these machines to include commands which deal with
|
||
the creation of directories. Since there are other hosts on the
|
||
ARPA-Internet which have tree-like directories (including TOPS-20 and
|
||
Multics), these commands are as general as possible.
|
||
|
||
Four directory commands have been added to FTP:
|
||
|
||
MKD pathname
|
||
|
||
Make a directory with the name "pathname".
|
||
|
||
RMD pathname
|
||
|
||
Remove the directory with the name "pathname".
|
||
|
||
PWD
|
||
|
||
Print the current working directory name.
|
||
|
||
CDUP
|
||
|
||
Change to the parent of the current working directory.
|
||
|
||
The "pathname" argument should be created (removed) as a
|
||
subdirectory of the current working directory, unless the "pathname"
|
||
string contains sufficient information to specify otherwise to the
|
||
server, e.g., "pathname" is an absolute pathname (in UNIX and
|
||
Multics), or pathname is something like "<abso.lute.path>" to
|
||
TOPS-20.
|
||
|
||
REPLY CODES
|
||
|
||
The CDUP command is a special case of CWD, and is included to
|
||
simplify the implementation of programs for transferring directory
|
||
trees between operating systems having different syntaxes for
|
||
naming the parent directory. The reply codes for CDUP be
|
||
identical to the reply codes of CWD.
|
||
|
||
The reply codes for RMD be identical to the reply codes for its
|
||
file analogue, DELE.
|
||
|
||
The reply codes for MKD, however, are a bit more complicated. A
|
||
freshly created directory will probably be the object of a future
|
||
|
||
|
||
Postel & Reynolds [Page 62]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
CWD command. Unfortunately, the argument to MKD may not always be
|
||
a suitable argument for CWD. This is the case, for example, when
|
||
a TOPS-20 subdirectory is created by giving just the subdirectory
|
||
name. That is, with a TOPS-20 server FTP, the command sequence
|
||
|
||
MKD MYDIR
|
||
CWD MYDIR
|
||
|
||
will fail. The new directory may only be referred to by its
|
||
"absolute" name; e.g., if the MKD command above were issued while
|
||
connected to the directory <DFRANKLIN>, the new subdirectory
|
||
could only be referred to by the name <DFRANKLIN.MYDIR>.
|
||
|
||
Even on UNIX and Multics, however, the argument given to MKD may
|
||
not be suitable. If it is a "relative" pathname (i.e., a pathname
|
||
which is interpreted relative to the current directory), the user
|
||
would need to be in the same current directory in order to reach
|
||
the subdirectory. Depending on the application, this may be
|
||
inconvenient. It is not very robust in any case.
|
||
|
||
To solve these problems, upon successful completion of an MKD
|
||
command, the server should return a line of the form:
|
||
|
||
257<space>"<directory-name>"<space><commentary>
|
||
|
||
That is, the server will tell the user what string to use when
|
||
referring to the created directory. The directory name can
|
||
contain any character; embedded double-quotes should be escaped by
|
||
double-quotes (the "quote-doubling" convention).
|
||
|
||
For example, a user connects to the directory /usr/dm, and creates
|
||
a subdirectory, named pathname:
|
||
|
||
CWD /usr/dm
|
||
200 directory changed to /usr/dm
|
||
MKD pathname
|
||
257 "/usr/dm/pathname" directory created
|
||
|
||
An example with an embedded double quote:
|
||
|
||
MKD foo"bar
|
||
257 "/usr/dm/foo""bar" directory created
|
||
CWD /usr/dm/foo"bar
|
||
200 directory changed to /usr/dm/foo"bar
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 63]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
The prior existence of a subdirectory with the same name is an
|
||
error, and the server must return an "access denied" error reply
|
||
in that case.
|
||
|
||
CWD /usr/dm
|
||
200 directory changed to /usr/dm
|
||
MKD pathname
|
||
521-"/usr/dm/pathname" directory already exists;
|
||
521 taking no action.
|
||
|
||
The failure replies for MKD are analogous to its file creating
|
||
cousin, STOR. Also, an "access denied" return is given if a file
|
||
name with the same name as the subdirectory will conflict with the
|
||
creation of the subdirectory (this is a problem on UNIX, but
|
||
shouldn't be one on TOPS-20).
|
||
|
||
Essentially because the PWD command returns the same type of
|
||
information as the successful MKD command, the successful PWD
|
||
command uses the 257 reply code as well.
|
||
|
||
SUBTLETIES
|
||
|
||
Because these commands will be most useful in transferring
|
||
subtrees from one machine to another, carefully observe that the
|
||
argument to MKD is to be interpreted as a sub-directory of the
|
||
current working directory, unless it contains enough information
|
||
for the destination host to tell otherwise. A hypothetical
|
||
example of its use in the TOPS-20 world:
|
||
|
||
CWD <some.where>
|
||
200 Working directory changed
|
||
MKD overrainbow
|
||
257 "<some.where.overrainbow>" directory created
|
||
CWD overrainbow
|
||
431 No such directory
|
||
CWD <some.where.overrainbow>
|
||
200 Working directory changed
|
||
|
||
CWD <some.where>
|
||
200 Working directory changed to <some.where>
|
||
MKD <unambiguous>
|
||
257 "<unambiguous>" directory created
|
||
CWD <unambiguous>
|
||
|
||
Note that the first example results in a subdirectory of the
|
||
connected directory. In contrast, the argument in the second
|
||
example contains enough information for TOPS-20 to tell that the
|
||
|
||
|
||
Postel & Reynolds [Page 64]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
<unambiguous> directory is a top-level directory. Note also that
|
||
in the first example the user "violated" the protocol by
|
||
attempting to access the freshly created directory with a name
|
||
other than the one returned by TOPS-20. Problems could have
|
||
resulted in this case had there been an <overrainbow> directory;
|
||
this is an ambiguity inherent in some TOPS-20 implementations.
|
||
Similar considerations apply to the RMD command. The point is
|
||
this: except where to do so would violate a host's conventions for
|
||
denoting relative versus absolute pathnames, the host should treat
|
||
the operands of the MKD and RMD commands as subdirectories. The
|
||
257 reply to the MKD command must always contain the absolute
|
||
pathname of the created directory.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 65]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
APPENDIX III - RFCs on FTP
|
||
|
||
Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
|
||
MIT-Project MAC, 16 April 1971.
|
||
|
||
Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
|
||
Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.
|
||
|
||
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
|
||
(NIC 6794), MIT-Project MAC, 23 June 1971.
|
||
|
||
Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
|
||
UCLA/CCN, 29 September 1971.
|
||
|
||
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
|
||
(NIC 7813), MIT-Project MAC, 17 November 1971.
|
||
|
||
McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
|
||
RFC 281 (NIC 8163), BBN, 8 December 1971.
|
||
|
||
Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
|
||
Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
|
||
25 January 1972.
|
||
|
||
Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
|
||
MIT-Project MAC, 8 July 1972.
|
||
|
||
Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
|
||
RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
|
||
|
||
Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
|
||
27 November 1972.
|
||
|
||
Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
|
||
Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.
|
||
|
||
Braden, Bob, "Comments on File Transfer Protocol", RFC 430
|
||
(NIC 13299), UCLA/CCN, 7 February 1973.
|
||
|
||
Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
|
||
RFC 438 (NIC 13770), BBN, 15 January 1973.
|
||
|
||
Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
|
||
27 February 1973.
|
||
|
||
McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
|
||
16 February 1973.
|
||
|
||
|
||
Postel & Reynolds [Page 66]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
|
||
(NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
|
||
|
||
Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
|
||
12 July 1973.
|
||
|
||
Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
|
||
Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.
|
||
|
||
Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
|
||
File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.
|
||
|
||
Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
|
||
"Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
|
||
Ames Research Center, SRI-ARC, 28 February 1974.
|
||
|
||
Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
|
||
(NIC 14573), MIT-DMCG, 21 February 1973.
|
||
|
||
Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
|
||
8 March 1973.
|
||
|
||
Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
|
||
MIT-DMCG, 6 March 1973.
|
||
|
||
Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
|
||
RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
|
||
|
||
White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
|
||
SRI-ARC, 8 March 1973.
|
||
|
||
White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
|
||
SRI-ARC, 8 March 1973.
|
||
|
||
Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
|
||
(NIC 16157), MIT-Multics, 26 June 1973.
|
||
|
||
Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
|
||
RFC 520 (NIC 16819), Illinois, 25 June 1973.
|
||
|
||
Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
|
||
(NIC 17451), UCSD-CC, 22 June 1973.
|
||
|
||
Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
|
||
15 November 1973.
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 67]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
|
||
Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
|
||
29 November 1973.
|
||
|
||
Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
|
||
Service", RFC 630 (NIC 30237), BBN, 10 April 1974.
|
||
|
||
Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
|
||
UCLA/NMC, 5 June 1974.
|
||
|
||
Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
|
||
SU-AI, 10 May 1975.
|
||
|
||
Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
|
||
28 May 1975.
|
||
|
||
Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.
|
||
|
||
Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
|
||
31 October 1977.
|
||
|
||
Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
|
||
SRI-KL, 30 December 1977.
|
||
|
||
Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
|
||
10 December 1978.
|
||
|
||
Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
|
||
June 1980.
|
||
|
||
Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
|
||
Commands", RFC 776, BBN, December 1980.
|
||
|
||
Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
|
||
July 1985.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 68]
|
||
|
||
|
||
|
||
RFC 959 October 1985
|
||
File Transfer Protocol
|
||
|
||
|
||
REFERENCES
|
||
|
||
[1] Feinler, Elizabeth, "Internet Protocol Transition Workbook",
|
||
Network Information Center, SRI International, March 1982.
|
||
|
||
[2] Postel, Jon, "Transmission Control Protocol - DARPA Internet
|
||
Program Protocol Specification", RFC 793, DARPA, September 1981.
|
||
|
||
[3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
|
||
Specification", RFC 854, ISI, May 1983.
|
||
|
||
[4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
|
||
ISI, April 1985.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Postel & Reynolds [Page 69]
|
||
|