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

["Arman Djusupov" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Takeshi Yoshino
Sent: Friday, May 11, 2012 8:55 AM
To: [e-mail]
Subject: [hybi] Handling multiple compression method entries of the same
extension

 

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?