GENWiki

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.

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;

          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

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
    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.

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

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

Merryman [Page 4]