RE: draft-ietf-secsh-filexfer-09

["Richard Whalen" <Whalenr%process.com@localhost>]

> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost]On
> Behalf Of Joseph Galbraith
> Sent: Saturday, August 27, 2005 5:19 PM
> To: Eric Brown
> Cc: ietf-ssh%netbsd.org@localhost
> Subject: Re: draft-ietf-secsh-filexfer-09
> 
> 
> Eric Brown wrote:
> > I've been reviewing draft-ietf-secsh-filexfer-09 and
> > noticed the space-available extended message has a
> > reply
> > that doesn't identify the message.  All other extended
> > messages identify the extended message type as the
> > first string in the packet.  This space-available
> > packet makes it difficult to implement in my client
> > and also makes it inconsistent.
> >        byte   SSH_FXP_EXTENDED
> >        uint32 request-id
> >        string "space-available"
> >        string path     [UTF-8]
> > 
> >        byte   SSH_FXP_EXTENDED_REPLY
> >        uint32 request-id
> >        uint64 bytes-on-device
> >        uint64 unused-bytes-on-device
> >        uint64 bytes-available-to-user
> >        uint64 unused-bytes-available-to-user
> >        uint32 bytes-per-allocation-unit
> 
> Argh...
> 
> The request-id should be sufficient to match up the request
> with the response... I don't understand why people need
> the string in the reply as well ....
> 
> Oh well...
> 
> What is peoples status on shipping SFTP v6 support?
> 
> I know we've got people using the vendor-id and supported2
> extensions already.
> 
> Has anyone shipped support for this request yet?
> 
> How about other portions of the draft?
> 
> Thanks,
> 
> Joseph
> 

I have this extension coded in our latest server,
our client currently does not make any use of it.
The server is version 4, and it also encodes the
vendor-id and supported2 extensions in the FXP_VERSION packet.
If the response were to change it would be possible
to use the vendor-id in future implementations of
the client to determine which format might be in use.
Since this packet has a fixed length, it may be possible
to determine which version of the response is in use by
the length of the packet.

That said, I'd rather that it didn't change.  Though I
have coded many of our private extensions to include the
extension name in the reply, it is not necessary as the
client keeps track of the extension name in the data structure
that keeps track of outstanding client requests.

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