Re: maximum size of packets from client to server

[der Mouse <mouse at Rodents-Montreal.ORG>]

>> and the channel open confirmer may use a smaller max packet size
>> when sending data if it feels like it but there's no need to tell
>> the open initiator about it.

> The reason why the second interpretation could be argued to be useful
> is if you see the exchange as:

> Client: I propose a max.packet size of 128 MB.
> Server: That looks a bit large to me, how about 64kB?

Yes, but, as Niels pointed out, there's no need for the server to tell
the client it's lowering the effective value.

...unless, of course, you see this as being a single value negotiated
for both directions at once, rather than a limit on just the size of
server->client packets.  This is a self-consistent point of view, of
course; the major thing I see going against it is that it violates the
way everything else is determined separately for the two directions.

I suspect the reason you haven't run into any interop issues with your
interpretation is that everything (or at least everything you've
interop tested against) uses (approximately) the same limit you do.
Try artificially lowering your max-packet value to, say, 64 octets, and
see what happens.

(And, of course, nothing says that the one sending the CHANNEL_OPEN is
the client and the one sending the CHANNEL_OPEN_CONFIRMATION is the
server; either end may initiate channel opens.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B