Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Fri, 29 Jul 2011, Takeshi Yoshino wrote: 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. I can't speak for the W3C, but yes, extensions to the standards are how we evolve the technology stack. As extensions are developed and adopted by browsers, the API spec will be updated accordingly. Updating the spec is a trivial matter. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
Is new XHR spec going to make gzip mandatory for its underlying HTTP? On Tue, Jul 26, 2011 at 06:05, Aryeh Gregor simetrical+...@gmail.comwrote: From the discussion here, it sounds like there are problems with WebSockets compression as currently defined. If that's the case, it might be better for the IETF to just drop it from the protocol for now and leave it for a future version, but that's up to them. As far as we're concerned, if the option is really a bad idea to start with, it might make sense for us to prohibit it rather than require it, but there's no reason at all we have to leave it optional for web browsers just because it's optional for other WebSockets implementations. Regarding deflate-stream, I think prohibiting is better than requiring. But I still don't understand the benefit of banning any extension other than what specified in the API spec. There are two different assertions made by W3C side. (a) it's not acceptable to make support (== request) of good-compression optional (b) it's not acceptable to allow any other compression/extension than specified in the API spec (a) is supported by the discussion you and Anne made by using analogy with HTTP. I may agree with this. (b) is what Hixie was asserting in the bug entry. I'd like to see clear support for (b). No one knows what kind of compression will be finally the win for WebSocket. I'd like to see ideas about how the evolution of WebSocket will be like. With (b), to experimentally implement some extension/compression not specified in the API spec, we have to make our browser non-compliant with W3C spec. I'd suggest that, once better-deflate is ready by IETF, W3C uses text like the user agent MUST request better-deflate extension instead of JUST better-deflate extension. Thanks, Takeshi
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com wrote: Is new XHR spec going to make gzip mandatory for its underlying HTTP? I do not think that analogy makes sense. The WebSocket protocol can only be used through the WebSocket API, HTTP is prevalent in more places. Having said that, XMLHttpRequest does place constraints on HTTP. E.g. it requires redirects to be followed, it does not expose 1xx responses, only works cross-origin in combination with CORS, etc. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, Jul 28, 2011 at 00:06, Anne van Kesteren ann...@opera.com wrote: On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com wrote: Is new XHR spec going to make gzip mandatory for its underlying HTTP? I do not think that analogy makes sense. The WebSocket protocol can only be used through the WebSocket API, HTTP is prevalent in more places. What do you mean by more places? Having said that, XMLHttpRequest does place constraints on HTTP. E.g. it requires redirects to be followed, it does not expose 1xx responses, only works cross-origin in combination with CORS, etc. I agree that there're some constrains must be placed on underlying protocol to make it useful/secure on browser.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com wrote: What do you mean by more places? XMLHttpRequest is not the sole API for HTTP, there's also a, form, etc. So indicating what parts of the HTTP protocol are mandatory for browsers is not really in scope for XMLHttpRequest. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, Jul 28, 2011 at 02:03, Anne van Kesteren ann...@opera.com wrote: On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com wrote: What do you mean by more places? XMLHttpRequest is not the sole API for HTTP, there's also a, form, etc. So indicating what parts of the HTTP protocol are mandatory for browsers is not really in scope for XMLHttpRequest. So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//. HTML5 is mostly transport-layer agnostic. 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. 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//* *. HTML5 is mostly transport-layer agnostic. 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. 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. Sounds like the consensus is to forbid this extension at the API layer, then. - James -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5// **. HTML5 is mostly transport-layer agnostic. 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. 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
I don't think we want to forbid any extensions. The whole point of extensions is to allow people to do something that doesn't necessarily have consensus by a broad enough group to be in the base protocol. That said, I think a lot of people would be happier if deflate-stream were an independent document as opposed to being the only extension included in the core specification as a known extension. -Ian 2011/7/27 James Robinson jam...@google.com On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. Sounds like the consensus is to forbid this extension at the API layer, then. - James -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5/ /**. HTML5 is mostly transport-layer agnostic. 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. 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: I don't think we want to forbid any extensions. At the protocol level, sure. At the API level we have to pick which functionality user agents are required to support and which they are required not to support, having 'optional' stuff is not an option. It sounds like you are saying that deflate-stream is bad, so we should not have it in the API. - James The whole point of extensions is to allow people to do something that doesn't necessarily have consensus by a broad enough group to be in the base protocol. That said, I think a lot of people would be happier if deflate-stream were an independent document as opposed to being the only extension included in the core specification as a known extension. -Ian 2011/7/27 James Robinson jam...@google.com On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. Sounds like the consensus is to forbid this extension at the API layer, then. - James -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5/ /**. HTML5 is mostly transport-layer agnostic. 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. 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
I agree we shouldn't require deflate-stream it in the API. I don't agree the API should specify an exact set of extensions, as that would prevent any future versions/developments. A minimum baseline would be reasonable though, once we have that minimum baseline in place (e.g. a stable set of extensions that are well tested, such as compression and multiplexing). I don't think we should put the cart before the horse. -Ian 2011/7/27 James Robinson jam...@google.com On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: I don't think we want to forbid any extensions. At the protocol level, sure. At the API level we have to pick which functionality user agents are required to support and which they are required not to support, having 'optional' stuff is not an option. It sounds like you are saying that deflate-stream is bad, so we should not have it in the API. - James The whole point of extensions is to allow people to do something that doesn't necessarily have consensus by a broad enough group to be in the base protocol. That said, I think a lot of people would be happier if deflate-stream were an independent document as opposed to being the only extension included in the core specification as a known extension. -Ian 2011/7/27 James Robinson jam...@google.com On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.com wrote: We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. Sounds like the consensus is to forbid this extension at the API layer, then. - James -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//**. HTML5 is mostly transport-layer agnostic. 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. 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011 15:31:28 -0700, Ian Fette (イアンフェッティ) ife...@google.com wrote: I agree we shouldn't require deflate-stream it in the API. I don't agree the API should specify an exact set of extensions, as that would prevent any future versions/developments. A minimum baseline would be reasonable though, once we have that minimum baseline in place (e.g. a stable set of extensions that are well tested, such as compression and multiplexing). I don't think we should put the cart before the horse. The API specification is not frozen. Case in point: http://html5.org/r/6330 -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote: I agree we shouldn't require deflate-stream it in the API. I don't agree the API should specify an exact set of extensions, as that would prevent any future versions/developments. A minimum baseline would be reasonable though, once we have that minimum baseline in place (e.g. a stable set of extensions that are well tested, such as compression and multiplexing). I don't think we should put the cart before the horse. As soon as there's a feature that browsers are to implement, we would update the WebSockets spec to list it as a requirement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On 27 July 2011 20:35, Takeshi Yoshino tyosh...@google.com wrote: (a) it's not acceptable to make support (== request) of good-compression optional I understand the desire to make good compression universal, but I'm not sure that making it a required part of the specification is the way to go. (b) it's not acceptable to allow any other compression/extension than specified in the API spec So long as the selection of extensions is essentially transparent to the application using the API, then the implementation should be free to use extensions. If a mux extension is developed that either includes it's own compression or works better with some alternative compression, then we don't want to stop browsers from adopting that extension because it would mean that they are non compliant with the API specification. So isn't there a compromise, of coming up with words that express that browsers SHOULD implement and some set of extensions, but allow user-agents to use other extensions without being called non compliant. regards
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On 7/25/11 5:05 PM, ext Aryeh Gregor wrote: From the discussion here, it sounds like there are problems with WebSockets compression as currently defined. Yes, this is what I have concluded too (and if we are wrong, I would appreciate it if someone on the hybi list would please clarify). If that's the case, it might be better for the IETF to just drop it from the protocol for now and leave it for a future version, but that's up to them. When hybi agrees on this issue, I would appreciate it if someone would update 12917 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917 and/or ping public-webapps. -AB
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman adria...@microsoft.com wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Do you think it would be feasible in practice for a mainstream web browser to not support HTTP compression? For instance, if Internet Explorer removed support for it, would you expect to get a sufficient number of bug reports that you'd be forced to re-add support? If so, then HTTP compression is in practice mandatory for web browsers, but optional for web servers. This is exactly the state of affairs proposed for WebSockets compression.
RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Monday, July 25, 2011 1:32 PM, Aryeh Gregor wrote: On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman adria...@microsoft.com wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Do you think it would be feasible in practice for a mainstream web browser to not support HTTP compression? For instance, if Internet Explorer removed support for it, would you expect to get a sufficient number of bug reports that you'd be forced to re-add support? If so, then HTTP compression is in practice mandatory for web browsers, but optional for web servers. This is exactly the state of affairs proposed for WebSockets compression. First, I don't think that's the same thing at all. Second, the IETF HyBi working group has asked members of this working group for Last Call feedback. If you think the protocol has the wrong mix of required/optional features then you should provide that feedback through the requested channel. Adrian.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Mon, Jul 25, 2011 at 4:58 PM, Adrian Bateman adria...@microsoft.com wrote: First, I don't think that's the same thing at all. Why not? Second, the IETF HyBi working group has asked members of this working group for Last Call feedback. If you think the protocol has the wrong mix of required/optional features then you should provide that feedback through the requested channel. I'm saying that it would be perfectly acceptable for a feature to be optional on the protocol level (what the IETF specifies) but mandatory for web browsers (what WebApps specifies). If HTML5 were to require that conforming user-agents must support HTTP compression, for the sake of argument, that would not contradict the RFCs that make it optional. An HTTP client that didn't support compression would be a conforming HTTP client but a non-conforming HTML5 user agent. There's nothing wrong with that: specifications are supposed to add requirements beyond the specs they normatively reference. Thus this is a question for us, not the IETF. From the discussion here, it sounds like there are problems with WebSockets compression as currently defined. If that's the case, it might be better for the IETF to just drop it from the protocol for now and leave it for a future version, but that's up to them. As far as we're concerned, if the option is really a bad idea to start with, it might make sense for us to prohibit it rather than require it, but there's no reason at all we have to leave it optional for web browsers just because it's optional for other WebSockets implementations.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
Resending. I've made mistake in processing public-webapps@w3.org confirmation page. On Fri, Jul 22, 2011 at 19:45, Takeshi Yoshino tyosh...@google.com wrote: On Fri, Jul 22, 2011 at 18:54, Anne van Kesteren ann...@opera.com wrote: On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino tyosh...@google.com wrote: Think of these facts, the only dominant implementation concern I can come up with for WebSocket compression is that big service provides may take an aggressive policy that they require users to use only WebSocket client with compression capability to reduce bandwidth. As a result clients with no compression capability may, in effect, be kicked out of WebSocket world. I can understand that concern. Is this true for the HTTP world? I.e. clients that send Accept-Encoding: \r\n cannot live? Yes. Optional features for browsers do not work. For servers it is fine if they do not support compression or whatnot, but browsers pretty much need to align on feature set. In summary, your point seems to be that we must choose feature set that is considered to be taken by majority as optimal like HTTP/gzip, and ask browsers to support that by specifying it the W3C spec (*). I see that. It might make sense. However deflate-stream is not yet considered as the optimal choice in the HyBi WG and we're trying to introduce better one. Even some are doubting if it's worth using deflate-stream compared to identity stream. Requiring all browsers request (== implement) deflate-stream can be asking everyone to do thrown-away work as a result. Is this acceptable? Based on W3C's stance (*) and IETF's stance, the only landing point is initially enforcing browsers to use identify encoding except for experimenting new compression, and when IETF provides new compression extension good enough to recommend, update the API spec to switch to that. Takeshi
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On 22 July 2011 03:16, Anne van Kesteren ann...@opera.com wrote: On Thu, 21 Jul 2011 19:02:31 +0200, Adrian Bateman adria...@microsoft.com wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Actually it has. You are pretty required to support it these days and you better be sure you Accept-Encoding header is formatted consistently. What is the evidence of that? Gzip encoding is optional in most java servlet containers, as it is implemented by a Filter that the application must configure.I've never heard of an application not working with a client because it did not have compression configured. Note that I'm a bit confused by what is intended by mandatory in this context. Is it intended that it be mandatory that browsers only accept connections with deflate-stream, or is it only mandatory that they request that extension, but can accept connections without compression? regards
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino tyosh...@google.com wrote: Think of these facts, the only dominant implementation concern I can come up with for WebSocket compression is that big service provides may take an aggressive policy that they require users to use only WebSocket client with compression capability to reduce bandwidth. As a result clients with no compression capability may, in effect, be kicked out of WebSocket world. I can understand that concern. Is this true for the HTTP world? I.e. clients that send Accept-Encoding: \r\n cannot live? Yes. Optional features for browsers do not work. For servers it is fine if they do not support compression or whatnot, but browsers pretty much need to align on feature set. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
Bug 12917 [1] has been discussed in at least bugzilla as well as e-mail including this thread started by Adrian (Hixie's follow-up is [2]) and Adrian's general Web Sockets LC thread [3]. This bug is currently resolved as WontFix and this resolution is supported by at least Hixie and Jonas. Adrian, Takeshi and Greg have argued against this resolution (i.e. they do not support deflate-stream being a mandatory extension in the API). What do others (Anne?, Maciej?, ...) think about this issue? Given the Protocol is now in LC review, it seems relatively important to align the API and Protocol. -Art Barstow [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917 [2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0242.html [3] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0193.html On 7/8/11 5:44 PM, ext Adrian Bateman wrote: On Friday, July 08, 2011 1:12 PM, Ian Hickson 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 strongly disagree. We must have interoperability amongst browser user agents. Having some support compression and others not would lead to authoring mistakes and will force us into either having or not having compression based on how big sites first get this wrong. It's fine to disagree, but you should disagree in the IETF working group where this is made optional and not in the Web API. There will be other users of WebSockets outside the browser and by implementing the protocol they won't be required to implement this extension. In addition, there are still discussions about whether this is an appropriate mechanism for compression since it requires intermediaries to decompress the whole stream if they want to review messages. There are still proposals to remove deflate-stream from the spec. We think there are legitimate cases for implementing the protocol without compression. That aside, however, we strongly disagree with one consumer of a protocol, the Web API, making decisions to override the requirements of the protocol spec. Adrian.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow art.bars...@nokia.com wrote: What do others (Anne?, Maciej?, ...) think about this issue? I don't know enough about the WebSocket protocol, but optional web platform features suck. They will become mandatory following the typical dominant implementation does it and we want to work on the same sites scenario. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, 21 Jul 2011, Arthur Barstow wrote: Given the Protocol is now in LC review, it seems relatively important to align the API and Protocol. The API and the protocal _are_ aligned. The protocol asks for the consumer to provide a list of extensions. Nothing in the protocol requires that this list of extensions be configurable by the consumer's user. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thursday, July 21, 2011 8:31 AM, Anne van Kesteren wrote: On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow art.bars...@nokia.com wrote: What do others (Anne?, Maciej?, ...) think about this issue? I don't know enough about the WebSocket protocol, but optional web platform features suck. They will become mandatory following the typical dominant implementation does it and we want to work on the same sites scenario. For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. There is still discussion in the IETF about whether stream or frame based compression is best. That's the right place to have that discussion. There are also implementers that want extensions for other things, such as multiplexing. This is a protocol layer handshake below the API and the API simply provides information about what was agreed. Adrian.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, 21 Jul 2011 19:02:31 +0200, Adrian Bateman adria...@microsoft.com wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Actually it has. You are pretty required to support it these days and you better be sure you Accept-Encoding header is formatted consistently. -- Anne van Kesteren http://annevankesteren.nl/
RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, 21 Jul 2011, Adrian Bateman wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Optional features in HTTP have caused no end of trouble and are amongst the many reasons I avoid optional features so much. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thursday, July 21, 2011 12:33 PM, Ian Hickson wrote: On Thu, 21 Jul 2011, Adrian Bateman wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Optional features in HTTP have caused no end of trouble and are amongst the many reasons I avoid optional features so much. What specific problems have been caused by the existence of extensions (separate from whether or not extensions have been well defined) and what API consequences have there been i.e. what changes to web APIs have you made because of this? It seems to me that HTTP has been wildly successful and its extensibility is a large part of that. In any case, that's a distraction - the W3C Web API should specify the things needed to project the protocol into the web developer's hands and no more. Discussions of the protocol, which is in Last Call, should be made in the appropriate working group at the IETF. There's no need to profile the protocol in the W3C API spec. Adrian.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
Ian, I understand this point of view. That said, there is a lot of disagreement in the IETF WG about deflate-stream. The extension basically breaks all other extensions, framing, etc. It's a bit of a mess and a lot of us want to just yank it out entirely. There was a much better proposal by yoshino-san (deflate-frame) that basically did compression but still properly framed the compressed result. I think that at least in Chrome we are hoping deflate-frame will take off. That will be in a separate document though as the current protocol doc is in last call, and you are undoubtedly familiar with the logistical considerations of such things. -Ian On Thu, Jul 21, 2011 at 12:33 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 21 Jul 2011, Adrian Bateman wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Optional features in HTTP have caused no end of trouble and are amongst the many reasons I avoid optional features so much. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, 21 Jul 2011, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote: I understand this point of view. That said, there is a lot of disagreement in the IETF WG about deflate-stream. The extension basically breaks all other extensions, framing, etc. It's a bit of a mess and a lot of us want to just yank it out entirely. There was a much better proposal by yoshino-san (deflate-frame) that basically did compression but still properly framed the compressed result. I think that at least in Chrome we are hoping deflate-frame will take off. That will be in a separate document though as the current protocol doc is in last call, and you are undoubtedly familiar with the logistical considerations of such things. I've been assuming that the Web Socket protocol spec was what UAs wanted to implement. If it's not, then that's a bigger problem. I don't mind if we turn specific extensions on or off. I just don't think it should be optional. If UAs do not want to implement what the protocol spec says, I'm equally happy for the API spec to just disallow that extension. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, 21 Jul 2011, Adrian Bateman wrote: On Thursday, July 21, 2011 12:33 PM, Ian Hickson wrote: On Thu, 21 Jul 2011, Adrian Bateman wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Optional features in HTTP have caused no end of trouble and are amongst the many reasons I avoid optional features so much. What specific problems have been caused by the existence of extensions (separate from whether or not extensions have been well defined) and what API consequences have there been i.e. what changes to web APIs have you made because of this? Content-Type is one big one. It's de-facto optional status (mostly driven by IE's sniffing behaviour) has had huge security implications, has resulted in complicated UA behaviours now being required, has resulted in complicated semantics in HTML with respect to when types are honoured and when they are not, etc. It seems to me that HTTP has been wildly successful and its extensibility is a large part of that. HTTP has been successful despite being poorly specified, not because of it. (Same with HTML.) In any case, that's a distraction - the W3C Web API should specify the things needed to project the protocol into the web developer's hands and no more. Discussions of the protocol, which is in Last Call, should be made in the appropriate working group at the IETF. There's no need to profile the protocol in the W3C API spec. If the IETF won't do the job right, we have to. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Fri, 8 Jul 2011, Adrian Bateman wrote: I strongly disagree. We must have interoperability amongst browser user agents. Having some support compression and others not would lead to authoring mistakes and will force us into either having or not having compression based on how big sites first get this wrong. It's fine to disagree, but you should disagree in the IETF working group where this is made optional and not in the Web API. There will be other users of WebSockets outside the browser and by implementing the protocol they won't be required to implement this extension. Non-browser clients don't have the same dynamics, so it makes sense for them to be allowed to not implement compression. Non-browser clients aren't going to have the market impact of browser clients. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
