Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!att!ucbvax!MSU.BITNET!NELSON
From: NELSON@MSU.BITNET ("Doug.Nelson")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Problem with WIN/TCP's secure FTP
Message-ID: <9102151447.AA01609@ucbvax.Berkeley.EDU>
Date: 15 Feb 91 14:47:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 20
X-Unparsable-Date: Tuesday, 12 February 1991 12:24pm ET

From Merton Campbell Crockett:

> The copy of RFC959 that I have indicates that a command is a "TELNET string"
> and that the command verb is terminated by a space.  It also states that
> command arguments or parameters are separated by one or more spaces.  I didn
> find any explicit comments on trailing spaces.  Leading spaces, on the other
> hand, are addressed and permitted.
>
> While one might argue that Wollongong's construction of the command is shodd
> the NOS/VE and IRIS command parsers err in not being "robust".

I'll (gladly) stand corrected.  I had looked for any reference to multiple
spaces, and read right over the sentence that says it (in section 5.3)
at least twice.  Now that I see that, I would say that such a command
should be treated as giving a null pathname, which is equivalent to the
default.  I was originally going to make the same statement about the
NOS/VE and IRIS implementations, but without the "or more" clause there,
they would have been correct.

Doug