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