RFC relevance of connection

As per Relevance of the word connection, we have this rfc below:

IEN 149 J.
RFC 765
June 1980

FILE TRANSFER

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, and TIPs, with a simple, and
implemented protocol design

This paper assumes knowledge of the following protocols described
the ARPA Internet Protocol Handbook

The Transmission Control

The TELNET

In this section, the terminology and the FTP model are discussed
The terms defined in this section are only those that have
significance in FTP. Some of the terminology is very specific to
FTP model; some readers may wish to turn to the section on the
model while reviewing the terminology

The ASCII character set 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

1

June 1980 IEN 149
File Transfer Protocol RFC 765

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

data

A simplex 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 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

FTP

A set of commands that comprise the control information
from the user-FTP to the server-FTP process

2

IEN 149 June 1980
RFC 765 File Transfer

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. FTP only partially implements the
concept at this time

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

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

3

June 1980 IEN 149
File Transfer Protocol RFC 765

A reply is an acknowledgment (positive or negative) sent
server to user via the TELNET connections 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
sets up parameters for transfer and storage, and transfers
on command from its PI. The DTP can be placed in a "passive
state to listen for, rather than initiate a, connection on
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 protocol interpreter "listens" on Port L for a
from a user-PI and establishes a TELNET
connection. It receives standard FTP commands from
user-PI, sends replies, and governs the server-DTP

TELNET

The full-duplex communication path between a user-PI and
server-PI, operating according to the TELNET Protocol

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

4

IEN 149 June 1980
RFC 765 File Transfer

A human being or a process on behalf of a human being
to obtain file transfer service. The human user may
directly with a server-FTP process, but use of a user-
process is preferred since the protocol design is
towards 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 protocol interpreter initiates the TELNET connection
its port U to the server-FTP process, initiates FTP commands
and governs the user-DTP if that process is part of the
transfer

5

June 1980 IEN 149
File Transfer Protocol RFC 765

THE FTP

With the above definitions in mind, the following model (shown
Figure 1) may be diagrammed for an FTP service

-------------
|/---------\|
|| User || --------
||Interface|<--->| User |
|\----:----/| --------
---------- | V |
|/------\| FTP Commands |/---------\|
||Server|<---------------->| User ||
|| PI || FTP Replies || PI ||
|\--:---/| |\----:----/|
| V | | V |
-------- |/------\| Data |/---------\| --------
| 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 TELNET connection. At the initiation of the user
standard FTP commands are generated by the user-PI and
to the server process via the TELNET connection. (The user
establish a direct TELNET connection to the server-FTP, from a
terminal for example, and generate standard FTP commands himself
bypassing the user-FTP process.) Standard replies are sent
the server-PI to the user-PI over the TELNET connection
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

6

IEN 149 June 1980
RFC 765 File Transfer

the same Host that initiates the FTP commands via the
connection, but the user or his user-FTP process must ensure
"listen" on the specified data port. It should also be noted
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 his local Host. He sets up
connections to the two servers and then arranges for a
connection between them. In this manner control information
passed to the user-PI but data is transferred between the
data transfer processes. Following is a model of
server-server interaction

TELNET ------------
---------->| 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 TELNET connections be open
data transfer is in progress. It is the responsibility of
user to request the closing of the TELNET 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

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

7

June 1980 IEN 149
File Transfer Protocol RFC 765

"Stream" transmission mode is dependent on the file
attribute and if "Compressed" transmission mode is used the nature
the filler byte depends on the representation type

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. PDP-10's generally store NVT-ASCII as five 7-bit
characters, left-justified in a 36-bit word. 360's store NVT-
as 8-bit EBCDIC codes. Multics stores NVT-ASCII as four 9-
characters in a 36-bit word. It may be desirable to
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
that FTP provides for very limited data type representations
Transformations desired beyond this limited capability should
performed by the user directly

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."
This has nothing to do with the byte size used for
over the data connection, called the "transfer byte size", and
two should not be confused. For example, NVT-ASCII has a
byte size of 8 bits. If the type is Local byte, then the
command has an obligatory second parameter specifying the
byte size. The transfer byte size is always 8 bits

8

IEN 149 June 1980
RFC 765 File Transfer

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 following
representation types are defined in FTP

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 his 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

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

9

June 1980 IEN 149
File Transfer Protocol RFC 765

A character file may be transferred to a Host for one of
purposes: for printing, for storage and later retrieval, or
processing. If a file is sent for printing, the receiving
must know how the vertical format control is represented. In
second case, it must be possible to store a file at a Host
then retrieve it later in exactly the same form. Finally,
ought to be possible to move a file from one Host to another
process the file at the second Host without undue trouble.
single ASCII or EBCDIC format does not satisfy all
conditions and so these types have a second parameter
one of the following three formats

Non-

This is the default format to be used if the second (format
parameter is omitted. Non-print format must be accepted
all FTP implementations

The file need contain no vertical format information. If
is passed to a printer process, this process may
standard values for spacing and margins

Normally, this format will be used with files destined
processing or just storage

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

Carriage Control (ASA

The file contains ASA (FORTRAN) vertical format
characters. (See RFC 740 Appendix C and Communications
the ACM, Vol. 7, No. 10, 606 (Oct. 1964)). In a line or
record, formatted according to the ASA Standard, the
character is not to be printed. Instead it should be
to determine the vertical movement of the paper which
take place before the rest of the record is printed

10

IEN 149 June 1980
RFC 765 File Transfer

The ASA Standard specifies the following control 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 file
record structure (see below) this is no problem;
will be explicitly marked during transfer and storage.
the file has no record structure, the end-of-
sequence is used to separate printing lines, but
format effectors are overridden by the ASA controls

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

Local byte Byte

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

11

June 1980 IEN 149
File Transfer Protocol RFC 765

difference in byte sizes, then the logical bytes should
packed contiguously, disregarding transfer byte
and with any necessary padding at the end

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 (that is an identical file can be retrieved
the same parameters are used) and should be well
by the FTP implementors

For example, a user sending 36-bit floating-point numbers
a Host with a 32-bit word could send his 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

Another example, a pair of hosts with a 36-bit word size
send data to one another in words by using TYPE L 36.
data would be sent in the 8-bit transmission bytes packed
that 9 transmission bytes carried two host words

A note of caution about parameters: a file must be stored
retrieved with the same parameters if the retrieved version is
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

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 and
file is considered to be a
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 structures

12

IEN 149 June 1980
RFC 765 File Transfer

be accepted for "text" files (i.e., files with TYPE ASCII
EBCDIC) by all FTP implementations. The structure of a file
affect both the transfer mode of a file (see the Section
Transmission Modes) and the interpretation and storage of
file

The "natural" structure of a file will depend on which Host
the file. A source-code file will usually be stored on an IBM 360
in fixed length records but on a PDP-10 as a stream of
partitioned into lines, for example by . If the transfer
files between such disparate sites is to be useful, there must
some way for one site to recognize the other's assumptions
the file

With some sites being naturally file-oriented and others
record-oriented there may be problems if a file with one
is sent to a Host oriented to the other. If a text file is
with record-structure to a Host which is file oriented, then
Host should apply an internal transformation to the file based
the record structure. Obviously this transformation should
useful but it must also be invertible so that an identical
may be retrieved using record structure

In the case of a file being sent with file-structure to
record-oriented Host, there exists the question of what
the Host should use to divide the file into records which can
processed locally. If this division is necessary the
implementation should use the end-of-line sequence,
ASCII, or for EBCDIC text files, as the delimiter. If an
implementation adopts this technique, it must be prepared
reverse the transformation if the file is retrieved
file-structure

Page

To transmit files that are discontinuous FTP defines a
structure. Files of this type are sometimes know as "
access files" or even as "holey files". In these files
is sometimes other information associated with the file as
whole (e.g., a file descriptor), or with a section of the
(e.g., page access controls), or both. In FTP, the sections
the file are called pages

To provide for various page sizes and associated
each page is sent with a page header. The page header has
following defined fields

13

June 1980 IEN 149
File Transfer Protocol RFC 765

Header

The number of logical bytes in the page header
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

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 types
defined

0 = Last

This is used to indicate the end of a
structured transmission. The header length must
4, and the data length must be 0.

1 = Simple

This is the normal type for simple paged files
no page level associated control information.
header length must be 4.

2 = Descriptor

This type is used to transmit the
information for the file as a whole

3 = Access Controled

This is type includes an additional header
for paged files with page level access
information. The header length must be 5.

14

IEN 149 June 1980
RFC 765 File Transfer

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

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 default
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
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

It is possible for the user to specify an alternate data port
use of the PORT command. He might want a file dumped on a
line printer or retrieved from a third party Host. In the
case the user-PI sets up TELNET connections with both server-PI's
One server is then told (by an FTP command) to "listen" for
connection which the other will initiate. The user-PI sends
server-PI a PORT command indicating the data port of the other
Finally both are sent the appropriate transfer commands.
exact sequence of commands and replies sent between
user-controller and the servers is defined in the Section on
Replies

In general it is the server's responsibility to maintain the
connection--to initiate it and to close it. The exception to

15

June 1980 IEN 149
File Transfer Protocol RFC 765

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 TELNET connection is closed legally or otherwise

5. An irrecoverable error condition occurs

Otherwise the close is a server option, the exercise of which
must indicate to the user-process by an appropriate reply

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 his 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 his internal denotation. An IBM 360 record
field may not be recognized at another Host, so the end of

16

IEN 149 June 1980
RFC 765 File Transfer

information may be transferred as a two byte control code
Stream mode or as a flagged bit in a Block or Compressed
descriptor. End of line in an ASCII or EBCDIC file with no
structure should be indicated by or , respectively
Since these transformations imply extra work for some systems
identical systems transferring non-record structured text
might wish to use a binary representation and stream mode for
transfer

The following transmission modes are defined in FTP

The data is transmitted as a stream of bytes. There is
restriction on the representation type used;
structures are allowed

In a record structured file EOR and EOF will each
indicated by a two-byte control code. The first byte of
control code will be all ones, the escape character.
second byte will have the low order bit on and
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
EOF. EOR and EOF may be indicated together on the last
transmitted by turning both low order bits on, i.e.,
value 3. If a byte of all ones was intended to be sent
data, it should be repeated in the second byte of
control code

If the structure is file structure, the EOF is indicated
the sending Host closing the data connection and all
are data bytes

The file is transmitted as a series of data blocks
by one or more header bytes. The header bytes contain
count field, and descriptor code. The count field
the total length of the data block in bytes, thus
the beginning of the next data block (there are no
bits). The descriptor code defines: last block in the
(EOF) last block in the record (EOR), restart marker (
the Section on Error Recovery and Restart) or suspect
(i.e., the data being transferred is suspected of errors
is not reliable). This last code is NOT intended for
control within FTP. It is motivated by the desire of

17

June 1980 IEN 149
File Transfer Protocol RFC 765

exchanging certain types of data (e.g., seismic or
data) to send and receive all the data despite local
(such as "magnetic tape read errors"), but to indicate
the transmission that certain portions are suspect).
structures are allowed in this mode, and any
type may be used

The header consists of the three bytes. Of the 24 bits
header information, the 16 low order bits shall
byte count, and the 8 high order bits shall
descriptor codes as shown below

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
marker

18

IEN 149 June 1980
RFC 765 File Transfer

For example, to transmit a six-character marker,
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 |
+--------+--------+--------+

There are three kinds of information to be sent:
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)
regular data are sent, these n bytes are preceded by a
with the left-most bit set to 0 and the right-most 7
containing the 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
the following 2 bytes are sent

