Eliot, On May 29, 2014, at 12:57 PM, Eliot Lear <lear@cisco.com> wrote: >> ... >> I haven't seen any justification for creating a protocol variation. >> See Section 3.4 of RFC 6709: >> http://tools.ietf.org/html/rfc6709#section-3.4 > > That's really not the intent, if not the reading, of that section. A > variation occurs within a protocol, and the key focus of that text is > one of assuring interoperability with means to identify among the > communicating systems that different rules in play. Here there are > clear mechanisms to do that. They are talking about a separate clearly > identified protocol. Whether or not a separate protocol is warranted is > a different discussion. Michael says yes. I didn't say anything about a separate protocol. I have filed an issue and mentioned on several occasions that I would like a setting (that can be passed in the initial HTTP/2 setup) to disable Huffman, just as we have a setting for the header table size. I don't think that would be overwhelming to test or implement, and since we are already asking implementations to track header representations that must be preserved (literal headers without indexing) I don't think it would be stretch to have a way to say "do not Huffman compress at all". _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Friday, 30 May 2014 14:09:24 UTC