rfc412  Work Information Center # 12404 G. Hicks Request for Comments # 412 Utah 27-Nov-72
   

Table of Contents:

 

User FTP Documentation
The attached document is the HELP file for the Utah-10
implementation of the User FTP Process. This is what the user has
typed on his console when he types 'HELP<cr>', and as such is the only
documention produced to date.


User FTP Documentation Detailed Command Listing
FTP User Documentation
November 27, 1972
I. Control Characters
There are several control characters that have meaning to the FTP
Process. First, the abort character is <control-z> (SUB), next for
editing, only <control-r>, <control-a>, <control-h>, <control-v>,
<control-w>, <alt-mode>, <eol>, <space>, <control-x> and <rub-out> have
any meaning, <control-a> (SOH) and <control-h> (BS) are the character
delete keys. <control-w> is the word delete character, Note: When dowing
the ' funktion, this character will delete the entire line typed.
<control-v> says take the next character literally. <alt-mode> (ESC)
terminates the command giving helpful noise words, <eol> and <space> are
terminators also. These last two will give no command completion or
noise words. All three echo as a space however. <control-x> (CAN) and
<rub-out> (DEL) are the command abort characters. <control-r> (DC2) will
retype the line as the command interpreter sees it. When using the ? as
a prompter, for initial commands, it will type-out all commands that
begin with that particular character string. If it is typed in a sub-
command field, it will type out the prompt message only if it is the
first character typed. At all other times, it will be accepted as part
of the typed string.
II. General Information
The FTP user process is designed to make transferring files from
one host on the ARPANET to another much easier than it has been up until
now. To this end, the command language was designed to be as natural as
possible.
The command interpreter is, of course, part of this idea.
Therefore, to help the user as much as possible, there are several ways
to find out what is expected in the form of commands, file-names, user-
names, etc. When the user has typed nothing, typing a ? will cause the
interpreter to type out all the commands that are available to the user.
If the user has typed anything at all, then it will respond with all
commands that begin with the particular character string.
So that the command language was as easy to learn as possible, the
command interpreter will 'see' nothing that is not part of a legal
command. If the user types anything that is not expected, the character
is not echoed and a bell is echoed instead.
[Page 2]

User FTP Documentation Detailed Command Listing
III. Brief Command Listing
The commands that are expected and their syntax are listed below.
NOTE: UPPER and lower case letters are identical.
<host-name>
D<decimal host number>
<octal host number>
;<any string> (useful for comments to a person that is linked to you)
MODE <mode name>
RETREIVE <remote file> (to) <local file>
GET <remote file> (to) <local file>
SEND <local file> (to) <remote file>
STORE <local file> (to) <remote file>
APPEND <local file> (to) <remote file>
RENAME <remote file> (to be) <new remote file name>
DELETE <remote file>
BYE
COPY <direction descriptor> <file group> (to) <file group>
(see detailed description below)
LOGOUT
DDT
LIST <file group> (to file) <local file name>
SOCKET (NOT IMPLEMENTED YET)
ALLOCATE <decimal number of bytes>
QUIT
foreign host)
HOST <any valid ARPANET host name or number>
USER <remote user name>
PASSWORD <password for remote user's name>
ACCOUNT <string or number for remote user's name>
STATUS (see description of status command below)
LOGIN <user name> <password> <optional account> <to host>
BYTE <decimal byte size>
TYPE <type descriptor>
STRUCTURE <structure descriptor>
TENEX
ASCII
VERBOSE
[Page 3]

User FTP Documentation Detailed Command Listing
IV. Detailed Description of the Commands
The commands and their syntax are described in greater detail
blow. The words in parenthesis are noise words. NOTE: upper and
lower case are identical. Unless otherwise noted in the command
description, all commands described are implemented.
<host name> or <host number>
Performs the ICP to the indicated host with explanatory remarks if
the ICP is not possible.
MODE <mode descriptor>
Sets the mode of the data transfer connection according to the
following sub-commandos:
STREAM: bit stream, end of file is indicated by the data connection
closing.
BLOCK: formats (or expects formatted) data into blocks.
TEXT: Sends or retreives text. Forces TYPE ASCII and BYTE 8. This
command sends the appropiate commands to the foreign host, then sends
the data using the TELNET codes for EOR and EOF as per the FTP
Protocol.
HASP: compress data.
NOTE: Of the above sub-commands, only MODE STREAM and MODE TEXT are
implemented at present.
RETREIVE (file) <remote file> (to file) <local file name>
Sends the retr command to the remote server, sets up the data
connection according to any previous MODE, TYPE, BYTE commands. Puts
the data coming on the the data connection into the local file
specified.
GET (file) <remote file name> (to file) <local file name>
See description of RETREIVE.
STORE (local file) <file name> (onto file) <remote file>
Accepts a local file name, does the formatting according to any
previous BYTE, TYPE, MODE commands and sends it to the foreign host.
SEND (local file) <file name> (onto file) <remote file>
See description of STORE.
APPEND (local file) <file name> (to remote file) <remote file>
Does the same as a store except that the file is appended to the
[Page 4]

