Re: comments on draft-ietf-secsh-filexfer-07.txt

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

Richard Whalen wrote:
> 4.1 Is it ok for a client to use 'version-select' after sending '4'
> as a requested version number?  Should this state a minimum
> value of '3'?

Yes, it is okay for a client to use 'version-select' as long as the
initially negotiated version has the SSH_FXP_EXTENDED, the client
can use the 'version-select'

I have however, updated the draft to require that the 'version-select'
be the first request.  This avoids questions about what versionin-flight 
data from the server is using.

I also explicitly allowed a version-downgrade; this might be useful,
if, for example, due to bugs, the negotiated version can't be used.

In addition, I added a 'vendor-id' extension that can be used similarly
to the way the ssh-2.0- ident string is used in the main protocol.
Currently, many implemenations are done in seperate processes, which
makes it hard for them to use the ssh ident string when trying to
detect and work around sftp bugs (like the reversed symlink parameters
bug that several vendors, include us here at vandyke, have.)

> 4.5 "seperated" should be "separated" (multiple occurrences).

Thanks.  Done.

> In the example of a 'comma-seperated-versions' string the
> terminating quote after "3,6,7 is missing.

Fixed.

> The sentence that follows the example is awkward "Versions defined by 
are:"
> How about "The defined versions are:"

Thanks.  Fixed.

> 6.9 in the discussion of the SPARSE flag,
> "Some server may store..." should be "Some servers may store..."

Fixed.

> 6.10 Can an FSETSTAT operation with the text hint be used 
> to convert a text file handle to a binary file handle if
> the value is set to one of the binary value types or is
> the value ignored and this is always a request to convert
> a binary file handle to a text file handle?

Ugh... what do people think of this.  I'm inclined to take
this behavior out?

Does anyone think it is useful enough to be able to convert
handles to make it worth the pain?

I'm inclined to make it illegal for both fsetstat and setstat.

I've removed it for now (so if you really want it speak _real_
fast since I'm publishing again at the end of the day!)

If we decide to put it back in, I think it should do both.  And
of course a server could refuse to support such a conversion by
not including the text-hint flag in it's valid attribute mask.

> 7.4 Should there be a way to specify that a created directory
> should be case sensitive or case insensitive?  If it is not
> specified, which is it?  The implication based upon 6.9 is
> that it should be case sensitive, but what if that is
> not the default/possible for the file system?

We currently assume that this isn't a settable parameter, and is
an attribute of the filesystem.  In other words, the reason
we have it in the ATTR is because we presume it might change
as you cross mount points or drive letters, etc., but that it
can't be controlled by either the server or the client.

> 7.7 "The SSH_FXP_LINK request creates a symbolic link..."
> strike "symbolic" as it can create either a symbolic
> or hard link.

Thanks.  Done.

> 7.8.1 "A client that use REALPATH(".", "") and treats..."
> should be "A client that uses REALPATH(".", "") and treats..."

Fixed.

> 9.2 "The total number of unused bytes availabe on the device..."
> should be "The total number of unused bytes available on
> the device..."

Fixed.

Thanks for the review.  I'll be publishing another version
latter today.

- Joseph