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

From: [email-masked]
Date: Tue, 17 Feb 2015 06:55:01 -0800

A new version (-12) has been submitted for draft-ietf-httpbis-header-compression:
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-compression-12.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-compression/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-header-compression-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Feb 2015 16:38:50 +0100

So this now says:

>    The static table was created from the most frequent header fields
>    used by popular web sites, with the addition of HTTP/2-specific
>    pseudo-header fields (see Section 8.1.2.1 of [HTTP2]).  For header
>    fields with a few frequent values, an entry was added for each of
>    these frequent values.  For other header fields, an entry was added
>    with an empty value.

Is that really true? How did Proxy-Auth* end up in the table then?

It also leaves the reader to wonder why we did not remove header fields 
that can not appear in HTTP/2.

I still believe we should actually *fix* the table.

Best regards, Julian

---

From: Hervé Ruellan <[email-masked]>
Date: Tue, 17 Feb 2015 17:49:19 +0100

The list of headers used to create the static table was created at the client side. This explains why the Proxy-Auth is in the table.

Hervé

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Feb 2015 17:57:04 +0100

On 2015-02-17 17:49, Hervé Ruellan wrote:
> The list of headers used to create the static table was created at the
> client side. This explains why the Proxy-Auth is in the table.
>
> Hervé
> ...

So clarifying: it was created on a client that happened to be behind a 
proxy that required authentication?

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Feb 2015 18:45:23 +0000

--------
>proxy that required authentication?

Does that imply that it doesn't cover HTTPS traffic, which pressumably
was CONNECT'ed through ?

-- 
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: Willy Tarreau <[email-masked]>
Date: Tue, 17 Feb 2015 21:12:15 +0100

> I still believe we should actually *fix* the table.

I agree. There are a few minor things that were reported several times
that should be fixed. Grouping all fields for which a default value is
provided together would simplify implementations (eg: accept-charset
vs accept-encoding), sorting them lexicographically as well. Sure it
can be hard to respect both (unless we add missing values) but for now
we help in none of these cases.

Best regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 18 Feb 2015 11:24:54 +1300

> Does that imply that it doesn't cover HTTPS traffic, which pressumably

Ah, Irony.

ROFLMAO.

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Feb 2015 23:42:20 +0000

--------
In message <[email-masked]>, Willy Tarreau writes:

>I agree.

+1

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Feb 2015 10:46:54 +1100

Hi Julian,

> On 18 Feb 2015, at 2:38 am, Julian Reschke <[email-masked]> 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. 

This is even more true at this extremely late stage.

Cheers,

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 18 Feb 2015 00:00:11 +0000

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

>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. 
>

I disagree.

This is a protocol which aims to take over 30% of the traffic
on the web, there are many ways to make material improvements
to the compression part of it, and they are well worth doing.

I will therefore reiterate my considered professional opinion:

This draft is a great prototype for a HTTP/2 protocol, we have
learned a lot from developing it.

Now we should heed Frederick P. Brooks sage advice and throw our
prototype away and start from scratch, as we are now much wiser on
how not to do it right.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 18 Feb 2015 00:05:02 +0000

--------

>prototype away and start from scratch, as we are now much wiser on

s/right//

obviously, it's late here...

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 18 Feb 2015 01:47:52 +0100

>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. I also note that the text Julian quoted needs to be changed re-
gardless of whether the table is "fixed".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Feb 2015 12:48:00 +1100

Bjoern,

> On 18 Feb 2015, at 11:47 am, Bjoern Hoehrmann <[email-masked]> wrote:
> 
> * Mark Nottingham wrote:

The relevant issue is:
  https://github.com/http2/http2-spec/issues/587

Note that was raised as a "non-blocking" issue -- i.e., even when it was raised, we acknowledged that it was only worth doing if other things were changing too.

Here was the resolution:
  http://www.w3.org/mid/[email-masked]

... and this is perhaps relevant context:
  http://www.w3.org/mid/[email-masked]

Of interest may be the experiments Greg ran:
  http://www.w3.org/mid/[email-masked]
... which show that there is negligible change in efficiency when the static table is reduced or changed.

Cheers,

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 08:11:44 +0000

On Wednesday,18 February 2015 02:48, [email-masked] 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:

Apples and oranges. Greg was talking about improving the table efficiency. Julian et al are talking about fixing flat out bugs.

>   http://www.w3.org/mid/[email-masked]

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, [email-masked] 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

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: Greg Wilkins <[email-masked]>
Date: Wed, 18 Feb 2015 19:34:15 +1100

> improvement in the protocol.

For the record, my part of that consensus was based on thinking that we
were bound to make a breaking change at some stage before h2, at least for
the change of version number.   Thus in my process naivety, I fully
expected that the table would be fixed and/or optimised before RFC status

-- 
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: Julian Reschke <[email-masked]>
Date: Wed, 18 Feb 2015 11:30:20 +0100

On 2015-02-18 09:34, Greg Wilkins wrote:
>
> On 18 February 2015 at 10:46, Mark Nottingham <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> were bound to make a breaking change at some stage before h2, at least
> for the change of version number.   Thus in my process naivety, I fully

Same here.

Best regards, Julian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Feb 2015 15:00:55 -0800

On Wed, Feb 18, 2015 at 12:11 AM, <[email-masked]> wrote:

> Apples and oranges. Greg was talking about improving the table efficiency.
> Julian et al are talking about fixing flat out bugs.
>
> I'd like clarification from the AD (Barry?) on the text from this
> "context". To quote (from Mark's link above):
>
> "If there is a minority of folks who have a valid technical objection,
> that objection must be dealt with before consensus can be declared."
>
> [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