User FTP Documentation Detailed Command Listing
remote file rather that just writing over the file.
RENAME (existing file) <file name> (to be) <new file name>
Accepts the name of n old remote file and asks for a new file name,
sends the appropiate commands and names to the foreign host causing
the old file name to be replaced by the new file name.
DELETE (file) <file name>
This command causes the remote file to be marked for deletion. It
does require that the command be confirmed twice.
BYE
Takes no arguments. Causes the server to terminate the current
session with the user. The program will return to the EXEC MODE when
the command has been acknowledged by the remote server.
COPY
This command does a variety of things. First. it allows the user do
describe a file group. EG: *.mac, *.sav, etc. The *'s may be for
foreign files or local files according to the following sub-commands:
REMOTE (remote file group) <remote file grouping>:
Causes the user FTP to ask the server for the file in <remote file
grouping>. Then asks the user to specify where each file is to go. A
typical sequence might look like the following:
!copy remote (remote file group) ftp.*
Please be patient. Getting remote file names.
Got them.
!copy (file) <HICKS>FTP.MAC;| (to file) ftp.mac [New file]
[Messages and etc. follow with the above line being
repeated for each file in the remote file group.]
LOCAL (local file grouping) <local file group>:
Causes the user FTP to accept the file group specified, and send the
file names to the server leaving off the <directory name> and version
number of the local file. The user may not specify *'d devices of *'d
directorys. A line for this might look like the following:
!copy local (local file group) ftp.*;*
[Confirm]
Next, if the user does not specify any *'s for either the remote file
or the local file, this command is exactly like the RETREIVE or STORE
command described earlier.
LOGOUT
Takes no arguments. See description of BYE command for more details.
[Page 5]

User FTP Documentation Detailed Command Listing
RESET
Takes no arguments. Causes the user process to close all connections
(if necessary), all files (if necessary), and reset the programs
parameters to their defaults.
DDT
If DDT is loaded, just starts DDT. If DDT is not loaded, it will load
DDT and then start it at its initial start-up location. This command
will casue an abnormal interrupt if DDT is not found.
LIST (file group) <remote file group> (to file) <local file>
Esentially causes the remote server to do a directory command. The
default is *.* and since the listing will come on the data connection,
the user must specify a local file. A sample line might look like the
following: !list (file group) *.* (going to file) tty: [ok]
SOCKET <socket descriptor>
Will accept a socket descriptor for the data to go to or come from. At
present it is NOT IMPLEMENTED because we have not decided on the
format of the command to the server.
ALLOCATE <decimal number of bytes>
Accepts as its argument a decimal number of bytes (of the specified
size) telling the server how many bytes of storage to reserve for the
next store of append.
QUIT
Takes no arguments. Returns the console to the EXEC. The program may
be continued with no harm done.
This command allows the user to send arbitrary strings to the remote
server. At present, when talking to a TENEX site, it is only useful
for doing the 'MAIL' command. Other sites may have help commands of
whatever.
HOST <ARPANET host name of number>
Allows the user to specify an ARPANET host without actually connecting
to the host. This specified host will be the ont that is connected to
(or the attempt will be made anyway) when the next 'immediate' command
is executed. EG: LOGIN, RETREIVE, STORE, LIST, etc.
USER (name is) <remote user's name>
Sets the user name for the remote system. Useful for systems that
require no password for the specified name. Does nothing until an
user must be 'logged into' the remote system. The programm knows this
and so will not let the user execute any commands (RETREIVE, STORE,
APPEND, LIST, STATUS, RENAME, DELETE) until he has at least specified
a remote user name. The LOGIN command does this as does this command.
[Page 6]

User FTP Documentation Detailed Command Listing
STATUS (of the) <sub-cmd> (at host) <ARPANET host>
Accepts as its argument one of the following sub-commands:
SERVICE (at host) <ARPANET host name or number>: Attempts to
perform the ICP to the specified host. Does not disturb any existing
connections.
<ARPANET host name or number>: See description of STATUS SERVICE
above.
STATUS (of file) <remote file group>: Similar to the LIST
command described above except that the listing does not gone back on
the data connection but on the TELNET connection. See LIST command for
more details.
<COMMAND-TERMINATOR>: Just sneds the STAT command.
Typically, is good for finding out where your are and perhaps who you
are.
PASSWORD (is) <passowrd for remote user's name>
Sets the password for the remote user's name. It is NOT echoed and
does nothing until the next 'immediate' command is executed.
ACCOUNT (is) <account number or string>
Accepts a string of number that can be charged for any activity the
user specifies. EG: STORE, RETREIVE or APPEND. Useful only for systems
that require this information of course. Also does nothing until the
next immediate command is executed.
LOGIN <user name> <password> <optional account>
the format of this command is identical to the TENEX login command. It
accepts a user name, password, and an optional account number. If no
host has been specified, it will ask for the host to be connected to.
This command will cause the ICP to take place if necessary.
BYTE (size is) <decimal byte size>
This command sets the byte size for the data connection. The default
byte size is 8 bytes.
Type (is) <type descriptor>
Takes as its argument one of the following subcommands:
TENEX: Shorthand that sets TYPE IMAGE and BYTE 36.
EBCDIC: Says that the data will be Ebcdic.
PRINT: Says that the data is an Ascii print file with ASA vertical
format controls.
LOCAL: Forces the user and server FTP to accept whatever
byte size the user has specified. For the present, this type is
treated the same as for IMAGE TYPE.
IMAGE: Does the same as LOCAL. Just forces the user and server FTP to
accept the specified byte size without doing any translation as is
done for ASCII type. For most efficient usage of this command, the
[Page 7]

User FTP Documentation Detailed Command Listing
matching byte size should be BYTE 36 when using TENEX sites as
servers.
ASCII: Sets TYPE ASCII and 8 bit bytes. Useful for text files.
NOTE: Of the above sub-commands, only PRINT and EBCDIC are not
implemented yet.
STRUCTURE (is) <file structure descriptor>
Accepts as its argument one of the following sub-commands:
REDORD: Says the data on the data connection has record
structure information contained in it. NOTE: Since TENEX NOT support
record structured files per se, this mode only useful for sending text
files to or retreiving text files from non-TENEX sites. The <EOL> in
these files is converted to the TELNET EOR code for transmission and
EOR to <EOL> etc. for reception.
File: Says the data stream has no record structure information in it.
TENEX
See description under TYPE TENEX.
ASCII
See description under TYPE ASCII.
VERBOSE
This command sets the command completion/no completion flag. The
program assumes the NO VERBOSE mode and thus does not complete
commands when <space> or <eol> is used as a command terminator It also
causes the noise words to be typed if in the verbose mode.
[Page 8]

User FTP Documentation Detailed Command Listing
V. Sample Session using the FTP
The following scenario shows some uses of the FTP.
Everything that the user types is underlined.
UTAH-TENEX 1.29.03 EXEC 1.38
LOGIN (USER) HICKS (PASSOWRD) (ACCOUNT #) 1200
JOB 24 ON TTY2 11-NOV-72 1:51
TERMINAL (TYPE IS) 4
ftp
FTP User Process 1.10 5-NOV-72. Type Help<cr> for help.
!login (user) network (password) (account) 4 (to host) case-10
CONNECTION IS OPEN TO CASE-10.
< CASE-10 FTP Server 1.14.0 - at SAT 11-NOV-72 2:00-EST
!tenex ? confirm with carriage return
tenex
!copy remote (remote group) ftp.*
Please be patient. Getting remote file-names.
Got them.
!copy (file) <NETWORK>FTP.MAC:32 (no file) ftp.mac [new file]
< IMAGE retreive of <NETWORK>FTP.MAC;32 startet.
< Transfer completed.
!copy (file) <NETWORK>FTP.SAV;5 (fo file) FTP.SAV;5 [new version]
< IMAGE retreive of <NETWORK>FTP.SAV;5 started.
< Transfer completed.
!copy (file) <NETWORK>FTP.REL;1 (to file) xxx
!copy (file) <NETWORK>FTP.HELP;5 (to file) ftp.help [New version]
copy (file) <NETWORK>FTP.HELP;5 (to file) FTP.HELP;1
< IMAGE retreive of <NETWORK>FTP.HELP;5 started.
< Transfer completed.
Done...
!usc-isi
Closing connections to CASE-10.
CONNECTION IS OPEN TO USC-ISI.
< USC-ISI FTP Server 1.14.0 - at SAT 11-NOV-72 2:15-PST
!log
user hicks
(password)
(account) ? account number or string for remote user's name
log
(user) hicks
(password)
(account) |
!send (local file) ftp.sav;5 (to remote file) ftp.sav
< STORE of <HICKS>FTP.SAV;P777752;a|, IMAGE type, started.
< Transfer completed.
!cp r acs.mac (to local file) acs.mac [new file]
< IMAGE Retreive of <HICKS>ACS.MAC;3 started.
[Page 9]

User FTP Documentation Detailed Command Listing
< Transfer completed.
!copy 1 ? Local file group, *'s ok - TENEX sites only,
copy 1 ftp.*
[Confirm]
< Store of <HICKS>FTP.MAC;1;P777752;A1, IMAGE type, Started.
< Transfer completed.
< Store of <HICKS>FTP.SAV;2;P777753;A1, IMAGE type, Started.
< Transfer completed.
< copy of <HICKS>FTP.HELP;1;P777752;A1 IMAGE type, Started,
< Transfer completed.
!bye
!< BYE command recieved.
< Therefore connection terminated.
logout
[logout message go here]
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Gottfried Janik 6/97 ]
 
   
   
   
   
  Re: File Transfer Protocol May 28, 1975
