Re: draft-ietf-secsh-filexfer-05.txt

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Ouadah Farid wrote:

> Hello,
>
> I suggest the draft mentions if the hash is used for
> the local file or it's wire format (wich may be different
> in case of data transformations like text files).

If the handle version is used, it should be the hash
over the range as it would appear if a READ command
were issued.

If the name version is used, it the hash will be
over the data on disk.

I'll clarify these things.

> Anyway woluldn't it be more simple for this hash
> feature to be an extended field in the file attributes
> when replying a SSH_FXP_LSTAT/FSTAT/STAT query ?

The problem is that calculating a hash is expensive,
and there is no way to request a particular extended
attribute.

The hash calculation needs to be done on-demand, which
means the client has to have a way to ask for it.

> Section 4.4 describes an intersting "max_read_size"
> however I  think the this value must only be an
> indication for the client  for its read queries.
> IMHO, assuming that shorter read replies are faulty
> is an unecessary lack of telerency.

I'm not quite sure what you are saying here.

This field was introduced because, as previously
discussed on this list, the way to get maximum
performance from SFTP, is to issue multiple read
requests, without waiting for a response.

C->S: READ Id:0, Pos:0,    Size:4096
C->S: READ Id:1, Pos:4096, Size:4096
C->S: READ Id:2, Pos:8192, Size:4096
S->C: 4096 bytes of data for Id:0
C->S: READ Id:3, Pos:12288, Size:4096
S->C: 4096 bytes of data for Id:1
C->S: READ Id:4, Pos:12288, Size:4096
S->C: 4096 bytes of data for Id:2
C->S: READ Id:5, Pos:12288, Size:4096

etc.

This allows the server to keep the pipe-line
full with data coming back from the server.

However, there is in practice, one implementation
that behaves as follows (which is not disallowed
in the draft):

C->S: READ Id:0, Pos:0,    Size:4096
C->S: READ Id:1, Pos:4096, Size:4096
C->S: READ Id:2, Pos:8192, Size:4096
S->C: 1024 bytes of data for Id:0
C->S: READ Id:3, Pos:12288, Size:4096
S->C: 1024 bytes of data for Id:1
C->S: READ Id:4, Pos:12288, Size:4096
S->C: 1024 bytes of data for Id:2
C->S: READ Id:5, Pos:12288, Size:4096

Now that makes processing a little more difficult.
So I added a way to ask the server to say
I'm only going to return 1024 bytes of read
data no matter how much you ask for.

In practice, most servers will only give you
32K, regardless of how much you ask for.

> Section 5.8. SSH_FILEXFER_ATTR_FLAGS_ARCHIVE_ENCRYPTED
> and COMPRESSED are very suprising. They don't provide the
> compression/encryption method used and they are "in-file"
> informations and are not more usefull than a
> SSH_FILEXFER_AATR_FLAG_MP3.  Such information could be
> provided in protocol extentions (a kind of sftp/mime ?).

Well, there are three differences between ATTR_FLAG_MP3
and ENCRYPTED or COMPRESSED:

1. These don't actually reflect the contents of the file.
   They can be applied to any file, regardless of the
   contents.  They reflect the status of the file on
   disk, _NOT_ on the wire.

   In other words, COMPRESS means that the file MUST
   be stored on disk in a compress format.  However,
   the results of a READ operation return the actuall
   file data, not the compressed data.

   These flags are meant to enable/disable filesystem
   level, transparent, compression and/or encryption.

2. These flags don't just represent the current on-disk
   state of the file, they can be used to change that state.

3. A major operating system we all know and loves
   has these file attributes.

I will, however, look at clarifying the meaning of these
flags.

> Section 6.3.1 under SSH_FXF_CREATE_TRUNCATE I think we
> should read "A new file is created" instead of "is create".

I'll take a look at this.

- Joseph