Subject: [hybi] More feedback on draft-ietf-hybi-permessage-compression-05

From: Dario Crivelli <[email-masked]>
Date: Mon, 11 Mar 2013 10:55:57 +0100

Hi,

I would like to contribute to the discussion by sending feedback on my
reading of the specification draft, as a potential implementor.

A) permessage-deflate

As far as the "permessage-deflate" extension to the WebSocket protocol is
concerned, it seems to me that the description is complete, although I have
not tried to implement the extension support yet.

For the handshake negotiation part, I acknowledge that the alternative text
proposed by Barry Leiba is clearer, though it does not mention the
requirements on the extension parameters in the response.

In paragraph 5.1.2, I found it difficult to read the sentence:
    Otherwise, the server MUST NOT accept the request with a response with
the parameter.
I suppose it is equivalent to:
    Otherwise, if accepting the request, the server MUST NOT include this
parameter in the response.

The example in paragraph 3.1 reports the "Hello World" parameter value,
with a space in the middle.
Wasn't that unallowed, as also discussed in
http://www.ietf.org/mail-archive/web/hybi/current/msg09904.html ?

I see from the example in paragraph 5.2.3.1 that a compressed text message
still retains the opcode=text flag, so that, after decompression, it will
still be subject to UTF-8 compliance.
This rule may probably be inferred from the context; yet it is not so
obvious, because the "application data" in the resulting frames is not
UTF-8.
Hence, I think it's worth clarifying explicitly, in paragraphs 4.1/4.2,
that the opcode will not change.
In fact, honestly, I'm not able to find, in RFC6455, where it is stated
that the constraints in paragraph 5.6 do not apply to extensions.

B) Per-message Compression Extensions

On the other hand, I cannot understand the scope of the definition of the
"Per-message Compression Extensions" framework concept.
I assume that by "Per-message Compression Extensions" we mean a subset of
extensions to the WebSocket protocol, and that what's being defined is the
common part that any extension definition has to share, in order for its
inclusion in this subset to be claimed.
In this regard, I suggest including a reference to paragraph 9 (or 5.8) of
RFC6455, where the "extension" concept is introduced.

In my opinion, the definition of the boundaries of this subset is not clear.
The WebSocket specification leaves many degrees of freedom to extension
definitions, in terms of reserved bits, opcodes, extension data,
fragmentation, status codes, handshake tokens, and perhaps even more.
The extensions belonging to the "Per-message Compression Extensions" subset
will take advantage of some of these degrees of freedom;
but it is not stated what they will not be allowed to take advantage of.
For instance: can a future extension belonging to this set also reserve the
RSV2 bit?
This would affect whether or not the compatibility rules and other
implementation aspects regarding all extensions in the "Per-message
Compression Extensions" subset could be handled by the same code.

About the compatibility rules, I understand that,
- since compression requires that the whole payload is modified first, and
only then are the frames cast,
- as a consequence, the compression cannot be applied after another
extension which imposes its own requirements on the framing.
But how can I ensure that my implementation will comply with this
constraint?

The proposed specification says:
    Per-message Compression Extensions MUST NOT be used after any extension
for which frame boundary needs to be preserved.
    Per-message Compression Extensions MUST NOT be used after any extension
that uses "Extension data" field or any of the reserved bits on the
WebSocket header as per-frame attribute.

This assumes that any extension can be evaluated as to whether:
- frame boundary needs to be preserved;
- "Extension data" field is used as per-frame attribute;
- any of the reserved bits on the WebSocket header is used as per-frame
attribute.

Should I expect the evaluation of the above predicates to be indicated
somewhere in the specifications of all future extensions?
Or will I be supposed to evaluate these predicates myself from the
extension specification text alone?

Regards
Dario Crivelli

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 12 Mar 2013 17:23:18 +0900

Hi Dario,

Thanks for the feedback.

On Mon, Mar 11, 2013 at 6:55 PM, Dario Crivelli <
[email-masked]> wrote:

> For the handshake negotiation part, I acknowledge that the alternative
> text proposed by Barry Leiba is clearer, though it does not mention the
OK. I've rewritten the whole text for clarification. Please take a look
again when I publish the revised one. I-D submission is closed now for f2f
meeting.

> http://www.ietf.org/mail-archive/web/hybi/current/msg09904.html ?
Oh, right. Fixed.

> that the opcode will not change.

Done.

> that the constraints in paragraph 5.6 do not apply to extensions.
I agree that it's not clarified in the RFC.

> RFC6455, where the "extension" concept is introduced.

Done.

> The extensions belonging to the "Per-message Compression Extensions"
> subset will take advantage of some of these degrees of freedom;

The concept doesn't require/allow/prohibit anything other than the RSV1 bit.

> For instance: can a future extension belonging to this set also reserve
> the RSV2 bit?
>

It may though it needs to be discussed and registered with the registry.

> Compression Extensions" subset could be handled by the same code.
It's not easy to have flexible code to resolve dependency/incompatibility
between offered extensions. Yes.

> extension which imposes its own requirements on the framing.

Right

> But how can I ensure that my implementation will comply with this
I think even the RFC left many degrees of freedom to extension design,
we'll use small subset of combination/order of extensions, and the code for
resolve/integrate extensions support only such a small subset.

>     Per-message Compression Extensions MUST NOT be used after any
> extension for which frame boundary needs to be preserved.
>     Per-message Compression Extensions MUST NOT be used after any
> extension that uses "Extension data" field or any of the reserved bits on
> the WebSocket header as per-frame attribute.
>
Good point. Maybe to evolve WebSocket with lots of extensions and
combination between them, we need to define and maintain some list of
characteristics like them, and suggest that people writing extension specs
to check yes/no for each of them.

It's burden, and that's one of the reasons why RFC6455 was published with
only general concept of extension.

Takeshi