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

Hi Takeshi,

I have implemented extension negotiation per the 04 draft and I can say that the parsing is definitely more complicated and error prone than anything else previously used in the WebSocket protocol, thought not necessarily in the deep corners of HTTP itself. This change should simplify that considerably. I previously didn't have strong feelings either way. The 04 method was more complicated but cleaner and more expressive. The new method was a lot simpler but more messy and verbose at the extension header level.

Looking more closely at my extension negotiation code this morning I think the 1 extension per algorithm is a good idea. Specifically, I noticed that at the extension level I already have a system for evaluating and choosing which extensions to use. Batching multiple sets of extension parameters into the parameter list of a single extension requires a second stage of parameter negotiation that while very similar, is just different enough to need separate per extension parameter negotiation code. Assuming multiple extension values with the same name are still allowed (RFC6455 doesn't seem to forbid it) and the rules about mutual exclusivity between different extensions in the same family are clearly laid out, I don't see any functionality loss. 

For this extension I think this is a good choice. One last question I have though.. will this set a precedent towards simpler extension options that will be a problem for any future extensions that might need it for something other than parameter negotiation?

Peter

On Jan 14, 2013, at 22:30 , Takeshi Yoshino <tyoshino@google.com> wrote:

> Thanks, Arman.
> 
> It passed 1 week since my post calling for comments. Based on:
> - Julian and Arman's comment
> - the fact that we didn't have strong objection to 1 extension per 1 algorithm approach
> I'd like to
> - revert the spec (1 extension per 1 algorithm)
> - but keep text for general compression extension and deflate specific text separate (John Tamplin's opinion)
> - keep the spec name
> - keep framing detail unchanged
> 
> I'll publish it as -05 in a few days. Tell me if you have any objection.
> 
> Best
> Takeshi
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi