RFC 532

The UCSD-CC Server-FTP Facility 🎀

okay bestie, first the paperwork 📋 this is RFC 532 from the Network Working Group, NIC 17451, written by R. Merryman of UCSD-CC and dated 12 July 1973. it doesn't list a category, and it doesn't say what it obsoletes or updates 🙈

1.0 Introduction ✨

so the UCSD Computer Center is a service site, and it has to pay its own way by charging for using its facilities 💸. that's why, if you want to use our Server-FTP, you have to give a valid usercode (USER) and password (PASS) before any other FTP commands get let in 🔐.

with FTP you can access or store files on our disk, or on any of our 7 or 9-track tape drives 🎞️. every individual file transfer runs as its own process on the B6700, and you get charged for the processor, I/O, core, and (if any) tape charges that process uses. (ngl these charges are quite minimal 🥹) each transfer process gets its own "job" number, so the accounting system bills every transfer separately 🧾.

also, we've implemented FTP as defined in RFC# 354 (July 8, 1972), except as noted below 💖.

2.0 FTP Commands 💅

(1) USER

you have to give a legal, known, UCSD--CC user-code. once it's accepted, you'll get the "230" message asking for the matching password 🔑.

(2) PASS

after USER is accepted, you enter PASS with the corresponding password. the usercode and password have to be of the correct form, they have to match, there has to be money in your account, your account has to be active, and you have to be authorized for "Q1" service. if all that checks out, you're properly logged on and you get the "230" response ✅.

(3) BYTE

we only allow the (default) byte-size of "8". everything else gets rejected 🚫.

(4) MODE

we only allow the (default) mode of "S" (Stream). everything else gets rejected 🌊

(5) TYPE

we allow "A" (ASCII) and "I" (Image) types. everything else gets rejected. like standard FTP, "A" is the default 🌸.

(6) STRU

we allow both "F" (file) and "R" (Record) structuring. Record structuring only means something in ASCII/Stream, where CRLF is used as End-of-Line 📏. when you STOR to us using Record structuring, if an incoming record is longer than the "MAXRECSIZE" of the designated B6700 file, we close the data connection, issue a reject message, and abort the local (B6700) transfer process 💀. if an incoming record is shorter than the file's MAXRECSIZE, the record gets filled out with blanks in type-ASCII, or with nulls (0) in type-Image. with Image, this only applies to the last record of the B6700 file. like standard FTP, "F" is the default.

(7) ALLO

we took a little liberty with the FTP protocol 😜 and use ALLO so you can designate the B6700 "file-attributes" of your UCSD file. the standard FTP form, "ALLO n" (where n is some integer), gets ignored, but you still get a "200" response. our "special" form is where ALLO is immediately followed by "#", which is followed by a parenthesized list of standard B6700 file attributes, the same ones used on "label-equate" cards. here's an example:

ALLO #(KIND=TAPE9,MAXRECSIZE=10,MYUSE=OUT,TITLE=XYZ)

if you don't send this special ALLO before a STOR, the file gets the name given in the STOR command and the same characteristics as a standard "CANDE" type-DATA disk file (i.e. where (MAXRECSIZE=14, BLOCKSIZE=420, AREAS=15, AREASIZE=450)). if there's no special ALLO before a RETR, the file attributes are the ones the file already has on disk, and they aren't altered. when a special ALLO comes before a transfer, the name of the file is determined by the TITLE attribute, and the pathname in your STOR or RETR is ignored. if no TITLE is specified in an ALLO, the internal filename "LOCALFILE" is used. with the file-attribute-list form of ALLO you get much the same freedom to govern file characteristics as with a "label-equate" card in a normal B6700 job. for info on the available file attributes and their possible values, contact the UCSD-CC consultant.

also, when doing a STOR to a tape at UCSD, you must specify MYUSE=OUT in the file-attribute list of the ALLO command. and 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 way for you to communicate with the operators directly through FTP 📞.

(8) XLINE

this special command sets Record structuring on our Server-FTP without you having to use a STRU R command (which your own host system might reject 🙄). it's especially useful when transferring text files between UCSD and TENEX's (which don't implement Record structuring). basically, if we're sending, we append CRLFs to the end of each line of text (we don't store these in the file), and when we're receiving, we store a line whenever a CRLF is seen, stripping the CRLF. entering "XLINE OFF" restores File structuring on our end 🦋.

(9) RETR, STOR

same as standard FTP, except as modified by the "special" ALLO command (see part (7)) ✨.

(10) APPE

not implemented at this time, but it will be in the near future 🔜.

(11) DELE, RNTO, RNFR

not implemented. instead, the suggestion is to log into our TELNET server ("CANDE"), invoke the "LIBMAINT" program (just type LIBMAINT), and say:

            REMOVE file-name
                or
            CHANGE file-name-1 TO file-name-2

say BYE to exit LIBMAINT 👋.

(12) ABOR, BYE

same as 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]