Subject: Call for Consensus: #578

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Oct 2014 16:03:21 +1100

<https://github.com/http2/http2-spec/issues/578>

We've straw polled the before, but after further discussion we have another proposal for this issue.

The proposals for this issue are now:

1) Close with no change (status quo).

2) Jeff's proposal: <https://github.com/http2/http2-spec/issues/578#issuecomment-58030551>

3) Willy's proposal: <http://www.w3.org/mid/[email-masked]>

Please state which you support (multiples are fine), as well as what you can't live with (and, briefly, why).

A word about how I'll judge consensus -- as we are post-WGLC, we are only entertaining changes that fall into one of four categories:

a) editorial improvements
b) substantial interop problems
c) serious security issues
d) changes that have broad consensus (i.e., we all agree it's worth it)

Our AD has said that it's entirely appropriate to raise the bar in this manner as we get closer to delivery.

As such, proposal #2 and #3 above can only fall under (d). What I'm looking for here, then, is for *strong* support (as in, very few if any detractors) for either (2) or (3); if making these changes is controversial, we haven't met the bar for (d) and so #1 wins the day.

When we straw polled this before, many people said that they didn't want to see any change; what I'm specifically looking for is whether they've changed their minds.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Jason Greene <[email-masked]>
Date: Wed, 22 Oct 2014 00:10:54 -0500

3, 1, 2 in order of preference. I can live with all of them.

> On Oct 22, 2014, at 12:03 AM, Mark Nottingham <[email-masked]> wrote:
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 22 Oct 2014 16:27:01 +1100

My preferred option is 4!  which is the status quo for encoding but with a
trimmed static table of approx 32 entries, mostly with values (to give
space for dynamic headers).

Almost as good is option 3 - but it needs to be considered together with a
refined static table.

I can live with 1, but I agree with Willy that it is clear we missed a
revision of the static table.

Can't live with 2 because it removes the possibility of pre-generation in
many cases.

cheers

On 22 October 2014 16:03, Mark Nottingham <[email-masked]> wrote:

> 2) Jeff's proposal: <
> https://github.com/http2/http2-spec/issues/578#issuecomment-58030551>
>
> A word about how I'll judge consensus -- as we are post-WGLC, we are only
> entertaining changes that fall into one of four categories:
>
> As such, proposal #2 and #3 above can only fall under (d). What I'm
> looking for here, then, is for *strong* support (as in, very few if any
> detractors) for either (2) or (3); if making these changes is
> controversial, we haven't met the bar for (d) and so #1 wins the day.
>
> When we straw polled this before, many people said that they didn't want
> to see any change; what I'm specifically looking for is whether they've
> changed their minds.
>
> Regards,
>
>
>
> --

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Oct 2014 16:28:16 +1100

> On 22 Oct 2014, at 4:27 pm, Greg Wilkins <[email-masked]> wrote:
> 
> 
> My preferred option is 4!  which is the status quo for encoding but with a trimmed static table of approx 32 entries, mostly with values (to give space for dynamic headers).

That's a separate issue, and I'd like it to remain one.

> Almost as good is option 3 - but it needs to be considered together with a refined static table.
> 
> I can live with 1, but I agree with Willy that it is clear we missed a revision of the static table.
> 
> Can't live with 2 because it removes the possibility of pre-generation in many cases.

Thanks, Greg.

Cheers,

> Greg Wilkins <[email-masked]>  @  Webtide - an Intalio subsidiary

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Oct 2014 08:34:44 +0200

Hi Mark,

> Please state which you support (multiples are fine), as well as what you can't live with (and, briefly, why).

3 > 1 > 2 for me.

None are a showstopper though. They just leave me an increasing feeling that
we did something bad for the future.

Regards,
Willy

---

From: Cory Benfield <[email-masked]>
Date: Wed, 22 Oct 2014 08:53:55 +0100

> Please state which you support (multiples are fine), as well as what you can't live with (and, briefly, why).

3 > 1 > 2 for me, but I can live with any of them.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 22 Oct 2014 06:59:46 -0400

3 1 2, can live with any of them

> On Oct 22, 2014, at 1:03 AM, Mark Nottingham <[email-masked]> wrote:
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 22 Oct 2014 20:22:12 +0900

Are there anyone who implemented proposal 3 and vetified that it shows the
satisfying results with custom header dominated data?

Best regards,
Tatsuhiro Tsujikawa

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 23 Oct 2014 01:52:43 +1300

3 > 1 > 2, can live with any.

Amos

On 22/10/2014 6:03 p.m., Mark Nottingham wrote:
> 2) Jeff's proposal:
> <https://github.com/http2/http2-spec/issues/578#issuecomment-58030551>
>
>  3) Willy's proposal:
> <http://www.w3.org/mid/[email-masked]>
> 
> Please state which you support (multiples are fine), as well as
> what you can't live with (and, briefly, why).
> 
> 
> A word about how I'll judge consensus -- as we are post-WGLC, we
> are only entertaining changes that fall into one of four
> categories:
> 
> a) editorial improvements b) substantial interop problems c)
> serious security issues d) changes that have broad consensus (i.e.,
> we all agree it's worth it)
> 
> Our AD has said that it's entirely appropriate to raise the bar in
> this manner as we get closer to delivery.
> 
> looking for here, then, is for *strong* support (as in, very few if
> any detractors) for either (2) or (3); if making these changes is
> When we straw polled this before, many people said that they didn't
> want to see any change; what I'm specifically looking for is
> whether they've changed their minds.
> 
> Regards,
> 
> 
> 
> -- Mark Nottingham   https://www.mnot.net/
> 
>

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Wed, 22 Oct 2014 15:20:21 +0000

>can't live with (and, briefly, why).

In order of preference (and reasoning):

Option 3: Puts static and dynamic on equal footing, removes the desire to
trim the static table, allows for pre-generated headers from the static
table, and allows the static table to grow in the future.  Ideally we
would reorder the static table, add values to the static table, and
perhaps swap the prefixes as suggested, if we agree to make this change.

Option 1: Allows for pre-generated headers from the static table, gives a
preference to static table entries (e.g., standard headers).

Option 2: Is a -1 for me.  This switches the efficiency to non-standard
headers, removes the ability for pre-generated headers from the static
table, but does allow the static table to grow and removes the desire to
trim the static table.

- Robby

---

From: Adrian Cole <[email-masked]>
Date: Wed, 22 Oct 2014 08:42:10 -0700

(3, 2), 1 - prefer either change (and ack the case others made for 3 over
2), but also not scuffed on no change.

-A

---

From: Nicholas Hurley <[email-masked]>
Date: Wed, 22 Oct 2014 09:19:10 -0700

I'm all in favor of option 1 (still).

Option 2 didn't get much support last time around, so I'm not quite sure
I see the point in it being on the table again, but since it is... I'm
still not in favor. It optimizes a special use case at the detriment of
the general use case. That's just bad design.

I'm a -1 on option 3, as well. So far as I can tell, it has zero testing
whatsoever, and I haven't seen any data indicating an actual global
improvement. Just because we can make more things fit in a single byte
doesn't mean this is a dramatic improvement over the existing scheme. If
it doesn't make everything dramatically better, it's not worth risking
at this stage. We have a protocol that works, and works well.

-- 
Peace,
  -Nick

---

From: Shigeki Ohtsu <[email-masked]>
Date: Thu, 23 Oct 2014 02:00:57 +0900

My preference is 3, 1 and 2.

I think that adding one bit flag to switch a static and a dynamic header 
table is worth
for trying even in this last stage.

And if possible, I wish to change the current alphabet order of  a 
static header table
to make the most of 31 entries.

Regards,

---

From: "Kulkarni, Saurabh" <[email-masked]>
Date: Wed, 22 Oct 2014 12:04:05 -0500

Same here for me, prefer option 1. There has absolutely been no data to
support either option 2 or 3 as mentioned below.

- Saurabh

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 22 Oct 2014 17:09:34 +0000

--------
In message <[email-masked]>, Mark Nottingham wri
tes:

3, 1, 2, in that order.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Kinkie <[email-masked]>
Date: Wed, 22 Oct 2014 19:16:22 +0200

Hi all,
   3 > 1 > 2 for me as well.

-- 
    Francesco

---

From: Mike Bishop <[email-masked]>
Date: Wed, 22 Oct 2014 19:23:37 +0000

1 > 3 > 2, can live with any.

At this point, any change needs to have good data showing an improvement commensurate with its invasiveness.  We haven't seen the data, so our preference remains with the status quo.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2014 10:03 PM
To: HTTP Working Group
Subject: Call for Consensus: #578

Regards,

---

From: <[email-masked]>
Date: Wed, 22 Oct 2014 20:15:27 +0000

3, 1, 2 in that order

-Keith

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 22 Oct 2014 13:42:55 -0700

2 > 3 >> 1

I would much prefer either of 2 or 3 to 1.

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 22 Oct 2014 22:50:41 +0200 (CEST)

> can't live with (and, briefly, why).

1 - 3 - 2.

I can live with any.

-- 

  / daniel.haxx.se

---

From: Craig Tiller <[email-masked]>
Date: Wed, 22 Oct 2014 20:54:42 +0000

3 - 2 - 1

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 23 Oct 2014 08:53:43 +1000

I think Willy is proposing to address a relatively significant oversight,
so I'm very slightly +more for 3, but otherwise I don't have strong
opinions and can live with any.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 23 Oct 2014 09:47:36 +0900

Since we are doing this discussion for few percent efficiency gain in
certain usecase, without actual measurement and verified results, -1 to
option 3 for now.

My preference is 1. I can live with 2.

Best regards,
Tatsuhiro Tsujikawa
 2014/10/22 20:22 "Tatsuhiro Tsujikawa" <[email-masked]>:

>> 3) Willy's proposal: <http://www.w3.org/mid/[email-masked]
>> >
>>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Oct 2014 15:31:50 -0700

We’ve heard people’s preferences here, got a sense of implementer intent, and run some experiments using the alternative approaches. I don’t see minds being changed.

Based on all of that and the discussion involved, I don’t think we’ve met the criteria below to make a change.

Closing with no action. Thanks to everyone for talking this through and coming to the table with data.

Cheers,

> On 21 Oct 2014, at 10:03 pm, Mark Nottingham <[email-masked]> wrote:
> 

--
Mark Nottingham   http://www.mnot.net/