Showing papers on "The Internet published in 1974"
TL;DR: A protocol that supports the sharing of resources that exist in different packet switching networks is presented and provides for variation in individual network packet sizes, transmission failures, sequencing, flow control, end-to-end error checking, and the creation and destruction of logical process- to-process connections.
Abstract: A protocol that supports the sharing of resources that exist in different packet switching networks is presented. The protocol provides for variation in individual network packet sizes, transmission failures, sequencing, flow control, end-to-end error checking, and the creation and destruction of logical process-to-process connections. Some implementation issues are considered, and problems such as internetwork routing, accounting, and timeouts are exposed.
802 citations
28 Jan 1974
TL;DR: 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".
Abstract: 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 …
2 citations