IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Additional thoughts on text transfers



Richard Whalen <Whalenr%process.com@localhost> writes:

> 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 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.



Home | Main Index | Thread Index | Old Index