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

[Takeshi Yoshino <[e-mail]>]

Thank you for careful review. I'll address them.

Some questions.


On Wed, Oct 9, 2013 at 12:14 PM, Joakim Erdfelt <[e-mail]> wrote:

>  > what is this trying to say?
>  > starts out by saying that a new key phrase "agreed parameters" is
>  > a mandatory representation of all parameters that can determine
>  > the behavior of incoming vs outgoing frames.  Then it adds on the
>  > confusing part about about the parameters being unnessary to use
>  > to identify which offer has been accepted.  That's counter to
>  > how this extension works later in the same document, even the
>  > example in same paragraph.
>

How about

"Agreed parameters" MUST represent how the requests and hints in the
client's offer have been handled in addition to the server's requests and
hints on the client's behavior, so that the client can configure its
behavior without identifying which PMCE offer has been accepted.


>
>    For example, if a client
>    sends an offer with a parameter "enable_compression" and another
>    without the parameter, the server accepts the former by sending back
>    an element including a parameter that acknowledges
>    "enable_compression".  The name of the acknowledging parameter
>    doesn't need to be the same as the offer.
>
>  > to put this another way, like the example hints at.
>  > the client makes an offer, identifying 2 sets of parameters.
>  > how it wants to talk to server, and how it wants the server to
>  > talk to it.
>  > the server will use the stated client side configuration/behavior,
>  > if it can, (otherwise it doesn't negotiate the extension), and
>  > then make a determination of its own configuration/behavior,
>  > based on hints provided in the client request extension /
>  > negotiation, and respond to the extension negotiation with
>  > how it is expecting the client communications and how it
>  > will communicate to the client.  If the client doesn't like
>  > it, then the client closes with close code 1010.
>

Thanks for the suggestion. Made some rephrasing. Please take a look:

----

Though how to handle parameters in detail will be specified in the
specifications for each PMCEs, general negotiation flow will be like this:

A client makes an offer including parameters identifying the followings:
- Hints about how the client is planning to compress data
- Requests about how the server compresses data
- Limitation of the client's compression functionality

The peer server uses these parameters, makes a determination of its
behavior based on them if it can and wants to proceed with this PMCE
enabled, and responds to the client with parameters identifying the
followings:
- Requests about how the client compresses data
- How the server will compress data

The client uses these parameters from the server make a determination of
its behavior based on them if it can and wants to proceed.
Otherwise, the client starts closing handshake with close code 1010.

----


>  > We see the new language for s2c_ and c2s_, but still think these are
>  > awful choices, and will point out why this language just adds to the
>  > confusion later in the spec.
>
>  > The added language about the directionality is useful.
>
>  > 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 thought like this: Each client does both compression and
decompression. Their compression parameters can differ. So, it'd be better
prefixing them with explicit words about direction (or together with words
like _trasmitted or _outgoing. I.e. server_transmitted, client_transmitted,
server_outgoing, server_incoming).

But looking at them again, I see that it's not so unclear that they're
about compressing operation.

I'm fine with that renaming.


>           permessage-foo; use_y, permessage-foo
>
>  > suggest eliminating this entirely.
>  > we believe this to be an improper interpretation of the extension
>  > rules in RFC6455.
>  > Basically, Extensions should not be aware of each other, but rather
>  > have some rules that apply equally to all extensions in a consistent
>  > behavior.
>

Are you suggesting that we drop the feature of multiple configuration
offering?


>   > If we have extensions that need to be aware of each other in order
>  > to know if they can run or not, then you put the burden of all
>  > future extensions to be aware of all other extensions.
>

I agree that without some O(n)-like rule, it's very hard to resolve
conflict of extensions. In pywebsocket, we experienced that, yes.


>   > If an offer arrives with all of these ..
>  >   Sec-WebSocket-Extension: interleaving, metadata, gpgsig,
> permessage-deflate
>  >
>  > What should the base RFC6455 do to negotiate this?
>  >   1) one path would be to not respond with metadata or
> permessage-deflate
>  >      as both declare RSV1 bit use, and that's a conflict.  This is the
>  >      behavior outlined in RFC6455, but the reasons for conflict are lost
>  >      as theres no mechanism to communicate this conflict.
>  >   2) another path would be to fail the handshake with an HTTP response
> code 400
>  >      with details about the conflict.
>  >   3) a first-to-file approach could also be used, and if there is a RSV1
>  >      conflict, the first one in the offer to declare it is the one that
>  >      will be used, and all subsequent RSV1 declarations will not be
> used.
>  >   4) extension spec specific fallback behavior (as outlined in the
>  >      current permessage-deflate spec)
>  >      This is a variation to the first-to-file approach, but instead of
>  >      first to file, its first to negotiate successfully, causing all
>  >      downstream conflicting extensions to never be negotiated.
>  >
>  > You might be leaning towards #3 or #4, but wait!  Mux changes the rules
> again.
>  > If during mux you see an offer like this ...
>  >   Sec-WebSocket-Extension: metadata, mux, permessage-deflate
>  > Then the physical connection will be using metadata, and the
>  > all of the virtual connection (channels) will be using
> permessage-deflate.
>

Yes, handling of mux is complex...

I thought that it's not realistic to have generalize rule but get consensus
on how to handle special extensions such as mux e.g. mux needs to be
resolved first.

Except for such special things, basically resolution should happen based on
combination of (3) and (4) ((4) only inside subgroup like a set of PMCEs
listed in sequence) and the client should be aware of that to decide the
order of offers properly.


>
>  > Now, to go back to the example in the spec documentation.
>  >    permessage-foo; use_y, permessage-foo
>

As far as PMCEs are grouped together, it should be easy to resolve between
them and choose one.