Subject: filexfer version packet

From: Sami Lehtinen <[email-masked]>
Date: Wed, 10 Jan 2001 19:32:40 +0200

In this proposal, SSH_FXP_INIT packet has the following format

uint32 version
<extension data>

This will, however, make version 3 and higher versions incompatible
with version 2 or lower (they won't understand the extension field).

I will be happy to remove that field, unless someone can think of a
solid reason to leave it (we already have the SSH_FXP_EXTENDED
packet in this proposal).

It is possible, of course, to work around this incompatibility, but it
would be cleaner implementationwise not to use different packet format
for the version packet as in the previous versions.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: Markus Friedl <[email-masked]>
Date: Thu, 11 Jan 2001 00:46:00 +0100

oh yes, please remove the extension fields
from the version messages...

-markus

---

From: [email-masked] (Niels M�ller)
Date: 11 Jan 2001 14:47:12 +0100

> with version 2 or lower (they won't understand the extension field).

What was the reason for including this field from the start?

> for the version packet as in the previous versions.

A clean way to keep the field would be to say as follows:

1. Both servers and clients MUST accept extensions data, and ignore
   any extensions they don't know about. In particular, if no
   extensions are known, all data after the version field is ignored
   completely.

2. Servers MAY send extension data, if the client is version 3 or
   higher. Note that the spec already requires the server not to send
   its SSH_FXP_INIT message until the client's message is received and
   processed, so that the client's version is always known by the time
   the servers message is sent.

3. Clients SHOULD not send any extension data, at this time. Doing so
   breaks interoperability with earlier protocol versions.

As far as I can see, that shouldn't case any problems, it makes it
easy to start using server extensions now, and it makes it possible to
start using client extensions as soon as one believes pre-version-3
servers are no longer in use.

/Niels

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 11 Jan 2001 22:58:14 +0200 (EET)

> What was the reason for including this field from the start?

I didn't think about it enough when I wrote the spec.  I fully agree with
Sami and others that we should keep the version exchange compatible.

Generally the idea of the extension data was to allow smooth negotiation
of support for various features that might be added in the future.
Examples might include:
  - chroot support
  - rename support (I think that was in the base spec now but was only
    added less than a year ago)
  - file name syntax conventions
  - additional compression support
  - support for more advanced access control mechanisms
  - etc.

> servers are no longer in use.

Or: client must not send extension data in their first version message,
but if they have received a version 3 or higher reply fron the server
they may send another SSH_FXP_INIT that contains extension data.

   Tatu