Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC

["Arman Djusupov" <[e-mail]>]

For me it doesn't make a big difference, I'm OK with going back to the old
way, but we have to remember the reason why we ended up with method
parameter. We did so in order to make compression extensions mutually
exclusive. Plus, the current specification defines the DEFLATE method as
just one of several possible methods, theoretically there can be multiple
methods . If we change to permessage-compress-deflate then the specification
would have to define how the extension name is formed based on the format it
uses.

 

I personally don't mind going back to old way, but AFAIR Tobias was working
on Autobahn's test suite for permessage-compress interoperability. If his
work is already done then reverting the spec again will require re-testing
interop once again.

 

With best regards,

Arman

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Takeshi Yoshino
Sent: Monday, January 07, 2013 6:51 AM
To: Julian Reschke
Cc: [e-mail]
Subject: Re: [hybi] Resolutions for the issues of the compression spec
reported during WGLC

 

Thanks, Julian.

 

On Fri, Jan 4, 2013 at 10:26 PM, Julian Reschke <[e-mail]>
wrote:

I haven't followed the discussions that led to the current design, but this
smells a bit like a case of an over-engineered extension point. Do you
*really* expect that negotiation will have to happen on *paramaters*?

 

No. But see below, please.

 

If this is not the case, it would be *much* simpler to simply define
different tokens for the different schemes and be done. So, for instance:

  Sec-WebSocket-Extensions: permessage-compress-deflate

instead of

  Sec-WebSocket-Extensions: permessage-compress; method=deflate

 

We've discussed that in this thread.

http://www.ietf.org/mail-archive/web/hybi/current/msg09605.html

and made a decision as announced in

http://www.ietf.org/mail-archive/web/hybi/current/msg09618.html

 

There was no strong opinion on either of them. We chose the current design
because:

- to simplify correspondence between a RSV bit and an ext.

- to ease extension list processing by grouping compression method
candidates into one ext.

 

Shall we go back to the old approach? I'm ok with it.

 

Comment please everyone.

 

Keep in mind that if you extend quoted-string to essentially wrap other
name/parameter pairs, you may end up with having to escape double quotes;
and this is asking for trouble for something that really should be easy.