RFC 614

Response to RFC 607, "Comments on the File Transfer Protocol" ✨

okay bestie, the title block 🎀 says this is RFC 614 (NIC #21530), by K. Pogran (MIT-Multics) and N. Neigus (BBN-NET), dated Jan 1974. It's a Network Working Group doc, it responds to RFC 607, and it references RFC #607 and RFC #542. It doesn't list a category, and it doesn't obsolete or update anything. 💅

Mark Krilanovich and George Gregg flagged a bunch of sticky issues in the File Transfer Protocol 😭. The authors don't agree with all of their proposed changes, but they think everyone who cares about FTP should think about each point. Each numbered paragraph below responds to the paragraph with the same number in RFC 607. 🦋

---

1.

Servers told to be "passive" only apply that to the next single file transfer, then they go back to active mode. RFC 607 points out the catch: there's no way for a user to "change his mind" once he's told a server to be passive, and he has to start a transfer first 😤. The suggested fix is a welcome one 🙌. The authors suggest the "successful reply" to the ACTV command say whether the server was previously in "active" or "passive" mode, like this:

200 MODE CHANGED TO ACTIVE

or

200 MODE IS ALREADY ACTIVE

Important tea ☕: once some servers "listen" on a connection in response to a PASV command, they can no longer check the Telnet control connection for an ACTV command. User-FTP programs should put a SYNC sequence in front of the ACTV command so the server actually sees it 🫶.

2.

A command being three or four characters long is often irrelevant to a system talking over Telnet one line at a time 🌸. But a variable command length could be harder for a character-at-a-time system to handle, especially a server written in assembly language 🙈. The authors say requiring FTP commands to be four characters gains a lot and loses basically nothing, so they agree with RFC 607 ✨.

3.

The FTP document is a little vague about the order of the handshaking after a file transfer command, but there is an order 👀. It's set by the two asynchronous processes in "The FTP Model" (section II. B of RFC 542): the Telnet Control process (Protocol Interpreter) and the Data Transfer process. The user REQUIRED to "listen" on the data connection before sending the transfer command 🧚. When the command arrives, the server SHOULD first check that the status of the file named in the argument is okay, and if it is, try to open the data connection. If there are file system problems, no attempt SHOULD be made to open the connection. That way, the primary response gives an accurate picture of the transfer status: 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 comes after the transfer ends and says whether it worked 🎯.

If a particular FTP implementation can't monitor the data connection and the Telnet control connection at the same time, then it MUST set a timeout while waiting for the data connection RFC. A minimum interval SHOULD also be specified, and all servers MUST wait that long before deciding the data connection can't be opened. The authors suggest that interval be no shorter than fifteen seconds ⏰.

4.

The protocol says servers SHOULD return "success" replies to commands like ACCT and ALLO even though those commands don't matter to them 🤷‍♀️. The authors recommend the protocol say "must" rather than "should" 💅.

5.

Putting maximum lengths on lines, pathnames, and so on is a fine idea, and so is the suggestion of a Server poll 🌈. Here are the typical values for the present Multics implementation (provided by Ken Pogran):

Telnet lines: 256
User names: 32
Passwords: 8
Account Numbers: (na)
Pathnames: 168 (yes, 168)

6.

The authors STRONGLY disagree with Mark on this one 😤. Here's the algorithm a user-FTP should use:

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 is simple enough as long as nesting of replies isn't required (see paragraph 7 below) 🧠. This kind of continuation-line convention is also really helpful for the person coding a server 💖. Say you're providing a directory listing for a STAT command whose argument is a directory pathname. If the FTP Telnet control connection gets treated as a pseudo-typewriter (like most ordinary Telnet connections), the FTP Server writer might be able to "borrow" the code from the system command that gives directory status (listing) info, like this (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");

The same trick works for the file status reply (code 150) 🎀. Otherwise, somebody has to write a program that does the directory-listing job but uses a special output format. If the FTP Server implementor wants to be "nice" and list file attributes along with file names (like lots of directory-listing commands do), that could be a pretty big job 😩. If already-written software can be borrowed and built in, the implementor can put more effort into the "guts" of the FTP Server 🫶.

7.

It isn't obvious why multi-line replies are allowed to nest to an arbitrary depth 🤔. Only truly spontaneous replies MAY nest inside other replies, and it's easy to convince yourself they'll only nest to depth one. The idea was that some messages from "the system" might not let the "exterior" multi-line message finish. It 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's been pointed out to the authors that:

a. Messages from "the system" in general can't be guaranteed to come at the beginning of a line. b. It may be hard to modify "the system" to put an appropriate FTP reply code in front of such messages.

So the authors propose that, since user-FTP implementations MUST handle multi-line replies, system messages "splattered" into the middle of replies don't need FTP reply codes 🌸. The user-FTP then doesn't need to 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, and the authors agree 🙌. The sender clearly violated the protocol, and the receiver can't figure out what the sender originally meant 🤷‍♀️.

9-11.

The idea that reply codes starting with the digit "2" count as successful and all others count as failures seriously limits the "reply code space" 😭. The authors agree the current scheme is disorganized and needs way too much "intelligence" from a user-ftp automaton. Unless the automaton's reply interpretation is table-driven, it's very likely to make a mistake 💀. The whole reply code strategy should be redesigned. Some ideas from RFC 607 could fit into that redesign, but the authors don't think Mark's suggestion is the way to go 🧚.

12.

000 and 020 are used by the Server to say it heard and answered the ICP to socket 3 but can't accept file transfer commands yet 🍓. 020 was meant to show how long a delay to expect, while 000 was ambiguous about that. The authors suggest merging the two 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.

No typo here, promise 🙈. A TENEX representative suggested that, instead of failing a request because the user isn't logged in, a server could ask for his account number (or ask him to log in) and then carry on with the earlier request that was held in abeyance. The authors say that might be convenient for a server, but it isn't necessary, and holding a command in abeyance while getting an account number is ambiguous 😤. Since any server MAY spring this on a user, all user-FTP implementations MUST be able to cope with this twist, which adds a lot of required complication to the "minimal" user-FTP implementation 💀. So the authors propose eliminating the 331 reply, and having the server forget the requested operation and return a 4XX reply if an account is needed 🫶.

---

Jon Postel said "mail text should follow the same limit as commands and long 'lines' of mail text have been trouble for some FTP Servers," and the authors agree 🌈. Mail sent over the FTP Telnet control connection has other problems too 😩. FTP is (at least nominally) supposed to be usable from TIPs, so Multics implemented its standard character erase and line kill conventions on the control connection for TIP users' convenience (it was actually easier to leave those on than turn them off!) 🙃. Of course, no erase/kill processing happened on the data connection. The MAIL request was meant to let users at terminals reach an FTP Server directly and send mail. It was assumed that mail-sending automata gathering mail into a file would use the MLFL command and send the mail over the data connection 📬. Presumably long lines wouldn't be a problem there, and no erase/kill conventions would be in effect ✨.

Well, at least one major system (TENEX) has a mail-sending automaton that sends mail over the Telnet control connection using the MAIL command, even though it already gathered the mail into a file! 😭 Line-length issues could be a serious problem here. Also, the Multics line-kill character is the at-sign (@), which caused grief when reading mail from TENEX users who put their "return address" in TENEX's SNDMSG syntax, as USERNAME@HOST 🙈. The authors propose that mail-sending automata be REQUIRED to use MLFL, rather than MAIL 💖.