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