Subject: [hybi] Compression spec decoupling

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 26 Apr 2012 13:23:47 +0900

As the target data is close, I'd like to list options with concrete
examples and call for opinions to settle this topic.

See also this thread:
http://www.ietf.org/mail-archive/web/hybi/current/msg09469.html

We have two options.
(I saw slight objection to add a new handshake header to pass
algorithm parameter in f2f meeting)

a) One per-frame compression extension for all compression algorithm

draft-ietf-hybi-websocket-perframe-compression defines
- an extension "perframe-compress" and how it frames data including usage
of RSV1
- an extension parameter "algorithm" and its format
- an algorithm parameter "deflate" and how it transforms data

RSV1 is given to perframe-compress extension. It might make incompatible
extension checking easier.

There something does "per-frame compression" but needs framing beyond what
we define in this spec might come in the future. Then, we need to choose
either of break this 1:1 assignment or forbid it to use RSV1.

Example:
Sec-WebSocket-Extensions: perframe-compress; algorithm="foo;
foo-param1=123, bar; bar-param1=abc"; general-param1=xyz", ...

Example (with mux):
Sec-WebSocket-Extensions: perframe-compress; algorithm="... (algorithms for
pre-mux) ...", mux, perframe-compress; algorithm="... (algorithms for
post-mux) ..."

b) One extension for each per-frame compression algorithm

draft-ietf-hybi-websocket-perframe-compression defines
- a method how to frame data with per-frame compression including usage of
RSV1
- an extension "deflate-frame" which uses the framing method and how to
transforms data

RSV1 is given to any extension that does per-frame compression. Endpoints
need to sort out mutually exclusive extensions.

Any future per-frame compression extension may or may not refer to the
framing method defined in draft-ietf-hybi-websocket-perframe-compression.

Example:
Sec-WebSocket-Extensions: foo-compress; foo-param1=123, bar-compress;
bar-param-1=abc, ...

Example (with mux):
Sec-WebSocket-Extensions: ... (extensions for pre-mux) ...", mux, ...
(extensions for post-mux) ..."

---

From: John Tamplin <[email-masked]>
Date: Thu, 26 Apr 2012 00:29:59 -0400

> examples and call for opinions to settle this topic.

I am fine with either, as long as if it is option b) the spec is mostly
about the generic per-frame compression extension, and the
deflate-compression mandatory extension is confined to one section.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: "Arman Djusupov" <[email-masked]>
Date: Thu, 26 Apr 2012 12:11:16 +0300

I'm also fine with both options.

With best regards,

Arman

From: Takeshi Yoshino [mailto:[email-masked]] 
Sent: Thursday, April 26, 2012 7:24 AM
To: [email-masked]; John Tamplin; Arman Djusupov; Greg Wilkins
Subject: Compression spec decoupling

As the target data is close, I'd like to list options with concrete examples
and call for opinions to settle this topic.

See also this thread:

We have two options.

(I saw slight objection to add a new handshake header to pass algorithm
parameter in f2f meeting)

- an extension "perframe-compress" and how it frames data including usage of
RSV1

Example:

Sec-WebSocket-Extensions: perframe-compress; algorithm="foo; foo-param1=123,
bar; bar-param1=abc"; general-param1=xyz", ...

Example (with mux):

Example:

Example (with mux):

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 26 Apr 2012 19:12:41 +1000

I prefer a) to b),  but don't strongly object to b)

cheers

On 26 April 2012 19:11, Arman Djusupov <[email-masked]> wrote:
> I’m also fine with both options.
>
>
>
> With best regards,
>
> Arman
>
>
>
> See also this
> thread: http://www.ietf.org/mail-archive/web/hybi/current/msg09469.html
>
>
>
> We have two options.
>