RE: [websockets] Getting WebSockets API to Last Call

On Thursday, July 07, 2011 3:55 PM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman <adrianba@microsoft.com> wrote:
> > 12917 - "deflate-stream" should be an optional extension when establishing a connection
> > Resolved, WontFix
> > MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec
> > on what is optional in the protocol. The API spec should not normatively mention specific
> > extensions. References to "deflate-stream" should be informative and only provided as examples.
>
> I agree with the WONTFIX here. I think optional parts of
> specifications is a bad thing in the web space and bad for
> interoperability. If we really end up needing the ability to set
> optional parts we can always add that in the future.

I agree with the general principle of not adding optional features. However, I think this case
is different for a couple of reasons:

1) This is optional in the protocol spec. If you don't think it should be optional in the protocol
that argument should be made in the IETF working group. I don't agree that the W3C API should
override the discussions in the protocol working group just because some people don't like the
outcome.

2) This feature is an extension point. Its sole purpose is to support optional features.
Mandating one example of an extension seems arbitrary to me. As soon as there is another
extension there will still be differences. We believe that there will be legitimate
implementations that don't want to support deflate-stream and servers will have to
support with and without to be conforming anyway.

> > 13178 - binaryType should be immutable after connection is established
> > Open, Assigned to Ian Hickson
> > MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.
>
> I don't agree with making binaryType immutable, and I added a comment
> to that effect to the bug. I did also put in another proposal in the
> bug which also aims to reduce implementation complexity and improve
> performance.

Thanks for the feedback on this one. It would be good to get a sense from other
implementers about how there feel here.

Cheers,

Adrian.

Received on Thursday, 7 July 2011 23:06:00 UTC