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

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 9 Oct 2013 17:06:35 +0900

(Splitting into an independent thread)

Joakim suggested that we should rename them.
http://www.ietf.org/mail-archive/web/hybi/current/msg10201.html
 > Since all websocket communications are initiated by client to server
 > these should just be s/s2c_/server_/g and s/c2s_/client_/g

Initially, I chose these prefixes to make it easy to understand that
they're attributes for each direction by including source and destination
explicitly. But server_ and client_ are not so confusing, too. As these
parameters are request about the peer's output, everyone should understand
X_no_context_takeover and X_max_window_bits as parameters instructing
compressor of X.

If we do this, we should do this right now. I don't have strong opinion
about this change. If there's no objection, I'll take it.

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 9 Oct 2013 01:14:25 -0700

I have no strong opinion either. But if we change, then now (before Chrome gets shipped with compression enabled ..)

/Tobias

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Takeshi Yoshino
Gesendet: Mittwoch, 9. Oktober 2013 10:07
An: [email-masked]
Betreff: [hybi] [permessage-deflate] Renaming s2c_ and c2s_ prefix to server_ and client_

 > these should just be s/s2c_/server_/g and s/c2s_/client_/g

Initially, I chose these prefixes to make it easy to understand that they're attributes for each direction by including source and destination explicitly. But server_ and client_ are not so confusing, too. As these parameters are request about the peer's output, everyone should understand X_no_context_takeover and X_max_window_bits as parameters instructing compressor of X.

If we do this, we should do this right now. I don't have strong opinion about this change. If there's no objection, I'll take it.

---

From: Peter Thorson <[email-masked]>
Date: Wed, 9 Oct 2013 09:16:22 -0500

Mostly neutral here with a slight preference for s2c/c2s vs server_/client_ for the following reason:

server_no_context_takeover

If I am a server receiving a message does this parameter apply to me? well it says server.. but in fact it doesn't.
If I am a client receiving a message does this parameter apply to me? well it says server.. but in fact it does.

s2c_no_context_takeover

If I am a server receiving a message does this parameter apply to me? In the prefix, server is not in the receiving position, does not apply.
If I am a client receiving a message does this parameter apply to me? In the prefix, client is in the receiving position, does apply.

The original relies on the spec to encode the fact that the s and c in s2c are "server" and "client". The proposal relies on the spec to encode the fact that server_ implies server to client. I found the explicit mention of both ends in the parameter helpful for quickly working out whether a particular parameter applied to a particular piece of code without referencing the spec.

Whether that outweighs the initial cryptic-ness of "s2c/c2s" I don't have a strong opinion on. I'd prefer server_no_context_takeover to server_to_client_no_context_takeover. In the grand scheme of things the difference is minor and I'll be fine with updating WebSocket++ either way.

Peter

On Oct 9, 2013, at 3:06 , Takeshi Yoshino <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 15 Oct 2013 23:08:49 +0900

Thanks, all.

Joakim, please show Jetty's opinion again. Then, I'll make decision to move
forward.

Tobias: neutral
Peter: neutral slight preference for s2c_
Takeshi: neutral slight preference for s2c_
Joakim: preference for server_

---

From: Joakim Erdfelt <[email-masked]>
Date: Tue, 15 Oct 2013 08:13:24 -0700

The problem is the language choices in the spec already.

Take this for example: (from Section
8.1.2.2<http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-13#section-8.1.2.2>of
draft-ietf-hybi-permessage-compression-13)

8.1.2.2.  c2s_max_window_bits

   A client MAY include the "c2s_max_window_bits" extension parameter in
   an offer.  This parameter has no value or a decimal integer value
   without leading zeroes between 8 to 15 inclusive indicating the
   base-2 logarithm of the LZ77 sliding window size.  Using this
   parameter, a client tells the peer server that the client supports
   the server-to-client "c2s_max_window_bits" extension parameter.  If
   the parameter has a value, the parameter also tells the peer server a
   hint that even if the server sends the "c2s_max_window_bits"
   extension parameter with a bigger value or doesn't send it at all,
   the client is not going to use LZ77 sliding window size greater than
   the size specified by the value to compress messages.

   If a received offer has the "c2s_max_window_bits" extension
   parameter, the server MAY include the "c2s_max_window_bits" extension
   parameter in the response to the offer.  If the "c2s_max_window_bits"
   extension parameter in the received offer has a value, the server may
   either ignore this value or use this value to avoid allocating an
   unnecessarily big LZ77 sliding window by specifying
   "c2s_max_window_bits" extension parameter with a value equal to or
   smaller than the received value in the response.  This server-to-
   client parameter has a decimal integer value without leading zeroes
   between 8 to 15 inclusive indicating the base-2 logarithm of the LZ77
   sliding window size.

       c2s_max_window_bits = 1*DIGIT

   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.

   If a received offer doesn't have the "c2s_max_window_bits" extension
   parameter, the server MUST NOT include the "c2s_max_window_bits"
   extension parameter in the response to the offer.

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.

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"

"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.
   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.

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.

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

Here's the example of same Section 8.1.2.2 with the proposed change: (quick
edit)

8.1.2.2.  client_max_window_bits

   A client MAY include the "client_max_window_bits" extension parameter in
   an extension negotiation offer.  This parameter MAY have no value or a
decimal integer value
   without leading zeroes between 8 to 15 inclusive indicating the
   base-2 logarithm of the LZ77 sliding window size.  The use of this
   parameter in a extension negotiation offer informs the peer server that
   the client supports the "client_max_window_bits" extension parameter.
   If the parameter has a value, the parameter also tells the peer server a
   hint that even if the server sends the "client_max_window_bits"
   extension parameter on the extension negotiation response with a bigger
value,
   or doesn't send it at all, the client is not going to use LZ77 sliding
window
   size greater than the size specified by the value to compress messages.

   If a received extension negotiation offer has the
"client_max_window_bits" extension
   parameter, the server MAY include the "client_max_window_bits" extension
   parameter in the extension negotiation response.  If the
"client_max_window_bits"
   extension parameter in the received extension negotiation offer has a
value, the server may
   either ignore this value or use this value to avoid allocating an
   unnecessarily big LZ77 sliding window by specifying
   "client_max_window_bits" extension parameter with a value equal to or
   smaller than the received value in the response.
   The extension negotiation accept parameter value MUST have a decimal
   integer value without leading zeroes between 8 to 15 inclusive
   indicating the base-2 logarithm of the LZ77 sliding window size.

       client_max_window_bits = 1*DIGIT

   The use of the extension negotiation response parameter allows a server
to limit 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 "server_max_window_bits" extension
   parameter does for the client.

   If a received extension negotiation offer doesn't have the
"client_max_window_bits" extension
   parameter, the server MUST NOT include the "client_max_window_bits"
   extension parameter in the extension negotiation response to the offer.

Hope this helps explain where we are coming from.

--
Joakim Erdfelt <[email-masked]>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org

On Tue, Oct 15, 2013 at 7:08 AM, Takeshi Yoshino <[email-masked]>wrote:

> Thanks, all.
>
> Joakim, please show Jetty's opinion again. Then, I'll make decision to
> move forward.
>
> Tobias: neutral

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 16 Oct 2013 18:13:45 +0900

> extension negotiation step, sometimes it refers to the extension

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
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_.

> accept" for current "server-to-client" use.

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

> consistent with RFC6455 (see Section 5.3<http://tools.ietf.org/html/rfc6455#section-5.3>
> ).
Makes sense! Done.

> 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.
I see, yeah. It must be the source of complexity.

> 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.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 16 Oct 2013 18:19:23 +0900

Decision: rename to server_ and client_

Published -15. Please take a look.

With Chrome developer hat: We'll try to turn on permessage-deflate with the
new parameter naming on Chrome by default soon unless we see any objection
to the renaming with reasonable justification.

Thanks.

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 17 Oct 2013 00:38:07 -0700

>With Chrome developer hat: We'll try to turn on permessage-deflate with the new parameter naming on Chrome by default soon unless we see any objection to >the renaming with reasonable justification.

