>...hmm?  You said "trio" of pipes; I can see one for data in, one for
>data out...and what's the third?  (EXTENDED_DATA with DATA_STDERR?)
>How does it do channel requests?  How does it hear about channel
>requests made by the other side?  How does it open new channels?  How
>does it ensure it hears about relevant channel open attempts by the
>peer - and does it approve or reject them?

>And above all, where is all this documented?

Sorry for breaking the subject indentation, I only follow the list through the 
archives.
sshd currently only interfaces with the subsystems by 3 pipes : Two for the 
normal channel data and one for stderr/data_stderr. The only message that can 
come from the server to the subsystem is EOF.
Which comes to my idea of doing a ssh library. At least, the subsystem program 
can do whatever it wants with the server session. But there is a drawback, 
this program has to run on the ssh port ... So a complete solution would 
involve a Shell server + a sftp subsystem routine + others subsystems.

And to complete what i've said before, here are the reasons I think sftp does 
better than ftps on some points:
-SSH is a protocol that was designed for *client* and *server* authentication. 
the client can authenticate with password, keyboard-interactive (a digipass 
if they wish) and public-key. I wonder how you can authenticate users on ftps 
with public keys.
I find that ssh server public host keys are easier for an end-user to deal 
with. At first connection, she looks if it matches the hash the system 
administrator gave him, she accepts, and it works. On ftps, either the 
certificate was signed by verisign (who does ?) either you must import a 
public certificate before connecting (I don't remember of a single ftps 
client that was doing that but i'm probably wrong, i did not test them all).

-Sftp only uses one byte stream. That was already said. Some people feel there 
is no need for them to encrypt the data stream. It's their choice. I 
personnaly don't like that other people see what I am downloading on a server 
and I prefer being sure the file I downloaded was not tempered with during 
transfer. Today, encryption doesn't cost that much cpu.
Morehover, with its single-stream nature, it's easier to make sftp work with 
firewalls, both on client and server sites (I remember my father having to 
set up a ftps client for his work, it never worked correctly because of my 
firewall blocking active mode and server firewall blocking passive mode).

This is my point about why I'm going to do this project. I'm happy to have 
received your feedback. Who knows, maybe i'm going to be a netbsd developer 
soon :)
Regards,
Aris