RE: solving the SFTP text mode issue

[Richard Whalen <Whalenr%process.com@localhost>]

Good suggestions, though the 'client' should not be required to understand
text storage modes.

Text file conversion is best handled by the routines that access the file on
the system that the file is stored on.  Doing it in the file access routines
makes it such that an implementation only needs to understand its storage
method(s) and the common storage method. Requiring the 'client' to do
conversion would mean that the client would have to have information about
storage methods for all systems that it desires to interoperate with
included in its (the clients) implementation.

Some methods do not have explicit line separator(s), but have an implicit
line break and the end of each record stored.  There may be additional
binary information that varies between the individual records (lines).

-----Original Message-----
From: denis bider [mailto:ietf-ssh%denisbider.com@localhost]
Sent: Friday, May 10, 2002 3:19 PM
To: ietf-ssh%netbsd.org@localhost
Subject: solving the SFTP text mode issue


Judging from the number of times that text file support has been requested
for SFTP, we might as well do something about it. I suggest that, in the
next version of the filexfer draft, we document a recommended way for client
software to do text file conversion. (On its own, of course, without any
ugly hacks into the protocol.)

What if we provide an SFTP command that the client could execute to learn
the line separator on the server machine?

We could then document a text file conversion algorithm such as the
following:
1. The client queries the server about the server's line separator.
2. If the server's line separator is the same as the client's, the file is
transferred in binary mode.
3. Otherwise, the client determines whether the file is textual using, for
instance, the Kermit 8 algorithms mentioned by Jeffrey earlier on this list.
If the file is textual, the client converts it.