Ok, fine. If possible, please drop a notification here when Chrome/Chromium has done so .. so we can test asap.

/Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Sun, 20 Oct 2013 03:20:37 +0900

Renaming is done and rolled out to canary (32.0.1675.*). Still behind flag
(use --enable-experimental-web-platform-features or turn it on at
chrome://flags).

On Thu, Oct 17, 2013 at 4:38 PM, Tobias Oberstein <
[email-masked]> wrote:

> >With Chrome developer hat: We'll try to turn on permessage-deflate with
> the new parameter naming on Chrome by default soon unless we see any
> objection to >the renaming with reasonable justification.
>
> Ok, fine. If possible, please drop a notification here when
> Chrome/Chromium has done so .. so we can test asap.
>
> /Tobias
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 21 Oct 2013 12:35:53 +0900

> (use --enable-experimental-web-platform-features or turn it on at

Sorry. The commandline flag doesn't work. Please go to
chrome://flags/#enable-websocket-experimental-implementation and click
"Enable".

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 21 Oct 2013 08:50:49 -0700

Hi Takeshi,

AutobahnPython 0.6.4 has been adjusted and published:

https://pypi.python.org/pypi/autobahn
https://github.com/tavendo/AutobahnPython/blob/master/CHANGELOG.md

Tested with canary 32.0.1677.0: no issues found .. I've tested a couple of negotiated parameter sets also.

We will extend AutobahnTestsuite for _systematic_ testing of various parameter sets ..

>From my side, there is only 1 minor point left .. see below. I just want to raise it for completeness, but am happy if Draft-15 makes it into final RFC also.

Sidenote: I've seen that Chrome will log extensions negotiated in Web inspector also. Nice nice. Thanks. It seems just hours away .. mine does not have it yet. Anyway: reckless pace! Awesome.

/Tobias

Proposal: Make support for "no context takeover" optional, and consequently announce "client_no_context_takeover".

That makes the whole parameter negotiation more "consistent" and allows implementors who do not want to implement "no context takeover" for whatever reasons (technically, it should be possible to do always, but ..).

Chrome announces:

1. Sec-WebSocket-Extensions:
permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
and supports "client_no_context_takeover", but that is implicit, not explicit.

Autobahn (client) currently (deliberately) announces:

Sec-WebSocket-Extensions: permessage-deflate; client_no_context_takeover; client_max_window_bits

hence _explicitly_ announces "client_no_context_takeover"

===

Should above _not_ go into the final spec, AutobahnPython will then of course comply (and remove the announcement) when the RFC is issued.

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 22 Oct 2013 15:16:44 +0900

> We will extend AutobahnTestsuite for _systematic_ testing of various

Thank you!

> From my side, there is only 1 minor point left .. see below. I just want
> to raise it for completeness, but am happy if Draft-15 makes it into final
> RFC also.
>
> Sidenote: I've seen that Chrome will log extensions negotiated in Web
> inspector also. Nice nice. Thanks. It seems just hours away .. mine does
> not have it yet. Anyway: reckless pace! Awesome.
>

Yes. It has been unexpectedly dropped. We've fixed it recently.

>
> /Tobias
>
>
> Proposal: Make support for "no context takeover" optional, and
> consequently announce "client_no_context_takeover".
>
> That makes the whole parameter negotiation more "consistent" and allows
> implementors who do not want to implement "no context takeover" for
> whatever reasons (technically, it should be possible to do always, but ..).
>
>
As you know, we've given the role as a hint to client_no_context_takeover
parameter in a negotiation offer, that syntax is not available for
capability announcement now. So, we need to introduce a new syntax for hint
like:

client_no_context_takeover=likely

to free the syntax "client_no_context_takeover without a value" for
capability announcement. Or instead, we need to drop the hint feature.

Maybe Java users like Joakim would be happier with having MUST there than
SHOULD?

> Should above _not_ go into the final spec, AutobahnPython will then of
> course comply (and remove the announcement) when the RFC is issued.
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 23 Oct 2013 18:20:35 +0900

Now permessage-deflate is enabled by default on Chrome canary.