As per Relevance of the word connection, we have this rfc below:
Network Working Group K. Pogran (MIT-Multics
Request for Comments: 614 N. Neigus (BBN-NET
NIC #21530 Jan 1974
References: RFC #607, RFC #542
Response to RFC 607, "Comments on the File Transfer Protocol
Mark Krilanovich and George Gregg have pointed out a number of "sticky
issues in the current File Transfer Protocol. Although we don't
with all of their proposed protocol modifications, we do feel that
of the points they have raised should be given some thought by
concerned about FTP. Each numbered paragraph in the discussion below is
comment on the identically-numbered paragraph in RFC 607.
1. Instructions to the Server to be "passive" are defined to apply
to the next single file transfer operation, after which the
reverts to active mode. RFC 607 does, however, point out a drawback
the present specification, in that there is no way for a user to "
his mind": once he has told a server to be "passive", he has to
some file transfer operation. The suggested solution is a welcome one.
suggest that the text of the "successful reply" to the ACTV
indicate whether the server had previously been in "active" or "passive
mode, viz
200 MODE CHANGED TO
200 MODE IS ALREADY
It is important to note that once some servers "listen" on a
in response to a PASV command, they no longer can examine the
control connection for the possible arrival of an ACTV command. User-
programs should precede the ACTV command with a SYNC sequence to
that the server will see the ACTV command
2. While the length of an FTP command -- either three or four
-- might often be irrelevant to a system which interacts over
connections on a line-at-a-time basis, we can see how a variable
length might be harder for a character-at-a-time system to handle
especially for a server implemented in assembly language. Quite a bit
gained, and nothing seems to be lost, by requiring that FTP commands
four characters, so we agree with the suggestion in RFC 607.
3. While the FTP document may be somewhat ambiguous in its
of the order of the handshaking which takes place following a
transfer command, such an order does exist as far as is possible for
two asynchronous processes described in "The FTP Model" (section II. B
RFC 542) -- the Telnet Control process (Protocol Interpreter) and
Data Transfer process. The user is required to "listen" on the
connection before sending the transfer command. Upon receipt of
command the server should first check that the status of the
specified by the argument to the file transfer command is okay, and,
so, attempt to open the data connection. If there are file
problems, no attempt should be made to open the connection. In this way
-1-
the primary response to the command gives an accurate picture of
transfer status -- i. e., connection opened and transfer started (250),
or connection not opened because of file problems (450, 451, 455, 457)
connection problems (454). The secondary reply follows the conclusion
the transfer, and describes its success or failure
If a particular FTP implementation cannot monitor the data connection
the Telnet control connection simultaneously, then it must establish
timeout waiting for the data connection RFC. In addition, a
interval should be specified for which all servers must wait
deciding that the data connection cannot be opened. We suggest that
interval be no shorter than fifteen seconds
4. The protocol states that servers should return "success", replies
commands such as ACCT and ALLO which were irrelevant to them.
recommend that the protocol say "must" rather than "should".
5. Specification of maximum lengths for lines, pathnames, etc. is a
idea, as is the suggestion of a Server poll. Typical values for
present Multics implementation (provided by Ken Pogran) are as follows
Telnet lines: 256
User names: 32
Passwords: 8
Account Numbers: (na
Pathnames: 168 (yes, 168)
6. We strongly disagree with Mark on this point. The algorithm a user-
should use goes something like this
a. Examine the first four characters of the reply.
b. If the fourth character is a space, the reply is not a multi-line reply.
c. If the fourth character is a hyphen, the reply is a multi-line reply
and the text portion of this line and succeeding lines should be
to the user if this is desired
d. On each succeeding line, if the first four characters are not
three digits of the original reply code followed by a space, the line
entirely a text line and should either be reported to the user
discarded
e. If the first four characters on the line are the three digits of
reply code followed by space, this line is the last line of the reply
This algorithm seems simple enough, if nesting of replies is not
(see comments on paragraph 7, below). This sort of continuation-
convention provides a number of benefits to the person coding a server
Consider the problem of providing a directory listing, in response to
STAT command whose argument is the pathname of a directory. If the
Telnet control connection is treated as a pseudo-typewriter (as
ordinary Telnet connections are), the writer of an FTP Server may be
to "borrow" the code from the system command which provides
status (listing) information, as follows (in a pseudo-PL/l syntax):
call write_out_line ("151- Directory listing follows") ;
call list_directory_contents (directory_pathname);
call write_out_line ("151 Directory listing complete");
-2-
The same can be done for the file status reply (code 150). Otherwise,
program must be written which performs the function of
directory-listing command, but uses a special output format. If
implementor of an FTP Server wants to be "nice" and list file attributes
as well as file names, in the directory listing (as
directory-listing commands do), this could be a fairly big job.
already-written software can be borrowed and incorporated into the
Server, the implementor of the FTP Server can put more of his effort
doing a better job of building the "guts" of the FTP Server
7. It is not obvious why multi-line replies are allowed to be nested
an arbitrary depth. Only truly spontaneous replies may nest inside
replies -- and it is easy to convince yourself that they will only
to depth one. It was envisioned that some messages from "the system
might not allow the "exterior" multi-line message to finish; the
might go something like this:.
151- Directory listing follows
a1pha.p11
rfc.
010- From Operator
010 Emergency shutdown in 5 mins. due to hardware probs
beta.
foo.
151 Directory listing complete
It has been pointed out to us that
a. Messages from "the system" in general cannot be guaranteed to come
the beginning of a line
b. It may be difficult to modify "the system" to preface such
with an appropriate FTP reply code
Therefore, we propose that, since user-FTP implementations must
multi-line replies, system messages "splattered" into the middle
replies need not be escorted by FTP reply codes. The user-FTP thus
not detect and handle "nested" FTP replies
8. RFC 607 proposes that any data between the last end-of-record
of a file and the end-of-file marker be discarded. We agree. The
of the data has clearly violated the protocol, and the receiver
divine the sender's original intent
9-11. The suggestion that reply codes beginning with the digit "2"
taken as successful, and all others be taken as failures,
restricts use of the available "reply code space". We agree that
present scheme is disorganized and requires far too much "intelligence
on the part of a user-ftp automaton. With the present scheme, unless
automaton's reply-interpretation is table-driven, it is extremely
to make a mistake. We feel that the whole reply code strategy should
redesigned; some of the ideas proposed in RFC 607 could fit in with
a redesign, but we do not think that Mark's suggestion is the way to go
-3-
12. 000 and 020 are used by the Server to indicate that it has heard
answered the ICP to socket 3, but cannot accept file transfer
yet. 020 was intended to indicate how much of a time delay could
expected, while 000 was ambiguous on this point. We suggest that the
be merged to mean "I am here; please wait a specified or
amount of time"; then, 300 would clearly mean "I am ready; you may
send me commands".
13. There is no typographical error here. A TENEX
suggested that, rather than give a "fail" reply to a particular
because the user is not logged in, a server might ask for his
number (or ask him to log in) and then proceed with the previous request
which has been held in abeyance. While this may be convenient for
server, it is not necessary, and certainly ambiguous to hold a command
abeyance while obtaining an account number. Since any server may
this on a user, all user-FTP implementations must be able to cope
this twist, which adds a good deal of required complication to
"minimal" user-FTP implementation. We propose that the 331 reply
eliminated, and that the server forget the requested operation and
a 4XX reply if an account is needed
Jon Postel has remarked that "mail text should follow the same limit
commands and long 'lines' of mail text have been trouble for some
Servers." We agree. In fact, mail transmitted over the FTP Telnet
connection has other problems, too: Since FTP is (nominally, at least
supposed to be usable from TIPs, Multics implemented its
character erase and line kill conventions on the control connection
the convenience of TIP users (it was actually easier to have
conventions in effect than to turn them off!). Of course, no erase/
processing was done on the data connection. The intent of the
request was to allow users at terminals to access an FTP Server
and transmit mail; it was presumed that mail-sending automata
gathered the mail to be sent into a file would use the MLFL command
transmit the mail over the data connection. Presumably, long lines
not be a problem, and, of course, no erase/kill conventions would be
effect. Well, at least one major system (TENEX) has a mail-
automaton which transmits mail over the Telnet control connection
the MAIL command - even though it has previously gathered the mail into
file! Line-length considerations could be a severe problem here, and
fact that the Multics line-kill character is the at-sign (@) caused
in reading mail from TENEX users who included their "return address"
TENEX's SNDMSG syntax, as USERNAME@HOST. We propose that mail-
automata be required to use MLFL, rather than MAIL
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
