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

From: [email-masked]
Date: Tue, 10 Feb 2015 06:22:26 -0800

A new version (-11) has been submitted for draft-ietf-httpbis-header-compression:
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-compression-11.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-11

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: Barry Leiba <[email-masked]>
Date: Tue, 10 Feb 2015 10:36:11 -0500

This version is ready, and addresses all the comments you think need
to be addressed?

Barry

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 17:01:15 +0100

On 2015-02-10 16:36, Barry Leiba wrote:
> ...

For the record: the static table still contains a header field name 
that's not registered ("refresh"), and I doubt that it's actually used a 
lot on the wire.

I asked about this during LC 
(<https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0074.html>), 
and it would be nice if there was at least an explanation why this can 
not be fixed at this time.

Best regards, Julian

---

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

I overlooked this specific comment.

I just created a pull request for handling it:
https://github.com/http2/http2-spec/pull/714

I can publish a new draft for this and any other comment I would have 
missed.

Cheers,

Hervé.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 20:06:33 +0100

> I can publish a new draft for this and any other comment I would have

Thanks a lot. That explains the state of the table (another oversight is 
the presence of T-E, no?).

I'd still prefer to actually fix the table, given the fact that 
implementations will have to update the ALPN identifier anyway...

Best regards, Julian

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Tue, 10 Feb 2015 20:29:47 +0000

PLEASE, if the static table is open for _minor_ modifications, also
consider these two (I can hear the moans from here):
1) Lexicographical ordering ("accept" should come before "accept-charset")
2) Default header values instead of nothing at all (see
https://github.com/http2/http2-spec/issues/587)

At a minimum, perhaps some wording like in the PR for #1, as I'm sure its
going to cause implementation issues..

- Robby

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Feb 2015 13:41:38 +1100

> https://github.com/http2/http2-spec/pull/714

At this point, an RFC Editor's note is probably more appropriate:

With some of my own edits:

OLD:
-                The static table was created by listing the most common
-                header fields that are valid for messages exchanged inside a
-                HTTP/2 connection.
NEW:
+                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 <xref target="HTTP2" x:fmt="of"
+                    x:rel="#PseudoHeaderFields"/>).

I would not keep the explanation about why the list isn't as good as
we know it could be.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Feb 2015 08:45:24 +0100

> At this point, an RFC Editor's note is probably more appropriate:

Why? The spec isn't even approved yet, no?

> I would not keep the explanation about why the list isn't as good as

I absolutely think that it's needed, because otherwise the same question 
is going to come up again and again.

The best fix of course would be to fix the list. I don't understand why 
that is so hard.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Feb 2015 09:24:41 +0100

> Why? The spec isn't even approved yet, no?

Oh, indeed it was. Silly me.

Best regards, Julian

---

From: Hervé Ruellan <[email-masked]>
Date: Thu, 12 Feb 2015 10:29:03 +0100

Works with me.

Hervé.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 13 Feb 2015 12:06:38 +1100

> The best fix of course would be to fix the list. I don't understand why

Wow,  I really think the IETF needs to consider their process if simple
stupid things like this can be detected by the process and still not fixed.

I thought we had just deferred the fixing of the table until a breaking
binary change - and surely updating from h2-14 to h2-17 and then eventually
to h2 is a binary breaking change that would have allowed us to fix the
table?

So it is a distinct possibility that we will carry these errors in this
table for decades.   Somebody should calculate the carbon emissions we are
going to be responsible for because we didn't go for the small efficiency
gains on offer with an optimised table!

I know I say this a lot, but EPIC FAIL!

-- 
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: Fri, 13 Feb 2015 16:36:04 +1100

Greg,

> On 13 Feb 2015, at 12:06 pm, Greg Wilkins <[email-masked]> wrote:
> 
> The best fix of course would be to fix the list. I don't understand why that is so hard.
> 
> Wow,  I really think the IETF needs to consider their process if simple stupid things like this can be detected by the process and still not fixed.
> 
> I thought we had just deferred the fixing of the table until a breaking binary change - and surely updating from h2-14 to h2-17 and then eventually to h2 is a binary breaking change that would have allowed us to fix the table?

Those aren't breaking changes -- i.e., they don't change the format.

> 
> So it is a distinct possibility that we will carry these errors in this table for decades.   Somebody should calculate the carbon emissions we are going to be responsible for because we didn't go for the small efficiency gains on offer with an optimised table!
> 

Yes...

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Feb 2015 08:54:15 +0100

> Those aren't breaking changes -- i.e., they don't change the format.

For a definition of "format" I happen to disagree with :-)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Feb 2015 11:19:35 +0000

--------
In message <CAH_y2NE5Yi+XixocVmGJmYjqFxSXdAhnnbLu=[email-masked]>

>I know I say this a lot, but EPIC FAIL!

+1

-- 
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: Amos Jeffries <[email-masked]>
Date: Sat, 14 Feb 2015 11:23:47 +1300

>> I know I say this a lot, but EPIC FAIL!

+1 more

Amos

---

From: "Jason T. Greene" <[email-masked]>
Date: Sat, 14 Feb 2015 09:05:22 -0500 (EST)

> On Feb 13, 2015, at 4:29 PM, Amos Jeffries <[email-masked]> wrote:
> 

h2.1? :)