- From: <K.Morgan@iaea.org>
- Date: Wed, 25 Jun 2014 20:00:10 +0000
- To: <grmocg@gmail.com>
- CC: <pmcmanus@mozilla.com>, <jason.greene@redhat.com>, <hurley@todesschaf.org>, <mnot@mnot.net>, <phk@phk.freebsd.dk>, <w@1wt.eu>, <gregw@intalio.com>, <ietf-http-wg@w3.org>, <duerst@it.aoyama.ac.jp>
On 25 June 2014 21:48, grmocg@gmail.com wrote: > The same is true for any other optional thing under the sun. > It doesn't seem to be a motivating argument for including more optional features, though. > -=R That's not the point. Patrick implied that adding the jumbo frame option kills the ability to efficiently mux. That's simply false. On Tuesday,22 April 2014 09:00, fielding@gbiv.com said [1]: "Likewise, restricting packet sizes to a small length in order to prevent fools from HOL blocking their own multiplexed channels makes some sense, for browser developers. However, it actively harms applications of HTTP that are not interested in multiplexing because they only want to transmit a single large data stream. ... I don't think it makes sense to limit an application-level protocol to the worst case. ....Roy" So let's be straight. There are legitimate use cases for jumbo frames. You and Patrick just think the world is full of a bunch of what Roy calls "fools" (see above) who will HOL block their own multiplexed channels. Roy (and I) don't disagree. Roy (and I) don't think it makes sense to limit the protocol to protect against an unknown number of fools. [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0416.html 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 Wednesday, 25 June 2014 20:01:29 UTC