On Thu, Jul 28, 2011 at 03:11, Anne van Kesteren <ann...@opera.com> wrote:
> HTML5 is mostly transport-layer agnostic. > HTML5 is transport-layer agnostic though it involves communication with server in handling <a>, <form> element. The WebSocket API specifies much detail of transport-layer. What does make this difference of philosophy in building these specs? If the role of specs for browsers is to define what mainstream modern browsers should behave like, we may mandate gzip for HTTP somewhere. That's what I tried to mean by using the analogy. > I am not sure why we are going through this theoretical side-quest on where > we should state what browsers are required to implement from HTTP to > function. Please see my comment at the bottom half of http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0498.html. I don't intend to focus on the theoretical side-quest. As I said, hearing your and Hixie's opinions, I now understand W3C/WHATWG's position to require some good compression. It's acceptable. Banning something considered to be bad is also fine. So, please ban deflate-stream than requiring it. According to the reply from Hixie to my mail on wha...@whatwg.org http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032650.html, one of the API spec's mission is considered to give clear/normative guideline to browser developers how to implement WebSocket by saying Yes/No on everything listed on the IETF spec. Require X / forbid X are used to make it clear X is required or not required. For extensions listed in the core spec, I may support this aggressive stance (use of forbid) to guide browser developers without ambiguity. But extending this aggressive stance beyond what not listed in the core spec is too much, I think. As far as, A, B, C,... S, T, U, ... cover what listed in the core spec, text like this is enough, I believe. - "A, B, C, ..." must be implemented - "S, T, U, ..." must not be implemented - any other extension are not required to be implemented. No one knows what kind of extensions will finally be taken as the best for WebSocket, yet. Without getting enough data and community support by conducting live experiment, it's unreasonable to require method X and ban the others. While conducting such experiments, user-agents are not standard compliant. If W3C/WHATWG are confident that violating specs is the right way to evolve specs, I'll stop arguing this. Yes, we'll make our browsers standard non-compliant to seek the way to improve WebSocket. > The HTTP protocol has its own set of problems and this is all largely > orthogonal to what we should do with the WebSocket protocol and API. > Sure > If you do not think this particular extension makes sense raise it as a > last call issue with the WebSocket protocol and ask for the API to require > implementations to not support it. Lets not meta-argue about this. Yeah. Getting answer for the meta-argument is not my goal. Thanks, Takeshi