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

Re: #540: "jumbo" frames

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Thu, 26 Jun 2014 17:54:20 +1000
Message-ID: <CACweHNA__tT+_NAiPN0_e8z77Pt3eQkTN0RZVAamnt6hCLbs-A@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 26 June 2014 17:00, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> In message <CACweHNBGP2sd069AsoZoxL9pbm=f_s7q4MqKqGCrmpEcxFhL=
> A@mail.gmail.com>
> , Matthew Kerwin writes:
>
> >I think the current term for those sorts of optional features is
> >"extensions." If you drafted a good one, I wouldn't oppose its adoption by
> >the wg.
>
> Getting rid of the CONTINUATION kludge is not an extension, that's a vast
> improvement and reduction of complexity in the proposed protocol.
>
>
Potayto, potahto. If it's a feature or functionality that is advertised in
settings and defaults to "off", it goes in an extension. Even if it's
absolutely critical to getting a *nicely* working protocol; even if, in the
end, everyone implements it (remember when 'Connection:keep-alive' was
non-standard?)

I think the initial release of HTTP2 doesn't have to be perfect, and in
fact​, thanks to the extensibility, I don't think it has to even be that
good. It just needs to provide a framework to allow it to evolve and
improve with time and experience.

Does it really matter which RFC contains the text, so long as it's out
there in the end? Is it worth blocking the publication of the
minimal/suboptimal/lame/whatever-you-want-to-call-it HTTP2, when there
clear are avenues for extensibility and improvement? My ample gut tells me
there won't be too much silicon wasted burning hard copies of the spec in
the near future, people will surely wait to see how it goes before
committing.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/
Received on Thursday, 26 June 2014 07:54:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC