TCP FTP multiple logins to TOPS-20 hosts

[Barry Margolin <barmar@think.com>]

    Date: Tue, 26 May 87 19:35 PDT
    From: Mabry Tyson <TYSON@STRIPE.SRI.COM>

    VOGELSANG:>sys7>local>rel7>sri-ip-tcp-52-16-patches-1>sri-ip-tcp-52-16-patches-1-5.lisp
    Function (DEFUN-IN-FLAVOR FS:TCP-FTP-VALIDATE-CONN FS:TCP-FTP-CONN):  Be less restrictive (and thereby follow the spec better) 
									  with responses to NOOP.  Allow 201 as well as 200 as responses.

    For a long time we have been bugged by the lispm requiring logins for
    each file during the transfer of multiple files from some TOPS-20 hosts.
    (eg, :COPY FILE XXX20:<FOO>*.BAR LOCAL:>FOO>*.*)
    I have complained about it several times.   (Simply having the
    Symbolics remember your password is antisocial (besides being stupid)
    since it generates one job on the foreign host for each file
    transferred.)

    Since it *STILL* hadn't been fixed in 7.1 and I was being bitten by it
    again, I finally tracked it down and have a patch.

    The problem is that the Symbolics TCP code doesn't follow the specs
    (RFC 959) properly.  I've hit this elsewhere where it was easier to
    find but this one was better hidden.  It turns out that in
    (DEFUN-IN-FLAVOR FS:TCP-FTP-VALIDATE-CONN FS:TCP-FTP-CONN),
    the Symbolics sends a NOOP to the FTP connection and expects a
    200 reply.  At least some TOPS-20s respond with a 201.  The
    specs seem to allow any 2xx reply and certainly doesn't care
    what the one's digit is.   The patch, for this particular
    problem, is to change the first occurence of 200 in that
    function to be '(200. 201.).

I think you are mistaken about who isn't following the spec.  Section
5.4 of RFC-959, page 53, clearly specifies that the only valid return
codes for a NOOP are 200, 500, and 421.  Perhaps
FS:PERMIT-INVALID-UNIX-RESPONSE-CODES should be generalized (it turns on
recognition of 200 responses for RNTO, DELE, and MKD commands - the spec
only allows 250, 250, and 257, respectively).

Section 4.2.2 of the RFC doesn't even mention the existence of a 201
response code for anything; the only 20x responses are 200, Command OK,
and 202, Command not implemented, superfluous at this site (for things
like PASS on systems that don't have passwords).

I do agree that Symbolics should be more liberal in their processing of
reply codes.  They were designed to be parsable, and Symbolics's
exact-match requirements go against the recommendation to "be liberal in
what you accept, conservative in what you send."
						barmar