As per Relevance of the word connection, we have this rfc below:
Network Working Group J.
Request for Comments: 959 J.
Obsoletes RFC: 765 (IEN 149) October 1985
FILE TRANSFER PROTOCOL (FTP
Status of this
This memo is the official specification of the File
Protocol (FTP). Distribution of this memo is unlimited
The following new optional commands are included in this edition
the specification
CDUP (Change to Parent Directory), SMNT (Structure Mount),
(Store Unique), RMD (Remove Directory), MKD (Make Directory),
(Print Directory), and SYST (System).
Note that this specification is compatible with the previous edition
1.
The objectives of FTP are 1) to promote sharing of files (
programs and/or data), 2) to encourage indirect or implicit (
programs) use of remote computers, 3) to shield a user
variations in file storage systems among hosts, and 4) to
data reliably and efficiently. FTP, though usable directly by a
at a terminal, is designed mainly for use by programs
The attempt in this specification is to satisfy the diverse needs
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
(TCP) [2] and the Telnet Protocol [3]. These documents are
in the ARPA-Internet protocol handbook [1].
2.
In this section, the history, the terminology, and the FTP model
discussed. The terms defined in this section are only those
have special significance in FTP. Some of the terminology is
specific to the FTP model; some readers may wish to turn to
section on the FTP model while reviewing the terminology
Postel & Reynolds [Page 1]
RFC 959 October 1985
File Transfer
2.1.
FTP has had a long evolution over the years. Appendix III is
chronological compilation of Request for Comments
relating to FTP. These include the first proposed file
mechanisms in 1971 that were developed for implementation on
at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
RFC 172 provided a user-level oriented protocol for file
between host computers (including terminal IMPs). A revision
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
was now defined as a protocol for file transfer between HOSTs
the ARPANET, with the primary function of FTP defined
transfering files efficiently and reliably among hosts
allowing the convenient use of remote file storage capabilities
RFC 385 further commented on errors, emphasis points,
additions to the protocol, while RFC 414 provided a status
on the working server and user FTPs. RFC 430, issued in 1973,
(among other RFCs too numerous to mention) presented
comments on FTP. Finally, an "official" FTP document
published as RFC 454.
By July 1973, considerable changes from the last versions of
were made, but the general structure remained the same. RFC 542
was published as a new "official" specification to reflect
changes. However, many implementations based on the
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
differences between all of the early and later versions of FTP
RFC 691 presented a minor revision of RFC 686, regarding
subject of print files
Motivated by the transition from the NCP to the TCP as
underlying protocol, a phoenix was born out of all of the
efforts in RFC 765 as the specification of FTP for use on TCP
This current edition of the FTP specification is intended
correct some minor documentation errors, to improve
explanation of some protocol features, and to add some
optional commands
Postel & Reynolds [Page 2]
RFC 959 October 1985
File Transfer
In particular, the following new optional commands are included
this edition of the specification
CDUP - Change to Parent
SMNT - Structure
STOU - Store
RMD - Remove
MKD - Make
PWD - Print
SYST -
This specification is compatible with the previous edition.
program implemented in conformance to the previous
should automatically be in conformance to this specification
2.2.
The ASCII character set is as defined in the ARPA-
Protocol Handbook. In FTP, ASCII characters are defined to
the lower half of an eight-bit code set (i.e., the
significant bit is zero).
access
Access controls define users' access privileges to the use of
system, and to the files in that system. Access controls
necessary to prevent unauthorized or accidental use of files
It is the prerogative of a server-FTP process to invoke
controls
byte
There are two byte sizes of interest in FTP: the logical
size of the file, and the transfer byte size used for
transmission of the data. The transfer byte size is always 8
bits. The transfer byte size is not necessarily the byte
in which data is to be stored in a system, nor the logical
size for interpretation of the structure of the data
Postel & Reynolds [Page 3]
RFC 959 October 1985
File Transfer
control
The communication path between the USER-PI and SERVER-PI
the exchange of commands and replies. This connection
the Telnet Protocol
data
A full duplex connection over which data is transferred, in
specified mode and type. The data transferred may be a part
a file, an entire file or a number of files. The path may
between a server-DTP and a user-DTP, or between
server-DTPs
data
The passive data transfer process "listens" on the data
for a connection from the active transfer process in order
open the data connection
The data transfer process establishes and manages the
connection. The DTP can be passive or active
End-of-
The end-of-line sequence defines the separation of
lines. The sequence is Carriage Return, followed by Line Feed
The end-of-file condition that defines the end of a file
transferred
The end-of-record condition that defines the end of a
being transferred
error
A procedure that allows a user to recover from certain
such as failure of either host system or transfer process.
FTP, error recovery may involve restarting a file transfer at
given checkpoint
Postel & Reynolds [Page 4]
RFC 959 October 1985
File Transfer
FTP
A set of commands that comprise the control information
from the user-FTP to the server-FTP process
An ordered set of computer data (including programs),
arbitrary length, uniquely identified by a pathname
The mode in which data is to be transferred via the
connection. The mode defines the data format during
including EOR and EOF. The transfer modes defined in FTP
described in the Section on Transmission Modes
The Network Virtual Terminal as defined in the Telnet Protocol
The Network Virtual File System. A concept which defines
standard network file system with standard commands
pathname conventions
A file may be structured as a set of independent parts
pages. FTP supports the transmission of discontinuous files
independent indexed pages
Pathname is defined to be the character string which must
input to a file system by a user in order to identify a file
Pathname normally contains device and/or directory names,
file name specification. FTP does not yet specify a
pathname convention. Each user must follow the file
conventions of the file systems involved in the transfer
The protocol interpreter. The user and server sides of
protocol have distinct roles implemented in a user-PI and
server-PI
Postel & Reynolds [Page 5]
RFC 959 October 1985
File Transfer
A sequential file may be structured as a number of
parts called records. Record structures are supported by
but a file need not have record structure
A reply is an acknowledgment (positive or negative) sent
server to user via the control connection in response to
commands. The general form of a reply is a completion
(including error codes) followed by a text string. The
are for use by programs and the text is usually intended
human users
server-
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
data on command from its PI. The DTP can be placed in
"passive" state to listen for, rather than initiate
connection on the data port
server-FTP
A process or set of processes which perform the function
file transfer in cooperation with a user-FTP process and
possibly, another server. The functions consist of a
interpreter (PI) and a data transfer process (DTP).
server-
The server protocol interpreter "listens" on Port L for
connection from a user-PI and establishes a
communication connection. It receives standard FTP
from the user-PI, sends replies, and governs the server-DTP
The data representation type used for data transfer
storage. Type implies certain transformations between the
of data storage and data transfer. The representation
defined in FTP are described in the Section on
Data Connections
Postel & Reynolds [Page 6]
RFC 959 October 1985
File Transfer
A person or a process on behalf of a person wishing to
file transfer service. The human user may interact
with a server-FTP process, but use of a user-FTP process
preferred since the protocol design is weighted
automata
user-
The data transfer process "listens" on the data port for
connection from a server-FTP process. If two servers
transferring data between them, the user-DTP is inactive
user-FTP
A set of functions including a protocol interpreter, a
transfer process and a user interface which together
the function of file transfer in cooperation with one or
server-FTP processes. The user interface allows a
language to be used in the command-reply dialogue with
user
user-
The user protocol interpreter initiates the control
from its port U to the server-FTP process, initiates
commands, and governs the user-DTP if that process is part
the file transfer
Postel & Reynolds [Page 7]
RFC 959 October 1985
File Transfer
2.3. THE FTP
With the above definitions in mind, the following model (shown
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-
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
In the model described in Figure 1, the user-protocol
initiates the control connection. The control connection
the Telnet protocol. At the initiation of the user, standard
commands are generated by the user-PI and transmitted to
server process via the control connection. (The user
establish a direct control connection to the server-FTP, from
TAC terminal for example, and generate standard FTP
independently, bypassing the user-FTP process.) Standard
are sent from the server-PI to the user-PI over the
connection in response to the commands
The FTP commands specify the parameters for the data
(data port, transfer mode, representation type, and structure)
the nature of file system operation (store, retrieve, append
delete, etc.). The user-DTP or its designate should "listen"
the specified data port, and the server initiate the
connection and data transfer in accordance with the
parameters. It should be noted that the data port need not be
Postel & Reynolds [Page 8]
RFC 959 October 1985
File Transfer
the same host that initiates the FTP commands via the
connection, but the user or the user-FTP process must ensure
"listen" on the specified data port. It ought to also be
that the data connection may be used for simultaneous sending
receiving
In another situation a user might wish to transfer files
two hosts, neither of which is a local host. The user sets
control connections to the two servers and then arranges for
data connection between them. In this manner, control
is passed to the user-PI but data is transferred between
server data transfer processes. Following is a model of
server-server interaction
Control ------------
---------->| User-FTP |<-----------
| | User-PI | |
| | "C" | |
V ------------
-------------- --------------
| Server-FTP | Data Connection | Server-FTP |
| "A" |<---------------------->| "B" |
-------------- Port (A) Port (B) --------------
Figure 2
The protocol requires that the control connections be open
data transfer is in progress. It is the responsibility of
user to request the closing of the control connections
finished using the FTP service, while it is the server who
the action. The server may abort data transfer if the
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
server-PI may implement the rules of the Telnet
directly in their own procedures; or, second, the user-PI
the server-PI may make use of the existing Telnet module in
system
Ease of implementaion, sharing code, and modular
argue for the second approach. Efficiency and
Postel & Reynolds [Page 9]
RFC 959 October 1985
File Transfer
argue for the first approach. In practice, FTP relies on
little of the Telnet Protocol, so the first approach does
necessarily involve a large amount of code
3. DATA TRANSFER
Files are transferred only via the data connection. The
connection is used for the transfer of commands, which describe
functions to be performed, and the replies to these commands (see
Section on FTP Replies). Several commands are concerned with
transfer of data between hosts. These data transfer commands
the MODE command which specify how the bits of the data are to
transmitted, and the STRUcture and TYPE commands, which are used
define the way in which the data are to be represented.
transmission and representation are basically independent but
"Stream" transmission mode is dependent on the file
attribute and if "Compressed" transmission mode is used, the
of the filler byte depends on the representation type
3.1. DATA REPRESENTATION AND
Data is transferred from a storage device in the sending host to
storage device in the receiving host. Often it is necessary
perform certain transformations on the data because data
representations in the two systems are different. For example
NVT-ASCII has different data storage representations in
systems. DEC TOPS-20s's generally store NVT-ASCII as five 7-
ASCII characters, left-justified in a 36-bit word. IBM Mainframe'
store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-
as four 9-bit characters in a 36-bit word. It is desirable
convert characters into the standard NVT-ASCII representation
transmitting text between dissimilar systems. The sending
receiving sites would have to perform the
transformations between the standard representation and
internal representations
A different problem in representation arises when
binary data (not character codes) between host systems
different word lengths. It is not always clear how the
should send data, and the receiver store it. For example,
transmitting 32-bit bytes from a 32-bit word-length system to
36-bit word-length system, it may be desirable (for reasons
efficiency and usefulness) to store the 32-bit
right-justified in a 36-bit word in the latter system. In
case, the user should have the option of specifying
representation and transformation functions. It should be
Postel & Reynolds [Page 10]
RFC 959 October 1985
File Transfer
that FTP provides for very limited data type representations
Transformations desired beyond this limited capability should
performed by the user directly
3.1.1. DATA
Data representations are handled in FTP by a user specifying
representation type. This type may implicitly (as in ASCII
EBCDIC) or explicitly (as in Local byte) define a byte size
interpretation which is referred to as the "logical byte size."
Note that this has nothing to do with the byte size used
transmission over the data connection, called the "
byte size", and the two should not be confused. For example
NVT-ASCII has a logical byte size of 8 bits. If the type
Local byte, then the TYPE command has an obligatory
parameter specifying the logical byte size. The transfer
size is always 8 bits
3.1.1.1. ASCII
This is the default type and must be accepted by all
implementations. It is intended primarily for the
of text files, except when both hosts would find the
type more convenient
The sender converts the data from an internal
representation to the standard 8-bit NVT-
representation (see the Telnet specification). The
will convert the data from the standard form to his
internal form
In accordance with the NVT standard, the
should be used where necessary to denote the end of a
of text. (See the discussion of file structure at the
of the Section on Data Representation and Storage.)
Using the standard NVT-ASCII representation means that
must be interpreted as 8-bit bytes
The Format parameter for ASCII and EBCDIC types is
below
Postel & Reynolds [Page 11]
RFC 959 October 1985
File Transfer
3.1.1.2. EBCDIC
This type is intended for efficient transfer between
which use EBCDIC for their internal
representation
For transmission, the data are represented as 8-bit
characters. The character code is the only
between the functional specifications of EBCDIC and
types
End-of-line (as opposed to end-of-record--see the
of structure) will probably be rarely used with EBCDIC
for purposes of denoting structure, but where it
necessary the character should be used
3.1.1.3. IMAGE
The data are sent as contiguous bits which, for transfer
are packed into the 8-bit transfer bytes. The
site must store the data as contiguous bits. The
of the storage system might necessitate the padding of
file (or of each record, for a record-structured file)
some convenient boundary (byte, word or block).
padding, which must be all zeros, may occur only at the
of the file (or at the end of each record) and there must
a way of identifying the padding bits so that they may
stripped off if the file is retrieved. The
transformation should be well publicized to enable a user
process a file at the storage site
Image type is intended for the efficient storage
retrieval of files and for the transfer of binary data.
is recommended that this type be accepted by all
implementations
3.1.1.4. LOCAL
The data is transferred in logical bytes of the
specified by the obligatory second parameter, Byte size
The value of Byte size must be a decimal integer; there
no default value. The logical byte size is not
the same as the transfer byte size. If there is
difference in byte sizes, then the logical bytes should
packed contiguously, disregarding transfer byte
and with any necessary padding at the end
Postel & Reynolds [Page 12]
RFC 959 October 1985
File Transfer
When the data reaches the receiving host, it will
transformed in a manner dependent on the logical byte
and the particular host. This transformation must
invertible (i.e., an identical file can be retrieved if
same parameters are used) and should be well publicized
the FTP implementors
For example, a user sending 36-bit floating-point numbers
a host with a 32-bit word could send that data as Local
with a logical byte size of 36. The receiving host
then be expected to store the logical bytes so that
could be easily manipulated; in this example putting
36-bit logical bytes into 64-bit double words
suffice
In another example, a pair of hosts with a 36-bit word
may send data to one another in words by using TYPE L 36.
The data would be sent in the 8-bit transmission
packed so that 9 transmission bytes carried two host words
3.1.1.5. FORMAT
The types ASCII and EBCDIC also take a second (optional
parameter; this is to indicate what kind of vertical
control, if any, is associated with a file. The
data representation types are defined in FTP
A character file may be transferred to a host for one
three purposes: for printing, for storage and
retrieval, or for processing. If a file is sent
printing, the receiving host must know how the
format control is represented. In the second case, it
be possible to store a file at a host and then retrieve
later in exactly the same form. Finally, it should
possible to move a file from one host to another and
the file at the second host without undue trouble. A
ASCII or EBCDIC format does not satisfy all
conditions. Therefore, these types have a second
specifying one of the following three formats
3.1.1.5.1. NON
This is the default format to be used if the
(format) parameter is omitted. Non-print format must
accepted by all FTP implementations
Postel & Reynolds [Page 13]
RFC 959 October 1985
File Transfer
The file need contain no vertical format information.
it is passed to a printer process, this process
assume standard values for spacing and margins
Normally, this format will be used with files
for processing or just storage
3.1.1.5.2. TELNET FORMAT
The file contains ASCII/EBCDIC vertical format
(i.e., , , , , ) which the
process will interpret appropriately. , in
this sequence, also denotes end-of-line
3.1.1.5.2. CARRIAGE CONTROL (ASA
The file contains ASA (FORTRAN) vertical format
characters. (See RFC 740 Appendix C; and
of the ACM, Vol. 7, No. 10, p. 606, October 1964.) In
line or a record formatted according to the ASA Standard
the first character is not to be printed. Instead,
should be used to determine the vertical movement of
paper which should take place before the rest of
record is printed
The ASA Standard specifies the following
characters
Character Vertical
blank Move paper up one
0 Move paper up two
1 Move paper to top of next
+ No movement, i.e.,
Clearly there must be some way for a printer process
distinguish the end of the structural entity. If a
has record structure (see below) this is no problem
records will be explicitly marked during transfer
storage. If the file has no record structure, the
end-of-line sequence is used to separate printing lines
but these format effectors are overridden by the
controls
Postel & Reynolds [Page 14]
RFC 959 October 1985
File Transfer
3.1.2. DATA
In addition to different representation types, FTP allows
structure of a file to be specified. Three file structures
defined in FTP
file-structure, where there is no internal structure
the file is considered to be
continuous sequence of data bytes
record-structure, where the file is made up of
records
and page-structure, where the file is made up of
indexed pages
File-structure is the default to be assumed if the
command has not been used but both file and record
must be accepted for "text" files (i.e., files with TYPE
or EBCDIC) by all FTP implementations. The structure of a
will affect both the transfer mode of a file (see the
on Transmission Modes) and the interpretation and storage
the file
The "natural" structure of a file will depend on which
stores the file. A source-code file will usually be stored
an IBM Mainframe in fixed length records but on a DEC TOPS-20
as a stream of characters partitioned into lines, for
by . If the transfer of files between such
sites is to be useful, there must be some way for one site
recognize the other's assumptions about the file
With some sites being naturally file-oriented and
naturally record-oriented there may be problems if a file
one structure is sent to a host oriented to the other. If
text file is sent with record-structure to a host which is
oriented, then that host should apply an
transformation to the file based on the record structure
Obviously, this transformation should be useful, but it
also be invertible so that an identical file may be
using record structure
In the case of a file being sent with file-structure to
record-oriented host, there exists the question of
criteria the host should use to divide the file into
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
for ASCII, or for EBCDIC text files, as
delimiter. If an FTP implementation adopts this technique,
must be prepared to reverse the transformation if the file
retrieved with file-structure
3.1.2.1. FILE
File structure is the default to be assumed if the
command has not been used
In file-structure there is no internal structure and
file is considered to be a continuous sequence of
bytes
3.1.2.2. RECORD
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
records
3.1.2.3. PAGE
To transmit files that are discontinuous, FTP defines a
structure. Files of this type are sometimes known
"random access files" or even as "holey files". In
files there is sometimes other information associated
the file as a whole (e.g., a file descriptor), or with
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
information, each page is sent with a page header. The
header has the following defined fields
Header
The number of logical bytes in the page
including this byte. The minimum header length is 4.
Page
The logical page number of this section of the file
This is not the transmission sequence number of
page, but the index used to identify this page of
file
Postel & Reynolds [Page 16]
RFC 959 October 1985
File Transfer
Data
The number of logical bytes in the page data.
minimum data length is 0.
Page
The type of page this is. The following page
are defined
0 = Last
This is used to indicate the end of a
structured transmission. The header length
be 4, and the data length must be 0.
1 = Simple
This is the normal type for simple paged
with no page level associated
information. The header length must be 4.
2 = Descriptor
This type is used to transmit the
information for the file as a whole
3 = Access Controlled
This type includes an additional header
for paged files with page level access
information. The header length must be 5.
Optional
Further header fields may be used to supply per
control information, for example, per page
control
All fields are one logical byte in length. The logical
size is specified by the TYPE command. See Appendix I
further details and a specific case at the page structure
A note of caution about parameters: a file must be stored
retrieved with the same parameters if the retrieved version is
Postel & Reynolds [Page 17]
RFC 959 October 1985
File Transfer
be identical to the version originally transmitted. Conversely
FTP implementations must return a file identical to the
if the parameters used to store and retrieve a file are the same
3.2. ESTABLISHING DATA
The mechanics of transferring data consists of setting up the
connection to the appropriate ports and choosing the
for transfer. Both the user and the server-DTPs have a
data port. The user-process default data port is the same as
control connection port (i.e., U). The server-process
data port is the port adjacent to the control connection
(i.e., L-1).
The transfer byte size is 8-bit bytes. This byte size is
only for the actual transfer of the data; it has no bearing
representation of the data within a host's file system
The passive data transfer process (this may be a user-DTP or
second server-DTP) shall "listen" on the data port prior
sending a transfer request command. The FTP request
determines the direction of the data transfer. The server,
receiving the transfer request, will initiate the data
to the port. When the connection is established, the
transfer begins between DTP's, and the server-PI sends
confirming reply to the user-PI
Every FTP implementation must support the use of the default
ports, and only the USER-PI can initiate a change to non-
ports
It is possible for the user to specify an alternate data port
use of the PORT command. The user may want a file dumped on a
line printer or retrieved from a third party host. In the
case, the user-PI sets up control connections with
server-PI's. One server is then told (by an FTP command)
"listen" for a connection which the other will initiate.
user-PI sends one server-PI a PORT command indicating the
port of the other. Finally, both are sent the
transfer commands. The exact sequence of commands and
sent between the user-controller and the servers is defined in
Section on FTP Replies
In general, it is the server's responsibility to maintain the
connection--to initiate it and to close it. The exception to
Postel & Reynolds [Page 18]
RFC 959 October 1985
File Transfer
is when the user-DTP is sending the data in a transfer mode
requires the connection to be closed to indicate EOF. The
MUST close the data connection under the following conditions
1. The server has completed sending data in a transfer
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
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
server must indicate to the user-process by either a 250 or 226
reply only
3.3. DATA CONNECTION
Default Data Connection Ports: All FTP implementations
support use of the default data connection ports, and only
User-PI may initiate the use of non-default ports
Negotiating Non-Default Data Ports: The User-PI may specify
non-default user side data port with the PORT command.
User-PI may request the server side to identify a non-
server side data port with the PASV command. Since a
is defined by the pair of addresses, either of these actions
enough to get a different data connection, still it is
to do both commands to use new ports on both ends of the
connection
Reuse of the Data Connection: When using the stream mode of
transfer the end of the file must be indicated by closing
connection. This causes a problem if multiple files are to
transfered in the session, due to need for TCP to hold
connection record for a time out period to guarantee the
communication. Thus the connection can not be reopened at once
There are two solutions to this problem. The first is
negotiate a non-default port. The second is to use
transfer mode
A comment on transfer modes. The stream transfer mode
Postel & Reynolds [Page 19]
RFC 959 October 1985
File Transfer
inherently unreliable, since one can not determine if
connection closed prematurely or not. The other transfer
(Block, Compressed) do not close the connection to indicate
end of file. They have enough FTP encoding that the
connection can be parsed to determine the end of the file
Thus using these modes one can leave the data connection
for multiple file transfers
3.4. TRANSMISSION
The next consideration in transferring data is choosing
appropriate transmission mode. There are three modes: one
formats the data and allows for restart procedures; one which
compresses the data for efficient transfer; and one which
the data with little or no processing. In this last case the
interacts with the structure attribute to determine the type
processing. In the compressed mode, the representation
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
data connection. For files with record structure, all
end-of-record markers (EOR) are explicit, including the final one
For files transmitted in page structure a "last-page" page type
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
translate its internal end of line or end of record
into the representation prescribed by the transfer mode and
structure, and the receiving host will perform the
translation to its internal denotation. An IBM Mainframe
count field may not be recognized at another host, so
end-of-record information may be transferred as a two byte
code in Stream mode or as a flagged bit in a Block or
mode descriptor. End-of-line in an ASCII or EBCDIC file with
record structure should be indicated by or ,
respectively. Since these transformations imply extra work
some systems, identical systems transferring non-record
text files might wish to use a binary representation and
mode for the transfer
Postel & Reynolds [Page 20]
RFC 959 October 1985
File Transfer
The following transmission modes are defined in FTP
3.4.1. STREAM
The data is transmitted as a stream of bytes. There is
restriction on the representation type used; record
are allowed
In a record structured file EOR and EOF will each be
by a two-byte control code. The first byte of the control
will be all ones, the escape character. The second byte
have the low order bit on and zeros elsewhere for EOR and
second low order bit on for EOF; that is, the byte will
value 1 for EOR and value 2 for EOF. EOR and EOF may
indicated together on the last byte transmitted by turning
low order bits on (i.e., the value 3). If a byte of all
was intended to be sent as data, it should be repeated in
second byte of the control code
If the structure is a file structure, the EOF is indicated
the sending host closing the data connection and all bytes
data bytes
3.4.2. BLOCK
The file is transmitted as a series of data blocks preceded
one or more header bytes. The header bytes contain a
field, and descriptor code. The count field indicates
total length of the data block in bytes, thus marking
beginning of the next data block (there are no filler bits).
The descriptor code defines: last block in the file (EOF)
block in the record (EOR), restart marker (see the Section
Error Recovery and Restart) or suspect data (i.e., the
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
of data (e.g., seismic or weather data) to send and receive
the data despite local errors (such as "magnetic tape
errors"), but to indicate in the transmission that
portions are suspect). Record structures are allowed in
mode, and any representation type may be used
The header consists of the three bytes. Of the 24 bits
header information, the 16 low order bits shall represent
count, and the 8 high order bits shall represent
codes as shown below
Postel & Reynolds [Page 21]
RFC 959 October 1985
File Transfer
Block
+----------------+----------------+----------------+
| Descriptor | Byte Count |
| 8 bits | 16 bits |
+----------------+----------------+----------------+
The descriptor codes are indicated by bit flags in
descriptor byte. Four codes have been assigned, where
code number is the decimal value of the corresponding bit
the byte
Code
128 End of data block is
64 End of data block is
32 Suspected errors in data
16 Data block is a restart
With this encoding, more than one descriptor coded
may exist for a particular block. As many bits as
may be flagged
The restart marker is embedded in the data stream as
integral number of 8-bit bytes representing
characters in the language being used over the
connection (e.g., default--NVT-ASCII). (Space, in
appropriate language) must not be used WITHIN a restart marker
For example, to transmit a six-character marker, the
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
3.4.3. COMPRESSED
There are three kinds of information to be sent: regular data
sent in a byte string; compressed data, consisting
replications or filler; and control information, sent in
two-byte escape sequence. If n>0 bytes (up to 127) of
data are sent, these n bytes are preceded by a byte with
left-most bit set to 0 and the right-most 7 bits containing
number n
Byte string
1 7 8 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| n | | d(1) | ... | d(n) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
^ ^
|---n bytes---|
of
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,
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
byte, where the filler byte varies with the
type. If the type is ASCII or EBCDIC the filler byte is
(Space, ASCII code 32, EBCDIC code 64). If the type is
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
Postel & Reynolds [Page 23]
RFC 959 October 1985
File Transfer
escape byte (all zeros) and the second of which
descriptor codes as defined in Block mode. The
codes have the same meaning as in Block mode and apply to
succeeding string of bytes
Compressed mode is useful for obtaining increased bandwidth
very large network transmissions at a little extra CPU cost
It can be most effectively used to reduce the size of
files such as those generated by RJE hosts
3.5. ERROR RECOVERY AND
There is no provision for detecting bits lost or scrambled in
transfer; this level of error control is handled by the TCP
However, a restart procedure is provided to protect users
gross system failures (including failures of a host,
FTP-process, or the underlying network).
The restart procedure is defined only for the block and
modes of data transfer. It requires the sender of data to
a special marker code in the data stream with some
information. The marker information has meaning only to
sender, but must consist of printable characters in the default
negotiated language of the control connection (ASCII or EBCDIC).
The marker could represent a bit-count, a record-count, or
other information by which a system may identify a
checkpoint. The receiver of data, if it implements the
procedure, would then mark the corresponding position of
marker in the receiving system, and return this information to
user
In the event of a system failure, the user can restart the
transfer by identifying the marker point with the FTP
procedure. The following example illustrates the use of
restart procedure
The sender of the data inserts an appropriate marker block in
data stream at a convenient point. The receiving host marks
corresponding data point in its file system and conveys the
known sender and receiver marker information to the user,
directly or over the control connection in a 110 reply (
on who is the sender). In the event of a system failure, the
or controller process restarts the server at the last
marker by sending a restart command with server's marker code
its argument. The restart command is transmitted over the
Postel & Reynolds [Page 24]
RFC 959 October 1985
File Transfer
connection and is immediately followed by the command (such
RETR, STOR or LIST) which was being executed when the
failure occurred
4. FILE TRANSFER
The communication channel from the user-PI to the server-PI
established as a TCP connection from the user to the standard
port. The user protocol interpreter is responsible for sending
commands and interpreting the replies received; the server-
interprets commands, sends replies and directs its DTP to set up
data connection and transfer the data. If the second party to
data transfer (the passive transfer process) is the user-DTP, then
is governed through the internal protocol of the user-FTP host; if
is a second server-DTP, then it is governed by its PI on command
the user-PI. The FTP replies are discussed in the next section.
the description of a few of the commands in this section, it
helpful to be explicit about the possible replies
4.1. FTP
4.1.1. ACCESS CONTROL
The following commands specify access control
(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
server for access to its file system. This command
normally be the first command transmitted by the user
the control connections are made (some servers may
this). Additional identification information in the form
a password and/or an account command may also be required
some servers. Servers may allow a new USER command to
entered at any point in order to change the access
and/or accounting information. This has the effect
flushing any user, password, and account information
supplied and beginning the login sequence again.
transfer parameters are unchanged and any file transfer
progress is completed under the old access
parameters
Postel & Reynolds [Page 25]
RFC 959 October 1985
File Transfer
PASSWORD (PASS
The argument field is a Telnet string specifying the user'
password. This command must be immediately preceded by
user name command, and, for some sites, completes the user'
identification for access control. Since
information is quite sensitive, it is desirable in
to "mask" it or suppress typeout. It appears that
server has no foolproof way to achieve this. It
therefore the responsibility of the user-FTP process to
the sensitive password information
ACCOUNT (ACCT
The argument field is a Telnet string identifying the user'
account. The command is not necessarily related to the
command, as some sites may require an account for login
others only for specific access, such as storing files.
the latter case the command may arrive at any time
There are reply codes to differentiate these cases for
automation: when account information is required for login
the response to a successful PASSword command is reply
332. On the other hand, if account information is
required for login, the reply to a successful
command is 230; and if the account information is needed
a command issued later in the dialogue, the server
return a 332 or 532 reply depending on whether it
(pending receipt of the ACCounT command) or discards
command, respectively
CHANGE WORKING DIRECTORY (CWD
This command allows the user to work with a
directory or dataset for file storage or retrieval
altering his login or accounting information.
parameters are similarly unchanged. The argument is
pathname specifying a directory or other system
file group designator
CHANGE TO PARENT DIRECTORY (CDUP
This command is a special case of CWD, and is included
simplify the implementation of programs for
directory trees between operating systems having
Postel & Reynolds [Page 26]
RFC 959 October 1985
File Transfer
syntaxes for naming the parent directory. The reply
shall be identical to the reply codes of CWD.
Appendix II for further details
STRUCTURE MOUNT (SMNT
This command allows the user to mount a different
system data structure without altering his login
accounting information. Transfer parameters are
unchanged. The argument is a pathname specifying
directory or other system dependent file group designator
REINITIALIZE (REIN
This command terminates a USER, flushing all I/O and
information, except to allow any transfer in progress to
completed. All parameters are reset to the default
and the control connection is left open. This is
to the state in which a user finds himself immediately
the control connection is opened. A USER command may
expected to follow
LOGOUT (QUIT
This command terminates a USER and if file transfer is
in progress, the server closes the control connection.
file transfer is in progress, the connection will
open for result response and the server will then close it
If the user-process is transferring files for several
but does not wish to close and then reopen connections
each, then the REIN command should be used instead of QUIT
An unexpected close on the control connection will cause
server to take the effective action of an abort (ABOR) and
logout (QUIT).
4.1.2. TRANSFER PARAMETER
All data transfer parameters have default values, and
commands specifying data transfer parameters are required
if the default parameter values are to be changed. The
value is the last specified value, or if no value has
specified, the standard default value is as stated here.
implies that the server must "remember" the applicable
values. The commands may be in any order except that they
precede the FTP service request. The following
specify data transfer parameters
Postel & Reynolds [Page 27]
RFC 959 October 1985
File Transfer
DATA PORT (PORT
The argument is a HOST-PORT specification for the data
to be used in data connection. There are defaults for
the user and server data ports, and under
circumstances this command and its reply are not needed.
this command is used, the argument is the concatenation of
32-bit internet host address and a 16-bit TCP port address
This address information is broken into 8-bit fields and
value of each field is transmitted as a decimal number (
character string representation). The fields are
by commas. A port command would be
PORT h1,h2,h3,h4,p1,p
where h1 is the high order 8 bits of the internet
address
PASSIVE (PASV
This command requests the server-DTP to "listen" on a
port (which is not its default data port) and to wait for
connection rather than initiate one upon receipt of
transfer command. The response to this command includes
host and port address this server is listening on
REPRESENTATION TYPE (TYPE
The argument specifies the representation type as
in the Section on Data Representation and Storage.
types take a second parameter. The first parameter
denoted by a single Telnet character, as is the
Format parameter for ASCII and EBCDIC; the second
for local byte is a decimal integer to indicate Bytesize
The parameters are separated by a (Space, ASCII
32).
The following codes are assigned for type
\ /
A - ASCII | | N - Non-
|-><-| T - Telnet format
E - EBCDIC| | C - Carriage Control (ASA
/ \
I -
L - Local byte Byte
Postel & Reynolds [Page 28]
RFC 959 October 1985
File Transfer
The default representation type is ASCII Non-print. If
Format parameter is changed, and later just the
argument is changed, Format then returns to the Non-
default
FILE STRUCTURE (STRU
The argument is a single Telnet character code
file structure described in the Section on
Representation and Storage
The following codes are assigned for structure
F - File (no record structure
R - Record
P - Page
The default structure is File
TRANSFER MODE (MODE
The argument is a single Telnet character code
the data transfer modes described in the Section
Transmission Modes
The following codes are assigned for transfer modes
S -
B -
C -
The default transfer mode is Stream
4.1.3. FTP SERVICE
The FTP service commands define the file transfer or the
system function requested by the user. The argument of an
service command will normally be a pathname. The syntax
pathnames must conform to server site conventions (
standard defaults applicable), and the language conventions
the control connection. The suggested default handling is
use the last specified device, directory or file name, or
standard default defined for local users. The commands may
in any order except that a "rename from" command must
followed by a "rename to" command and the restart command
be followed by the interrupted service command (e.g., STOR
RETR). The data, when transferred in response to FTP
Postel & Reynolds [Page 29]
RFC 959 October 1985
File Transfer
commands, shall always be sent over the data connection,
for certain informative replies. The following
specify FTP service requests
RETRIEVE (RETR
This command causes the server-DTP to transfer a copy of
file, specified in the pathname, to the server- or user-
at the other end of the data connection. The status
contents of the file at the server site shall be unaffected
STORE (STOR
This command causes the server-DTP to accept the
transferred via the data connection and to store the data
a file at the server site. If the file specified in
pathname exists at the server site, then its contents
be replaced by the data being transferred. A new file
created at the server site if the file specified in
pathname does not already exist
STORE UNIQUE (STOU
This command behaves like STOR except that the
file is to be created in the current directory under a
unique to that directory. The 250 Transfer Started
must include the name generated
APPEND (with create) (APPE
This command causes the server-DTP to accept the
transferred via the data connection and to store the data
a file at the server site. If the file specified in
pathname exists at the server site, then the data shall
appended to that file; otherwise the file specified in
pathname shall be created at the server site
ALLOCATE (ALLO
This command may