Re: [hybi] Restarting IESG review on permessage-deflate

[Joakim Erdfelt <[e-mail]>]

On Fri, Oct 4, 2013 at 8:57 AM, Tobias Oberstein <
[e-mail]> wrote:

> >>>We also find the nature of configuration parameters awkward (even if
> >>>Java supported these specific ones) The whole "s2c" and "c2s" prefix
> noise is unnecessary.
> >>
> >>No, it's not.
>
> >What is your reasoning?
>
> We need to differentiate between parameter offers and parameter accepts,
> and do that for both directions.
>
> If there is no prefix, both client and server would only be able to use
> the same parameters for both directions.
>
>
That's desired actually, and consistent with behavior of other protocols
and extensions (mux for example).
The websocket handshake is always client initiated to server.
The client always says what it desires on the handshake request.  (this is
the spec "c2s")
The server always says what it can do on the handshake response.  (this is
the spec "s2c")
Where does the need for the "s2c" and "c2s" prefixes come from?
Even the justification for them in the permessage-deflate spec is lacking.

To put it another way:

Handshake Request:
"c2s_no_context_takeover"
"c2s_max_window_bits"

Handshake Response:
"s2c_no_context_takeover"
"s2c_max_window_bits"

The spec use of these prefixes is unclear at best, and downright misleading
at worst.
If the spec is trying to say something like this ...

   Hi, I'm the client, I want to talk to you using 1 set of configurations,
and I want you to talk back to me on a different set of configurations.

... then this is not made clear in
http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-12

And If this is the intention, make it clear, in the spec, that the whole
point of the prefixes is to have different configurations for incoming vs
outgoing frames. (and explain the pros and cons of this)

- Joakim