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 04:25:44PM -0400, Bill Sommerfeld wrote:
> > > I'm still at a loss as to why SSH FTP wasn't simply FTP wrapped in
> > > SSH.
> >
> > for the record, the working group chair (me) is *still* at a loss to
> > understand why there seems to be so much of a desire to reinvent the
> > wheel here.
>
> I can think of a few reasons:
>
> 1. SFTP is very easy to understand and implement, once you've implemented
> SSH.

The implication here is that FTP is not. This is a pretty odd statement; FTP
has been in use for so long, the volume of expertise with it surely exceeds
the volume of expertise in SSH/SFTP by several orders of magnitude. It's a
long-ago solved problem. There's nothing new to understand. Even if SFTP is
easy to understand, it's just creating work where none was needed. It's also
obvious, by the length of these discussions, that it is not well thought out
enough to address many desired usage scenarios.

> 2. FTP's seperate control and data channels are an annoyance in the
> context of SSH.

SSH itself is a multi-channel protocol. I don't see the problem in mapping
FTP PORT commands to SSH channels.

> 3. Historically FTP implementations have been vulnerable
> to various attacks. SFTP implementations have not been.

This is like saying "historically libcurses has been insecure compared to
libdes." And just because an implementation is broken is no reason to
discard
the protocol definition.

> 4. SFTP server typically runs under the user's account instead of root.

This is an implementation detail, not a protocol feature.

> 5. SFTP can be used as a basic network file system, again lightweight and
> secure compared to existing solutions.

FTP has been used in this manner for many years. Again, it is not unique to
the protocol definition.
>
> Unless people foresee more problems beyond the current one (i.e. text
> transfer mode) with SFTP, why not finish it up?

If all you want is to come to consensus on how to finalize one last detail
of the current implementation, fine, do that as an informational RFC. I
don't believe this spec merits Standard status.

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