On Thursday, July 07, 2011 3:55 PM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman <[email protected]> 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.

Reply via email to