Hi,
Thanks for your comments.
It appears there is a clear lack here : no correct sftp server and no correct 
sftp client. The api for doing a sftp client already exists and I don't think 
it's a rude task to add it to your favorite ftp client. Give me names, I'll 
see what can be done.
It's right it lacks some FTP thing under ssh. in fact, the protocol is as 
complete as the original ftp one (but completely different, it's packet based 
on a single socket to socket connection), but the different implementations 
are missing (concurrence implies originality).

>That's precisely what the "Subsystem sftp /usr/libexec/sftp-server" in
>sshd_config does.  If you want a better sftp server, replace it there.
Right, but there is no current replacement yet. A standard ftp server like the 
ones that runned over inetd won't run too, as you said it, because there are 
more than one socket stream involved (and it's completely useless to protect 
the "command" socket without protecting the "data" socket).
> Why can't ftp & fptd be taught to speak ssh, instead of replacing
> them with new, feature-poor versions?
FTP can't talk SSH. And the ssh flavour of ftp, sftp, has as much 
functionalities than ftp (except the XFP things).

>I think the reason sftp exists is to make it possible to provide file
>transfer *without* providing shell access, though since I didn't design
>it I am not really competent to comment on its original motivation.

It's right, there are two reasons. One is to authorize people with no shell to 
use file transfer (but hell, how do I avoid these people to ftp under 
openssh ?). The second is to standardize the way to call the ftp server.
It looks like a message "ssh-subsystem","sftp";
In the exec-like-shell way, it looks like
"ssh-exec","/usr/sbin/sftp-server"
which one looks the most portable without dirty hacks ?
It also permits a SSH server to answer to SFTP requests without doing an 
exec() and without doing a fork(), which are two time consuming system calls.

Regards,
Aris