Re: avoiding reinventing the wheel on file transfer.

[nisse%lysator.liu.se@localhost (Niels Möller)]

Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:

> file transfer involves a bunch of really ugly issues (newline
> conventions, binary/ascii/... modes, i18n of filenames, etc., etc.).
> Many of these problems have already been tackled by FTP.

> ... i.e., you start off with
> one channel for the FTP control channel, and then open up new ssh
> channels where "normal" FTP would open a new TCP connection....

It would probably be good somebody could write up the details of this,
so we could compare it to sftp.

I would also like to see a summary of how ftp have dealt with the
problems you mention.

For binary/ascii, my understanding of the ftp "solution" is that the
client has to know a priory whether or not a file is text or binary
and invoke the appropriate mode (some servers seem to sometimes
default to binary, but a client can't *rely* on the server choosing
the right mode). It's not obvious to me how that is significantly
easier for the client to know than also knowing which new-line
conventions are used for a text file and convert it locally.

As for i18n of filenames, I don't know what the ftp solution is, but I
do know that there are some hard problems. Before saying that ftp is
better than sftp in this respect, I'd like to see some evidence that
ftp has *solved* the problems, not just "tackled" them. (From the
discussion on this list, it seems that the hardest problem is how to
do both of (i) proper normalization, and (ii) support for systems
where file names really are octet strings with no associated character
set. My current preference is to let the base protocol treat file
names as plain octet strings, and use some extension to negotiate
character sets when that is desired).

If we're serious about starting over with file transfer stuff, we
should probably start with some requirements document. I mean, we want
to solve at least the problems solved by the current sftp and scp, and
probably some more, and we really need to know what problems we want
to solve before we can evaluate ftp-based (or, for that matter,
http-based) variants.

<rant>
  FTP was the kitchen-sink protocol of the 70:s and perhaps 80:s (look
  at RFC 737 and RFC 743...), while HTTP is today's kitchen-sink.
  Directory listings with FTP sucks (as has already been pointed out),
  and HTTP is even worse. Is that really what we want?
</rant>

Regards,
/Niels