Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt

[Tobias Oberstein <[e-mail]>]

>     http://code.google.com/p/chromium/issues/detail?id=245732
>     http://code.google.com/p/chromium/issues/detail?id=245719
> 
> 
> Thanks so much.

Thanks for awesome speed with fixing the first!

> 
>     2)
>     If client offers multiple PMCE choices to the server by including
>     multiple elements in the "Sec-WebSocket-Extensions" header and the
>     server supports more than one of the PMCEs offered, is there any
>     preference which PMCE the server SHOULD choose? E.g. the first PMCE
>     in the header that is supported by the server?
> 
>     The description of the examples in "5.1. Negotiation Examples" seem
>     to suggest that the _ordering_ of alternative PMCE offered
>     designates _preference_.
> 
> 
> Yes. Order means preference. The server may choose any even if it 
> supports all of them.
> 
> Do you think we need any text to make it clear?

I think it would clarify things by adding text like

"""
A server MAY choose any PMCE offered by the client and supported by the server.
The order of PMCE offered by the client designates preference by the client and a server SHOULD accept the first offer in the list (by order) that it supports.
"""

This IMHO makes sense and brings the abstract description in line with the text in "5.1. Negotiation Examples".

> 
>     3)
>     """
>         A server MUST decline a "permessage-deflate" offer if any of the
>         following conditions is met:
> 
>         o  The offer has any extension parameter not defined for use in an
>            offer.
> 
>         o  The offer has any extension parameter with an invalid value.
> 
>         o  The offer has multiple extension parameters with the same name.
> 
>         o  The server doesn't support the offered configuration.
>     """
> 
>     So if multiple permessage-deflate PMCEs are offered by the client,
>     the server silently skips any invalid until the first valid or none
>     if there is no single valid one?
> 
>     The server does NOT fail the WS connection upon encountering the
>     first invalid PMCE in the list of offers?
> 
> 
> Yes. As far as there's no WebSocket-core-protocol-level grammar error 
> (extension-param ABNF in RFC 6455), the server doesn't have to fail the 
> connection.

"doesn't have to fail" ..

So a server MAY fail the handshake instead of just skipping bad offers? Confused.

At least for me I have troubles with the word "decline" in "A server MUST decline .."

a) decline = silently skip

OR

b) decline = fail handshake

?

I'd prefer b) - why be too liberal here - , but am ok with a) also .. but please consider defining "decline" in the text.

Sorry: maybe it's just me, but I was really spending time with above question ..

> 
> 
>     4)
>     """
>        A client MUST _Fail the WebSocket Connection_ if the server accepted
>         a "permessage-deflate" offer with a response meeting any of the
>         following condition:
> 
>         o  The response has any extension parameter not defined for use in a
>            response.
> 
>         o  The response has any extension parameter with an invalid value.
> 
>         o  The response has multiple extension parameters with the same
>     name.
> 
>         o  The client doesn't support the configuration the response
>            represents.
>     """
> 
>     This list does not include: "The response corresponds to a PMCE
>     configuration not offered by the client originally".
>     Is this on purpose?
>     (A client may support a configuration which it did not offer .. for
>     whatever reasons)
> 
> 
> Yes. To allow multiple offers but make it unnecessary to identify 
> accepted request (e.g. we need to attach request ID or something to each 
> extension entry to do that), I made permessage-deflate responses 
> self-contained (both client side parameters and server side parameters 
> are listed in a response).
> 
> Each extension has sole discretion to consider what response to be 
> invalid/unsupported.

Lets say a client supports all features, but offers

permessage-deflate; s2c_max_window_bits=10

(hence, no fallback)

and the server responds:

permessage-deflate.

Autobahn client will FAIL that, since the PMCE response from the server does not match any offer, despite the reponse PMCE is supported.

If it would accept that, why would there be a need to offer explicit fallbacks like

permessage-deflate; s2c_max_window_bits=10, permessage-deflate

?