Ref: RFC 354, 385, 414, 448, 454, 630, 542, 640 1
One More Try on the FTP
This is a slight revision of RFC 686, mainly differing in the
discussion of print files. Reading several RFCs that I (sigh)
never heard of before writing 686 has convinced me that although
I was right all along it was for the wrong reasons. The list of
reply codes is also slightly different to reflect the four lists
in RFCs 354, 454, 542, and 640 more completely. Let me also
suggest that if there are no objections before June 1, everyone
take it as official that HELP should return 200, that SRVR should
be used as discussed below, and that "permanent" 4xx errors be
changed to 5xx. And thanks to Jon Postel who just spent all
evening helping me straighten this all out.
Aside from a cry of anguish by the site responsible for the
security hassle described below, I've only had one comment on
this, which was unfavorable but, alas, unspecific. Let me just
say, in the hopes of avoiding more such, that I am not just
trying to step on toes for the fun of it, and that I don't think
the positive changes to FTP-1 proposed here are necessarily the
best possible thing. What they are, I think, is easily doable.
The great-FTP-in-the-sky isn't showing any signs of universal
acceptability, and it shouldn't stand in the way of solving
immediate problems.
Leaving Well Enough Alone
I recently decided it was time for an overhaul of our FTP user and
server programs. This was my first venture into the world of
network protocols, and I soon discovered that there was a lot we
were doing wrong--and a few things that everyone seemed to be doing
differently from each other. When I enquired about this, the
response from some quarters was "Oh, you're running Version 1!" 4
Since, as far as I can tell, all but one network host are running
version 1, and basically transferring files OK, it seems to me that
the existence on paper of an unused protocol should not stand in the
way of maintaining the current one unless there is a good reason to
believe that the new one is either imminent or strongly superior or
both. (I understand, by the way, that FTP-2 represents a lot of
thought and effort by several people who are greater network experts
than I, and that it isn't nice of me to propose junking all that
work, and I hereby apologize for it.) Let me list what strike me as
the main differences in FTP-2 and examine their potential impact on
the world.
1. FTP-2 uses TELNET-2. The main advantage of the new Telnet
protocol is that it allows flexible negotiation about things like
echoing. But the communicators in the case of FTP are computer
programs, not people, and don't want any echoing anyway. The
argument that new hosts might not know about old Telnet seems an
unlikely one for quite some time to come; if TELNET-2 ever does
really take over the world, FTP-1 could be implemented in it. 5a
2. FTP-2 straightens out the "print file" mess. First of all,
there are two separate questions here: what command one ought to
give to establish a print file transfer, and which end does what
sort of conversion. For the second question, although all of the
FTP-1 documents are confusing on the subject, I think it is
perfectly obvious what to do: if the user specifies, and the
server accepts, an ASCII or EBCDIC print file transfer parameter
sequence, then the data sent over the network should contain
Fortran control characters. That is, the source file should
contain Fortran controls, and should be sent over the net as is,
and reformatted if necessary not by the SERVER as the protocol
says but by the RECIPIENT (server for STOR, user for RETR). (The
"Telnet print file" non-issue will be debunked below.)
As a non-Fortran-user I may be missing something here but I don't
think so; it is just like the well-understood TYPE E in which the
data is sent in EBCDIC and the recipient can format it for local
use as desired. One never reformats a file from ASCII to EBCDIC
at the sending end. Perhaps the confusion happened because the
protocol authors had in mind using these types to send files
directly to a line printer at the server end, and indeed maybe
that's all it's good for and nobody's user program will implement
TYPE P RETR.
As for the specific commands used to negotiate such a transfer,
there may currently be some confusion because the most recent
FTP-1 document on the subject (RFC 454) invents a new command,
FORM, which is not in general use as far as I know. (Most of my
experiments have been on PDP-10s; perhaps other systems have
adopted this command.) FTP-2 puts the format argument in the
TYPE command as a second argument. Either way, using a
two-dimensional scheme to specify the combinations of
ASCII/EBCDIC and ASA/normal conveys no more information than the
present A-P-E-F scheme. FTP-2 also introduces the notion of
Telnet formatted vs. non-print files. These types are used when
a Telnet format oriented system is sending a file to an ASA
oriented one, and the recipient needs to know, not what is coming
over the net, but how to solve a local file storage problem. It
is unnecessary and unfair for hosts to have to negotiate
something which does not acttually affect what gets sent over the
net. It is unnecessary because the sending user process (there
is no problem if the user process is receiving) need not
understand what the issue is, it need only make the server
understand by transmitting a message from the human user to the
server process. Any TYPE parameter must be understood by both
processes even if the user treats it just like some other type. 5c
To take a specific example, if I want to send an ASCII file to a
360, my FTP user program needs to have built into it the
knowledge that there are two TYPEs which are really the same, AN
and AT in the FTP-2 notation. If tomorrow someone needs to know
the ultimate use of a binary file (for instance, the old PDP-6
DECtape format stores dump files differently from ordinary data
files), I will have to add another piece of information to my FTP
user and server (maybe they try to read such a file from me).
Instead, information which affects only the RECIPIENT of a file,
and not the format AS SENT OVER THE NET, should be specified in
some form which the sending process can ignore. This is what the
SRVR command should be used for.
If a user at a 360 wants to retrieve a "Telnet print file" from
another system, he might tell his FTP user process something like 5e
TYPE A
DISP PRINT
RETR FOO etc.
(or whatever syntax they use in their FTP). If a user at a 10
wants to send such a file to a 360, he would say 5f
TYPE A
SRVR PRINT
STOR FOO etc.
His FTP user program would send on the SRVR command without
comment. Suppose that the transformation is one which might be
used in either direction between the same two hosts. (This is
not the case for the Telnet print file thing because two 360s
would be using ASA format.) Then the user process could accept
the equivalent of DISP PRINT from the user, and if the transfer
turned out to be a STOR it would decide to send SRVR PRINT first.
In this way the FTP user program can be written so that the human
user types the same command regardless of the direction of
transfer.
Thus, FTP servers which care about the distinction between Telnet
print and non-print could implement SRVR N and SRVR T. Ideally
the SRVR parameters should be registered with Jon Postel to avoid
conflicts, although it is not a disaster if two sites use the
same parameter for different things. I suggest that parameters
be allowed to be more than one letter, and that an initial letter
X be used for really local idiosyncracies. The following should
be considered as registered: 5h
T - Telnet print file
N - Normal.
Means to turn off any previous SRVR in effect. (This makes
"non-print" the default case, rather than
making "Telnet print" and "non-print" equal. It is
probably a good idea if a user program can count on
being able to turn off an earlier SRVR without having
to know a specific inverse for it. Servers which do not
implement any other SRVR parameters need not implement
SRVR N either; user processes shouldn't send SRVR N
just for the hell of it.)
3. FTP-2 reshuffles reply codes somewhat. There have been four
attempts altogether, that I know of, at specifying a list of
reply codes: RFCs 354 and 454 for FTP-1, and RFCs 542 and 640 for
FTP-2. There is not much to choose from among the first three of
these, which are basically the same, except for a slight increase
in specificity each time through, e.g., the introduction of reply
code 456 for a rename which fails because a file of the same
(new) name already exists. This increased specificity of reply
codes doesn't seem to be much of a virtue; if a rename operation
fails, it is the human user, not the FTP user program, who needs
to know that it was because of a name conflict rather than some
other file system error. I am all for putting such information
in the text part of FTP replies. Some real problems are actually
addressed in the reply code revision of RFC 640, in which the
basic scheme for assigning reply code numbers is more rational
than either the FTP-1 scheme or the original FTP-2 scheme.
However, I think that most of the benefits of RFC 640 can be
obtained in a way which does not require cataclysmic
reprogramming. More on this below.
4. FTP-2 was established by a duly constituted ARPAnet committee
and we are duty-bound to implement it. I don't suppose anyone
would actually put it that baldly, but I've heard things which
amounted to that. It's silly.
5. FTP-2 specifies default sockets for the data connection.
Most places use the default sockets already anyway, and it is
easy enough to ignore the 255 message if you want to. This is a
security issue, of course, and I'm afraid that I can't work up
much excitement about helping the CIA keep track of what anti-war
demonstrations I attended in 1968 and which Vietnamese hamlets to
bomb for the greatest strategic effect even if they do pay my
salary indirectly. I could rave about this subject for pages,
and probably will if I ever get around to writing an argument
against MAIL-2, but for now let me just get one anecdote off my
chest: I have access to an account at an ARPAnet host because I
am responsible at my own site for local maintenance of a program
which was written by, and is maintained by, someone at the other
site. However, the other site doesn't really trust us outsiders
(the account is shared by people in my position at several other
hosts) to protect their vital system security, so every week they
run a computer program to generate a new random password for the
account (last week's was HRHPUK) and notify us all by network
mail. Well, on my system and at least one of the others, that
mail isn't read protected. I delete my mail when I read it, but
since it is hard enough remembering HRHPUK without them changing
it every week, I naturally write it in a file on our system.
That file could in principle be read protected but it isn't,
since sometimes I'm in someone else's office when I want to use
it, and the other passwords in it are for open guest accounts
which are widely known. Moral #1: Security freaks are pretty
weird. Moral #2: If you have a secret don't keep it on the
ARPAnet. (In the past week I have heard about two newly
discovered holes in TENEX security.) 5k
6. FTP-2 is available online and FTP-1 isn't, so new hosts can't
find out how to do it. Aargh!!! What a reason for doing
anything! Surely it would be less costly for someone to type it
in again than for everyone to reprogram. Meanwhile these new
hosts can ask Jon or Geoff or Bobby or even me for help in
getting FTP up.
7. FTP-2 has some changes to the strange MODEs and STRUs. This
is another thing I can't get too excited about. We support only
MODE S and STRU F and that will probably still be true even if we
are forced into FTP-2. If the relatively few people who do very
large file transfers need to improve the restart capability, they
can do so within FTP-1 without impacting the rest of us. The
recent implementation of paged file transfers by TENEX shows that
problems of individual systems can be solved within the FTP-1
framework. If the IBM people have some problem about record
structure in FTP-1, for example, let them solve it in FTP-1, and
whatever the solution is, nobody who isn't affected has to
reprogram.
Well, to sum up, I am pretty happy with the success I've had
transferring files around the network the way things are. When I do
run into trouble it's generally because some particular host hasn't
implemented some particular feature of FTP-1, and there's no reason
to suppose they'll do it any faster if they also have to convert to
FTP-2 at the same time. The main thing about FTP-2, as I said at
the beginning, is that its existence is an excuse for not solving
problems in FTP-1. Some such problems are quite trivial except for
the fact that people are reluctant to go against anything in the
protocol document, as if the latter were the Holy Writ. A few
actually require some coordinated effort. Here is my problem list: 6
1. It is almost true that an FTP user program can understand
reply codes by the following simple algorithm: 6a
a. Replies starting with 0 or 1 should be typed out and
otherwise ignored.
b. Replies starting with 2 indicate success (of this step or
of the whole operation, depending on the command). 6a2
c. Replies starting with 4 or 5 indicate failure of the
command.
d. Replies starting with 3 are only recognized in three cases:
the initial 300 message, the 330 password request, and the
350 MAIL response. (Note that the user program need not
distinguish which 300 message it got, merely whether or not it
is expecting one right now.) 6a4
The only real problem with this, aside from bugs in a few servers
whose maintainers tell me they're working on it, is the HELP
command, which is not in the original protocol and which returns
0xx, 1xx, or 2xx depending on the server. (Sometimes more than
one message is returned.) The word from one network protocol
expert at BBN is that (a) 050 or 030 is the correct response to
HELP, and (b) there is a perfectly good mechanism in the protocol
for multi-line responses. Unfortunately this does not do much
good in dealing with reality. There seems to be a uniform
procedure for handling the STAT command: 6b
151 information
151 information
151 ...
151 information
200 END OF STATUS 6b1
which fits right in with the above algorithm. This is despite
the fact that 1xx is supposed to constitute a positive response
to a command like STAT, so that according to RFC 354 it ought to
be
151-information
information
...
151 information
instead. RFC 414, which approves of the 200 reply for STAT, also
gives 200 for HELP. (It seems to me, by the way, that 050 and
030 aren't good enough as responses to HELP since they
"constitute neither a positive nor a negative acknowledgement" of
the HELP command and thus don't tell the user program when it
ought to ask the human user what to do next.) I suggest that,
despite RFC 354, a 200 response be given by all servers at the
end of whatever other HELP it gives as of, let's say, June 1.
The alternatives are either to let the current rather chaotic
situation continue forever while waiting for FTP-2, or to try to
standardize everyone on a multi-line 1xx for both HELP and STAT.
I'm against changing STAT, which works perfectly for everyone as
far as I can tell, and it should be clear that I'm against
waiting for FTP-2. Unfortunately there is no real mechanism for
"officially" adopting my plan, but I bet if TENEX does it on June
1 the rest of the world will come along.
2. Another reply code problem is the use of 9xx for
"experimental" replies not in the protocol. This includes the
BBN mail-forwarding message and one other that I know of. This
procedure is sanctioned by RFC 385, but it seems like a bad idea
to me. For one thing, the user program has no way of knowing
whether the reply is positive, negative, or irrelevant. The
examples I've been burned by all should have been 0xx messages.
I propose that all such messages be given codes in the 000-599
range, chosen to fit the scheme given above for interpreting
reply codes. x9x or xx9 could be used to indicate experiments. 6e
3. One more on reply codes: RFC 630 (the one about the TENEX mod
to the reply codes for MAIL and MLFL) raises the issue of
"temporary" versus "permanent" failures within the 4xx category.
RFC 640 deals with this question in the FTP-2 context by changing
the meaning of 4xx and 5xx so that the former are for temporary
errors and the latter are for permanent errors. I like this
idea, and I think it could easily be adapted for FTP-1 use in a
way which would allow people to ignore the change and still win.
At present, I believe that the only program which attempts to
distinguish between temporary and permanent errors is the TENEX
mailer. For other programs, no distinction is currently made
between 4xx and 5xx responses; both indicate failure, and any
retrials are done by the human user based on the text part of the
message. A specific set of changes to the reply codes is
proposed below.
Perhaps I should make a few more points about RFC 640, since it's
the best thing about FTP-2 and the only argument for it I find at
all convincing. Let me try to pick out the virtues of 640 and
indicate how they might be achieved in FTP-1. 6g
a. The 3xx category is used uniformly for "positive
intermediate replies" where further negotiation in the Telnet
connection is required, as for RNFR. I'm afraid this one
can't be changed without affecting existing user programs.
(One of my goals here is to enable existing user programs to
work while some servers continue as now and others adopt the
suggestions I make below.) However, although this 3xx idea is
logically pleasing, it is not really necessary for a
simple-minded user program to be able to interpret replies.
The only really new 3xx in RFC 640 is the 350 code for RNFR.
But this would only be a real
improvement for the user program if there were also a 2xx code
which might be returned after RNFR, which is not the case.
640 also abolishes the 300 initial connection message with
220, but again there is clearly no conflict here. 6g1
b. The use of 1xx is expanded to include what is now the 250
code for the beginning of a file transfer. The idea is that a
1xx message doesn't affect the state of the user process, but
this is not really true. Consider the file transfer commands.
The state diagram on page 13 of RFC 640 is slightly
misleading. It appears as if 1xx replies are simply ignored by
the user program. In reality, that little loop hides a lot of
work: the file transfer itself! If the server replied to the
file transfer command immediately with a 2xx message, it would
be a bug in the server, not a successful transfer. The real
state diagram is more like
B --> cmd --> W --> 1 --> W --> 2 --> S
(with branches out from the "W"s for bad replies). It should
be clear from this diagram that the user program, if it trusts
the server to know what it's doing, can expect a 2xx instead
of the 1xx without getting confused, since it knows which of
the W states it's in. In fact, the use of 1xx in file
transfer is very different from its other uses, which are
indeed more like the 0xx and 1xx replies in FTP-1. I'd call
this particular point a bug in RFC 640.
c. Automatic programs which use FTP (like mailers) can decide
whether to queue or abandon an unsuccessful transfer based on
the distinction between 4xx and 5xx codes. I like this
idea, although those temporary errors virtually never happen
in real life. This could be accomplished in FTP-1 by moving
many of the 4xx replies to 5xx. Mailers would be modified to
use the first digit to decide whether or not to retry. This
scheme does not cause any catastrophes if some server is slow
in converting; it merely leads to unnecessary retries. A few
CPU cycles would be wasted in the month following the official
switch. Thus, this feature is very different from (a) and
(b), which could lead to catastrophic failures if not
implemented all at once. (Yes, I know that FTP-2 is supposed
to be done on a different ICP socket. I am not discussing
FTP-2 but whether its virtues can be transferred to FTP-1.)
The specific codes involved are listed below. 6g4
d. The use of the second digit to indicate the type of
message. (The proposed division is not totally clean;
for example, why is 150 ("file status okay; about to open
data connection") considered to be more about the file
system than about the data connection?) This can easily
be done, since the second digit is not currently important
to any user process--the TENEX mailer is, in this plan,
already due for modification because of (c). Since this
is mostly an aesthetic point, I'm hesitant to do it if it
would be difficult for anyone. In particular, I would want to
leave the 25x messages alone, in case some user programs
distinguish these. This is especially likely for the ones
which are entirely meant for the program: 251 and 255.
Therefore I propose that if this idea is adopted in FTP-1
the meanings of x2x and x5x be interchanged. This proposal is
reflected in the specific list below.
Let me summarize the specific changes to FTP-1 I'd like to see made,
most of which are merely documentation changes to reflect reality: 7
1. HELP should return 200. All commands should return 2xx if
successful, and I believe all do except HELP.
2. The definition of 1xx messages should be changed to read:
"Informative replies to status inquiries. These constitute
neither a positive nor a negative acknowledgment."



3. Experimental reply codes should be of the form x9x or xx9,
where the first digit is chosen to reflect the significance of
the reply to automated user programs. Reply codes greater than
599 are not permitted. The xx9 form should be used if the reply
falls into one of the existing categories for the second digit.
User programs are encouraged to determine the significance of the
reply from the first digit, rather than requiring a specific
reply code, when possible.
4. The STAT command with no argument is considered a request for
a directory listing for the current working directory, except
that it may be given along with TELNET SYNCH while a transfer is
in progress, in which case it is a request for the status of that
transfer. (Everyone seems to do the first part of this. I'm not
sure if anyone actually implements the second. This is just
getting the protocol to agree with reality.) The reply to a STAT
command should be zero or more 1xx messages followed by a 200. 7d
5. TYPEs P and F mean that the source file contains ASA control
characters and that the recipient program should reformat it if
necessary. Servers which care about Telnet-print vs. non-print
should implement SRVR T and SRVR N. All user processes should
provide a way for the human user to specify an arbitrary SRVR
command.
6. (This is just a resolution of a loose end in documentation.)
Nested reply codes are not allowed. I don't think this really
needs more discussion; they never happen and can't possibly work,
and FTP user programs shouldn't have to worry about them. 7f
Here is a list of the current FTP-1 replies, and how they should
be renumbered for the new scheme. The changes from 4xx to 5xx
should be REQUIRED as of June 1; changes in the second or third
digit are not so important. (As explained above, it will not be
catastrophic even if some hosts do not meet the requirement.) The
list also contains one new possible reply adapted from RFC 640.
Replies invented in RFC 454 are so noted; since some of them are
for commands largely not implemented like REIN, they may be
irrelevant.
 
   
  OLD
0x0

100
NEW
0x0

110
 TEXT
(These messages are not very well defined nor very
     important. Servers should use their judgment.)
System status reply. (Since nobody does STAT as in the protocol, this may be a moot point.)
110 111 System busy doing... (This RFC 454 message could
easily be considered an example of the one above,
but since the 454 authors want to distinguish it,
here it is in another number.)
150 150 "File status reply." (If this were really that,
it
would be switched to 120, but I believe what is
meant
is the response to a bare STAT in mid-transfer,
which
is more a connection status reply than a file
status
reply.)
151 121 Directory listing reply.
200 200 Last command ok.
201 251 ABOR ok. 7g2
202 252 ABOR ignored, no transfer in progress.
new 206 Command ignored, superfluous here.
230 230 Login complete.
231 231 Logout complete. (RFC 454: Closing connection.)
232 232 Logout command will be processed when transfer is
complete. 7g3
233 233 Logout complete, parameters reinitialized. (RFC
454 for REIN) 7g4
250 250 Transfer started correctly.
251 251 MARK yyyy = mmmm
252 252 Transfer completed ok.
253 223 Rename ok.
254 224 Delete ok.
255 255 SOCK nnnn
256 256 Mail completed ok.
300 300 Connection greeting
301 301 Command incomplete (no crlf)
330 330 Enter password 7g5
331 331 Enter account (RFC 454)
350 350 Enter mail. 7g6
400 huh? "This service not implemented." I don't
understand
this; how does it differ from 506? If it means no FTP
at all, who gave the message? Flush.

401 451 Service not accepting users now, goodbye.
430 430 Foo, you are a password hacker!
431 531 Invalid user or password.
432 532 User invalid for this service.
433 533 Need account to write files.
434 454 Logout by operator.
435 455 Logout by system.
436 456 Service shutting down.
450 520 File not found.
451 521 Access denied.
452 452 Transfer incomplete, connection closed. 7g8
453 423 Transfer incomplete, insufficient storage space.
454 454 Can't connect to your socket.
455 425 Random file system error (RFC 454) 7g9
456 526 Name duplication, rename failed (RFC 454)
457 557 Bad transfer parameters (TYPE, BYTE, etc) (RFC
454)
500 500 Command gibberish.
501 501 Argument gibberish.
502 502 Argument missing.
503 503 Arguments conflict.
504 504 You can't get there from here.
505 505 Command conflicts with previous command.
506 506 Action not implemented.
507 507 Some other problem. (RFC 454)
550 520 Bad syntax in pathname. (RFC454)

 
  1. FTP Operation Over Big Address Records (FOOBAR)
    1. Introduction
rfc1639
Network Working Group D. Piscitello
Request for Comments: 1639 Core Competence, Inc.
Obsoletes: 1545 June 1994
Category: Experimental
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
This paper describes a convention for specifying address families
other than the default Internet address family in FTP commands and
replies.

 
Introduction
In the File Transfer Protocol (STD 9, RFC 959), the PORT command argument <host-port> specifies the data port to be used to establish a data connection for FTP (STD 9, RFC 959). This argument is also used in the PASV reply to request the server-DTP to listen on a data port other than its default data port. This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a "long Port (LPRT)" command and "Long Passive (LPSV)" reply, each having as its argument a <long-host-port>, which allows for additional address families, variable length network addresses and variable length port numbers. This is a general solution, applicable for all "next generation" IP alternatives, as well as for other network protocols than IP. This revision also extends FTP to allow for its operation over transport interfaces other than TCP.
 

Acknowledgments

Many thanks to all the folks in the IETF who casually mentioned how
to do this, but who left it to me to write this RFC. Special thanks
to Rich Colella, Bob Ullmann, Steve Lunt, Jay Israel, Jon Postel,
Shawn Ostermann, and Tae Kyong Song, who contributed to this work.
Piscitello [Page 1]

RFC 1639 FTP Over Big Address June 1994
1. Background
The PORT command of File Transfer Protocol allows users to specify an
address other than the default data port for the transport connection
over which data are transferred. The PORT command syntax is:
PORT <SP> <host-port> <CRLF>
The <host-port> argument is the concatenation of a 32-bit internet
<host-address> and a 16-bit TCP <port-address>. This address
information is broken into 8-bit fields and the value of each field
is transmitted as a decimal number (in character string
representation). The fields are separated by commas. A PORT command
is thus of the general form "PORT h1,h2,h3,h4,p1,p2", where h1 is the
high order 8 bits of the internet host address.
The <host-port> argument is also used by the PASV reply, and in
certain negative completion replies.
To accommodate larger network addresses anticipated for all IP "next
generation" alternatives, and to accommodate FTP operation over
network and transport protocols other than IP, new commands and reply
codes are needed for FTP.
2. The LPRT Command
The LPRT command allows users to specify a "long" address for the
transport connection over which data are transferred. The LPRT
command syntax is:
LPRT <SP> <long-host-port> <CRLF>
The <long-host-port> argument is the concatenation of the following
fields;
o an 8-bit <address-family> argument (af)
o an 8-bit <host-address-length> argument (hal)
o a <host-address> of <host-address-length> (h1, h2, ...)
o an 8-bit <port-address-length> (pal)
o a <port-address> of <port-address-length> (p1, p2, ...)
The initial values assigned to the <address-family> argument take the
value of the version number of IP (see Assigned Numbers, STD 2, RFC
1340); values in the range of 0-15 decimal are thus reserved for IP
Piscitello [Page 2]

RFC 1639 FTP Over Big Address June 1994
and assigned by IANA. Values in the range 16-255 are available for
the IANA to assign to all other network layer protocols over which
FTP may be operated.
Relevant assigned <address-family> numbers for FOOBAR are:
Decimal Keyword
------ -------
0 reserved
1-3 unassigned
4 Internet Protocol (IP)
5 ST Datagram Mode
6 SIP
7 TP/IX
8 PIP
9 TUBA
10-14 unassigned
15 reserved
16 Novell IPX
The value of each field is broken into 8-bit fields and the value of
each field is transmitted as an unsigned decimal number (in character
string representation, note that negative numbers are explicitly not
permitted). The fields are separated by commas.
A LPRT command is thus of the general form
LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...
where h1 is the high order 8 bits of the internet host address, and
p1 is the high order 8 bits of the port number (transport address).
3. The LPSV Command
The L(ONG) PASSIVE command requests the server-DTP to listen on a
data port other than its default data port and to wait for a
connection rather than initiate one upon receipt of a transfer
command. The response to this command includes the address family,
host address length indicator, host address, port address length, and
port address of the listener process at the server. The reply code
and text for entering the passive mode using a long address is 228
(Interpretation according to FTP is: positive completion reply 2yz,
connections x2z, passive mode entered using long address xy8).
The suggested text message to accompany this reply code is:
228 Entering Long Passive Mode
(af, hal, h1, h2, h3,..., pal, p1, p2...)
Piscitello [Page 3]

RFC 1639 FTP Over Big Address June 1994
4. Permanent Negative Completion Reply Codes
The negative completion reply codes that are associated with syntax
errors in the PORT and PASV commands are appropriate for the LPRT and
LPSV commands (500, 501). An additional negative completion reply
code is needed to distinguish the case where a host supports the LPRT
or LPSV command, but does not support the address family specified.
Of the FTP function groupings defined for reply codes (syntax,
information, connections, authentication and accounting, and file
system), "connections" seems the most logical choice; thus, an
additional negative command completion reply code, 521 is added, with
the following suggested textual message:
521 Supported address families are (af1, af2, ..., afn)
Where (af1, af2, ..., afn) are the values of the version numbers of
the "next generation" or other protocol families supported. (Note: it
has been suggested that the families could also be represented by
ASCII strings.)
5. Rationale
An explicit address family argument in the LPRT command and LPSV
reply allows the Internet community to experiment with a variety of
"next generation IP" and other network layer protocol alternatives
within a common FTP implementation framework. (It also allows the use
of a different address family on the command and data connections.)
An explicit length indicator for the host address is necessary
because some of the IPNG alternatives make use of variable length
addresses. An explicit host address is necessary because FTP says
it's necessary.
The decision to provide a length indicator for the port number is not
as obvious, and certainly goes beyond the necessary condition of
having to support TCP port numbers.
Currently, at least one IPng alternative (TP/IX) supports longer port
addresses. And given the increasingly "multi-protocol" nature of the
Internet, it seems reasonable that someone, somewhere, might wish to
operate FTP operate over Appletalk, IPX, and OSI networks as well as
TCP/IP networks. (In theory, FTP should operate over *any* transport
protocol that offers the same service as TCP.) Since some of these
transport protocols may offer transport selectors or port numbers
that exceed 16 bits, a length indicator may be desirable. If FTP must
indeed be changed to accommodate larger network addresses, it may be
prudent to determine at this time whether the same flexibility is
useful or necessary with respect to transport addresses.
Piscitello [Page 4]

RFC 1639 FTP Over Big Address June 1994
6. Conclusions
The mechanism defined here is simple, extensible, and meets both IPNG
and multi-protocol internet needs.
7. References
STD 9, RFC 959 Postel, J., and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, USC/Information Sciences Institute,
October 1985.
STD 2, RFC 1340 Reynolds, J., and J. Postel, "Assigned Numbers",
STD 2, RFC 1340, USC/Information Sciences Institute,
July 1992. (Does not include recently assigned IPv7
numbers).
STD 3, RFC 1123 Braden, R., Editor, "Requirements for Internet
Hosts - Application and Support", STD 3, RFC 1123,
USC/Information Sciences Institute, October 1989.
8. Security Considerations
Security issues are not discussed in this memo.
9. Author's Address
David M. Piscitello
Core Competence, Inc.
1620 Tuckerstown Road
Dresher, PA 19025
EMail: dave@corecom.com
Piscitello [Page 5]