It's an option in the protocol, but why would we make it an option in the API?

The protocol spec speaks for itself and it is an optional feature there. The API spec shouldn't mandate anything that isn't required for the API. The API spec doesn't need to require support for "deflate-stream"; it doesn't need to say anything normatively about it.

I'm not proposing it be an option in the API, I'm saying that the extensions list may contain "deflate-stream" or it may not - it just depends what extensions the implementation supports. The way the spec is written is ambiguous: the informative language says 'Currently this will only ever be either the empty string or "deflate-stream"' but then the normative text describing the constructor says extensions will be 'a list containing just "deflate-stream" for the extensions'. An implementation without extensions will have the empty string here instead.

We do have to say something normatively about it, because otherwise different UAs will have different sets of extensions supported, which would be an interoperability nightmare.

The spec isn't contradicting itself; the extensions sent from the UA must include 'deflate-stream', but the extensions the server returns might not include it, hence the attribute will either be the empty string or the 'deflate-stream' string.

The point of extensions is that they are not a mandatory part of the spec. They are not required for interop. It is perfectly possible to make a client and service work without deflate-stream. Just as the extension is optional for a service, it should be optional for a client. I don't understand why this is an interoperability nightmare - it's part of the extensibility mechanism in the protocol.

IMHO, adding extensions like this is one of the ways the IETF broke the protocol. We're not going to extend this breakage into the API as well, it's bad enough that servers are allowed to do this kind of thing.

If different browsers randomly decide to include or exclude compression, servers are just going to get confused and have weird bugs. To get good interoperability, browsers have to act as close to identical to each other as possible.

Objections about how the IETF defined extensions in the protocol should be dealt with at the IETF. They don't belong in the API specification at W3C.

The protocol specifically makes support of deflate-stream a MAY and there's no reason a conforming implementation of the API needs to be required to implement this option. There are reasonable use cases for simple UAs (say in embedded systems) not to need this additional complexity.

It's also not clear that deflate-stream will be the most successful approach to compression. For example, Google has proposed an alternative: http://tools.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-00.txt

1) Maybe a bit off topic, but first I'd like to clarify what the interface provided by protocol side for the protocol user (here it's "the WebSocket API") to tell what extension to use (request) actually is.

/extensions/ has been added to client requirement on HyBi 08. It's saying "a list of /protocols/ and /extensions/ to be used." is given by the protocol user.

Different from other parameters (/host/, /port/, /resource name/, /secure/ and /protocols/), what extension to use is not likely to be fully under the control of the protocol user, I think.

Actually, other than compression, we're going to introduce multiplexing extension. It will be automatically handled by the UA. Some hints may be given by JavaScript but basically it's hidden to the WebSocket API (except the point that extension property indicates multiplexing is being used).

So, the interface "/extensions/" exposed by the protocol is a kind of "suggestion" or "required extension list" about extension, not directly connected to actual value sent in Sec-WebSocket-Extensions.

This point is not clear on the latest WebSocket protocol spec.

----

2) I agree that it's good to encourage most of browsers to have identical and ideal implementation. But this requirement doesn't really help, I think.

It can encourage browsers and servers to support deflate-stream, but as Adrian pointed out, non browser UAs are free to be implemented without deflate-stream. In addition, server developers would care only the protocol spec. So, servers would simply accept both requests with deflate-stream and ones without deflate-stream. No one would reject w/o deflate-stream, I think. So, in summary, the requirement
- would literally encourage browsers and servers to support deflate-stream but no one would face any difficulties to get their implementation without deflate-stream live in the world (though the spec is separated into protocol and API, usually both parts are implemented together by the same person/vendor. Any restriction between them is easily ignored.)
- wouldn't free server implementor from the situation "If different browsers randomly decide to include or exclude compression, servers are just going to get confused and have weird bugs."

In terms of server development, I believe most of developer start with no deflate-stream and add deflate-stream later since it's easier to debug, and leave both of them available.

----

3) Regarding enforcing browsers to have some identical behavior, since most of people are considering deflate-stream as interim solution, and some are even objecting to it, I think it's not the right way to go.

There has been significant concerns raised against the deflate-stream extension within the ietf WG and I do not think that it has yet been resolved that this extension will be in the final version of the specification.

Specifically, as the compression is applied after masking, it is highly ineffective and can actually increase the bytes sent (http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html).

There have also been security concerns raised that it could defeat the purpose of masking and allow an attacker to control the actual bytes sent by producing large content with repeating 4 bytes patterns that will be compressed the same way regardless of masking.

There is an alternative proposal to deflate the content within the frame, before masking is applied.

In light of this, I do not think that making deflate-stream mandatory is wise.   It certainly will not be mandatory in servers, and the jetty project currently has no intention of implementing this extension - as it does not achieve any compression.     Thus a user-agent with mandatory deflate-stream will not be able to interoperate with servers that a compliant with the specification and do not implement this extension.

More importantly, mandatory deflate-stream support will remove the UA's flexibility to adopt a better extension if and when it becomes available.

I don't see how a non mandatory compression extension effects interoperability in any way, as the no compression extension option is the lingua franca.   User agents should be free to list whatever compression extensions they wish to implement and servers should be free to support which ever ones they also decide.   Market forces will decide which is best, just as has happened with gzip for HTTP content.

I've changed the spec to disallow the extension rather than require it, since browser vendors don't want to implement it.