W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: New Version Notification - draft-ietf-httpbis-header-compression-12.txt

From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 18 Feb 2015 15:00:55 -0800
Message-ID: <CABcZeBM6b5OkA0RtAY9k2sxxz6j0b_9WfmDkdR4avjO5n-f=mA@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: Mark Nottingham <mnot@mnot.net>, Bjoern Hoehrmann <derhoermi@gmx.net>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, Barry Leiba <barryleiba@computer.org>
On Wed, Feb 18, 2015 at 12:11 AM, <K.Morgan@iaea.org> wrote:

> On Wednesday,18 February 2015 02:48, mnot@mnot.net wrote:
> >
> > On 18 Feb 2015, at 11:47 am, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> >>
> >> * Mark Nottingham wrote:
> >>> As we discussed (but for the benefit of everyone else) -- we've
> >>> already talked about this extensively, and came to consensus that
> >>> making such a change would be more likely to cause problems, without
> >>> making a material improvement in the protocol.
> >>
> >> Do you have a reference for this conclusion? I do not really agree
> >> that we should ship a new protocol with known bugs for the short-term
> >> benefit of experimental implementations, and I would like to find out
> >> what I am missing.
> >
> > The relevant issue is:
> >  https://github.com/http2/http2-spec/issues/587
>
> Apples and oranges. Greg was talking about improving the table efficiency.
> Julian et al are talking about fixing flat out bugs.
>
> > ... and this is perhaps relevant context:
> >   http://www.w3.org/mid/B47FA4E6-6F91-44A1-8257-AE5086EF4DC1@mnot.net
>
> I'd like clarification from the AD (Barry?) on the text from this
> "context". To quote (from Mark's link above):
>
> On Tue, 7 Oct 2014 16:41:06 +1100, mnot@mnot.net wrote:
> > We've discussed this many times, and had it confirmed by our Area
> Director;
> > it's entirely appropriate to reject changes that don't meet this bar
> (either an
> > overriding security or interop issue, or strong group consensus to make
> the
> > change) at this point in the lifetime of the protocol.
>
> Where does this concept of "strong" group consensus come from? To quote
> Section 6 of RFC7282 [1]...
> "If there is a minority of folks who have a valid technical objection,
> that objection must be dealt with before consensus can be declared."
>
> I fail to see how this doesn't apply here.
>
>
> [1] "On Consensus and Humming in the IETF"
> http://tools.ietf.org/html/rfc7282#page-14


Without taking a position on the substantive issue, RFC 7282 is an
Informational RFC
not a BCP, so it doesn't dictate WG practice.

-Ekr
Received on Wednesday, 18 February 2015 23:02:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:36 UTC