As per Relevance of the word specific, we have this rfc below:
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
Brian
SU-
Re: File Transfer Protocol May 28, 1975
Ref: RFC 354, 385, 414, 448, 454, 630, 542, 640 1
One More Try on the FTP 2
This is a slight revision of RFC 686, mainly differing in
discussion of print files. Reading several RFCs that I (sigh
never heard of before writing 686 has convinced me that
I was right all along it was for the wrong reasons. The list
reply codes is also slightly different to reflect the four
in RFCs 354, 454, 542, and 640 more completely. Let me
suggest that if there are no objections before June 1,
take it as official that HELP should return 200, that SRVR
be used as discussed below, and that "permanent" 4xx errors
changed to 5xx. And thanks to Jon Postel who just spent
evening helping me straighten this all out. 2
Aside from a cry of anguish by the site responsible for
security hassle described below, I've only had one comment
this, which was unfavorable but, alas, unspecific. Let me
say, in the hopes of avoiding more such, that I am not
trying to step on toes for the fun of it, and that I don't
the positive changes to FTP-1 proposed here are necessarily
best possible thing. What they are, I think, is easily doable
The great-FTP-in-the-sky isn't showing any signs of
acceptability, and it shouldn't stand in the way of
immediate problems. 2
Leaving Well Enough Alone 3
I recently decided it was time for an overhaul of our FTP user
server programs. This was my first venture into the world
network protocols, and I soon discovered that there was a lot
were doing wrong--and a few things that everyone seemed to be
differently from each other. When I enquired about this,
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
version 1, and basically transferring files OK, it seems to me
the existence on paper of an unused protocol should not stand in
way of maintaining the current one unless there is a good reason
1
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
believe that the new one is either imminent or strongly superior
both. (I understand, by the way, that FTP-2 represents a lot
thought and effort by several people who are greater network
than I, and that it isn't nice of me to propose junking all
work, and I hereby apologize for it.) Let me list what strike me
the main differences in FTP-2 and examine their potential impact
the world. 5
1. FTP-2 uses TELNET-2. The main advantage of the new
protocol is that it allows flexible negotiation about things
echoing. But the communicators in the case of FTP are
programs, not people, and don't want any echoing anyway.
argument that new hosts might not know about old Telnet seems
unlikely one for quite some time to come; if TELNET-2 ever
really take over the world, FTP-1 could be implemented in it. 5
2. FTP-2 straightens out the "print file" mess. First of all
there are two separate questions here: what command one ought
give to establish a print file transfer, and which end does
sort of conversion. For the second question, although all of
FTP-1 documents are confusing on the subject, I think it
perfectly obvious what to do: if the user specifies, and
server accepts, an ASCII or EBCDIC print file transfer
sequence, then the data sent over the network should
Fortran control characters. That is, the source file
contain Fortran controls, and should be sent over the net as is
and reformatted if necessary not by the SERVER as the
says but by the RECIPIENT (server for STOR, user for RETR). (
"Telnet print file" non-issue will be debunked below.)
As a non-Fortran-user I may be missing something here but I don'
think so; it is just like the well-understood TYPE E in which
data is sent in EBCDIC and the recipient can format it for
use as desired. One never reformats a file from ASCII to
at the sending end. Perhaps the confusion happened because
protocol authors had in mind using these types to send
directly to a line printer at the server end, and indeed
that's all it's good for and nobody's user program will
TYPE P RETR. 5
As for the specific commands used to negotiate such a transfer
there may currently be some confusion because the most
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
2
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
experiments have been on PDP-10s; perhaps other systems
adopted this command.) FTP-2 puts the format argument in
TYPE command as a second argument. Either way, using
two-dimensional scheme to specify the combinations
ASCII/EBCDIC and ASA/normal conveys no more information than
present A-P-E-F scheme. FTP-2 also introduces the notion
Telnet formatted vs. non-print files. These types are used
a Telnet format oriented system is sending a file to an
oriented one, and the recipient needs to know, not what is
over the net, but how to solve a local file storage problem.
is unnecessary and unfair for hosts to have to
something which does not acttually affect what gets sent over
net. It is unnecessary because the sending user process (
is no problem if the user process is receiving) need
understand what the issue is, it need only make the
understand by transmitting a message from the human user to
server process. Any TYPE parameter must be understood by
processes even if the user treats it just like some other type. 5
To take a specific example, if I want to send an ASCII file to
360, my FTP user program needs to have built into it
knowledge that there are two TYPEs which are really the same,
and AT in the FTP-2 notation. If tomorrow someone needs to
the ultimate use of a binary file (for instance, the old PDP-6
DECtape format stores dump files differently from ordinary
files), I will have to add another piece of information to my
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
some form which the sending process can ignore. This is what
SRVR command should be used for. 5
If a user at a 360 wants to retrieve a "Telnet print file"
another system, he might tell his FTP user process something like 5
TYPE
DISP
RETR FOO etc. 5e
(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 5
TYPE
3
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
SRVR
STOR FOO etc. 5f
His FTP user program would send on the SRVR command
comment. Suppose that the transformation is one which might
used in either direction between the same two hosts. (This
not the case for the Telnet print file thing because two 360
would be using ASA format.) Then the user process could
the equivalent of DISP PRINT from the user, and if the
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
user types the same command regardless of the direction
transfer. 5
Thus, FTP servers which care about the distinction between
print and non-print could implement SRVR N and SRVR T.
the SRVR parameters should be registered with Jon Postel to
conflicts, although it is not a disaster if two sites use
same parameter for different things. I suggest that
be allowed to be more than one letter, and that an initial
X be used for really local idiosyncracies. The following
be considered as registered: 5
T - Telnet print file 5h
N - Normal. 5h
Means to turn off any previous SRVR in effect. (This
"non-print" the default case, rather
making "Telnet print" and "non-print" equal. It
probably a good idea if a user program can count
being able to turn off an earlier SRVR without
to know a specific inverse for it. Servers which do
implement any other SRVR parameters need not
SRVR N either; user processes shouldn't send SRVR
just for the hell of it.)
3. FTP-2 reshuffles reply codes somewhat. There have been
attempts altogether, that I know of, at specifying a list
reply codes: RFCs 354 and 454 for FTP-1, and RFCs 542 and 640
FTP-2. There is not much to choose from among the first three
these, which are basically the same, except for a slight
in specificity each time through, e.g., the introduction of
4
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
code 456 for a rename which fails because a file of the
(new) name already exists. This increased specificity of
codes doesn't seem to be much of a virtue; if a rename
fails, it is the human user, not the FTP user program, who
to know that it was because of a name conflict rather than
other file system error. I am all for putting such
in the text part of FTP replies. Some real problems are
addressed in the reply code revision of RFC 640, in which
basic scheme for assigning reply code numbers is more
than either the FTP-1 scheme or the original FTP-2 scheme
However, I think that most of the benefits of RFC 640 can
obtained in a way which does not require
reprogramming. More on this below. 5
4. FTP-2 was established by a duly constituted ARPAnet
and we are duty-bound to implement it. I don't suppose
would actually put it that baldly, but I've heard things
amounted to that. It's silly. 5
5. FTP-2 specifies default sockets for the data connection
Most places use the default sockets already anyway, and it
easy enough to ignore the 255 message if you want to. This is
security issue, of course, and I'm afraid that I can't work
much excitement about helping the CIA keep track of what anti-
demonstrations I attended in 1968 and which Vietnamese hamlets
bomb for the greatest strategic effect even if they do pay
salary indirectly. I could rave about this subject for pages
and probably will if I ever get around to writing an
against MAIL-2, but for now let me just get one anecdote off
chest: I have access to an account at an ARPAnet host because
am responsible at my own site for local maintenance of a
which was written by, and is maintained by, someone at the
site. However, the other site doesn't really trust us
(the account is shared by people in my position at several
hosts) to protect their vital system security, so every week
run a computer program to generate a new random password for
account (last week's was HRHPUK) and notify us all by
mail. Well, on my system and at least one of the others,
mail isn't read protected. I delete my mail when I read it,
since it is hard enough remembering HRHPUK without them
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
5
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
it, and the other passwords in it are for open guest
which are widely known. Moral #1: Security freaks are
weird. Moral #2: If you have a secret don't keep it on
ARPAnet. (In the past week I have heard about two
discovered holes in TENEX security.) 5
6. FTP-2 is available online and FTP-1 isn't, so new hosts can'
find out how to do it. Aargh!!! What a reason for
anything! Surely it would be less costly for someone to type
in again than for everyone to reprogram. Meanwhile these
hosts can ask Jon or Geoff or Bobby or even me for help
getting FTP up. 5
7. FTP-2 has some changes to the strange MODEs and STRUs.
is another thing I can't get too excited about. We support
MODE S and STRU F and that will probably still be true even if
are forced into FTP-2. If the relatively few people who do
large file transfers need to improve the restart capability,
can do so within FTP-1 without impacting the rest of us.
recent implementation of paged file transfers by TENEX shows
problems of individual systems can be solved within the FTP-1
framework. If the IBM people have some problem about
structure in FTP-1, for example, let them solve it in FTP-1,
whatever the solution is, nobody who isn't affected has
reprogram. 5
Well, to sum up, I am pretty happy with the success I've
transferring files around the network the way things are. When I
run into trouble it's generally because some particular host hasn'
implemented some particular feature of FTP-1, and there's no
to suppose they'll do it any faster if they also have to convert
FTP-2 at the same time. The main thing about FTP-2, as I said
the beginning, is that its existence is an excuse for not
problems in FTP-1. Some such problems are quite trivial except
the fact that people are reluctant to go against anything in
protocol document, as if the latter were the Holy Writ. A
actually require some coordinated effort. Here is my problem list: 6
1. It is almost true that an FTP user program can
reply codes by the following simple algorithm: 6
a. Replies starting with 0 or 1 should be typed out
otherwise ignored. 6a
6
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
b. Replies starting with 2 indicate success (of this step
of the whole operation, depending on the command). 6a
c. Replies starting with 4 or 5 indicate failure of
command. 6a
d. Replies starting with 3 are only recognized in three cases
the initial 300 message, the 330 password request, and
350 MAIL response. (Note that the user program need
distinguish which 300 message it got, merely whether or not
is expecting one right now.) 6a
The only real problem with this, aside from bugs in a few
whose maintainers tell me they're working on it, is the
command, which is not in the original protocol and which
0xx, 1xx, or 2xx depending on the server. (Sometimes more
one message is returned.) The word from one network
expert at BBN is that (a) 050 or 030 is the correct response
HELP, and (b) there is a perfectly good mechanism in the
for multi-line responses. Unfortunately this does not do
good in dealing with reality. There seems to be a
procedure for handling the STAT command: 6
151
151
151 ...
151
200 END OF STATUS 6b
which fits right in with the above algorithm. This is
the fact that 1xx is supposed to constitute a positive
to a command like STAT, so that according to RFC 354 it ought
be 6
151-
...
151 information 6c
instead. RFC 414, which approves of the 200 reply for STAT,
gives 200 for HELP. (It seems to me, by the way, that 050
030 aren't good enough as responses to HELP since
"constitute neither a positive nor a negative acknowledgement"
7
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
the HELP command and thus don't tell the user program when
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
end of whatever other HELP it gives as of, let's say, June 1.
The alternatives are either to let the current rather
situation continue forever while waiting for FTP-2, or to try
standardize everyone on a multi-line 1xx for both HELP and STAT
I'm against changing STAT, which works perfectly for everyone
far as I can tell, and it should be clear that I'm
waiting for FTP-2. Unfortunately there is no real mechanism
"officially" adopting my plan, but I bet if TENEX does it on
1 the rest of the world will come along. 6
2. Another reply code problem is the use of 9xx
"experimental" replies not in the protocol. This includes
BBN mail-forwarding message and one other that I know of.
procedure is sanctioned by RFC 385, but it seems like a bad
to me. For one thing, the user program has no way of
whether the reply is positive, negative, or irrelevant.
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
reply codes. x9x or xx9 could be used to indicate experiments. 6
3. One more on reply codes: RFC 630 (the one about the TENEX
to the reply codes for MAIL and MLFL) raises the issue
"temporary" versus "permanent" failures within the 4xx category
RFC 640 deals with this question in the FTP-2 context by
the meaning of 4xx and 5xx so that the former are for
errors and the latter are for permanent errors. I like
idea, and I think it could easily be adapted for FTP-1 use in
way which would allow people to ignore the change and still win
At present, I believe that the only program which attempts
distinguish between temporary and permanent errors is the
mailer. For other programs, no distinction is currently
between 4xx and 5xx responses; both indicate failure, and
retrials are done by the human user based on the text part of
message. A specific set of changes to the reply codes
proposed below. 6
Perhaps I should make a few more points about RFC 640, since it'
the best thing about FTP-2 and the only argument for it I find
8
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
all convincing. Let me try to pick out the virtues of 640
indicate how they might be achieved in FTP-1. 6
a. The 3xx category is used uniformly for "
intermediate replies" where further negotiation in the
connection is required, as for RNFR. I'm afraid this
can't be changed without affecting existing user programs
(One of my goals here is to enable existing user programs
work while some servers continue as now and others adopt
suggestions I make below.) However, although this 3xx idea
logically pleasing, it is not really necessary for
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
improvement for the user program if there were also a 2xx
which might be returned after RNFR, which is not the case
640 also abolishes the 300 initial connection message
220, but again there is clearly no conflict here. 6g
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
1xx message doesn't affect the state of the user process,
this is not really true. Consider the file transfer commands
The state diagram on page 13 of RFC 640 is
misleading. It appears as if 1xx replies are simply ignored
the user program. In reality, that little loop hides a lot
work: the file transfer itself! If the server replied to
file transfer command immediately with a 2xx message, it
be a bug in the server, not a successful transfer. The
state diagram is more like 6g
B --> cmd --> W --> 1 --> W --> 2 -->
(with branches out from the "W"s for bad replies). It
be clear from this diagram that the user program, if it
the server to know what it's doing, can expect a 2xx
of the 1xx without getting confused, since it knows which
the W states it's in. In fact, the use of 1xx in
transfer is very different from its other uses, which
indeed more like the 0xx and 1xx replies in FTP-1. I'd
this particular point a bug in RFC 640. 6g
c. Automatic programs which use FTP (like mailers) can
9
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
whether to queue or abandon an unsuccessful transfer based
the distinction between 4xx and 5xx codes. I like
idea, although those temporary errors virtually never
in real life. This could be accomplished in FTP-1 by
many of the 4xx replies to 5xx. Mailers would be modified
use the first digit to decide whether or not to retry.
scheme does not cause any catastrophes if some server is
in converting; it merely leads to unnecessary retries. A
CPU cycles would be wasted in the month following the
switch. Thus, this feature is very different from (a)
(b), which could lead to catastrophic failures if
implemented all at once. (Yes, I know that FTP-2 is
to be done on a different ICP socket. I am not
FTP-2 but whether its virtues can be transferred to FTP-1.)
The specific codes involved are listed below. 6g
d. The use of the second digit to indicate the type
message. (The proposed division is not totally clean
for example, why is 150 ("file status okay; about to
data connection") considered to be more about the
system than about the data connection?) This can
be done, since the second digit is not currently
to any user process--the TENEX mailer is, in this plan
already due for modification because of (c). Since
is mostly an aesthetic point, I'm hesitant to do it if
would be difficult for anyone. In particular, I would want
leave the 25x messages alone, in case some user
distinguish these. This is especially likely for the
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
reflected in the specific list below. 6g
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
successful, and I believe all do except HELP. 7
2. The definition of 1xx messages should be changed to read
"Informative replies to status inquiries. These
neither a positive nor a negative acknowledgment." 7
10
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
3. Experimental reply codes should be of the form x9x or xx9,
where the first digit is chosen to reflect the significance
the reply to automated user programs. Reply codes greater
599 are not permitted. The xx9 form should be used if the
falls into one of the existing categories for the second digit
User programs are encouraged to determine the significance of
reply from the first digit, rather than requiring a
reply code, when possible. 7
4. The STAT command with no argument is considered a request
a directory listing for the current working directory,
that it may be given along with TELNET SYNCH while a transfer
in progress, in which case it is a request for the status of
transfer. (Everyone seems to do the first part of this. I'm
sure if anyone actually implements the second. This is
getting the protocol to agree with reality.) The reply to a
command should be zero or more 1xx messages followed by a 200. 7
5. TYPEs P and F mean that the source file contains ASA
characters and that the recipient program should reformat it
necessary. Servers which care about Telnet-print vs. non-
should implement SRVR T and SRVR N. All user processes
provide a way for the human user to specify an arbitrary
command. 7
6. (This is just a resolution of a loose end in documentation.)
Nested reply codes are not allowed. I don't think this
needs more discussion; they never happen and can't possibly work
and FTP user programs shouldn't have to worry about them. 7
Here is a list of the current FTP-1 replies, and how they
be renumbered for the new scheme. The changes from 4xx to 5
should be REQUIRED as of June 1; changes in the second or
digit are not so important. (As explained above, it will not
catastrophic even if some hosts do not meet the requirement.)
list also contains one new possible reply adapted from RFC 640.
Replies invented in RFC 454 are so noted; since some of them
for commands largely not implemented like REIN, they may
irrelevant. 7
OLD NEW
7g
0x0 0x0 (These messages are not very well defined nor
11
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
important. Servers should use their judgment.)
100 110 System status reply. (Since nobody does STAT
the protocol, this may be a moot point.)
110 111 System busy doing... (This RFC 454 message
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
would be switched to 120, but I believe what
is the response to a bare STAT in mid-transfer
is more a connection status reply than a
reply.)
151 121 Directory listing reply
200 200 Last command ok
201 251 ABOR ok. 7g
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
complete. 7g
233 233 Logout complete, parameters reinitialized. (
454 for REIN) 7g
250 250 Transfer started correctly
251 251 MARK yyyy =
252 252 Transfer completed ok
253 223 Rename ok
254 224 Delete ok
255 255 SOCK
256 256 Mail completed ok
300 300 Connection
301 301 Command incomplete (no crlf
330 330 Enter password 7g
331 331 Enter account (RFC 454)
350 350 Enter mail. 7g
400 huh? "This service not implemented." I don'
this; how does it differ from 506? If it means
12
NWG/RFC# 691 BH 6-JUN-75 23:15 32700
One More Try on the
at all, who gave the message? Flush. 7g
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. 7g
453 423 Transfer incomplete, insufficient storage space
454 454 Can't connect to your socket
455 425 Random file system error (RFC 454) 7g
456 526 Name duplication, rename failed (RFC 454)
457 557 Bad transfer parameters (TYPE, BYTE, etc) (
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
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
