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

Re: Striving for Compromise (Consensus?)

From: <K.Morgan@iaea.org>
Date: Fri, 11 Jul 2014 23:06:02 +0000
To: <martin.thomson@gmail.com>
CC: <phk@phk.freebsd.dk>, <hurley@todesschaf.org>, <gregw@intalio.com>, <jpinner@twitter.com>, <ietf-http-wg@w3.org>
Message-ID: <E66483CA-B66B-4D45-80C4-8DD840023B3D@iaea.org>
On 12 Jul 2014, at 00:41, "martin.thomson@gmail.com" <martin.thomson@gmail.com> 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.
> [snip]
> 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.

Having the default and minimum the same value is a great idea - especially for resource constrained implementations that want to "ignore a setting from the other side". What value do you suggest though? I would be really, really, really surprised if anybody went for 256. For browser implementations, you'd have to wait up to one RTT before you know what the peer actually supports and can send a request safely - or speculatively send larger frames assuming the peer is going to increase from the default setting.

BTW, we still work with micro-controllers with ~100K, where 16K is a significant resource  commitment.


This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Friday, 11 July 2014 23:06:41 UTC

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