On Thu, Jul 28, 2011 at 03:11, Anne van Kesteren <annevk@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
whatwg@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