- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 05 Sep 2014 17:05:43 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- cc: Martin Nilsson <nilsson@opera.com>, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <CABkgnnVEyR2BV7gf_BANXN=cF3UbdV=vwEP_vij6bRCgBubVMQ@mail.gmail.com> , Martin Thomson writes: >On 5 September 2014 09:25, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> Can I propose that the origin of the data and the procedure used >> to derive the table be added to the draft as an appendix. > >You certainly can propose pretty much anything you like. I personally >don't see the point. > >I'd be interested in learning why you might think that tampering would >produce a benefit for anyone. There are no accusations of tampering anywhere I can see, and it's not about what I think. This table is a key element in HPACK and therefore their provenance should be documented, if nothing else for historys sake. I found this email: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1196.html Which seems to be for a check-run to see if the current able should be updated ? It doesn't answer my question if HTTP/1 headers which cannot ever be sent through HTTP/2 were filtered out before estimating the PDFs. I'm thinking specifically of: "HTTP/1.1" (HTTP-Version in the status line) Reason-Phrases in the status line Connection: close Connection: keepalive Transfer-Encoding: chunked None of these will pass through HTTP/2.0 and should therefore not be used as training material for HPACK Does anybody know if these headers were removed from the data-set ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Friday, 5 September 2014 17:06:10 UTC