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

[Takeshi Yoshino <[e-mail]>]

Hi all,

Thanks for review.

Issues reported during WGLC (ended 2012/Nov/14) except for the ABNF
conflict issue are already addressed and there's -05 staged (not posted
yet.
http://www.ietf.org/staging/draft-ietf-hybi-permessage-compression-05.txt).

==== Resolved issues ====

- Syntax/rules defined in RFC 2616 are used but not referenced
-- http://www.ietf.org/mail-archive/web/hybi/current/msg09902.html
-- FIXED: Added references
- How endpoints should handle bad values (ABNF violation, etc.) is
unspecified
-- http://www.ietf.org/mail-archive/web/hybi/current/msg09912.html
-- FIXED: Specified (ABNF violation -> ignore, wrong extension parameter ->
ignore)
- English grammar issues
-- http://www.ietf.org/mail-archive/web/hybi/current/msg09902.html
-- FIXED
- Add an option to suppress compression on client-to-server data
-- http://www.ietf.org/mail-archive/web/hybi/current/msg09922.html
-- WONT FIX: Didn't receive much support/justification.

- Clarified that the condition list defining bad method descriptions is OR
list (any of them is true then bad)

==== 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.

Thanks
Takeshi