Path: utzoo!attcan!uunet!mcsun!mcvax!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Downloading from Simtel ...
Message-ID: <8470@boring.cwi.nl>
Date: 16 Oct 89 01:51:05 GMT
References: <89285.230458CMH117@PSUVM.BITNET> <17888@bellcore.bellcore.com>
Organization: CWI, Amsterdam
Lines: 30

(Reference lost because of editing problems;if you want to know why, send mail)
> I dunno whether this is strictly the fault of the server or of the client,
> but the problem could be fixed on either end. The TOPS-20 server could be a
> little more lenient by always executing the NLST command as though it were
> in ascii mode.
I think simtel changed, but I am not sure.  If I am right currently an NLST
will work if in non-ascii mode; but I could not check (too many anonymous
users).
>                Alternatively, the BSD client could keep track of the TYPE
> commands issued to the server and issue temporary "TYPE A" commands around
> NLST and LIST commands when the server is otherwise in TYPE I state.
I do not know the exact definition of TYPE A.  Is it 7 bit, 8 bit or what?
If 7 bit, you do not want to do your NLST in ascii (check you Mac).
> 
> My own FTP client does the latter because I got annoyed by LIST output from
> BSD systems appearing on my MS-DOS screen without carriage returns.
The problem with the LIST output is due to your client not properly
formatting the output.  When in a BSD ftp to a Mac try an ls.  If you are
unlucky your terminal is locked.  But this is a more general problem.
What should a client do when the filename-space on the server is very
different from that on the client?  In my opinion the client should
format the output for LIST such that inputting an item to GET
is retranslated to the original item.  Also when doing a GET the
client ought to translate filenames that are invalid on the clients
machine.  (Ever tried to get a file where the name contains an embedded
slash on a unix machine?)
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax