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

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Jan 2013 14:26:38 +0100

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 7 Jan 2013 13:50:55 +0900

Thanks, Julian.

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

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

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 7 Jan 2013 13:58:55 +0900

> - introduces a new header not defined in 6455

I got a request from chairs to elaborate why I considered this to be a
disadvantage. Here are my thoughts about this.

1) To keep it able to use the same extension multiple times, we have to
associate entries in the Sec-WebSocket-Compression-Spec header with entries
in the Sec-WebSocket-Extensions header by adding ID for each of them.

Sec-WebSocket-Extensions: permessage-compress; id=0, bar-ext,
permessage-compress; id=1
Sec-WebSocket-Compression-Spec: id=0; max_win...
Sec-WebSocket-Compression-Spec: id=1; max_win...

This complicates the spec more than putting everything together in the
Sec-WebSocket-Extensions.

2) Everyone knows Sec-WebSocket-Extensions, but not
Sec-WebSocket-Compression-Spec. It's possible that headers not defined in
RFC 6455 are filtered out by some firewall, proxy, etc. For these two
extensions, it's ok since they're going to be well-known. But this approach
misguides everyone that extension configuration that doesn't fit should go
outside of Sec-WebSocket-Extensions. In the future, there'll be lots of
headers that intermediary developers must take care of.

---

From: "Arman Djusupov" <[email-masked]>
Date: Thu, 10 Jan 2013 16:12:02 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Monday, January 07, 2013 6:51 AM
To: Julian Reschke
Cc: [email-masked]
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 <[email-masked]>
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*?

instead of

Comment please everyone.

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 15 Jan 2013 13:30:04 +0900

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

---

From: "Arman Djusupov" <[email-masked]>
Date: Tue, 15 Jan 2013 13:00:55 +0200

Hello Takeshi,

That's fine with me.

But will the specification define the rules for naming extensions that use
other algorithms, and a general guideline on how to serialize compressed
data into frames? Or from now on this specification will cover only deflate
compression ?

With best regards,

Arman

From: Takeshi Yoshino [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2013 6:30 AM
To: Arman Djusupov
Cc: Julian Reschke; [email-masked]
Subject: Re: [hybi] Resolutions for the issues of the compression spec
reported during WGLC

Thanks, Arman.

I'd like to

- keep the spec name

Best

Takeshi

---

From: Peter Thorson <[email-masked]>
Date: Tue, 15 Jan 2013 06:05:40 -0600

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 <[email-masked]> wrote:

> - the fact that we didn't have strong objection to 1 extension per 1 algorithm approach
> I'd like to
> - but keep text for general compression extension and deflate specific text separate (John Tamplin's opinion)
> - keep the spec name
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi