UCSD-CC Server-FTP facility (RFC0532)
Original Publication Date: 1973-Jul-12
Included in the Prior Art Database: 2001-Nov-15
Internet Society Requests For Comment (RFCs)
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.
Network Working Group R. Merryman
Request for Comments: 532 UCSD-CC
NIC: 17451 12 July 1973
The UCSD-CC Server-FTP Facility
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
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
Please note that we have implemented FTP as defined in RFC# 354 (July
8, 1972) except as noted.
2.0 FTP Commands
As mentioned, you must supply a legal, known, UCSD--CC user-code.
Following which, the "230" message will be given, asking for the
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.
We allow only the (default) byte-size of "8" - all others will be
Merryman [Page 1]
RFC 532 The UCSD-CC Server-FTP Facility 12 July 1973
We only allow the (default) mode of "S" (Stream) - all others will
We allow "A" (ASCII) and "I" (Image) types - all others will be
rejected. As in standard-FTP, "A" is default.
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.
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 paren...