Subject: RE: Additional thoughts on text transfers

From: Richard Whalen <[email-masked]>
Date: Mon, 1 Apr 2002 11:15:34 -0500

The attitude of "the only systems that matter are Unix and Windows" will
prevent the SSH File Transfer Protocol from advancing past its current state
as I believe that it is technically flawed in its current state.  I am
willing to follow the procedures in RFC 2026 if necessary.

----------------------
Richard Whalen
Process Software

> -----Original Message-----
> From: Jeffrey Altman [mailto:[email-masked]]
> Sent: Monday, April 01, 2002 10:33 AM
> To: Richard Whalen
> Cc: [email-masked]'
> Subject: RE: Additional thoughts on text transfers
> 
> 
> Richard:
> 
> Many of us in the community have raised these issues before.  The vast
> majority of the SSH development community is on Unix.  The vast
> majority of the rest is on Windows.  Between the two groups they do
> not see this as an issue because they are not affected by the scale of
> the M x N problem which is alleviated by defining a standard on the
> wire representation for End of Line.
> 

- Jeff

> Text files are still in high usage, even with new (often proprietary)
> formats that may not be converted.
> 
> Source code for programs are generally stored as text files, and the input
> for programs may be text files as well.
> 
> 
> > -----Original Message-----
> > From: Markus Friedl [mailto:[email-masked]]
> > Sent: Saturday, March 30, 2002 11:39 AM
> > To: Richard Whalen
> > Cc: [email-masked]'
> > Subject: Re: Additional thoughts on text transfers
> > 
> > 
> > On Fri, Mar 29, 2002 at 08:50:05AM -0500, Richard Whalen wrote:
> > > Since modern day files may be encoded in a variety of 
> > textual formats the
> > > client and server need to come to an agreement on a format 
> > when exchanging
> > > text files.
> > 
> > Modern day files are binary documents (pdf, doc, viruses), so no
> > conversions is necessary.  SFTP is slim and simple, you can do text
> > conversion in you client application based on suffix-heuristics,
> > for example.
> > 
> 

 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 
 [email-masked]                OpenSSL. Interfaces with OpenSSH

---

From: Pontus Skoeld <[email-masked]>
Date: 01 Apr 2002 23:54:57 +0200

Richard Whalen <[email-masked]> writes:

> as I believe that it is technically flawed in its current state.  

I don't think that is really the problem. In my mind, the difference
is between what people expect sftp to do for them. A lot of people
want ftp, but with an s for secure. Others want something that solves
any problem they might have. Certain others don't know (I belong
there, but I'm rather sure that I don't want ftp).

<standard rant> 
I think we need to decide what sftp should do (or even if we are the
ones to design it or if it belongs to another area).
</standard rant>

Having said that, I actually think the protocol is quite well
designed. Moreover, I consider it to be a remote file system protocol
rather than a file-transfer protocol.

And to address the current issue; I don't want a "text-mode" for sftp.
I believe it will not solve, but create problems. On some systems,
it's only a matter of policy (and hence impossible for the
sftp-implementation to know) what character sets are used, so we can't
reasonably expect servers to handle conversion to wire format.

I see the chances of this helping more than it breaks as very slim. We
might be able to handle EOL-conversion, but handling that alone
doesn't help much, the user would still (likely) need to convert the
text, so we may as well leave it be.

And ASCII/Binary has been a constant headache with ftp, I don't see
why it wouldn't cause the same problems in sftp.

To me, the proper solution is to let the user convert the file if
necessary, which, as Marcus pointed out and my own experiences tells
me, is rather seldom nowadays.

One thing we might consider (though I'm not certain what I think of it
myself) is adding an extension to the file attributes, allowing the
declaration of the file contents and character set and anything else
you'd want to know (think Content-Type with certain bonuses). This
would allow for easy conversion if necessary (supposedly most often by
the client).

In short; I recognize the problem, I just don't think the file
transfer protocol should be responsible for fixing it.

	/Pontus

-- 

Pontus Sköld, see <URL:http://soua.net/> for more information.