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