Subject: draft-ietf-secsh-filexfer-09

From: Eric Brown <[email-masked]>
Date: Sat, 27 Aug 2005 09:07:50 -0700 (PDT)

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Joseph Galbraith <[email-masked]>
Date: Sat, 27 Aug 2005 15:19:19 -0600

>        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