19

June 1980 IEN 149
File Transfer Protocol RFC 765

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
(Space, ASCII code 32., EBCDIC code 64). If the
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
the 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
the succeeding string of bytes

Compressed mode is useful for obtaining increased
on very large network transmissions at a little extra
cost. It can be most effectively used to reduce the size
printer files such as those generated by RJE Hosts

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 TELNET connection (ASCII or EBCDIC).
The marker could represent a bit-count, a record-count, or

20

IEN 149 June 1980
RFC 765 File Transfer

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 TELNET 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
connection and is immediately followed by the command (such
RETR, STOR or LIST) which was being executed when the
failure occurred

FILE TRANSFER

The communication channel from the user-PI to the server-PI
established by a TCP connection from the user to a 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

FTP

ACCESS CONTROL

The following commands specify access control
(command codes are shown in parentheses).

21

June 1980 IEN 149
File Transfer Protocol RFC 765

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 TELNET 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 account

PASSWORD (PASS

The argument field is a TELNET string identifying 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
automaton: 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

22

IEN 149 June 1980
RFC 765 File Transfer

return a 332 or 532 reply depending on whether he
(pending receipt of the ACCounT command) or discards
command, respectively

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 TELNET connection is left open. This is
to the state in which a user finds himself immediately
the TELNET 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 TELNET 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 TELNET connection will cause
server to take the effective action of an abort (ABOR) and
logout (QUIT).

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 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

DATA PORT (PORT

The argument is a HOST-PORT specification for the data
to be used in data connection. There defaults for both
user and server data ports, and under normal
this command and its reply are not needed. If this

23

June 1980 IEN 149
File Transfer Protocol RFC 765

is used the argument is the concatenation of a 32-
internet host address and a 16-bit TCP port address.
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

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

24

IEN 149 June 1980
RFC 765 File Transfer

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

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 TELNET 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. The data,
transferred in response to FTP service commands, shall
be sent over the data connection, except for
informative replies. The following commands specify
service requests

25

June 1980 IEN 149
File Transfer Protocol RFC 765

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

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

MAIL FILE (MLFL

The intent of this command is to enable a user at the
site to mail data (in form of a file) to another user at
server site. It should be noted that the files to be
are transmitted via the data connection in ASCII or
type. (It is the user's responsibility to ensure that
type is correct.) These files should be inserted into
destination user's mailbox by the server in accordance
serving Host mail conventions. The mail may be marked
sent from the particular user HOST and the user specified
the 'USER' command. The argument field may contain a
system ident, or it may be empty. If the argument field
empty or blank (one or more spaces), then the mail
destined for a printer or other designated place for
delivery site mail

26

IEN 149 June 1980
RFC 765 File Transfer

MAIL (MAIL

This command allows a user to send mail that is NOT in
file over the TELNET connection. The argument field
contain system ident, or it may be empty. The ident
defined as above for the MLFL command. After the 'MAIL
command is received, the server is to treat the
lines as text of the mail sent by the user. The mail
is to be terminated by a line containing only a
period, that is, the character sequence "CRLF.CRLF". It
suggested that a modest volume of mail service should
free; i.e., it may be entered before a USER command

MAIL SEND TO TERMINAL (MSND

This command is like the MAIL command, except that the
is displayed on the addressed user's terminal, if
access is currently allowed, otherwise an error is returned

MAIL SEND TO TERMINAL OR MAILBOX (MSOM

This command is like the MAIL command, except that the
is displayed on the addressed user's terminal, if
access is currently allowed, otherwise the data is placed
the user's mailbox

MAIL SEND TO TERMINAL AND MAILBOX (MSAM

This command is like the MAIL command, except that the
is displayed on the addressed user's terminal, if
access is currently allowed, and, in any case, the data
placed in the user's mailbox

MAIL RECIPIENT SCHEME QUESTION (MRSQ

This FTP command is used to select a scheme for
transmission of mail to several users at the same host.
schemes are to list the recipients first, or to send
mail first

MAIL RECIPIENT (MRCP

This command is used to identify the individual
of the mail in the transmission of mail for multiple
at one host

27

June 1980 IEN 149
File Transfer Protocol RFC 765

ALLOCATE (ALLO

This command may be required by some servers to
sufficient storage to accommodate the new file to
transferred. The argument shall be a decimal
representing the number of bytes (using the logical
size) of storage to be reserved for the file. For
sent with record or page structure a maximum record or
size (in logical bytes) might also be necessary; this
indicated by a decimal integer in a second argument field
the command. This second argument is optional, but
present should be separated from the first by the
TELNET characters R . This command shall
followed by a STORe or APPEnd command. The ALLO
should be treated as a NOOP (no operation) by those
which do not require that the maximum size of the file
declared beforehand, and those servers interested in
the maximum record or page size should accept a dummy
in the first argument and ignore it

RESTART (REST

The argument field represents the server marker at
file transfer is to be restarted. This command does
cause file transfer but "spaces" over the file to
specified data checkpoint. This command shall
immediately followed by the appropriate FTP service
which shall cause file transfer to resume

RENAME FROM (RNFR

This command specifies 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
specified in the immediately preceding "rename from
command. Together the two commands cause a file to
renamed

ABORT (ABOR

This command tells the server to abort the previous
service command and any associated transfer of data.

28

IEN 149 June 1980
RFC 765 File Transfer

abort command may require "special action", as discussed
the Section on FTP Commands, to force recognition by
server. No action is to be taken if the previous
has been completed (including data transfer). The
connection is not to be closed by the server, but the
connection must be closed

There are two cases for the server upon receipt of
command: (1) the FTP service command was already completed
or (2) the FTP service command is still in progress

In the first case, the server closes the data
(if it is open) and responds with a 226 reply,
that the abort command was successfully processed

In the second case, the server aborts the FTP service
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
processed

DELETE (DELE

This command causes the file specified in the pathname to
deleted at the server site. If an extra level of
is desired (such as the query, "DO you really wish
delete?"), it should be provided by the user-FTP process

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

LIST (LIST

This command causes a list to be sent from the server to
passive DTP. If the pathname specifies a directory,
server should transfer a list of files in the
directory. If the pathname specifies a file then the
should send current information on the file. A
argument implies the user's current working or

29

June 1980 IEN 149
File Transfer Protocol RFC 765

directory. The data transfer is over the data connection
type ASCII or type EBCDIC. (The user must ensure that
TYPE is appropriately ASCII or EBCDIC).

NAME-LIST (NLST

This command causes a directory listing to be sent
server to user site. The pathname should specify
directory or other system-specific file group descriptor;
null argument implies the current directory. The
will return a stream of names of files and no
information. The data will be transferred in ASCII
EBCDIC type over the data connection as valid
strings separated by or . (Again the user
ensure that the TYPE is correct.)

SITE PARAMETERS (SITE

This command is used by the server to provide
specific to his system that are essential to file
but not sufficiently universal to be included as commands
the protocol. The nature of these services and
specification of their syntax can be stated in a reply
the HELP SITE command

STATUS (STAT

This command shall cause a status response to be sent
the TELNET connection in the form of a reply. The
may be sent during a file transfer (along with the TELNET
and Synch signals--see the Section on FTP Commands) in
case the server will respond with the status of
operation in progress, or it may be sent between
transfers. In the latter case the command may have
argument field. If the argument is a pathname, the
is analogous to the "list" command except that data shall
transferred over the TELNET connection. If a
pathname is given, the server may respond with a list
file names or attributes associated with that specification
If no argument is given, the server should return
status information about the server FTP process.
should include current values of all transfer parameters
the status of connections

30

IEN 149 June 1980
RFC 765 File Transfer

HELP (HELP

This command shall cause the server to send
information regarding its implementation status over
TELNET connection to the user. The command may take
argument (e.g., any command name) and return more
information as a response. The reply is type 211 or 214.
It is suggested that HELP be allowed before entering a
command. The server may use this repl