Re: Draft draft of coming sftp revision...

[Simon Tatham <anakin%pobox.com@localhost>]

Joseph Galbraith <galb-list%vandyke.com@localhost> wrote:
> It seems like it has been a while since we had a ruckus on the
> mailing list -- so I thought I'd post a draft-draft of the coming
> version of the sftp draft.

First things first: I _like_ the human-readable error message field
in SSH_FXP_STATUS. This is something that institutions I have
contact with have been complaining bitterly about for ages - one lot
refused to provide SFTP to their users _at all_ simply because it
was unable to report errors with the same richness as SCP. Even if
every other proposed change gets shouted down, KEEP THIS ONE!

>    o  Added 'newline' extension.
>    o  Added SSH_FXF_TEXT file open flag.

These seem like a half-decent 90% solution (covers Windows, Mac and
Unix with no difficulty), but I'm concerned about the other 10% :-)

For a start, if you consider text file issues to be only about
newline conventions, you thereby ignore other problems such as
character sets. If a server uses EBCDIC and a client doesn't, is it
really the expected behaviour of a text-mode file transfer that it
should yield an EBCDIC file at the client end or an ASCII file on
the server? I was vaguely under the impression that (say) FTP's idea
of a text-mode transfer was that character sets would get converted.
Granted that EBCDIC is a pretty extreme example, but if one system
uses ISO-8859-1 while another uses UTF-8, or (more subtly) if two
systems use UTF-8 with different default normalisation forms, this
might still be an issue.

If the wire format for text files use \r\n as a newline, what should
an implementation do if it sees a lone \r or a lone \n? It's always
annoyed me that so many protocol specifications use \r\n as the
newline and don't mention anything about this situation. Can we have
a definitive specification of this?

Seeking in text files worries me a little. If each server can choose
to define the wire text format to be its own newline convention,
then this means 90% of servers (as above) can effectively treat text
files as binary and seeking isn't a problem. But what about things
like VMS? Don't VMS text files use a fixed-length record per line?
This surely isn't covered in the 90% solution that is SSH_FXF_TEXT.

I'm still not convinced it wouldn't be better to use a solution that
runs parallel to the standard C library's fpos_t: you define an
opaque type representing a position in a text file, with one
well-known value which represents beginning-of-file. Then you
introduce a text-mode variant of SSH_FXP_WRITE, perhaps called
SSH_FXP_WRITE_TEXT, which takes one of these as input in place of
FXP_WRITE's `offset' field, and _returns the updated one_ alongside
the data. This approach has the advantage that it can be implemented
entirely in terms of standard C library functions, so it can be
supported easily on _any_ OS which already supports ANSI C, no
matter how exotic its text file format. If you want to, of course,
you could still define an extension that allowed mainstream servers
to announce that their fpos_t was an ordinary file offset, so that
clients supporting this extension could seek arbitrarily in text
files.

That's just my 2p, though. Practically speaking, SSH_FXF_TEXT would
eliminate 99% of the complaints I get from SFTP users. Even if I
might wish it had been done a different way, what you've got here
would be better than nothing.

Cheers,
Simon
-- 
Simon Tatham         What do we want?        ROT13!
<anakin%pobox.com@localhost>   When do we want it?     ABJ!