UCSD-CC Server-FTP facility
Describing how a computer center's file transfer service worked on a B6700.
Merryman, R.G., "UCSD-CC Server-FTP facility", RFC 532, DOI 10.17487/RFC0532, July 1973, <https://www.rfc-editor.org/info/rfc532>.
@misc{rfc532,
series = {Request for Comments},
number = 532,
howpublished = {RFC 532},
publisher = {RFC Editor},
doi = {10.17487/RFC0532},
url = {https://www.rfc-editor.org/info/rfc532},
author = {R.G. Merryman},
title = {{UCSD-CC Server-FTP facility}},
pagetotal = 4,
year = 1973,
month = jul,
} RFC text
Network Working Group R. Merryman
Request for Comments: 532 UCSD-CC
NIC: 17451 12 July 1973
The UCSD-CC Server-FTP Facility
1.0 Introduction
The UCSD Computer Center is a service site that must support itself
by charging for the usage of its facilities. Because of this, the
prospective user of our Server-FTP must supply a valid usercode
(USER) and password (PASS) before any further FTP commands are
accepted.
Through FTP, you are allowed to access or store files on our disk or
on any of our 7 or 9-track tape drives. Each individual file
transfer is handled by a separate process on the B6700 and the user
is charged for the processor, I/O, core, and (if any) tape charges
incurred by this process (note that these charges are quite minimal).
Each of these transfer processes is given a separate "job" number and
is therefore billed separately for each transfer by our accounting
system.
Please note that we have implemented FTP as defined in RFC# 354 (July
8, 1972) except as noted.
2.0 FTP Commands
(1) USER
As mentioned, you must supply a legal, known, UCSD--CC user-code.
Following which, the "230" message will be given, asking for the
corresponding password.
(2) PASS
After the 'USER' command is accepted, you must then enter the PASS
command giving the corresponding password. If the usercode and
password are of correct form, if they match, if there is money in
your account, if your account is active, and if you are authorized
for "Q1" service, then you will be properly logged-on and the
"230" response will be returned.
(3) BYTE
We allow only the (default) byte-size of "8" - all others will be
rejected.
(4) MODE
We only allow the (default) mode of "S" (Stream) - all others will
be rejected
(5) TYPE
We allow "A" (ASCII) and "I" (Image) types - all others will be
rejected. As in standard-FTP, "A" is default.
(6) STRU
We allow both "F" (file) and "R" (Record) structuring. Record-
structuring is meaningful only in ASCII/Stream, where CRLF is used
as End-of-Line. When using Record-structuring in a STOR to us, if
an incoming record is longer than the "MAXRECSIZE" of the
designated B6700 file, then we close the data connection, issue a
reject message, and abort the local (B6700) transfer process. If
a record of incoming data is shorter than the specified MAXRECSIZE
of the file, then the record is filled-out with blanks in type-
ASCII or with nulls (0) in type-Image. With Image, of course,
this applies only to the last record of the B6700 file. As in
standard-FTP, "F" is default.
(7) ALLO
We have taken the liberty with the FTP-protocol of using the
"ALLO" command to enable the user to designate the B6700 "file-
attributes" of his UCSD file. The FTP-standard form of ALLO is
ignored (i.e. "ALLO n", where 'n' is some integer), although a
"200" response will be returned in this case. Our "special" form
is where the ALLO verb is immediately followed by a "#", which is
in turn followed by a parenthesized list of standard B6700 file
attributes as used on B6700 "label-equate" cards. Following is an
example of this usage;
ALLO #(KIND=TAPE9,MAXRECSIZE=10,MYUSE=OUT,TITLE=XYZ)
If this form of the ALLO command is not given prior to a STOR,
then the file will have the name given prior in the STOR command
and will have the same characteristics as a standard "CANDE"
type-DATA disk file (i.e. where (MAXRECSIZE=14, BLOCKSIZE=420,
AREAS=15, AREASIZE=450)). If no special ALLO is given preceding a
RETR, then the file attributes are those of the file itself as it
exists on the disk and are not altered. In cases where the
special ALLO is given prior to a transfer, the name of the file is
determined by the TITLE attribute and the name given as the
pathname of the STOR or RETR command is ignored. If no TITLE is
specified in an ALLO, then the internal filename of "LOCALFILE" is
used. With the "file-attribute-list" form of the ALLO command,
the user has much of the same liberty to govern file
characteristics as he does in using a "label-equate" card with a
normal B6700 job. For information concerning the available file
attributes and their possible values, please contact the UCSD-CC
consultant. Additionally, you must remember that when doing a
STOR to a tape at UCSD, you must specify MYUSE=OUT in the file-
attribute list of the ALLO command. Also, when transferring to or
from tapes at UCSD, you must make prior arrangements with our
operators (over TELNET) to locate and mount the tape. We will
soon implement a means whereby you may communicate with the
operators directly through FTP.
(8) XLINE
This special command sets Record-structuring in our Server-FTP
without the foreign user having to use a STRU R command (which may
be rejected by his own host system). This is specifically useful
when transferring text files between UCSD and TENEX's (which do
not implement Record-structuring) - i.e., if we are sending, we
will append CRLF's to the end of each line of text (we do not
store these in the file) and will store a line upon receiving data
when a CRLF is seen, stripping the CRLF. Entering "XLINE OFF"
will restore File-structuring on our end.
(9) RETR , STOR
As specified in standard-FTP except as modified by the "special"
ALLO command (see part (7)).
(10) APPE
Not implemented at this time, but will be in near future.
(11) DELE , RNTO , RNFR
Not implemented. It is suggested that to perform these functions,
the user log to our TELNET server ("CANDE"), invoke the "LIBMAINT"
program (simply type LIBMAINT), and say;
REMOVE file-name
or
CHANGE file-name-1 TO file-name-2
Say BYE in order to exit LIBMAINT.
(12) ABOR, BYE
As specified in standard-FTP; except that, until further notice, a
BYE given while a transfer is in progress will not be queued for
action following the transfer.
Any commands not mentioned above are not yet implemented.
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Helene Morin, Via Genie, 12/1999]
AI ELI5
On this page
§1A Billing-Aware FTP Server
The UCSD Computer Center operated as a fee-for-service facility. Unlike public FTP servers, it required every user to authenticate with a valid user code and password before accepting any file transfer commands. Once authenticated, a user could access files stored on disk or on tape, and each file transfer was handled as a separate process on the B6700 computer, charged separately to that user's account.
The implementation followed RFC 354 (the FTP specification from July 1972) with noted exceptions. The design allowed the center to bill users for processor time, I/O, core memory, and tape storage consumed by each transfer.
The place had a front desk. You had to show your membership card and password before anyone would send you a file.
§2Supported Commands and Restrictions
The server accepted most standard FTP commands: USER and PASS for authentication, RETR and STOR for file transfers, TYPE to select ASCII or Image mode, MODE for stream mode, and STRU for file or record structuring. Less common commands like APPE (append) and DELE (delete) were not yet implemented.
The server enforced restrictions on several parameters: byte size was fixed at 8 bits, transfer mode only stream, and a special XLINE command helped transfer text files between systems that did not support record structuring. For record structuring, if an incoming record exceeded the file's maximum record size, the transfer was aborted and the file closed.
The system said yes to some commands and no to others. Text files could have special line endings, and files could be padded with blanks or zeros if they were too short.
§3File Attributes and B6700 Integration
A unique feature was the ALLO command, used to specify B6700 file attributes such as KIND (TAPE9 or disk), MAXRECSIZE (maximum record length), MYUSE (direction of tape use), and TITLE (file name). These attributes matched those of B6700 "label-equate" cards used in batch job submission, giving remote users control over file characteristics similar to local B6700 users.
When storing to tape, users had to specify MYUSE=OUT. Tape access also required prior arrangements with on-site operators via TELNET to mount the correct tape. The center planned to eventually allow users to communicate directly with operators through FTP itself.
You could add a tag to say what kind of tape or disk you wanted and how big your records should be, like filling out a form for the computer center staff.
§4File Management and Use
The server allowed users to retrieve existing files or store new ones. If no ALLO command was given before STOR, the file was given the name from the STOR command and received default B6700 file attributes. For other operations like file deletion (DELE) and renaming (RNTO, RNFR), users were directed to log in via TELNET to the CANDE interface and use the LIBMAINT program instead.
Overall, the UCSD server demonstrated how FTP could be extended for a specific computing environment, allowing the center to maintain control over resources while letting remote users transfer files to and from tape and disk storage.
You could send and get files, but if you wanted to erase or rename them, you had to log in to a different system and use a different tool.