Re: [hybi] [permessage-deflate] Renaming s2c_ and c2s_ prefix to server_ and client_

[Takeshi Yoshino <[e-mail]>]

On Wed, Oct 16, 2013 at 12:13 AM, Joakim Erdfelt <[e-mail]> wrote:

> We start by talking of "c2s_" then half way through the first paragraph we
> start talking about "server-to-client" and even point out the "c2s_"
> parameter as an example of the "server-to-client".
>
> The spec mixes the use of "c2s" and "client-to-server" in various places,
> in what we can only assume is sometimes it refers the parameter, sometimes
> it refers to the direction of the conversation, sometimes it refers to the
> extension negotiation step, sometimes it refers to the extension
> negotiation phase.
>

Makes sense.


>
> Months have been spent trying to decipher this spec by multiple people
> with years of experience on ietf specs, both as consumers and participants.
>  the spec should be able to sit on its own, with as clear of definition as
> possible at the time, reducing as much of the "interpretation" and question
> asking that will arise from the spec.
>
> The "2s" and "2c" portions are irrelevant, and actually cause confusion as
> you use the same language elsewhere.
>
> proposal:
>
> "c2s_" used in extension-param tokens should be "client_" to refer to
> "client produced compression"
> "s2c_" used in extension-param tokens should be "server_" to refer to
> "server produced compression"
>
>
Hmm. The key here is the fact that compression is made only on traffic
after connection establishment. That may clarifies things. Only
client-produced and server-produced are still with ambiguity. Server and
client do produce extension parameters. Client_transmitted,
Client_outgoing, Client_egress, ... I think this applies to any of them.

As there's no strong opinion to keep c2s_ and s2c_, I've renamed them to
server_ and client_.


> "client-to-server", and "server-to-client" use within spec should be
> clarified, and never be left without a clarification.
>    when referring to the extension negotiation request phase.
>       consider "extension negotiation request" or "extension negotiation
> offer" for current "client-to-server" use
>       consider "extension negotiation response" or "extension negotiation
> accept" for current "server-to-client" use.
>

Good point. I put these for clarification but they lead to confusions. I
understand. Thanks.


>    when referring to the flow of frames on a connected websocket.
>       this is where the existing "Client-to-Server" terminology is
> consistent with RFC6455 (see Section 5.3<http://tools.ietf.org/html/rfc6455#section-5.3>
> ).
>       so feel free to start using for "Server-to-Client" here as well, but
> not in the above.
>
>
Makes sense! Done.


> another choice is to never leave "Client-to-Server" alone with no
> clarification, always follow it with consistent verbiage, like RFC6455 does.
>
> Its never "Client-to-Server" just to refer to a directionality, its a
> compound concept, such as "Client-to-Server Masking" or "Client-to-Server
> message".
>
> Suspicions/Theories:
>
> The language choices of this spec probably come from the overall attempt
> at being neutral to what side (client or server) the spec is documenting
> from.
> If you look at the overall language of RFC6455, you see that it is
> presented from the point of view of the Client, with the Server roles and
> responsibilities being explained only when needed to.  Otherwise, both
> sides are assumed to be the same in behavior.
> If RFC6455 used the same techniques as the permessage-deflate spec, then
> you'd have 2 sections: Client, fully documented with barely a mention of
> server, then Server, fully documented we barely a mention of client.
>
>
I see, yeah. It must be the source of complexity.


>
> Permessage-deflate could have been documented the same way as RFC6455, but
> it isn't, so now you have extra work to be careful in your language
> choices, eliminate ambiguity, make things more clear.
>
>
> Our the final translation of the permessage-deflate extension spec, as
> written:
>
> Simplified Neutral Language:
> Incoming frames/messages are compressed when RSV1 is set
> Outgoing frames/messages can be compressed, but set RSV1 if you do.
> Configuration of Incoming frames/messages compression is controlled by
> Extension Parameters for the opposite side of yourself.
> Configuration of Outgoing frames/messages compression is controlled by
> Extension Parameters for your side.
>
> Side Specific Language:
> client_* Extension Parameters are for controlling frames/messages
> compression produced by client
> server_* Extension Parameters are for controlling frames/messages
> compression produced by server
>
>
Refined. Please take a look again.


> Here's the example of same Section 8.1.2.2 with the proposed change:
> (quick edit)
>
>
Thanks for providing an example. I believe the new text addressed all of
the edit you made in the same or a bit different way.