Subject: [hybi] Handling multiple compression method entries of the same extension

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 11 May 2012 14:55:15 +0900

Hi,

I'm going to clarify whether multiple method descriptions with the same
method name is allowed to be listed in the perframe-compress's method
parameter or not.

The benefit of allowing multiple entries is that the client can offer the
same extension with different parameter settings to try to use the best
parameter both endpoints can agree.

There's also a problem with this. The client cannot identify which of the
entries has been accepted by the remote endpoint.

Options we can take are:

----

1-a) disallow use of multiple entries

2-a) tag requested methods
Request:
perframe-compress: method="deflate; id=0; foo=200, deflate; id=1; foo=100,
deflate; id=2; foo=0"
Response:
perframe-compress: method="deflate; id=1; bar=3.14"

2-b) put "rejected" that means the method placed at the corresponding
position in the requested-method-list has been rejected.
Request:
perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate;
foo=0"
Response:
perframe-compress: method="rejected, deflate; bar=3.14, rejected"

2-c) send back not a method description but the index of the description to
accept and server-side parameter
Request:
perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate;
foo=0"
Response:
perframe-compress: accept=1; bar=3.14

2-d) ack the requested parameters by echoing them back to make the
accepted-method-desc self-contained (describing all negotiated parameters)
Request:
perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate;
foo=0"
Response:
perframe-compress: method="deflate; foo=100; bar=3.14"

----

My preference is 2-d). I'll rename max_window_bits and no_context_takeover
by prefixing them.

What do you think?

---

From: "Arman Djusupov" <[email-masked]>
Date: Fri, 11 May 2012 16:41:22 +0300

Agree on the 2-d) choice. What I just don't understand is why you have to
prefix max_window_bits and no_context_takeover?

Note that there is another point which needs to be clarified. Theoretically
the max_window_bits and no_context_takeover can even be asymmetric. It is
possible to implement this extension in such a manner that there is context
takeover in one direction and no content takeover in the other direction.
Unless I missed something, the spec does not require the server to use
exactly the same parameters as the client requested. 

"a server MUST include an element with the "perframe-compress" extension
token as its extension identifier in the "Sec-WebSocket-Extensions" header
in its opening handshake.  The element MUST contain exactly one extension
parameter named "method".  The value of the "method" extension parameter
MUST be a compression method description.  The compression method
description MUST be a *valid response* for any of the methods listed by the
client in its opening handshake."

So it's a bit unclear what is a Valid response, obviously thought it is
compression method specific.

"An endpoint that received this parameter MUST NOT use LZ77 sliding window
size greater than the size specified by this parameter to *build frames*."

So this parameter affects only outbound frames and each side sets the
maximum window size for the remote side, but those parameters are not
currently required to be the same. For example, the client can limit the
server to 12bit window, while the server can set the client maximum to 15;
that would mean that the client is free to use a larger window for sending
messages, while the server has to stick to lower values. There are cases in
which such a design does make sense.

We need to clarify if the parameters must be symmetric or if they may be
asymmetric. If we limit the parameters to be symmetric, I believe this
limitation should specific to the "deflate" method, because other
compression methods might actually favor an asymmetric configuration.

By using option 2-d) an asymmetric configuration is possible. 

Personally I would even like to suggest that we support the asymmetric use
of compression methods (i.e. a different compression method in each
direction) but I'm afraid that someone might point his flame thrower at me
:) Anyone else care to support this? (the asymmetric compression methods,
not the flame thrower.)

With best regards,

Arman 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Friday, May 11, 2012 8:55 AM
To: [email-masked]
Subject: [hybi] Handling multiple compression method entries of the same
extension

Hi,

Options we can take are:

----

Request:

Response:

Request:

Response:

Request:

Response:

Request:

Response:

----

What do you think?

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 11 May 2012 23:31:02 +0900

On Fri, May 11, 2012 at 10:41 PM, Arman Djusupov <[email-masked]> wrote:

> Agree on the 2-d) choice. What I just don’t understand is why you have to
> prefix max_window_bits and no_context_takeover?****
>
> **
>

If we take 2-d), we'll echo back requested client parameters while
sending the server parameters. So, we need to add prefixes to distinguish
them. The example for 2-d) will be like the following for the "deflate"
method.

Request:
perframe-compress: method="deflate; s2c_max_window_bits=15"
Response:
perframe-compress: method="deflate; s2c_max_window_bits=15,
c2s_max_window_bits=8"

> exactly the same parameters as the client requested.

That's exactly what I intended to mean.

> **
>
> “a server MUST include an element with the "perframe-compress" extension
> client in its opening handshake.”****
>
> ** **
>
> So it’s a bit unclear what is a Valid response, obviously thought it is

OK. I'll fix it.

> **
>
> “An endpoint that received this parameter MUST NOT use LZ77 sliding window
> size greater than the size specified by this parameter to *build frames*.”
> ****
>
> ** **
>

Yes.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 11 May 2012 21:03:35 +0200

2-d looks fine to me.

cheers

---

From: Peter Thorson <[email-masked]>
Date: Fri, 11 May 2012 16:40:45 -0500

If this functionality is to be included I think 2-d is the best option.

I am mildly concerned about the increasing complexity of the perframe-compress extension handshake. Is this sort of negotiation common for compression in other protocols?

Peter Thorson

On May 11, 2012, at 0:55, Takeshi Yoshino <[email-masked]> wrote:

> Hi,
> 
> I'm going to clarify whether multiple method descriptions with the same method name is allowed to be listed in the perframe-compress's method parameter or not.
> 
> The benefit of allowing multiple entries is that the client can offer the same extension with different parameter settings to try to use the best parameter both endpoints can agree.
> 
> There's also a problem with this. The client cannot identify which of the entries has been accepted by the remote endpoint.
> 
> Options we can take are:
> 
> ----
> 
> perframe-compress: method="deflate; id=0; foo=200, deflate; id=1; foo=100, deflate; id=2; foo=0"
> Response:
> 2-b) put "rejected" that means the method placed at the corresponding position in the requested-method-list has been rejected.
> Request:
> perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0"
> Response:
> 2-c) send back not a method description but the index of the description to accept and server-side parameter
> Request:
> perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0"
> Response:
> 2-d) ack the requested parameters by echoing them back to make the accepted-method-desc self-contained (describing all negotiated parameters)
> Request:
> perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0"
> Response:
> My preference is 2-d). I'll rename max_window_bits and no_context_takeover by prefixing them.
> 
> What do you think?
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 15 May 2012 14:12:26 +0900

On Sat, May 12, 2012 at 6:40 AM, Peter Thorson <[email-masked]>wrote:

> I am mildly concerned about the increasing complexity of the
> perframe-compress extension handshake. Is this sort of negotiation common
> for compression in other protocols?
>

Suggesting multiple methods and asking the remote peer to choose one from
them and echoing it back is adopted by HTTP for content coding negotiation
(Accept-Encoding and Content-Encoding header).

I'm not sure if this kind of additional compression parameters is common.