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

[Takeshi Yoshino <[e-mail]>]

Hi Dario,

Thanks for the feedback.

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

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


>
> 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 ?
>
>
Oh, right. Fixed.


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

Done.


> 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.
>
>
I agree that it's not clarified in the RFC.


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

Done.


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

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.


> 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.
>
>
It's not easy to have flexible code to resolve dependency/incompatibility
between offered extensions. Yes.


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

Right


> But how can I ensure that my implementation will comply with this
> constraint?
>
>
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.


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