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

[Julian Reschke <[e-mail]>]

On 2012-12-17 05:28, Takeshi Yoshino wrote:
> ...
> ==== Open issue ====
>
> - Conflict between "method" extension parameter spec and RFC 6455
> -- http://www.ietf.org/mail-archive/web/hybi/current/msg09904.html
>
> Possible solutions are:
>
> a) revise RFC 6455 by replacing constraint on quoted-string from "token"
> to CHAR - CTL
> pros:
> - human readable
> cons:
> - needs very strong justification to change 6455
> -- existing implementations strictly conform to 6455 will "Fail" when
> method parameter including space, semicolon, etc. instead of just
> rejecting the extension
> -- there might be any private-use extension that manipulates extensions
> header assuming extension parameters conform to token after unquote
>
> b) move the method parameter into a new separate handshake header entry
> pros:
> - human readable
> cons:
> - introduces a new header not defined in 6455
>
> c) use hex-encoding to token-ize the method parameter string (for
> compatibility, use method_hex as the extension parameter name)
> pros:
> - just addition of well-known simple encoding. no change outside of
> Sec-WebSocket-Extensions header
> cons:
> - not human readable
>
> My thought:
>
> I think it can be considered to be a bug that the token constraint is
> making extension header hard to carry structured data. But as listed
> above, there're difficulties to adopt (a).
>
> (c) sounds like the most feasible interim solution.
> ...

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

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.

Best regards, Julian