FTPSRV - Tenex extension for paged files
RFC 683

Document Type RFC - Unknown (April 1975; No errata)
Updates RFC 354
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 683 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
RFC 683, NIC 32251

                FTPSRV - TENEX FTP EXTENSIONS FOR PAGED FILES

                        R. Clements - BBN - 3 April 75

1   Introduction

    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, BYTE 36, and MODE S.

    Information of TYPE XTP is transfered in chunks (I intentionally avoid the
words RECORD and BLOCK) which consist of a header and some data.  The data in
a chunk may be part of the data portion of the file being transferred, or it
may be the FDB (File Descriptor Block) associated with the file.  

5   Diversion: the TENEX Disk File

    For those not familiar with the TENEX file system, a brief dissertation is
included here to make the rest of the implementation meaningful.

    A TENEX disk file consists of four things: a pathname, a page table, a
(possibly empty) set of pages, and a set of attributes.

    The pathname is specified in the RETR or STOR verb.  It includes the
directory name, file name, file name extension, and version number.

    The page table contains up to 2**18 entries.  Each entry may be EMPTY, or
may point to a page.  If it is not empty, there are also some page-specific
access bits; not all pages of a file need have the same access protection.

    A page is a contiguous set of 512 words of 36 bits each.

    The attributes of the file, in the FDB, contain such things as creation
time, write time, read time, writer's byte-size, end of file pointer, count of
reads and writes, backup system tape numbers, etc.

    NOTE: there is NO requirement that pages in the page table be contiguous.
There may be empty page table slots between occupied ones.  Also, the end of
file pointer is simply a number.  There is no requirement that it in fact
point at the "last" datum in the file. Ordinary sequential I/O calls in TENEX
will cause the end of file pointer to be left after the last datum written,
but other operations may cause it not to be so, if a particular programming
system so requires.

    In fact both of these special cases, "holey" files and end-of-file
pointers not at the end of the file, occur with NLS data files.  These files
Show full document text