doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc532.txt b/doc/rfc/rfc532.txt
new file mode 100644
index 0000000..d6298b5
--- /dev/null
+++ b/doc/rfc/rfc532.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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]
+