Subject: SFTP extensions draft should be submitted as working group item

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 19:39:41 +0100

By the way, Joseph -

I think your filexfer extensions draft contains very useful extensions which I will be implementing, or indeed already have.

I think it's a pity that this draft should be lost to casual implementors who come to the secsh working group page to get their latest SSH and SFTP specifications. It is difficult to even know that your extensions exist without semi-privileged knowledge. (It was published individually as draft-galb-filexfer-extensions-00.txt.)

I suggest that further iterations of the extensions draft be published as a secsh group work item so that they will appear on the secsh group page as one of its drafts.

denis

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 11:49:17 -0700

> I suggest that further iterations of the extensions draft be published as a secsh group work item so that they will appear on the secsh group page as one of its drafts.

I would like to do that...

I'm not sure if Bill will accept a consensus of two or three
though :-)

I've been tempted to post and ask whether we want to keep it
as a separate working group draft or roll it back in to the
main draft.

Thanks,

Joseph

PS. In terms of time lines, I believe that we are getting very
close to being ready to call the SFTP draft done.

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 21:28:41 +0100

Hello all,

I feel that the SFTP extensions draft is in places underspecified.

For example, it is not explicitly stated what kind of an extension "vendor-id" is. Is this extension included in the server's VERSION packet? The specification doesn't say so; one might even be lead to think that it's a response to an SSH_FXP_EXTEND packet that must be sent by the client.

How does the server advertise that it supports the "check file" extension? There are two possible request names: "check-file-name" and "check-file-handle". In the "supported2" VERSION extension, should the server advertise "check-file", "check-file-name", "check-file-handle", or a combination thereof? Does it make sense for the server to implement only check-file-name, but not also check-file-handle? (My preference - the server should advertise "check-file" and support both.)

Why does the "check file" reply include the string "check-file"? The format of SSH_FXP_EXTENDED_REPLY does not require any such string; the response should be traced back to the original request by ID. Also, no such extra string is specified for "space-available". However, there is such an extra string in the reply for "home-directory". Unless someone already has a fielded implementation, I suggest that we get rid of these while there is time.

Best regards,

denis

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 21:44:32 +0100

On Tue, 6 Dec 2005 21:28:41 +0100, denis bider wrote:
> For example, it is not explicitly stated what kind of an extension
> "vendor-id" is. Is this extension included in the server's VERSION
> packet? The specification doesn't say so; one might even be lead to
> think that it's a response to an SSH_FXP_EXTEND packet that must be
> sent by the client.

Also, the spec says that the client MAY send the "vendor-id" as an SSH_FXP_EXTEND request to the server. The specification should specify the exact encoding of the request in this case, and should also determine how the server needs to respond to such a request. Does it send SSH_FXP_STATUS with SSH_FX_OK? Should it respond with SSH_FXP_EXTENDED_REPLY, perhaps re-sending its own vendor ID? Or does it simply ignore it?

These questions aren't answered by the current draft.

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 14:02:12 -0700

denis bider wrote:
>> For example, it is not explicitly stated what kind of an
>> extension "vendor-id" is. Is this extension included in the
>> server's VERSION packet? The specification doesn't say so;
>> one might even be lead to think that it's a response to an
>> SSH_FXP_EXTEND packet that must be sent by the client.

It is both.  The server sends it in it's version packet,
the client sends it as a SSH_FXP_EXTENDED packet.

> Also, the spec says that the client MAY send the "vendor-id"
> as an SSH_FXP_EXTEND request to the server. The specification
> should specify the exact encoding of the request in this case,
> and should also determine how the server needs to respond to
> such a request. Does it send SSH_FXP_STATUS with SSH_FX_OK?
> Should it respond with SSH_FXP_EXTENDED_REPLY, perhaps
> re-sending its own vendor ID? Or does it simply ignore it?
> 

When it is sent as a SSH_FXP_EXTENDED packet,
the contents vendor-structure becomes the extension
specific data:

       byte   SSH_FXP_EXTENDED
       uint32 request-id
       string "vendor-id"
       string vendor-name     [UTF-8]
       string product-name    [UTF-8]
       string product-version [UTF-8]
       uint64 product-build-number

The server responds with a status packet, which
should always be SSH_FX_OK.

I will clarify this.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 14:09:05 -0700

denis bider wrote:
> [...]
> How does the server advertise that it supports the "check
> file" extension? There are two possible request names:
> "check-file-name" and "check-file-handle". In the "supported2"
> VERSION extension, should the server advertise "check-file",
> "check-file-name", "check-file-handle", or a combination
> thereof? Does it make sense for the server to implement only
> check-file-name, but not also check-file-handle? (My
> preference - the server should advertise "check-file" and
> support both.)

I think I would put them both in-- it is the simplest most
straight forward way.  If you or someone else felt strongly
about it though, I'd be willing to specify the "check-file"
is the alias for both of these.

> Why does the "check file" reply include the string
> "check-file"? The format of SSH_FXP_EXTENDED_REPLY does not
> require any such string; the response should be traced back to
> the original request by ID. Also, no such extra string is
> specified for "space-available". However, there is such an
> extra string in the reply for "home-directory". Unless someone
> already has a fielded implementation, I suggest that we get
> rid of these while there is time.

Well, last time I did an extension w/o the string someone
(I don't recall) really really really really badly wanted
the string in the reply too...

I'm more than happy to take it out.  In fact, unless someone
screams bloody murder, I'm taking it out.

In fact, I've removed them from my local source, and also
specified the vendor-id thing in my local source.

Thanks,

Joseph

---

From: denis bider <[email-masked]>
Date: Wed, 7 Dec 2005 02:11:08 +0100

> If you or someone else felt strongly about it though,
> I'd be willing to specify the "check-file" is the alias
> for both of these.

Well, I'd actually like to require the server that if it supports one, it must support both. It seems trivial for a server to implement both versions (the only difference is it has to explicitly open the file in the check-file-name case), and adaptation is tricky for the client if it finds that the server supports "check-file-handle" but not "check-file-name", for example.

I think we should classify both types of the request as "check-file" and say explicitly that people should advertise exactly that, no variations.

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 18:22:02 -0700

denis bider wrote:
>> If you or someone else felt strongly about it though, I'd be
>> willing to specify the "check-file" is the alias for both of
>> these.
> 
> Well, I'd actually like to require the server that if it
> supports one, it must support both. It seems trivial for a
> server to implement both versions (the only difference is it
> has to explicitly open the file in the check-file-name case),
> and adaptation is tricky for the client if it finds that the
> server supports "check-file-handle" but not "check-file-name",
> for example.

Well, there is one other difference: check-file-handle
has to honor the SSH_FXF_ACCESS_TEXT_MODE flag.

But it still seems reasonable to require support for
both.  I'll make this change.

> I think we should classify both types of the request as
> "check-file" and say explicitly that people should advertise
> exactly that, no variations.

Thanks,

Joseph