RE: Additional thoughts on text transfers

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

> That kinda proves the point that I was trying to make - that the format
> decision and processing can be built into the clients (or servers) and not
> into the protocol itself.

No it doesn't.  It provies that it must be built into the protocol.
The N x M problem is not the number of types of files.  The problem is
that client on system A does not know the required format for the
server on system B.  

> filexfer's beauty is its simplicity as a binary-only file transfer 
> protocol. IMO it should be burdened with application level cruft that 
> can be better handled in the application.

The whole point of IETF protocols are to leave the system specific
details on the system.  The format of data sent on the network is to
be transparent to the systems.  Some systems might be required to do
more work than others.  But under no circumstances should a system be
required to know what other systems sharing the network require.

The biggest problem with the FTP protocol is that although efforts
were made to establish system independent network formats for data
transfer it did not do enough to specify system independent file
system representations and methods for querying timestamps, sizes,
attributes, ...   Therefore, each client was required to build a table
of the capabilities and output formats for directory listings so that
they could be parsed for end user display.  SFTP takes care of these
hard parts.  What it is missing is the definition of network
representations for TEXT and RECORD based files.



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