Re: Speaking of implementation quirks...

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

nisse%lysator.liu.se@localhost (=?iso-8859-1?q?Niels_M=F6ller?=) writes:
>pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann) writes:
>
>>The reason I asked for the disambiguation in -transport is that I've only ever
>>found one implementation that, if asked for a max.packet size of nK, sends
>>significantly more than nK.
>
>I think it would be good if you spelled out exactly which implementation(s)
>you are talking about. Mine (lsh) applies the channel max packet size to the
>application data portion of DATA and EXTENDED_DATA packets. I don't know what
>other implementors do.

Well I can't list all of them because I don't know what users are
communicating with, only the ones that they complain about, which in this case
was WS_FTP for Windows.  I've since worked around it by increasing the amount
of slop when defining upper bounds buffer sizes, but that's probably not a
long-term solution.

>It's not *explicitly* negotiated, but as long as the largest packets are the
>channel data packets, one can make sure one doesn't get very large packets by
>advertising a small channel max packet size. So it would probably work with a
>required buffer size of just a few thousand bytes.

Right, and that works fine.  The problem is that putting in a MUST 32K means
that someone can come along in the future and claim that something is non-
compliant because it can't handle a 32K packet even when though explicitly
asked for an 8K packet size.

Peter.