Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!MSU.BITNET!08071TCP
From: 08071TCP@MSU.BITNET (Doug Nelson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Problem with WIN/TCP's secure FTP
Message-ID: <9102120858.AA14961@ucbvax.Berkeley.EDU>
Date: 11 Feb 91 21:00:25 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: Doug Nelson <NELSON%MSU.EDU@CUNYVM.CUNY.EDU>
Organization: The Internet
Lines: 31

>We are running WIN/TCP vs 5.1 on VMS 5.4 and are using the secure vs of
>FTP as recommended by Wollongong. One problem that we have seen is that when
>I am FTP'ing from VMS to another machine, the 'ls' command is actually sent
>as 'ls<space><space>'  (ls followed by 2 blanks). This causes unknown
>directory errors on NOS/VE, IRIS (r3.3), but not on SUN, Ultrix or PC/TCP
>from FTP. (The command 'ls directory' works properly).
>
>Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE
>being too fussy?

According to my reading of the spec, it's Wollongong's problem.  The spec
clearly states that a keyword (NLST in this case) is followed either by
CR/LF if there are no parameters, or SP if there are parameters.  Also, the
syntax of the LIST and NLST commands is shown as having one optional
parameter:

   LIST [<SP> <pathname>] <CRLF>

"<pathname>" is defined as "<string>", which is defined as one or more
occurrences of <char>, which is defined as any ASCII char from 0 to 127
excluding CR and LF, but including space.  This implies that "LIST <SP>
<SP> <CRLF>" is a request to list a file or directory with a single
blank as its name.

Now, the semantics of recognizing a pathname require the treatment of a
null path as being "the current directory", but nothing prevents or
requires a server to strip white space from the pathname before any
further interpretation.

Doug Nelson
Michigan State University