Re: Speaking of implementation quirks...

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> The first is possible confusion with the definition in 5.1 Opening a
> Channel in -connect.  I recently found an implementation that thinks
> that "maximum packet size" is the maximum payload size (not the
> packet size), [...]

But it _is_ the packet size, just of different packets.  There are so
many layers to ssh that "packet size" is an unclear concept unless it's
disambiguated by reference to what layer it's at.

> Based on this, it'd be useful if the text could emphasise that the
> value refers to the total packet size by adding the "(including
> length, padding length, payload, padding, and MAC)" in -transport...

Except the text that needs changing isn't in -transport; it's in
-connect.  The description of channel opening just says it's "the
maximum size of an individual data packet that can be sent to the
sender".  In context, this could reasonably be taken to refer to
packets at the SSH Connection Protocol layer, though whether it refers
to data payload or payload plus nine bytes of CHANNEL_DATA header is
still ambiguous.

> The second one is the requirement for "MUST be able to process
> packets with uncompressed payload length of 32768 bytes or less".
> [...] I can just see something cropping up in the future that insists
> on the other side using 32K packet buffers to send a single keystroke
> because that's the magic number given in the spec.

> Given that -connect 5.1 makes the packet size negotiable, why does
> -transport 5.1 require non-negotiable 32K packets/buffers?  Wouldn't
> it be better to say:
> 
>   ... MUST send packets no larger than the size requested during the
>   channel-open negotiation in [SSH-CONNECT] (including length,
>   padding length, payload, padding, and MAC).

No, or at least not without more language added.

First, -connect 5.1's limit applies only to channel data packets; it
has no bearing whatever on other packets and thus cannot usefully be
used as a limit on other packets.

Second, what about packets not associated with any particular channel,
especially those sent or received before any channels are opened?

As for your own issues, nothing says that you have to have a 32K buffer
in order to receive and process packets 32K in length.  You're entirely
free to process packets byte by byte, chewing your way through that 32K
packet piecemeal - though you have to be careful that you can back out
any global data structure changes in case the MAC turns out to be
wrong.

And if all else fails, you could ignore that MUST.  You would,
strictly, be nonconformant, but if you interoperate with the
implementations you care about, you may be close enough for your
purposes.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B