NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
One More Try on the FTP 2
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. 2a
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. 2b Leaving Well Enough Alone 3
1
really take over the world, FTP-1 could be implemented in it. 5a
TYPE P RETR. 5b
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
2
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. 5d
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. 5e1
(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
3
SRVR PRINT
STOR FOO etc. 5f1
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. 5g
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 5h1 N - Normal. 5h2
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.)
4
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. 5i
amounted to that. It's silly. 5j
5
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
getting FTP up. 5l
reprogram. 5m
reply codes by the following simple algorithm: 6a
otherwise ignored. 6a1
6
of the whole operation, depending on the command). 6a2
command. 6a3
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 6c
151-information
information
...
151 information 6c1
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
7
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. 6d
reply codes. x9x or xx9 could be used to indicate experiments. 6e
proposed below. 6f
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
8
all convincing. Let me try to pick out the virtues of 640 and
indicate how they might be achieved in FTP-1. 6g
220, but again there is clearly no conflict here. 6g1
state diagram is more like 6g2
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. 6g3
9
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
reflected in the specific list below. 6g5
successful, and I believe all do except HELP. 7a
neither a positive nor a negative acknowledgment." 7b
10
reply code, when possible. 7c
command should be zero or more 1xx messages followed by a 200. 7d
command. 7e
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. 7g OLD NEW TEXT 7g1 0x0 0x0 (These messages are not very well defined nor very
11
important. Servers should use their judgment.)
100 110 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
12
FTP
at all, who gave the message? Flush. 7g7 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) 7g10
13