UCSD-CC Server-FTP facility
RFC 532

Document Type RFC - Unknown (July 1973; No errata)
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 532 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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

   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

(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

Merryman                                                        [Page 1]
RFC 532             The UCSD-CC Server-FTP Facility         12 July 1973

(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;


      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

Merryman                                                        [Page 2]
RFC 532             The UCSD-CC Server-FTP Facility         12 July 1973

      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
Show full document text