5. DECLARATIVE SPECIFICATIONS
5.1. MINIMUM IMPLEMENTATION
In order to make FTP workable without needless error messages, the
following minimum implementation is required for all servers:
TYPE - ASCII Non-print
MODE - Stream
STRUCTURE - File, Record
COMMANDS - USER, QUIT, PORT,
TYPE, MODE, STRU,
for the default values
RETR, STOR,
NOOP.
The default values for transfer parameters are:
TYPE - ASCII Non-print
MODE - Stream
STRU - File
All hosts must accept the above as the standard defaults.
5.2. CONNECTIONS
The server protocol interpreter shall "listen" on Port L. The
user or user protocol interpreter shall initiate the full-duplex
control connection. Server- and user- processes should follow the
conventions of the Telnet protocol as specified in the
ARPA-Internet Protocol Handbook [1]. Servers are under no
obligation to provide for editing of command lines and may require
that it be done in the user host. The control connection shall be
closed by the server at the user's request after all transfers and
replies are completed.
The user-DTP must "listen" on the specified data port; this may be
the default user port (U) or a port specified in the PORT command.
The server shall initiate the data connection from his own default
data port (L-1) using the specified user data port. The direction
of the transfer and the port used will be determined by the FTP
service command.
Note that all FTP implementation must support data transfer using
the default port, and that only the USER-PI may initiate the use
of non-default ports.
When data is to be transferred between two servers, A and B (refer
to Figure 2), the user-PI, C, sets up control connections with
both server-PI's. One of the servers, say A, is then sent a PASV
command telling him to "listen" on his data port rather than
initiate a connection when he receives a transfer service command.
When the user-PI receives an acknowledgment to the PASV command,
which includes the identity of the host and port being listened
on, the user-PI then sends A's port, a, to B in a PORT command; a
reply is returned. The user-PI may then send the corresponding
service commands to A and B. Server B initiates the connection
and the transfer proceeds. The command-reply sequence is listed
below where the messages are vertically synchronous but
horizontally asynchronous:
User-PI - Server A User-PI - Server B
------------------ ------------------
C->A : Connect C->B : Connect
C->A : PASV
A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
C->B : PORT A1,A2,A3,A4,a1,a2
B->C : 200 Okay
C->A : STOR C->B : RETR
B->A : Connect to HOST-A, PORT-a
Figure 3
The data connection shall be closed by the server under the
conditions described in the Section on Establishing Data
Connections. If the data connection is to be closed following a
data transfer where closing the connection is not required to
indicate the end-of-file, the server must do so immediately.
Waiting until after a new transfer command is not permitted
because the user-process will have already tested the data
connection to see if it needs to do a "listen"; (remember that the
user must "listen" on a closed data port BEFORE sending the
transfer request). To prevent a race condition here, the server
sends a reply (226) after closing the data connection (or if the
connection is left open, a "file transfer completed" reply (250)
and the user-PI should wait for one of these replies before
issuing a new transfer command).
Any time either the user or server see that the connection is
being closed by the other side, it should promptly read any
remaining data queued on the connection and issue the close on its
own side.
5.3. COMMANDS
The commands are Telnet character strings transmitted over the
control connections as described in the Section on FTP Commands.
The command functions and semantics are described in the Section
on Access Control Commands, Transfer Parameter Commands, FTP
Service Commands, and Miscellaneous Commands. The command syntax
is specified here.
The commands begin with a command code followed by an argument
field. The command codes are four or fewer alphabetic characters.
Upper and lower case alphabetic characters are to be treated
identically. Thus, any of the following may represent the
retrieve command:
RETR Retr retr ReTr rETr
This also applies to any symbols representing parameter values,
such as A or a for ASCII TYPE. The command codes and the argument
fields are separated by one or more spaces.
The argument field consists of a variable length character string
ending with the character sequence <CRLF> (Carriage Return, Line
Feed) for NVT-ASCII representation; for other negotiated languages
a different end of line character might be used. It should be
noted that the server is to take no action until the end of line
code is received.
The syntax is specified below in NVT-ASCII. All characters in the
argument field are ASCII characters including any ASCII
represented decimal integers. Square brackets denote an optional
argument field. If the option is not taken, the appropriate
default is implied.
5.3.1. FTP COMMANDS
The following are the FTP commands:
USER <SP> <username> <CRLF>
PASS <SP> <password> <CRLF>
ACCT <SP> <account-information> <CRLF>
CWD <SP> <pathname> <CRLF>
CDUP <CRLF>
SMNT <SP> <pathname> <CRLF>
QUIT <CRLF>
REIN <CRLF>
PORT <SP> <host-port> <CRLF>
PASV <CRLF>
TYPE <SP> <type-code> <CRLF>
STRU <SP> <structure-code> <CRLF>
MODE <SP> <mode-code> <CRLF>
RETR <SP> <pathname> <CRLF>
STOR <SP> <pathname> <CRLF>
STOU <CRLF>
APPE <SP> <pathname> <CRLF>
ALLO <SP> <decimal-integer>
[<SP> R <SP> <decimal-integer>] <CRLF>
REST <SP> <marker> <CRLF>
RNFR <SP> <pathname> <CRLF>
RNTO <SP> <pathname> <CRLF>
ABOR <CRLF>
DELE <SP> <pathname> <CRLF>
RMD <SP> <pathname> <CRLF>
MKD <SP> <pathname> <CRLF>
PWD <CRLF>
LIST [<SP> <pathname>] <CRLF>
NLST [<SP> <pathname>] <CRLF>
SITE <SP> <string> <CRLF>
SYST <CRLF>
STAT [<SP> <pathname>] <CRLF>
HELP [<SP> <string>] <CRLF>
NOOP <CRLF>
5.3.2. FTP COMMAND ARGUMENTS
The syntax of the above argument fields (using BNF notation
where applicable) is:
<username> ::= <string>
<password> ::= <string>
<account-information> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and
<LF>
<marker> ::= <pr-string>
<pr-string> ::= <pr-char> | <pr-char><pr-string>
<pr-char> ::= printable characters, any
ASCII code 33 through 126
<byte-size> ::= <number>
<host-port> ::= <host-number>,<port-number>
<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255
<form-code> ::= N | T | C
<type-code> ::= A [<sp> <form-code>]
| E [<sp> <form-code>]
| I
| L <sp> <byte-size>
<structure-code> ::= F | R | P
<mode-code> ::= S | B | C
<pathname> ::= <string>
<decimal-integer> ::= any decimal integer
5.4. SEQUENCING OF COMMANDS AND
REPLIES
The communication between the user and server is intended to be an
alternating dialogue. As such, the user issues an FTP command and
the server responds with a prompt primary reply. The user should
wait for this initial primary success or failure response before
sending further commands.
Certain commands require a second reply for which the user should
also wait. These replies may, for example, report on the progress
or completion of file transfer or the closing of the data
connection. They are secondary replies to file transfer commands.
One important group of informational replies is the connection
greetings. Under normal circumstances, a server will send a 220
reply, "awaiting input", when the connection is completed. The
user should wait for this greeting message before sending any
commands. If the server is unable to accept input right away, a
120 "expected delay" reply should be sent immediately and a 220
reply when ready. The user will then know not to hang up if there
is a delay.
Spontaneous Replies
Sometimes "the system" spontaneously has a message to be sent
to a user (usually all users). For example, "System going down
in 15 minutes". There is no provision in FTP for such
spontaneous information to be sent from the server to the user.
It is recommended that such information be queued in the
server-PI and delivered to the user-PI in the next reply
(possibly making it a multi-line reply).
The table below lists alternative success and failure replies for
each command. These must be strictly adhered to; a server may
substitute text in the replies, but the meaning and action implied
by the code numbers and by the specific command reply sequence
cannot be altered.
Command-Reply Sequences
In this section, the command-reply sequence is presented. Each
command is listed with its possible replies; command groups are
listed together. Preliminary replies are listed first (with
their succeeding replies indented and under them), then
positive and negative completion, and finally intermediary
replies with the remaining commands from the sequence
following. This listing forms the basis for the state
diagrams, which will be presented separately.
Connection Establishment
120
220
220
421
Login
USER
230
530
500, 501, 421
331, 332
PASS
230
202
530
500, 501, 503, 421
332
ACCT
230
202
530
500, 501, 503, 421
CWD
250
500, 501, 502, 421, 530, 550
CDUP
200
500, 501, 502, 421, 530, 550
SMNT
202, 250
500, 501, 502, 421, 530, 550
Logout
REIN
120
220
220
421
500, 502
QUIT
221
500
Transfer parameters
PORT
200
500, 501, 421, 530
PASV
227
500, 501, 502, 421, 530
MODE
200
500, 501, 504, 421, 530
TYPE
200
500, 501, 504, 421, 530
STRU
200
500, 501, 504, 421, 530
File action commands
ALLO
200
202
500, 501, 504, 421, 530
REST
500, 501, 502, 421, 530
350
STOR
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
STOU
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
RETR
125, 150
(110)
226, 250
425, 426, 451
450, 550
500, 501, 421, 530
LIST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
NLST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
APPE
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 550, 452, 553
500, 501, 502, 421, 530
RNFR
450, 550
500, 501, 502, 421, 530
350
RNTO
250
532, 553
500, 501, 502, 503, 421, 530
DELE
250
450, 550
500, 501, 502, 421, 530
RMD
250
500, 501, 502, 421, 530, 550
MKD
257
500, 501, 502, 421, 530, 550
PWD
257
500, 501, 502, 421, 550
ABOR
225, 226
500, 501, 502, 421
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
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.
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 |
+---+ +---+ +---+
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.
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 |
+---+ +---+------------->+---+
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
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.
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.
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.
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
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
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
<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.
APPENDIX III - RFCs on FTP
Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
MIT-Project MAC, 16 April 1971.
Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
(NIC 6794), MIT-Project MAC, 23 June 1971.
Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
UCLA/CCN, 29 September 1971.
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
(NIC 7813), MIT-Project MAC, 17 November 1971.
McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
RFC 281 (NIC 8163), BBN, 8 December 1971.
Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
25 January 1972.
Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
MIT-Project MAC, 8 July 1972.
Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
27 November 1972.
Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.
Braden, Bob, "Comments on File Transfer Protocol", RFC 430
(NIC 13299), UCLA/CCN, 7 February 1973.
Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
RFC 438 (NIC 13770), BBN, 15 January 1973.
Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
27 February 1973.
McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
16 February 1973.
Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
(NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
12 July 1973.
Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.
Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.
Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
"Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
Ames Research Center, SRI-ARC, 28 February 1974.
Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
(NIC 14573), MIT-DMCG, 21 February 1973.
Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
8 March 1973.
Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
MIT-DMCG, 6 March 1973.
Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
SRI-ARC, 8 March 1973.
White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
SRI-ARC, 8 March 1973.
Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
(NIC 16157), MIT-Multics, 26 June 1973.
Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
RFC 520 (NIC 16819), Illinois, 25 June 1973.
Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
(NIC 17451), UCSD-CC, 22 June 1973.
Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
15 November 1973.
McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
29 November 1973.
Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
Service", RFC 630 (NIC 30237), BBN, 10 April 1974.
Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
UCLA/NMC, 5 June 1974.
Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
SU-AI, 10 May 1975.
Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
28 May 1975.
Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.
Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
31 October 1977.
Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
SRI-KL, 30 December 1977.
Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
10 December 1978.
Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
June 1980.
Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
Commands", RFC 776, BBN, December 1980.
Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
July 1985.
REFERENCES
[1] Feinler, Elizabeth, "Internet Protocol Transition Workbook",
Network Information Center, SRI International, March 1982.
[2] Postel, Jon, "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
Specification", RFC 854, ISI, May 1983.
[4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
ISI, April 1985.