W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Striving for Compromise (Consensus?)

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sat, 12 Jul 2014 15:42:37 +1200
Message-ID: <53C0AEAD.2070901@treenet.co.nz>
To: ietf-http-wg@w3.org
On 12/07/2014 10:37 a.m., Martin Thomson wrote:
> On 11 July 2014 14:53, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>> If 256 bytes is enough for basic interop, we shouldn't require more.
> I find this reasonably convincing.  Interoperability is what we are
> looking for here.
> Though I'll note that the arguments regarding cost of implementation
> are very much less convincing. Those devices, when presented with a
> peer that doesn't know their capabilities, will have to deal with 16k
> frames until their setting is seen.  And I'm not sure that 16k is so
> hard for a constrained device to handle anyway.  I keep hearing about
> what amazing things that even the most constrained hardware can handle
> (TLS stacks, node.js, etc...).  So I'm disinclined to lend too much
> weight to arguments about limited capabilities.
> That said, if 256 is enough to get something working, then that's a
> good argument.
> An alternative approach would be to set the default and minimum to the
> same value.  That has other benefits, like being able to completely
> ignore a setting from the other side.  That seems pretty attractive.

When I sueggested that same point some time back you convinced me that
is was perfectly reasonable for a constrained device to reject a number
too-big frames and streams on connection initiation. Nothing has changed
since then. So why is it now such a burden to reject some frames up
front on a constrained processor?
 If the constrained processor is going to pick 256 in the first place
its something like an 8-bit processor counting memory by the byte. Even
16-bit ATOM these days have a few hundreds of KB of RAM attached.

Received on Saturday, 12 July 2014 03:43:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC