Subject: RE: SFTP File open modes

From: Richard Whalen <[email-masked]>
Date: Thu, 28 Mar 2002 11:35:17 -0500

> -----Original Message-----
> From: Simon Tatham [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 10:47 AM
> To: [email-masked]
> Subject: Re: SFTP File open modes
> 
> 
> Richard Whalen  <[email-masked]> wrote:
> > A server implementation that implements the ASCII read option will
> > need to maintain an internal persistent file pointer. When a file is
> > opened in ASCII mode all access must be sequential and the offset in
> > the READ & WRITE operations must be ignored.
> 
> So you're ruling out the possibility of, for example, two
> interleaved sets of read requests both reading the file from the
> beginning? Or a set of requests reading from beginning to end, with
> an extra request in the middle that takes another quick look at the
> very start of the file?
>

You'll have to clarify your question, as you didn't specify whether the
streams are from a single open request or from two open requests.  Read
requests from multiple open requests could proceed in parallel.

> 
> Also, you've just broken the stateless nature of SFTP. (Well, not
> _completely_ stateless, since the existence or non-existence of a
> file handle is state, but the absence of a concept of current
> working directory and the absence of file pointers strongly suggest
> that the designers had statelessness in mind as a desirable
> property.) Do you think SFTP should never have attempted to be
> stateless? Or that loss of statelessness is a small price to pay for
> ASCII file transfer, and it's not even worth trying to work out
> whether we can have both? Do you know _why_ SFTP is largely
> stateless? (I don't, and for precisely that reason I'd want to avoid
> breaking its statelessness in case there was a really good reason
> for it I hadn't thought of.)

No, I don't know the reason why SFTP is largely stateless; it is not
explained in the specification.  My guess is that the authors were familiar
with NFS (which is stateless), and created operations that are similar to
that.  The current specification does have the ability to provide general
file access, but is missing a method of transferring (text) files between
different systems.

I don't really think that there are any benefits to SFTP being a stateless
protocol.  Since it runs over a reliable transport requests don't get lost,
and hence, do not have to be repeated (part of the reason that NFS is
stateless).  Memory and computes are cheap these days, so keeping state
around is not a problem.  I'm not saying that stateless protocols are bad,
just that they are not necessarily better than stateful protocols.

The absence of the concept of a current working directory in SFTP would
really be beneficial if there had not been an attempt to define what a file
path looked like.  It would allow the server to do the appropriate things to
combine two parts of a file path and return something that could still be in
a system independent format.

> An example of an alternative solution that doesn't suffer from these
> problems would be to define new message types FXP_TEXT_READ and
> FXP_TEXT_WRITE. These hypothetical messages would work just like
> FXP_READ and FXP_WRITE, but instead of a numeric file offset they
> would take an opaque `file position' type. You'd have some standard
> means of constructing a `file position' type corresponding to the
> very start of a file, and you'd be entitled to re-use a given file
> position as many times as you liked once you'd received it from an
> FXP_TEXT_READ or FXP_TEXT_WRITE call. (These operations would have
> to return the file position after the read/write _as well_ as
> returning the number of bytes read/written and the data.)
> 

The operations that you propose are a viable alternative.

> 
> (Both these solutions assume that it's easy to define a wire format
> for textual data. I'm not sure what such a thing might be. UTF-8
> with \n line endings, perhaps? Or something negotiated between
> client and server?)
> 

A wire format for textual data was defined as far back as RFC 959 (FTP) (and
probably further).  Yes, text has been expanded these days to allow a wider
character set, and some considerations for this should be made.  But the
bulk of the textual data sent these days is done with a character set that
uses an 8 bit unit.

My employer's customers expect SFTP to provide functionality similar to what
is provided by FTP, with the added security of encryption and improved
authentication methods. The protocol that is currently defined is not
capable of providing that functionality.

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

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 28 Mar 2002 17:21:34 +0000

> capable of providing that functionality.

Rather than turn SFTP into a version of FTP,  I'd suggest that a way be
documented to run FTP over SSH.

i.e. a SSH session connection would serve as the FTP control connection
(port 21?),  and additional SSH connections would be opened for each
FTP file transfer connection (port 20?).

This would then just seem to just involve a few hacks to an FTP client
and server in order to run them over SSH.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 28 Mar 2002 17:32:44 +0000

> FTP file transfer connection (port 20?).

Or even easier - just use the SSH tcp port forwarding facility.  Plumb the
client and server into this and you have it all with minimal changes.

DF

---

From: [email-masked] (Albert Lunde)
Date: Thu, 28 Mar 2002 12:07:23 CST

> client and server into this and you have it all with minimal changes.

My understanding is that SSH port forwarding works only with the
control connection with the FTP protocol as it stands. Both existing
server code (wu-ftpd) and the FTP protocol are a rat's nest of
historical legacies which we would be better off not inflicting
on the next generation of software. (Speaking as a very minor
beta tester of wu-ftpd.)

If people want a text-mode file transfer, they'd be better off fitting
it into the archtecture of ssh/sftp and paying attention to i18n issues.

--
    Albert Lunde          [email-masked] (new address)
                          [email-masked] (old address)

---

From: Damien Miller <[email-masked]>
Date: Fri, 29 Mar 2002 21:19:27 +1100 (EST)

On Thu, 28 Mar 2002, Derek Fawcus wrote:

> > A wire format for textual data was defined as far back as RFC 959
> > (FTP) (and probably further).  Yes, text has been expanded these
> > days to allow a wider character set, and some considerations for
> > this should be made.  But the bulk of the textual data sent these
> > days is done with a character set that uses an 8 bit unit.
> >
> > My employer's customers expect SFTP to provide functionality
> > similar to what is provided by FTP, with the added security of
> > encryption and improved authentication methods. The protocol
> > that is currently defined is not capable of providing that
> > functionality.
>
> Rather than turn SFTP into a version of FTP, I'd suggest that a way
> be documented to run FTP over SSH.

I agree: filexfer should not know or care about ASCII files. FTP is a 
deployed standard which could meet the need with a few tweaks.

-d