450, 550
500, 501, 502, 421, 530
RMD
250
500, 501, 502, 421, 530, 550
MKD
257
500, 501, 502, 421, 530, 550
PWD
257
500, 501, 502, 421, 550
ABOR
225, 226
500, 501, 502, 421
RFC959 October 1985
File Transfer Protocol
Informational commands
SYST
215
500, 501, 502, 421
STAT
211, 212, 213
450
500, 501, 502, 421, 530
HELP
211, 214
500, 501, 502, 421
Miscellaneous commands
SITE
200
202
500, 501, 530
NOOP
200
500 421
RFC959 October 1985
File Transfer Protocol
6. STATE DIAGRAMS
Here we present state diagrams for a very simple minded FTP
implementation. Only the first digit of the reply codes is used.
There is one state diagram for each group of FTP commands or command
sequences.
The command groupings were determined by constructing a model for
each command then collecting together the commands with structurally
identical models.
For each command or command sequence there are three possible
outcomes: success (S), failure (F), and error (E). In the state
diagrams below we use the symbol B for "begin", and the symbol W for
"wait for reply".
We first present the diagram that represents the largest group of FTP
commands:
1,3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ +---+ +---+
|
| 4,5 +---+
----------->| F |
+---+
This diagram models the commands:
ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE.
RFC959 October 1985
File Transfer Protocol
The other large group of commands is represented by a very similar
diagram:
3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ --->+---+ +---+
| | |
| | | 4,5 +---+
| 1 | ----------->| F |
----- +---+
This diagram models the commands:
APPE, LIST, NLST, REIN, RETR, STOR, and STOU.
Note that this second model could also be used to represent the first
group of commands, the only difference being that in the first group
the 100 series replies are unexpected and therefore treated as error,
while the second group expects (some may require) 100 series replies.
Remember that at most, one 100 series reply is allowed per command.
The remaining diagrams model command sequences, perhaps the simplest
of these is the rename sequence:
+---+ RNFR +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 1,3 | | +---+
| 2| --------
| | | |
V | | |
+---+ RNTO +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ +---+ +---+
RFC959 October 1985
File Transfer Protocol
The next diagram is a simple model of the Restart command:
+---+ REST +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 3 | | +---+
| 2| --------
| | | |
V | | |
+---+ cmd +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ -->+---+ +---+
| |
| 1 |
------
Where "cmd" is APPE, STOR, or RETR.
We note that the above three models are similar. The Restart differs
from the Rename two only in the treatment of 100 series replies at
the second stage, while the second group expects (some may require)
100 series replies. Remember that at most, one 100 series reply is
allowed per command.
RFC959 October 1985
File Transfer Protocol
The most complicated diagram is for the Login sequence:
1
+---+ USER +---+------------->+---+
| B |---------->| W | 2 ---->| E |
+---+ +---+------ | -->+---+
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| | | | |
| --------- |
| 1| | | |
V | | | |
+---+ PASS +---+ 2 | ------>+---+
| |---------->| W |------------->| S |
+---+ +---+ ---------->+---+
| | | | |
3 | |4,5| | |
-------------- -------- |
| | | | |
| | | | |
| -----------
| 1,3| | | |
V | 2| | |
+---+ ACCT +---+-- | ----->+---+
| |---------->| W | 4,5 -------->| F |
+---+ +---+------------->+---+
RFC959 October 1985
File Transfer Protocol
Finally, we present a generalized diagram that could be used to model
the command and reply interchange:
------------------------------------
| |
Begin | |
| V |
| +---+ cmd +---+ 2 +---+ |
-->| |------->| |---------->| | |
| | | W | | S |-----|
-->| | -->| |----- | | |
| +---+ | +---+ 4,5 | +---+ |
| | | | | | |
| | | 1| |3 | +---+ |
| | | | | | | | |
| | ---- | ---->| F |-----
| | | | |
| | | +---+
-------------------
|
|
V
End
RFC959 October 1985
File Transfer Protocol
7. TYPICAL FTP SCENARIO
User at host U wanting to transfer files to/from host S:
In general, the user will communicate to the server via a mediating
user-FTP process. The following may be a typical scenario. The
user-FTP prompts are shown in parentheses, '---->' represents
commands from host U to host S, and '<----' represents replies from
host S to host U.
LOCAL COMMANDS BY USER ACTION INVOLVED
ftp (host) multics<CR> Connect to host S, port L,
establishing control connections.
<---- 220 Service ready <CRLF>.
username Doe <CR> USER Doe<CRLF>---->
<---- 331 User name ok,
need password<CRLF>.
password mumble <CR> PASS mumble<CRLF>---->
<---- 230 User logged in<CRLF>.
retrieve (local type) ASCII<CR>
(local pathname) test 1 <CR> User-FTP opens local file in ASCII.
(for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
<---- 150 File status okay;
about to open data
connection<CRLF>.
Server makes data connection
to port U.
<---- 226 Closing data connection,
file transfer successful<CRLF>.
type Image<CR> TYPE I<CRLF> ---->
<---- 200 Command OK<CRLF>
store (local type) image<CR>
(local pathname) file dump<CR> User-FTP opens local file in Image.
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
<---- 550 Access denied<CRLF>
terminate QUIT <CRLF> ---->
Server closes all
connections.
8. CONNECTION ESTABLISHMENT
The FTP control connection is established via TCP between the user
process port U and the server process port L. This protocol is
assigned the service port 21 (25 octal), that is L=21.
RFC959 October 1985
File Transfer Protocol
APPENDIX I - PAGE STRUCTURE
The need for FTP to support page structure derives principally from
the need to support efficient transmission of files between TOPS-20
systems, particularly the files used by NLS.
The file system of TOPS-20 is based on the concept of pages. The
operating system is most efficient at manipulating files as pages.
The operating system provides an interface to the file system so that
many applications view files as sequential streams of characters.
However, a few applications use the underlying page structures
directly, and some of these create holey files.
A TOPS-20 disk file consists of four things: a pathname, a page
table, a (possibly empty) set of pages, and a set of attributes.
The pathname is specified in the RETR or STOR command. It includes
the directory name, file name, file name extension, and generation
number.
The page table contains up to 2**18 entries. Each entry may be
EMPTY, or may point to a page. If it is not empty, there are also
some page-specific access bits; not all pages of a file need have the
same access protection.
A page is a contiguous set of 512 words of 36 bits each.
The attributes of the file, in the File Descriptor Block (FDB),
contain such things as creation time, write time, read time, writer's
byte-size, end-of-file pointer, count of reads and writes, backup
system tape numbers, etc.
Note that there is NO requirement that entries in the page table be
contiguous. There may be empty page table slots between occupied
ones. Also, the end of file pointer is simply a number. There is no
requirement that it in fact point at the "last" datum in the file.
Ordinary sequential I/O calls in TOPS-20 will cause the end of file
pointer to be left after the last datum written, but other operations
may cause it not to be so, if a particular programming system so
requires.
In fact, in both of these special cases, "holey" files and
end-of-file pointers NOT at the end of the file, occur with NLS data
files.
RFC959 October 1985
File Transfer Protocol
The TOPS-20 paged files can be sent with the FTP transfer parameters:
TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
Each page of information has a header. Each header field, which is a
logical byte, is a TOPS-20 word, since the TYPE is L 36.
The header fields are:
Word 0: Header Length.
The header length is 5.
Word 1: Page Index.
If the data is a disk file page, this is the number of that
page in the file's page map. Empty pages (holes) in the file
are simply not sent. Note that a hole is NOT the same as a
page of zeros.
Word 2: Data Length.
The number of data words in this page, following the header.
Thus, the total length of the transmission unit is the Header
Length plus the Data Length.
Word 3: Page Type.
A code for what type of chunk this is. A data page is type 3,
the FDB page is type 2.
Word 4: Page Access Control.
The access bits associated with the page in the file's page
map. (This full word quantity is put into AC2 of an SPACS by
the program reading from net to disk.)
After the header are Data Length data words. Data Length is
currently either 512 for a data page or 31 for an FDB. Trailing
zeros in a disk file page may be discarded, making Data Length less
than 512 in that case.
RFC959 October 1985
File Transfer Protocol
APPENDIX II - DIRECTORY COMMANDS
Since UNIX has a tree-like directory structure in which directories
are as easy to manipulate as ordinary files, it is useful to expand
the FTP servers on these machines to include commands which deal with
the creation of directories. Since there are other hosts on the
ARPA-Internet which have tree-like directories (including TOPS-20 and
Multics), these commands are as general as possible.
Four directory commands have been added to FTP:
MKD pathname
Make a directory with the name "pathname".
RMD pathname
Remove the directory with the name "pathname".
PWD
Print the current working directory name.
CDUP
Change to the parent of the current working directory.
The "pathname" argument should be created (removed) as a
subdirectory of the current working directory, unless the "pathname"
string contains sufficient information to specify otherwise to the
server, e.g., "pathname" is an absolute pathname (in UNIX and
Multics), or pathname is something like "<abso.lute.path>" to
TOPS-20.
REPLY CODES
The CDUP command is a special case of CWD, and is included to
simplify the implementation of programs for transferring directory
trees between operating systems having different syntaxes for
naming the parent directory. The reply codes for CDUP be
identical to the reply codes of CWD.
The reply codes for RMD be identical to the reply codes for its
file analogue, DELE.
The reply codes for MKD, however, are a bit more complicated. A
freshly created directory will probably be the object of a future
RFC959 October 1985
File Transfer Protocol
CWD command. Unfortunately, the argument to MKD may not always be
a suitable argument for CWD. This is the case, for example, when
a TOPS-20 subdirectory is created by giving just the subdirectory
name. That is, with a TOPS-20 server FTP, the command sequence
MKD MYDIR
CWD MYDIR
will fail. The new directory may only be referred to by its
"absolute" name; e.g., if the MKD command above were issued while
connected to the directory <DFRANKLIN>, the new subdirectory
could only be referred to by the name <DFRANKLIN.MYDIR>.
Even on UNIX and Multics, however, the argument given to MKD may
not be suitable. If it is a "relative" pathname (i.e., a pathname
which is interpreted relative to the current directory), the user
would need to be in the same current directory in order to reach
the subdirectory. Depending on the application, this may be
inconvenient. It is not very robust in any case.
To solve these problems, upon successful completion of an MKD
command, the server should return a line of the form:
257<space>"<directory-name>"<space><commentary>
That is, the server will tell the user what string to use when
referring to the created directory. The directory name can
contain any character; embedded double-quotes should be escaped by
double-quotes (the "quote-doubling" convention).
For example, a user connects to the directory /usr/dm, and creates
a subdirectory, named pathname:
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
257 "/usr/dm/pathname" directory created
An example with an embedded double quote:
MKD foo"bar
257 "/usr/dm/foo""bar" directory created
CWD /usr/dm/foo"bar
200 directory changed to /usr/dm/foo"bar
RFC959 October 1985
File Transfer Protocol
The prior existence of a subdirectory with the same name is an
error, and the server must return an "access denied" error reply
in that case.
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
521-"/usr/dm/pathname" directory already exists;
521 taking no action.
The failure replies for MKD are analogous to its file creating
cousin, STOR. Also, an "access denied" return is given if a file
name with the same name as the subdirectory will conflict with the
creation of the subdirectory (this is a problem on UNIX, but
shouldn't be one on TOPS-20).
Essentially because the PWD command returns the same type of
information as the successful MKD command, the successful PWD
command uses the 257 reply code as well.
SUBTLETIES
Because these commands will be most useful in transferring
subtrees from one machine to another, carefully observe that the
argument to MKD is to be interpreted as a sub-directory of the
current working directory, unless it contains enough information
for the destination host to tell otherwise. A hypothetical
example of its use in the TOPS-20 world:
CWD <some.where>
200 Working directory changed
MKD overrainbow
257 "<some.where.overrainbow>" directory created
CWD overrainbow
431 No such directory
CWD <some.where.overrainbow>
200 Working directory changed
CWD <some.where>
200 Working directory changed to <some.where>
MKD <unambiguous>
257 "<unambiguous>" directory created
CWD <unambiguous>
Note that the first example results in a subdirectory of the
connected directory. In contrast, the argument in the second
example contains enough information for TOPS-20 to tell that the
RFC959 October 1985
File Transfer Protocol
<unambiguous> directory is a top-level directory. Note also that
in the first example the user "violated" the protocol by
attempting to access the freshly created directory with a name
other than the one returned by TOPS-20. Problems could have
resulted in this case had there been an <overrainbow> directory;
this is an ambiguity inherent in some TOPS-20 implementations.
Similar considerations apply to the RMD command. The point is
this: except where to do so would violate a host's conventions for
denoting relative versus absolute pathnames, the host should treat
the operands of the MKD and RMD commands as subdirectories. The
257 reply to the MKD command must always contain the absolute
pathname of the created directory.
RFC959 October 1985
File Transfer Protocol
APPENDIX III - RFCs on FTP
Bhushan, Abhay, "A File Transfer Protocol", RFC114 (NIC 5823),
MIT-Project MAC, 16 April 1971.
Harslem, Eric, and John Heafner, "Comments on RFC114 (A File
Transfer Protocol)", RFC141 (NIC 6726), RAND, 29 April 1971.
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC172
(NIC 6794), MIT-Project MAC, 23 June 1971.
Braden, Bob, "Comments on DTP and FTP Proposals", RFC238 (NIC 7663),
UCLA/CCN, 29 September 1971.
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC265
(NIC 7813), MIT-Project MAC, 17 November 1971.
McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
RFC281 (NIC 8163), BBN, 8 December 1971.
Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
Transfer Protocol", RFC294 (NIC 8304), MIT-Project MAC,
25 January 1972.
Bhushan, Abhay, "The File Transfer Protocol", RFC354 (NIC 10596),
MIT-Project MAC, 8 July 1972.
Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC354)",
RFC385 (NIC 11357), MIT-Project MAC, 18 August 1972.
Hicks, Greg, "User FTP Documentation", RFC412 (NIC 12404), Utah,
27 November 1972.
Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
Comments", RFC414 (NIC 12406), MIT-Project MAC, 20 November 1972.
Braden, Bob, "Comments on File Transfer Protocol", RFC430
(NIC 13299), UCLA/CCN, 7 February 1973.
Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
RFC438 (NIC 13770), BBN, 15 January 1973.
Braden, Bob, "Print Files in FTP", RFC448 (NIC 13299), UCLA/CCN,
27 February 1973.
McKenzie, Alex, "File Transfer Protocol", RFC454 (NIC 14333), BBN,
16 February 1973.
RFC959 October 1985
File Transfer Protocol
Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC458
(NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
Neigus, Nancy, "File Transfer Protocol", RFC542 (NIC 17759), BBN,
12 July 1973.
Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
Protocol", RFC607 (NIC 21255), UCSB, 7 January 1974.
Pogran, Ken, and Nancy Neigus, "Response to RFC607 - Comments on the
File Transfer Protocol", RFC614 (NIC 21530), BBN, 28 January 1974.
Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
"Comments on the File Transfer Protocol", RFC624 (NIC 22054), UCSB,
Ames Research Center, SRI-ARC, 28 February 1974.
Bhushan, Abhay, "FTP Comments and Response to RFC430", RFC463
(NIC 14573), MIT-DMCG, 21 February 1973.
Braden, Bob, "FTP Data Compression", RFC468 (NIC 14742), UCLA/CCN,
8 March 1973.
Bhushan, Abhay, "FTP and Network Mail System", RFC475 (NIC 14919),
MIT-DMCG, 6 March 1973.
Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
RFC478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
White, Jim, "Use of FTP by the NIC Journal", RFC479 (NIC 14948),
SRI-ARC, 8 March 1973.
White, Jim, "Host-Dependent FTP Parameters", RFC480 (NIC 14949),
SRI-ARC, 8 March 1973.
Padlipsky, Mike, "An FTP Command-Naming Problem", RFC506
(NIC 16157), MIT-Multics, 26 June 1973.
Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
RFC520 (NIC 16819), Illinois, 25 June 1973.
Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC532
(NIC 17451), UCSD-CC, 22 June 1973.
Braden, Bob, "TENEX FTP Problem", RFC571 (NIC 18974), UCLA/CCN,
15 November 1973.
RFC959 October 1985
File Transfer Protocol
McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
Schedule Change", RFC593 (NIC 20615), BBN and MITRE,
29 November 1973.
Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
Service", RFC630 (NIC 30237), BBN, 10 April 1974.
Postel, Jon, "Revised FTP Reply Codes", RFC640 (NIC 30843),
UCLA/NMC, 5 June 1974.
Harvey, Brian, "Leaving Well Enough Alone", RFC686 (NIC 32481),
SU-AI, 10 May 1975.
Harvey, Brian, "One More Try on the FTP", RFC691 (NIC 32700), SU-AI,
28 May 1975.
Lieb, J., "CWD Command of FTP", RFC697 (NIC 32963), 14 July 1975.
Harrenstien, Ken, "FTP Extension: XSEN", RFC737 (NIC 42217), SRI-KL,
31 October 1977.
Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC743 (NIC 42758),
SRI-KL, 30 December 1977.
Lebling, P. David, "Survey of FTP Mail and MLFL", RFC751, MIT,
10 December 1978.
Postel, Jon, "File Transfer Protocol Specification", RFC765, ISI,
June 1980.
Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
Commands", RFC776, BBN, December 1980.
Padlipsky, Michael, "FTP Unique-Named Store Command", RFC949, MITRE,
July 1985.
RFC959 October 1985
File Transfer Protocol
REFERENCES
[1] Feinler, Elizabeth, "Internet Protocol Transition Workbook",
Network Information Center, SRI International, March 1982.
[2] Postel, Jon, "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC793, DARPA, September 1981.
[3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
Specification", RFC854, ISI, May 1983.
[4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC943,
ISI, April 1985.