Subject: Re: Negotiating compression

From: David Krauss <[email-masked]>
Date: Sun, 1 Jun 2014 16:20:27 +0800

On 2014–06–01, at 1:30 PM, Amos Jeffries <[email-masked]> wrote:

> As a result we need a halfway operation to prevent the existing huffman
> table being used. The best proposal for that so far is the
> disable-huffman SETTING. Which downgrades it from the existing table to
> none rather that changing to an arbitrary alternative table.

I’m not sure how this relates to the previous message, which was about the idea of allowing upgrades to a better table. We already have a facility to disable compression per header for security reasons.

> The simplicity gained for naive implementations is an added bonus.

Naive implementations may wish to hard-code request frames. If Huffman may be disabled for servers, then hard-coded clients must never use it. But, small implementations would often benefit from minimizing transmitted data.

So, it might not be a good idea to allow servers (origin or intermediary) to disable Huffman.

As for complexity, my C library compiles to under one kilobyte and I have placed it in the public domain. In terms of implementation effort, it’s only a matter of finding such a library in one’s chosen language.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Jun 2014 07:26:45 +0200

On 5/30/14, 4:08 PM, Michael Sweet wrote:
> Eliot,
>
> On May 29, 2014, at 12:57 PM, Eliot Lear <[email-masked]> 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.

But that is how it would be implemented, as far as TLS is concerned,
unless you're taking a roundtrip hit.

Eliot