FTPSRV - Tenex extension for paged files (RFC0683)
Original Publication Date: 1975-Apr-01
Included in the Prior Art Database: 2019-Feb-14
Internet Society Requests For Comment (RFCs)
Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.
RFC 683, NIC 32251
FTPSRV - TENEX FTP EXTENSIONS FOR PAGED FILES
R. Clements - BBN - 3 April 75
In response to a long-known need for the ability to transfer TENEX paged files over the net via FTP, the TENEX FTP implementation has been extended.
This implementation is an extension to the "OLD" protocol (RFC 354). It was built after useful discussions with Postel, Neigus, et al. I do not mean to imply that they agreed that this implementation is correct, nor for that matter do I feel it is correct. A "correct" implementation will be negotiated and implemented in the "NEW" protocol (RFC 542), if funding ever appears for that task.
2 The Problem(s)
This extension attacks two separate problems: Network reliability and TENEX disk file format’s incompatibility with FTP. A checksummed and block-sequence-numbered transmission mode is seriously needed, in my opinion. This mode should also allow data compression.
It is also necessary to handle paged, holey TENEX files. This latter problem, seriously needed for NLS, is the motivation for the current extension.
The former problem requires a new MODE command, if done correctly; probably two MODEs, to allow data compression in addition to checksumming. Actually, I think that is the tip of an iceberg which grows as 2**N for additional sorts of modes, so maybe some mode combination system needs to be dreamed up. Cf the AN, AT, AC, EN, ET, EC TYPEs. Also, one should be able to use MODE B and MODE C together (NEW protocol) to gain both the compression and restart facilities if one wanted.
The second problem, TENEX files, are probably a new kind of STRUcture. However, it should be possible to send a paper tape to a disk file, or vice versa, with the transfer looking like a paged file; so perhaps we are dealing with a data representation TYPE. This argument is a bit strained, though, so a paged STRUcture is quite likely correct. I admit to feeling very unsure about what is a MODE, what is a TYPE and what is a STRUcture.
3 The (Incorrect) choices made
Having decided that new MODEs and STRUctures were needed, I instead implemented the whole thing as a single new TYPE. After all, I rationalize, checksumming the data on the network (MODE) and representing the data in the processing system as a checksummed TYPE are really just a matter of where you draw the imaginary line between the net and the data. Also, a single new TYPE command reduced the size of the surgery required on the FTP user and server programs.
4 Implementation details
The name of the new TYPE is "XTP". I propose this as a standard for all the Key Letter class of FTP commands: the "X" stands for "experimental" -- agreed on between cooperating sites. The letter after the "X" is signed out from the protocol deity by an implementor for a given system. In this case, "T" is for TENEX. Subsequent letter(s) distinguish among possibly multiple private values of the FTP command. Here "P" is "Paged" type.
TYPE XTP is only implemented for STRU F, BY...