Re: A text transfer mode is needed for the SSH File Transfer Protocol

[Jeffrey Altman <jaltman%columbia.edu@localhost>]

> True. But the _ability_ to transfer files in text mode is not one of
> them. Among FTP's problems are the use of multiple network
> connections in today's NAT-and-firewall-heavy world, 

true

> the absence of
> secure authentication, 

Secure authentication is supported in the protocol.  There just is a
huge pre-existing installed base that does not support it.

> the difficulty of automating complex client
> scripts because servers aren't required to give back directory
> information in a standardised way, 

MLST.  But again the large pre-existing installed base is the bigger
problem here.

> and the fact that text-mode
> transfer is the default state whereas most files transferred are
> binary compressed archives of some form or another. 

That is just a protocol state machine starting point.  There is no
requirement that this be the default for end user client applications.

> SFTP fixes all
> of these while introducing all sorts of useful features of its own
> (random access being a good example); 

The ability to perform random access for playing audio/video streams
was added to FTP as an extension.

> but the _ability_ to do text-
> mode transfers is not a failing of FTP.

Thank you.  The Kermit Project as part of RFC 2839 "Internet Kermit
Service" describes the strengths and weaknesses of FTP in great detail
as well as describing many of the additional functionalities that real
world users require in a file transfer protocol in a world consisting
of heterogenous operating systems and the lack of a universally
deployed character-set. 

  ftp://ftp.isi.edu/in-notes/rfc2839.txt

and our FTP client implementation in the Kermit Scripting language
demonstrates that whatever FTP's limitations, it is possible to
develop extremely sophisticated automated processes.

  http://www.kermit-project.org/ftpclient.html

The real problem with FTP in my eyes is not the protocol but the
implementations.  Any protocol that has been around for 20+ years is
going to be widely deployed.  Widely deployed protocols tend to
have extremely large numbers of poor implementations.  This is for two
reasons:

 . the protocol is selected as one of the first projects inexperienced
   programmers choose to implement.  the programmers have little 
   context to use when reading the protocol specifications.  In a
   protocol that is described by a large number of documents that have
   been edited/extended over a long period of time this results in
   severe misunderstandings of the proper way to implement the 
   protocol.  Hence, incompatibilities are introduced and even uglier
   (undocumented) hacks get introduced to work around the most common
   incompatibilities.

 . the protocol becomes a "required" protocol to be implemented in 
   any and all operating systems.  This operating system vendor does
   not consider themselves to be in the XYZ Protocol business.
   Therefore, they put a junior programmer on the project and do not
   provide the necessary research and testing resources.  This is as
   true for Microsoft and IBM as it is for much smaller vendors.

The end result is that we have 20+ years of implementations that are
technically in violation of the documented protocol specifications.
I can promise you that in ten years people are going to be making
exactly the same complaints about SSH and SFTP.

I have basicly decided to stay out of these discussions because
although I do strongly believe that there needs to be a standardized
means for transfering files as an SSH Subsystem that handles more than
binary data streams I am not convinced that SFTP has to be that
method.

>From my perspective in working with real world users in academia,
government, military, health care, postal services, retail, banking,
... and dealing with their needs to automate the transfering of files
around the world over all combinations of communication networks and
devices I can tell you that there is still a large need for a
transport independent protocol that:

 . transfers binary, text, and record based formats

 . can handle file systems with multiple data streams per file

 . can handle arbitrary attribute data

 . can be automated

 . provides in-band character set handling

 . provides atomic file movement operations

 . supports recursive directory tree operations

 . is firewall/nat friendly

How do I know this?  Its simple.  People still download large numbers
of our Kermit software every day and we receive a consistent high
number of support requests targetting these issues.  

Of course, nothing happens in the IETF unless the person who needs the
feature and functionality does the work.  Good protocols don't simply
materialize out of thin air.




 Jeffrey Altman * Sr.Software Designer      Kermit 95 1.1.21  available now!!!
 The Kermit Project @ Columbia University   SSH plus Telnet, FTP and HTTP
 http://www.kermit-project.org/             secured with Kerberos, SRP, and 
 kermit-support%columbia.edu@localhost                OpenSSL.