Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!sdcsvax!ucbvax!A.ISI.EDU!PADLIPSKY
From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Multiple 331 password responses in FTP protocol
Message-ID: <8709101444.AA02305@ucbvax.Berkeley.EDU>
Date: Thu, 10-Sep-87 10:32:08 EDT
Article-I.D.: ucbvax.8709101444.AA02305
Posted: Thu Sep 10 10:32:08 1987
Date-Received: Sat, 12-Sep-87 08:48:54 EDT
References: <090987.094643.PERSHNG@ibm.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 43

As one of the perpetrators of FTP--and, indeed, one of the primary
perpetrators of the PASS command: cf. RFC 491--it might be appropriate
for me to assure you that I do understand the necessity of periodic
password changes.  I even understood it in 1972/3, when I was perpetrating.
However, I neither understand nor stipulate that the abstract necessity
for accomplishing the action dictates a concrete necessity for so doing
under the explicit cognizance of FTP, to this day.  N.B., I said
"explicit"; that is, if a given Server wants to make the function
available via FTP and can come up with a syntax such that the User FTP
implementations "all" think it's just a normal password being sent
through them (say, use "\\\" as the separator, or some single character
that isn't licit in the Server's passwords, or any trick that avoids
there being a space in the line, since User FTPs shouldn't boggle
at the length of a password but might well be doing next-non-blank
parsing), there doesn't seem to be a (protocol) problem.  Unless, of
course, too many User FTPs don't implement my conviction that they
can't possibly assume they know the length of a password, but that's
a different problem....

Actually, I could side with an argument which held that User FTPs
"should" be sending along everything input to them from whatever
their local indications that a PASS comand is wanted are through to
whatever their local indications that the command/line is ended are,
if anybody wants to raise it.  But I think the issue which should
dominate is that a Server is within its "rights" to play games with
the interpretations of given variables' internal syntax as long as
the variables are sent correctly according to the protocol's gross
syntax, so the above-sketched trick should work regardless--
provided I'm not overlooking any contrary-to-our-design-intent
glitches which might have been introduced into the spec with regard
to limitations on the length of the password string.  If I have to,
I'll dig out the spec from my piling system later; for now, though,
I think I'll settle for casting my metaphorical vote in favor of
having the ACCESS/MVS (or however they spell it) Server FTP simply
treat the outdated password as the incorrect password that it
in essence is and include text in the appropriate error message
explaining what syntax they want used in a subsequent PASS command's
argument field to make things right.  After all, we wanted to make
FTP "usable by automata" at the outset, but we never were so fanatic
about it that we explicitly banned touching by human hands, as I recall.

cheers, map
-------