clipper@uwocsd.csd.uwo.ca (Khun Yee Fung) (10/12/90)
This is an attempt to design an anonymous file tranfer protocol (for
TCP/IP). It consists of a README file, a LaTeX file and a LaTeX style
file. If you want the postscript file, send me a note.
clipper@csd.uwo.ca
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# README
# aftp.tex
# aftp.sty
# This archive created: Thu Oct 11 18:48:49 1990
export PATH; PATH=/bin:$PATH
if test -f 'README'
then
echo shar: will not over-write existing file "'README'"
else
cat << \SHAR_EOF > 'README'
This is a protocol I designed a while ago to replace the anonymous FTP
option in FTP. I tried to mail Postel. Of course, no response from
him. Maybe I just don't deserve any attention from him. I also tried
to post a message in comp.protocol.tcp-ip. I think my message must
have been written very badly and so nobody responded or the message
was not posted correctly. Anyhow, I now send this to this newsgroup
and I will forget about this whole thing if nobody responds. It is a
bit discouraging.
I am new to designing protocols. I just think after using Anonymous
FTP for so long, I am a bit fed up by the ad hoc'ism of it. So, I sat
down and thought about it for a while and came up with this protocol.
If you think you like the idea, please tell me. If you think FTP is
perfectly good enough for anonymous transfering of files, tell me too.
Of course, you can ignore this message.
This is only a draft. I can incorporate any improvements into it. Send
me any ideas you have. I would really like to know what kind of
service you think should be provided by anonymous file transfering.
Khun Yee
clipper@csd.uwo.ca
SHAR_EOF
fi # end of overwriting check
if test -f 'aftp.tex'
then
echo shar: will not over-write existing file "'aftp.tex'"
else
cat << \SHAR_EOF > 'aftp.tex'
%\documentstyle[ftm,aftp,11pt]{article}
\documentstyle[aftp,11pt]{article}
\setcounter{secnumdepth}{2}
\begin{document}
\pagestyle{fungheadings}
\markright{Anonymous File Transfer Protocol\hfill September 1990}
\evenfooter{\sf Khun Yee Fung\hfill [Page \thepage]}
\oddfooter{\sf Khun Yee Fung\hfill [Page \thepage]}
\noindent Draft Protocol\hfill Khun Yee Fung\par
\noindent The University of Western Ontario\hfill September 1990\par
\vspace*{20pt}
\begin{center}
\LARGE\bf
%\font\tfont=chanc at 20pt\tfont
Anonymous File Transfer Protocol (AFTP)
\end{center}
\vspace*{20pt}
\section{Introduction}
The purpose of Anonymous File Transfer Protocol (AFTP) is to promote
sharing of public available programs, documents, and data. To achieve
this objective, AFTP shields the user from the variations in various
file systems and operating systems. This protocol also allows multiple
data transfer simultaneously. This protocol is specified such that
intelligent, flexible and secure servers and clients can be written
easily.
\section{Background}
Anonymous FTP has been around for a few years now. Its popularity is
undeniable. You can find lists of anonymous FTP sites published in
newsgroups, anonymous FTP sites for software requested in newsgroups,
and anonymous FTP site given for software written.
The use of anonymous FTP also rises a lot of concerns. Foremost is the
security of the machines providing this service. FTP is meant for
users to log in to their own accounts and transfer files from a
machine to another machine. The accounts must exist for the users to
log on. Thus accountability is maintained, albeit remotely. However,
anonymous FTP has the opposite idea of letting anybody to logon using
a common account. Restrictions must then be applied to ensure the
integrity of the file system of the server machine. Since the FTP
server must have a very high privilege to be able to log on to any
user's account, any hole in the implementation can lead to disaster
if a criminal logs on. I think anonymous FTP is in general unsuitable
for FTP because of this security problem.
Another reason of not having anonymous FTP in FTP is that there are
many different machines around. Each operating system usually has
different convention to name files, organizes directories, and in
general does things differently. For normal FTP, this is no problem
because the user is expected to know the remote machine well enough to
transfer files from one machine to another. But for anonymous FTP,
this is different. A user can log in on a Tops-10 machine without a
clue as to how to proceed. Directories can be organized in a bizarre
way. Different structures for files and directories means that
automatic programs for transferring files at a set time from a machine
are difficult to write and usually not general enough to work on all
machines.
AFTP tries to aviate these problems. It is designed solely for
anonymous file transfer. It only has to know a limited amount of
files. Therefore, the AFTP server can have the same privilege as a
normal user on a system. It is easy to limit its knowledge of the
machine it is on. On a Unix machine, the AFTP server can be owned by a
ordinary user id. And implement the server such that only files owned
by this user id can be transferred. This solves the security problem.
To solve the incompatible file systems problem, AFTP defines a fixed
format for directory listings. It decrees that files and directories
must be listed separately. It also provides a
change-to-parent-directory command for tree-structured file systems.
\section{Data Representation}
The only recognized data representation in AFTP is the octet. The
server and client are responsible for the conversion of other
representations to octets. As in standard practice, ASCII characters
are converted to octets by adding a zero bit in the most significant
end of the characters. For example, an ASCII character, 1001001 in
binary is converted to a octet, 01001001 in binary.
There is a provision for extending the number of data representations
recognized by AFTP. Up to 10 file types can be specified. This will be
left for future considerations.
Whether to use $<$CR$>$$<$LF$>$ or $<$LF$>$ to delimit lines in a
ASCII file is left to the discretion of the servers and clients. The
server and the client are expected to send files as they are in the
file system, converted to octets if necessary.
\section{Terminology}
\begin{itemize}
\item {\bf ASCII}: In AFTP, eight-bit ASCII is used. Eight-bit
ASCII characters are derived by adding a zero bit at the most
significant bit of the seven-bit ASCII characters.
\item {\bf Client}: The part of a connection that demands service.
\item {\bf Client machine}: The machine the client is on.
\item {\bf Command}: A series of octets sent by the client to the
server to request service.
\item {\bf Connection}: A communication path between the client and
the server for the exchange of commands, replies, and data.
\item {\bf Control Connection}: The connection for the server to send
replies and the client to send commands. This connection
exists from the beginning for a AFTP session to the end.
\item {\bf Control port}: The port for the control connection.
\item {\bf Data connection}: The connection for exchanging data. A
data connection is established when a command requiring data
transfer requests a connection through the specification of a
port number. After the data transfer, a data connection is
disconnected.
\item {\bf Data port}: The port for a data connection.
\item {\bf Directory}: A logical container in a file system containing
files. It can contain other directories too.
\item {\bf Errorcode}: The third, fourth, and fifth digit of a return code.
\item {\bf File}: A series of octets with a size, date of creation and
filename. It has a type of either ASCII, binary, or Tenex. More
file types can be defined when needs arise.
\item {\bf File position}: A pointer in a file after a certain number
of octets.
\item {\bf Filename}: The name of a file in a directory.
\item {\bf Guest directory}: The directory for clients to put files to.
The server can decide whether it wants to have such a directory.
\item {\bf Local machine}: The machine the client is on.
\item {\bf Octet}: A eight-bit byte.
\item {\bf Opcode}: The first two digits of a return code.
\item {\bf Path}: The name of a file or directory independent of the
current directory. It is assumed that the LF (ASCII 10, decimal)
character is not valid in a path.
\item {\bf Regexp}: Regular expression used to discriminate files to
be shown in a directory listing.
\item {\bf Remote machine}: The machine the server is on.
\item {\bf Reply}: A message sent by the server to indicate success or
failure. It includes a return code with possibly text.
\item {\bf Return code}: A nine digit code sent by the server to signal
success or failure of a n operation demanded by the client.
\item {\bf Serial number}: A serial number is a three-digit decimal
number with leading zeroes from 000 to 999, assigned to a
command by the client. It is used to identify a command. The
server will use this serial number to precisely acknowledge a
command sent by the client. This is important because multiple
commands can be outstanding. Serial numbers are used to avoid
confusion. The assigning of numbers is up to the client.
\item {\bf Server}: The part of a connection that accepts requests and
manages the AFTP area of a machine.
\item {\bf Server machine}: The machine the server is on.
\end{itemize}
\section{Definitions}
\subsection{Files and Directories}
In AFTP, a virtual file system is defined with the convention that
there are two types of files: directories and regular files. These two
types can never be mixed together in AFTP. There can be directories in
a directory. However, directories need not be a tree-like structure.
A file has the following attributes: size, date of creation, and
filename. A directory has: date of creation, and directory name.
The size of a file is the number of octets that would be sent if this
file is to be sent. The date of creation is the date the file was
created. The filename of a file is the name of the file in its
directory.
\subsection{Replies}
In this protocol, we use a serial-number acknowledgement scheme. After
a command is sent by the client requesting a service, the server will
send back a reply informing the client whether the requested command
has been carried out correctly or not. A reply contains a return code
and possibly text data after the return code. In every command, there
is a serial number; the return code for a particular command has the
same serial number. Therefore, more than one command can be sent by
the client at one time and the server acknowledges them separately. A
data transfer is finished when the server closes the data connection.
We will discuss more about multiple commands later on.
A return code always consists of nine digits. The first three digits
constitute the serial number of the command this return code is
acknowledging. The serial number of a command is assigned by the
client. It can be selected arbitrarily. To avoid confusion,
incrementing the serial number for each command is a good idea but not
compulsory. The next two digits refer to the type of the command this
return code is acknowledging. The next three digits are used to
indicate error or success. The last digit is used for providing
additional information. This last digit is used only in some commands.
In other commands, it is left zero.
Syntax of a reply:
\begin{verbatim}
reply = serial space opcode space errorcode space digit data
serial = digit digit digit
data = space text | empty
empty =
opcode = "00" | "01" | "02" | "03" | "04" | "05" |
"06" | "07" | "08" | "09" | "10" | "11" |
"12" | "13" | "14" | "15" | "16" | "99"
errorcode = "000" | "001" | "002" | "003" | "004" |
"005" | "006" | "007" | "008" | "009" |
"010" | "011" | "012" | "013" | "014" |
"015" | "016"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" |
"7" | "8" | "9"
space = " "
\end{verbatim}
{\tt text} is a series of octets not containing the line feed
character (ASCII 10 decimal). It can exist only in errorcode {\bf
000}.
In this document, we generally omit the serial number when we discuss
the possible return codes sent by the server.
The set of opcodes and errorcodes can be expanded when needs arise.
The following is the set of opcodes.
\begin{center}
\begin{tabular}{|l|l||l|l|}
\hline
Opcode & Command & Opcode & Command\\\hline\hline
00 & continue & 01 & LD\\\hline
02 & CD & 03 & SD \\\hline
04 & GF & 05 & PF \\\hline
06 & ABORT & 07 & GD \\\hline
08 & TOP & 09 & RF \\\hline
10 & QUIT & 11 & TIME \\\hline
12 & TELLME & 13 & IAM \\\hline
14 & MD & 15 &RD \\\hline
16 &CDUP & 99 & System error\\\hline
\end{tabular}
\end{center}
Opcode {\bf 00} is used in places for signaling success where no other
opcodes are applicable, for example right after connection. The opcode
{\bf 99} is used when the server encounters some system errors that it
must terminate the AFTP session or an illegal command is sent by the
client. For both of these opcodes, the serial number can be any
number.
The errorcodes have the following meaning:
\begin{enumerate}
\item {\bf 000}. No error. Requested action carried out successfully.
It can have optional text as a means of returning information
requested by the client. Other errorcodes do not have this
property.
\item {\bf 001}. Syntax error. The last digit of the return code
specifies which word is in error.
\item {\bf 002}. Action not done. The client does not have the
privilege to request the action. This is most common when the
client wants to delete a file which it does not have the
permission to.
\item {\bf 003}. No such file or directory. The client has specified a
file or a directory that the server does not know.
\item {\bf 004}. Data transfer failed for some reason. This errorcode
is given when in the middle of a data transfer, something
happened in the server machine and the data connection must be
terminated. This errorcode substitutes the normal success {\bf
000} errorcode.
\item {\bf 005}. This is specific for the commands {\tt GF} and {\tt
PF}. The file position (explained later) specified is too large.
\item {\bf 006}. The server has encountered a problem. It must
terminate the AFTP session. The opcode of this errorcode is
always {\bf 99}. This errorcode can be sent anytime the server
encounters a problem, whether a data transfer is taking place or
not.
\item {\bf 007}. No more data connection allowed. The server decides
how many data connections allowed for a control connection.
\item {\bf 008}. The server is not prepared to serve a client. This is
sent right after connection to inform the client that the server
machine's system load is too high or there are too many AFTP
connections.
\item {\bf 009}. Current time is not permitted for a AFTP connection
on server machine. In most machines, AFTP connections are
restricted to a certain period in a day. If AFTP connections are
not permitted at a certain time, this errorcode should be sent
right after the connection. The opcode for this errorcode is
always {\bf 99}.
\item {\bf 010}. No such command. The client has sent a command that
the server does not know. The opcode for this errorcode is
always {\bf 99}.
\item {\bf 011}. File or directory exists when {\tt PF} is requested.
Delete the file before attempting the action.
\item {\bf 012}. File type is given in the last digit. This errorcode
is given when the client requests a file to be sent. The meaning
of the last digit is: 0 -- binary, 1 -- ASCII, 2 -- TENEX. This
list can be expanded to others. This code is sent to inform the
client of the type of the file being sent over. So that the
client knows how to reassemble the file from the octets received
from the server.
\item {\bf 013}. The server has waited too long for the client. Timed
out. Two trials should be given. The server should then
terminate the AFTP session. The opcode of this errorcode is
always {\bf 99}.
\item {\bf 014}. Signals the client to go ahead with the action or to
get ready for data.
\item {\bf 015}. Currently no command with the serial number specified
is being executed. This command is used to respond to a {\tt
ABORT} command when the command to be aborted is either not
existing or has been completed.
\item {\bf 016}. Cannot open data connection. The server cannot open a
data connection for reason other than too many data connections.
This errorcode is used before any data transfer has been done
whereas {\bf 004} is used when some data transfer has been done.
\end{enumerate}
\subsection{The AFTP Model}
For a client to connect to a remote machine, there must be a server
running in the remote machine. The server is expected to constantly
listening to the AFTP port. The client initiates the control
connection by trying to connect to the AFTP port. The server is
expected to accept the connection. Once the control connection is
established, a standard reply is sent from the server to the client to
inform the client whether the connection is ready ({\bf 00 000 0}
return code). Or, instead, the server can inform the client that the
system work load for the remote machine is too great for a new AFTP
session ({\bf 99 008 0} return code); or the remote machine does not
accept AFTP connections at current time ({\bf 99 009 0} return code).
Once this reply is received, the client can start issuing commands if
the connection is successful or terminate the connection if not.
Any time the control connection is closed by the client, the server
will close all data connections outstanding. It is the responsibility
of the client to make sure the control connection is open throughout
the AFTP session.
If the client is idle for more than a specific amount of time (about
15 minutes probably), the server can terminate the AFTP session after
sending two {\bf 013} time out errorcodes.
\subsection{Data and Control Connections}
A AFTP session begins when a control connection is established. This
connection continues until the end of the AFTP session. Commands and
replies are exchanged using this connection.
When a command requiring data transfer is passed to the server, it
passes a port number to the server at the same time. This port number
represents the port the data transfer will take place. This port is
called the data port. The connection for the data port is called the
data connection. A data port exists only for the transferring of data
of one command. After the data transfer is over, the data connection
is closed. The client is expected to listen to the port before
issuing a data transfer command. It then sends the command with the
port number. Once the server has received the command and agrees to
the data transfer, the server should try to connect to the port
specified. The client then accepts the connection and the data
transfer can then take place.
When data transfer occurs, the server is expected to monitor the
control connection for further commands sent by the client.
Simultaneous data transfer is possible because of this policy and the
use of the serial number acknowledgement scheme.
The maximum number of simultaneous data connections allowed for a
single control connection is left to the server to decide. If this
number is exceeded, the server sends a {\bf 007} errorcode to indicate
this problem.
A data connection is closed by the party sending data. The server will
send back a reply indicating that it has closed the data connection or
it has noticed the closing of the data port.
\section{Commands}
Each command is prefixed by a three-digit serial number, the command
body and terminated by a single LF (Line Feed, ASCII 10 decimal).
There should be at least one space character between words in the
commands, no space characters are allowed between the beginning of the
command and the first character of the command, and no space
characters are allowed after the last character and the end of the
command. Cases of the words in a command are always significant so
that `LD' is different from `ld'. We will omit the serial number in
the explanations here. They must exist in each command sent by the
client. No command can have more than 1024 octets, including the Line
Feed character at the end of the command.
For commands requiring a data port for data transfer, the client
should open the data port and wait for the server to signal `go ahead'
by sending a {\bf 014} errorcode. It can then receive or send data
using the data port. If the client sends data, it should close after
data has been sent. The server should close the data connection after
the server has sent all the data. After the data has been sent, the
server should send either {\bf 000} errorcode to signal success, or
{\bf 004} to signal failed data transfer to the client.
Syntax of a command:
\begin{verbatim}
aftp-command = serial space command
command = LD-command | CD-command | SD-command |
GF-command | PF-command | ABORT-command |
GD-command | RF-command | QUIT-command |
TIME-command | TELLME-command |
IAM-command | TOP-command | MD-command
RD-command | CDUP-command
space = " "
\end{verbatim}
\subsection{LD, list a directory}
Lists a directory and show the files or directories in the current
directory. The syntax of the command, in BNF:
\begin{verbatim}
LD-command = "LD" port "FULL" order regexp |
"LD" port order type regexp
order = "ALPHA" | "TIME"
type = "FILE" | "DIR"
regexp = alt | reg | empty
alt = "(" reg ")" "|" alt | "(" reg ")"
reg = kleene | plus | charcl | any | char |
kleene reg | plus reg | charcl reg |
char reg | any reg
plus = char "+" | any "+"
chars = char | char "-" char | char chars |
char "-" char chars
suffix = "+" | "*" | empty
neg = "^" | empty
charcl = "[" neg chars "]" suffix
kleene = char "*" | any "*"
any = "?"
empty =
port = eightbit "," eightbit "," eightbit ","
eightbit "," eightbit "," eightbit
\end{verbatim}
{\tt eightbit} is a number from 0 to 255. The first four numbers in
{\tt port} constitutes the IP address of the client machine. The last
two numbers represent the 32-bit TCP port number. To convert the
32-bit port number to two {\tt eightbit}s, divide the port number by
256. The quotient is the first {\tt eightbit} number, and the
remainder is the second {\tt eightbit} number.
To get the meta-characters used in the regular expressions, add
``$\backslash$'' in front of the character to be escaped. The sequence
``$\backslash\backslash$'' yields a single ``$\backslash$''. There are
a few special characters that can be specified only by using the
escape mechanism. They are line feed ($\backslash${\tt n} ASCII 10
decimal), tab ($\backslash${\tt t} ASCII 9 decimal), carriage return
($\backslash${\tt r} ASCII decimal 13), backspace ($\backslash${\tt b}
ASCII 8 decimal) and form feed ($\backslash${\tt f} ASCII 12 decimal).
These special characters, and other regular characters constitute the
syntax category {\tt char} in the BNF above.
Only files and directories that can be read by the client should be
listed by this command.
When {\tt FULL} is specified, all files accessible by AFTP should be
listed in the order selected by the command. Ordered by {\tt ALPHA}
means that files are ordered in their alphabetical order. For
characters other than the alphabets, the order is chosen according to
their ASCII values. Ordered by {\tt TIME} means the files should be
listed according to how recently they were created. The least recent
file is sent first and the most recent file is sent last.
Either {\tt FILE}s can be listed or {\tt DIR}ectories can be listed,
but not both. If {\tt regexp} exists, it is used to discriminate the
files or directories to be listed. Only files or directories with
filenames matching the {\tt regexp} will be listed. The semantics of
{\tt regexp} is almost identical to the usual Unix regular
expressions.
The output of the {\tt LD} command is standardized. For regular
files, each line of the output should be in the following form, with
white spaces (tabs and space characters) separating the fields:
\begin{verbatim}
size date filename
\end{verbatim}
Where {\tt size} is the size of the file, {\tt date} the date of
creation of the file, and {\tt filename} the filename of the file.
Each line of listing is delimited by a single LF (line-Feed ASCII 10
decimal) character.
The field {\tt date} is a decimal number representing the number of
seconds since 00:00:00 GMT, Jan. 1, 1970. Files created before that
time has negative numbers for their dates.
The syntax for {\tt date} is:
\begin{verbatim}
date = neg number
neg = "-" | empty
number = digit number | digit
\end{verbatim}
For directory listings, each line should have the following format,
with white spaces (tab or space characters) separating the fields:
\begin{verbatim}
date directory-name
\end{verbatim}
Where {\tt date} is the date of creation, and {\tt directory-name} the
name of the directory. Each line of listing should be delimited by a
single LF (line-Feed ASCII 10 decimal) character.
A {\bf 01 014 0} return code will be sent if the request is
successful. The client should expect the listing to follow from the
data port it specified. After the end of the listing, a {\bf 01 000 0}
return code will be sent to indicate the end of the listing. Other
return codes relevant for this command are:
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
01 001 X & Syntax error in word X\\\hline
01 003 0 & Directory not found\\\hline
01 007 0 & No more data connection allowed\\\hline
01 016 0 & The server cannot open data connection\\\hline
\end{tabular}
\end{center}
\subsection{CD, change current directory}
CD changes the current directory. The current directory is only useful
for the user.
Syntax:
\begin{verbatim}
CD-command = "CD" file
file = filename | path
\end{verbatim}
The syntax for {\tt filename} and {\tt path} is system-dependent.
However, it is always assumed that the LF character (ASCII 10 decimal)
is not a valid character in them.
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
02 000 0 & Success \\\hline
02 001 X & Syntax error in word X\\\hline
02 003 0 & Directory not found\\\hline
\end{tabular}
\end{center}
\subsection{SD, show current directory}
Syntax:
\begin{verbatim}
SD-command = "SD"
\end{verbatim}
SD shows the name of the current directory. This is meant for the user
only. The path of the directory should be returned by the server. If
successful, a {\bf 03 000 0} return code will be returned by the
server with the current directory follows.
Syntax of the output:
\begin{verbatim}
SD-reply = serial " 03 000 0 " path
\end{verbatim}
Other return codes:
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
03 001 X & Syntax error in word X\\\hline
\end{tabular}
\end{center}
\subsection{GF, get a file from the server}
The syntax for this command is:
\begin{verbatim}
GF-command = "GF" port number file
\end{verbatim}
The file matches the file should be sent from the server, starting
from the position after {\tt number}. For example, {\tt GF 10
pub/readme.txt} means getting the file named {\tt pub/readme.txt}
starting from the 11th octet from the beginning of the file.
If successful, the server will send back {\bf 04 012 X}, where {\bf X}
is the file type of the file to be sent. The client should then expect
to receive the contents of the file from the data connection it
specified. The server will then send {\bf 04 000 0} to signal
completion of the data transfer.
The types of files supported right now is ASCII and binary. Tenex file
type is defined but not supported. The numeric representation for
ASCII file is 1, and 0 for binary.
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
04 001 X & Syntax error in word X\\\hline
04 003 0 & Directory not found\\\hline
04 005 0 & The file position specified is larger than the file\\\hline
04 007 0 & No more data connection allowed\\\hline
04 016 0 & The server cannot open data connection\\\hline
\end{tabular}
\end{center}
\subsection{PF, put a file to server machine}
The syntax of the PF command is:
\begin{verbatim}
PF-command = "PF" port number length type file
type = "BIN" | "ASCII" | "TENEX"
length = number
\end{verbatim}
{\tt number} is the file position to start putting the file. The file
type is sent on the command line to the server so that the servers
knows how to store the file being sent from the client. The number of
file types can be expanded by two agreeing machines.
If successful, the server will send back {\bf 05 014 0}. The client
should then send the contents of the file using the data port
specified. The server will then send {\bf 05 000 0} to signal
completion of the data transfer. All files sent from the client to the
server will reside in the guest directory. To change to the guest
directory, use the {\tt GD} command. If the syntax of the filename is
not valid on the server machine, the server is responsible for the
renaming of the file. It can do it in anyway it deems appropriate. The
file types it supports can be expanded when need arises.
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
05 001 X & Syntax error in word X\\\hline
05 002 0 & Guest directory does not exist\\\hline
05 005 0 & The file position specified is larger than the file\\\hline
05 007 0 & No more data connection allowed\\\hline
05 011 0 & The named file exists\\\hline
05 016 0 & The server cannot open the data connection\\\hline
\end{tabular}
\end{center}
\subsection{ABORT, abort an executing command}
Syntax:
\begin{verbatim}
ABORT-command = "ABORT" serial
\end{verbatim}
This command terminates the execution of the command identified by the
serial number. The response from the server is:
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
06 000 0 & Success \\\hline
06 001 X & Syntax error in word X\\\hline
06 015 0 & No command with such serial number\\\hline
\end{tabular}
\end{center}
The serial number in the reply should be the serial number of the {\tt
ABORT} command, not the command the {\tt ABORT} command is trying to
abort. This command can only be used to abort multiple step commands,
namely, {\tt LD}, {\tt PF}, {\tt GF}, and {\tt TELLME}.
\subsection{GD, change to guest directory}
Syntax:
\begin{verbatim}
GD-command = "GD"
\end{verbatim}
If the guest directory exists, the server changes current directory to
the guest directory and return its path using {\bf 07 000 0} return
code with the path after the return code and before the line feed of
the return code.
The syntax of the output:
\begin{verbatim}
GD-reply = serial " 07 000 0 " path
\end{verbatim}
Other return codes are:
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
07 001 X & Syntax error in word X\\\hline
07 002 0 & Guest directory does not exist\\\hline
\end{tabular}
\end{center}
\subsection {TOP, change to the top directory}
This command changes the current directory to the directory AFTP puts
the client on when the control connection was first established.
Syntax:
\begin{verbatim}
TOP-command = "TOP"
\end{verbatim}
The server returns a {\bf 08 000 0} return code after the operation is
carried out. {\bf 08 001 X} is returned if the server encounters a
syntax error in word {\bf X}.
\subsection{RF, delete a file}
Syntax:
\begin{verbatim}
RF-command = "RF" file
\end{verbatim}
The file named is deleted. The server decides whether this command
will succeed. The file to be deleted must be in the guest directory.
Files in other directories are not allowed to be deleted by a client.
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
09 000 0 & Success\\\hline
09 001 X & Syntax error in word X\\\hline
09 002 0 & Client not allowed to delete the file\\\hline
09 003 0 & The named file does not exist\\\hline
\end{tabular}
\end{center}
\subsection{QUIT, terminate AFTP session}
Syntax:
\begin{verbatim}
QUIT-command = "QUIT"
\end{verbatim}
Everything being done should be aborted and the session terminated.
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
10 000 0 & Success \\\hline
10 001 X & Syntax error in word X\\\hline
\end{tabular}
\end{center}
After send {\bf 10 000 0}, the server can severe the control
connection. All data connections are also closed with no warning sent
from the server.
\subsection{TIME, show the time of the server machine}
Syntax:
\begin{verbatim}
TIME-command = "TIME"
\end{verbatim}
The time of the local machine of the server should be returned. The
syntax for specifying a date is the same as the {\tt date} syntax in
command {\tt LD}.
The server sends back {\bf 11 000 0} if the server agrees to send back
the local time. The time is given after the return code and before the
line feed of the reply.
The syntax of the reply is:
\begin{verbatim}
TIME-reply = serial " 11 000 0 " date
\end{verbatim}
The server sends back {\bf 11 001 X} if it found a syntax error in
word {\bf X}.
\subsection{TELLME, print introduction}
Syntax:
\begin{verbatim}
TELLME-command = "TELLME" port
\end{verbatim}
This command requests the server to send the introduction of the
server machine. This command is allowed to fail if the server machine
does not have such a file.
If successful, the server sends back {\bf 12 014 0} if it is ready to
send the file. The client should expect to receive data from the data
port it specified. The server then sends {\bf 12~000~0} to signal the
completion of the transfer.
The server sends back {\bf 12 001 X} if it found a syntax error in
word {\bf X}. The server send back a {\bf 12 007 0} return code if no
more data connections are allowed. The server sends {\bf 12 016 0} if
it cannot open the data port requested by the client.
\subsection{IAM, identifying client}
This commands identifies the client. This can be the first command
sent by the client after connection. Syntax:
\begin{verbatim}
IAM-command = "IAM" username
\end{verbatim}
Everything after the command word {\tt IAM}\ until the end of line is
taken to be the username.
The server sends back {\bf 13 000 0} if the operation is successful.
The server sends back {\bf 13 001 X} if it found syntax error in word
{\bf X}.
\subsection{MD, create a directory}
The syntax of the MD command is:
\begin{verbatim}
MD-command = "MD" filename
\end{verbatim}
If successful, the server will send back {\bf 05 000 0}. A directory
should not be allowed to be created in places other than in the guest
directory. It is up to the server to enforce this. If the filename is
not valid on the server machine, the server is responsible for the
renaming of the file. It can do it in anyway it deems appropriate. The
other responses are:
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
14 001 X & Syntax error in word X\\\hline
14 002 0 & Directory is not created\\\hline
14 011 0 & The named file exists\\\hline
\end{tabular}
\end{center}
\subsection{RD, remove a directory}
Syntax:
\begin{verbatim}
RF-command = "RF" file
\end{verbatim}
The file named is deleted. The server decides whether this command
will succeed. The directory to be deleted must be in the guest
directory. Directories in other directories are not allowed to be
deleted by a client. The server decides whether a non-empty directory
can be deleted or not.
\begin{center}
\begin{tabular}{|l|l|}
\hline
Return code & Explanation\\\hline\hline
15 000 0 & Success\\\hline
15 001 X & Syntax error in word X\\\hline
15 002 0 & Client not allowed to delete the directory\\\hline
15 003 0 & The named directory does not exist\\\hline
\end{tabular}
\end{center}
\subsection{CDUP, change to the parent of the current directory}
Syntax:
\begin{verbatim}
CDUP-command = "CDUP"
\end{verbatim}
This command changes directory to be the parent of the current
directory. Only file systems with tree-structured directories should
allow this. The successful execution of this command should return
{\bf 16~000~0}.
Other return codes:
\begin{center}
\begin{tabular}{|l|l|}\hline
Return code & Explanation\\\hline\hline
16 001 X & Syntax error in word X\\\hline
16 002 0 & This command is not valid in this file system\\\hline
\end{tabular}
\end{center}
The parent of the root directory is the root itself. The server should
be careful not to change directory beyond the AFTP area.
\section{References}
\noindent Jon Postel, and Joyce Reynolds, {\sl File Transfer
Protocol}, {\bf rfc 959}, ISI, October 1985.
\section{Author Information}
\noindent{\obeylines
Khun Yee Fung
Department of Computer Science
Middlesex College
The University of Western Ontario
London, Ontario
N6A 5B7
Canada
clipper@csd.uwo.ca
}
\end{document}
SHAR_EOF
fi # end of overwriting check
if test -f 'aftp.sty'
then
echo shar: will not over-write existing file "'aftp.sty'"
else
cat << \SHAR_EOF > 'aftp.sty'
\newcommand{\oddfooter}[1]{\def\@oddfoot{#1}}
\newcommand{\evenfooter}[1]{\def\@evenfoot{#1}}
\def\ps@fungheadings{\let\@mkboth\@gobbletwo
\def\@oddhead{\hbox{}\sl\rightmark}\def\@oddfoot{}\def\@evenhead{\sl\leftmark\hbox
{}}\def\@evenfoot{}\def\sectionmark##1{}\def\subsectionmark##1{}}
\textheight = 8.5in
\advance\textheight by \topskip
\textwidth 470pt \columnsep 10pt \columnseprule 0pt
\oddsidemargin 0pt \evensidemargin 0pt
SHAR_EOF
fi # end of overwriting check
# End of shell archive
exit 0
--
----
In Real life: Khun Yee Fung clipper@csd.uwo.ca (Internet)
Alternative: 4054_3267@UWOVAX.BITNET
UUCP: ...!{ihnp4|decvax|seismo}!{watmath|utzoo}!ria!csd!clipper
Department of Computer Science
Middlesex College
The University of Western Ontario
London, Ontario, N6A 5B7 CANADAggw%wolves@cs.duke.edu (Gregory G. Woodbury) (10/14/90)
What I can read of it SEEMS reasonable. I cannot comment on the technical details since I don't have a TeX processor to play with nor the inclination to ask for the PostScript to be sent to me, relayed to my office, transferred to the mac and output! In other words, effective contributions to usenet and this newsgroup are best made in plain and simple 7-bit ASCII! Save the fancy formatting and pretty printing for the final version. Additionally, with a "Distribution:" of comp, your article may not be seen everwhere you want it to be. -- Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC UUCP: ...dukcds!wolves!ggw ...mcnc!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ] <standard disclaimers apply>