RE: UTF8 in SFTP (was: solving the SFTP text mode issue)

["Howard Chu" <hyc%highlandsun.com@localhost>]

> -----Original Message-----
> From: ietf-ssh-owner%netbsd.org@localhost [mailto:ietf-ssh-owner%netbsd.org@localhost]On
> Behalf Of Wei Dai

> On Tue, May 14, 2002 at 11:02:23AM -0400, Richard Whalen wrote:
> > The text transfer mechanism in the SSH File Transfer Protocol
> should define
> > a single method of encoding the line end to remove any
> ambiguity.  Systems
> > that encode line breaks differently from the specified method would be
> > responsible for scanning the data and performing the necessary
> substitution.
>
> Ok, I now realize there is no point in allowing either CR, LF, or CR LF,
> so let's just specify LF.

One complication to watch out for - some systems actually treat CR and LF
according to their original definition. You will find text files that use
CRs by themselves to achieve overstrike, and LFs by themselves to insert
whitespace, etc., in addition to CR/LF "line terminator" sequences. There's
a good reason why all the existing RFCs that deal with text transmission
specify CR/LF as the line break sequence; if you use just a single CR or LF
as suggested here, it is impossible to canonicalize a file without losing
formatting (of individual CR or LFs).

I'm still at a loss as to why SSH FTP wasn't simply FTP wrapped in SSH. FTP
has already been designed, what is with all this re-inventing the wheel
business. How are you going to accomodate record-oriented file transfers,
records with line numbers, and other structured file transfers? As much as I
like Unix and its
simple bytestream file model, there's still a place for record-oriented
files
in this world...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support