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

Re: #540: "jumbo" frames

From: Nicholas Hurley <hurley@todesschaf.org>
Date: Thu, 10 Jul 2014 16:40:38 -0700
Message-ID: <CANV5PPU12k1BF4nCVVk_NnabmWJtcHHVHvPMxXJuyXJ-+3RWBA@mail.gmail.com>
To: Jason Greene <jason.greene@redhat.com>
Cc: Jeff Pinner <jpinner@twitter.com>, Amos Jeffries <squid3@treenet.co.nz>, IETF HTTP WG <ietf-http-wg@w3.org>
I see no convincing technical reasons in that list to make it a built-in
part of the protocol. It reads to me more like a list of "this would be
nice", which sounds just perfect for an extension.

--
Peace,
  -Nick


On Thu, Jul 10, 2014 at 11:15 AM, Jason Greene <jason.greene@redhat.com>
wrote:

>
> On Jul 10, 2014, at 12:37 PM, Jeff Pinner <jpinner@twitter.com> wrote:
>
> > On Thu, Jul 10, 2014 at 10:32 AM, Nicholas Hurley <hurley@todesschaf.org>
> wrote:
> >> On Thu, Jul 10, 2014 at 6:05 AM, Amos Jeffries <squid3@treenet.co.nz>
> wrote:
> >>>
> >>> http://staff.psc.edu/mathis/MTU/limits.html :
> >>>
> >>> IPv6 - The extended length option provides for a 32 bit length field,
> >>> supporting packets up to 4294967295 bytes.
> >>
> >>
> >> With the operative words there being "extended" and "option". So why
> can't
> >> we do this in an extension, again?
> >
> > +1
>
> The length settings in the proposal already serves the same purpose that
> an extension to go larger would, and they also allow you to have small
> frames. A benefit would be to save a couple bytes in the header when an
> implementation only plans to allow 16KB frames. However, if that was
> important you could also create a size encoding rule without an extension.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
Received on Thursday, 10 July 2014 23:41:05 UTC

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