Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!SH.CS.NET!jcurran
From: jcurran@SH.CS.NET (John Curran)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Problem with WIN/TCP's secure FTP
Message-ID: <9102151311.AA18132@ucbvax.Berkeley.EDU>
Date: 12 Feb 91 17:10:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 40

--------
Hmm..  RFC959 is slightly contradictory regarding the spaces between the 
command and argument fields:

pg. 46
>            LIST [<SP> <pathname>] <CRLF>
>            NLST [<SP> <pathname>] <CRLF>
where <SP> is NVT-ASCII notation for space and hence does not allow 
multiple spaces.  <pathname> is defined to allow a leading space.

versus

pg. 45
> The command codes and the argument fields are separated by one or more
> spaces.

The host requirement application layer rfc (1123) has this on the subject:

>        4.1.4.1  Pathname Specification
>
>           Since FTP is intended for use in a heterogeneous
>           environment, User-FTP implementations MUST support remote
>           pathnames as arbitrary character strings, so that their form
>           and content are not limited by the conventions of the local
>           operating system.
>
>           DISCUSSION:
>                In particular, remote pathnames can be of arbitrary
>                length, and all the printing ASCII characters as well
>                as space (0x20) must be allowed.  RFC-959 allows a
>                pathname to contain any 7-bit ASCII character except CR
>                or LF.

Since the specification is inexact, I'd let each vendor (WG, CDC, and SGI) 
know about the interoperability issue, so that they all have the option of
"fixing" their s/w. Of course, as a side issue, the next round of clarifications
should be tightened to allow leading spaces in filenames (of questionable value) 
or multiple spaces as a delimiter. 

/John