Subject: [hybi] More minor permessage-deflate notes

From: Peter Thorson <[email-masked]>
Date: Thu, 27 Jun 2013 20:16:46 -0500

8.1.2.1.  s2c_max_window_bits
Using this parameter, a client limits the LZ77 sliding window size that the server uses to compress messages. If the peer server doesn't use small LZ77 sliding window to compress messages, the client can reduce the memory for the LZ77 sliding window.

-> Is this right? Shouldn't it be... if the server *does* use a smaller sliding window then the client can save memory? The description of the reverse later on (for the server) appears correct:

Using this server-to-client parameter, a server limits the LZ77 sliding window size that the client uses to compress messages. This reduces the amount of memory that the server has to reserve for the connection, in the same way the "s2c_max_window_bits" extension parameter does for the client.

--------------------

8.1.2.2.  c2s_max_window_bits
If the parameter has a value, the parameter also tells the peer server a hint that the client is not likely to use LZ77 sliding window size greater than the size specified by the value to compress messages.

-> As with the previous mail. What does "not likely" mean? Announcing only seems useful if it is announcing something more definitive. 

--------------------

Minor grammar issue:

8.1.2.1.  s2c_max_window_bits
A client MAY include the "s2c_no_context_takeover" extension parameter to an offer.

Corrected:
A client MAY attach the "s2c_no_context_takeover" extension parameter to an offer.
OR
A client MAY include the "s2c_no_context_takeover" extension parameter in an offer.

... same error occurs in a few other places ...
- A server MAY include the "s2c_no_context_takeover" extension parameter to a response
- A client MAY include the "c2s_no_context_takeover" extension parameter to an offer.
- A server MAY include the "c2s_no_context_takeover" extension parameter to a response.
- A client MAY include the "s2c_max_window_bits" extension parameter to an offer.
- A server MAY include the "s2c_max_window_bits" extension parameter to a response
- A client MAY include the "c2s_max_window_bits" extension parameter to an offer.

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 28 Jun 2013 12:49:09 +0900

On Fri, Jun 28, 2013 at 10:16 AM, Peter Thorson <[email-masked]>wrote:

> Using this parameter, a client limits the LZ77 sliding window size that
> the server uses to compress messages. If the peer server doesn't use small
> LZ77 sliding window to compress messages, the client can reduce the memory
> for the LZ77 sliding window.
>
> -> Is this right? Shouldn't it be... if the server *does* use a smaller
> sliding window then the client can save memory? The description of the
> reverse later on (for the server) appears correct:
>

Right. Thanks for reporting.

> If the parameter has a value, the parameter also tells the peer server a
> hint that the client is not likely to use LZ77 sliding window size greater
> than the size specified by the value to compress messages.
>
> -> As with the previous mail. What does "not likely" mean? Announcing only
> seems useful if it is announcing something more definitive.
>

Now the response from the server represents all the configuration about
permessage-deflate on the session. If we give some definitive meaning to
client-to-server c2s_max_window_bits, configuration will depend on that too.

We can avoid this by requiring the peer server to acknowledge
c2s_max_window_bits by sending back server-to-client c2s_max_window_bits
equal to or smaller than this value. Then, the client-to-server
c2s_max_window_bits will have a definitive meaning "request
c2s_max_window_bits". I'm not sure if this is meaningful.

> Minor grammar issue:

Thanks. I'll fix them.

---

From: Peter Thorson <[email-masked]>
Date: Fri, 28 Jun 2013 06:19:40 -0500

On Jun 27, 2013, at 22:49 , Takeshi Yoshino <[email-masked]> wrote:

> On Fri, Jun 28, 2013 at 10:16 AM, Peter Thorson <[email-masked]> wrote:
> Now the response from the server represents all the configuration about permessage-deflate on the session. If we give some definitive meaning to client-to-server c2s_max_window_bits, configuration will depend on that too.
> 
> We can avoid this by requiring the peer server to acknowledge c2s_max_window_bits by sending back server-to-client c2s_max_window_bits equal to or smaller than this value. Then, the client-to-server c2s_max_window_bits will have a definitive meaning "request c2s_max_window_bits". I'm not sure if this is meaningful. 

So the idea would be.. 

1. client sends c2s_max_window_bits=10. 
2a. If the server doesn't care (perhaps it only supports the default 15 window) then it can omit that parameter from the negotiation. Client is still free to (but not strictly required to) stay under 10 bits.
2b. If the server understands this and acknowledges by returning c2s_max_window_bits=10, client is now bound by this value and server can reduce memory usage accordingly.

This interpretation wasn't clear to me from the text of the spec. Given your explanation here I think this is a good way to do it.

> Minor grammar issue:
> 
> Thanks. I'll fix them. 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi