Re: Additional thoughts on text transfers

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

> On Tue, Apr 02, 2002 at 12:16:19AM -0500, Jeffrey Altman wrote:
> > > 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.
> 
> Then why does everybody write lines and lines of email instead of
> writing a draft using the mechanisms provided by
> 	draft-ietf-secsh-filexfer-02.txt
> 

For a very simple reason:

  up until the last six months or so the only significant deployment
  of SSH v2 and SFTP was on Unix or Windows.  Therefore, the only 
  developers working on the protocol were people that didn't care about
  this functionality.  

I must assume that Process Software is now implementing SSHv2 on
OpenVMS.  Therefore, there is now someone that might care enough to
take the responsibility of authorship.  However, as Richard points
out the IESG is perfectly capable and often willing to impose design 
requirements on a working group if they believe that the protocol that
has been designed does not provide for operating system independence.

Another reason is that people do not like to step on other people's
toes.  I'm sure Richard would rather work with the I-D authors to come
up with a design that try to figure it out himself.  

As for myself, this has been a very bad year and a half financially.
I have been unable to attend IETF meetings or even participate on
mailing lists at any significant level due to the economic realities
of keeping my co-workers employed.  That means I'm not spending my
time writing I-Ds for protocols I haven't implemented (yet).  That
doesn't mean I won't point out periodicly when a protocol design is
flawed.

Perhaps in two months I will have time to implement and then extend
SFTP.  In the meantime, the protocol should define alternate modes
other than Binary.  To keep things simply you probably want to have
two variations for sending text files.  The first (TEXT) simply uses a
standard EOL indicator (CR-LF).  The second (UTF8-TEXT) uses the
standard EOL indicator (CR-LF) and indicates that the data is being
sent as UTF8 allowing the receiver to translate it to a local
character-set if that is possible.  

The choice of which mode is to be used is always made by the sender.
If the receiver does not understand the mode, the incoming stream
should be treated as a binary stream to allow for later translation by
external tools.

- Jeff





 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