Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Ian Hickson]

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)

[Takeshi Yoshino]

On Thu, Jul 28, 2011 at 03:11, Anne van Kesteren  wrote:

> HTML5 is mostly transport-layer agnostic.
>

HTML5 is transport-layer agnostic though it involves communication with
server in handling ,  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
wha...@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

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Greg Wilkins]

On 27 July 2011 20:35, Takeshi Yoshino  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)

[Ian Hickson]

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)

[Anne van Kesteren]

On Wed, 27 Jul 2011 15:31:28 -0700, Ian Fette (イアンフェッティ)  
 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)

[イアンフェッティ]

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 

> On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) 
> wrote:
>
>> 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 
>>
>>> On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) >> > 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 
 wrote:

> 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)

[James Robinson]

On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) wrote:

> 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 
>
>> On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) 
>> 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 wrote:
>>>
 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  >/**.
>

 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 

> On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) 
> 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 wrote:
>>
>>> On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino 
>>> wrote:
>>>
 So, let me correct my text by s/XHR/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)

[James Robinson]

On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) 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 wrote:
>
>> On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino 
>> wrote:
>>
>>> So, let me correct my text by s/XHR/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 wrote:

> On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino 
> wrote:
>
>> So, let me correct my text by s/XHR/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)

[Anne van Kesteren]

On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino   
wrote:

So, let me correct my text by s/XHR/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)

[Takeshi Yoshino]

On Thu, Jul 28, 2011 at 02:03, Anne van Kesteren  wrote:

> On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino 
> wrote:
>
>> What do you mean by "more places"?
>>
>
> XMLHttpRequest is not the sole API for HTTP, there's also , , 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 /.

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Anne van Kesteren]

On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino   
wrote:

What do you mean by "more places"?


XMLHttpRequest is not the sole API for HTTP, there's also , ,  
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)

[Takeshi Yoshino]

On Thu, Jul 28, 2011 at 00:06, Anne van Kesteren  wrote:

> On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino 
> 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)

[Anne van Kesteren]

On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino   
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)

[Takeshi Yoshino]

Is new XHR spec going to make gzip mandatory for its underlying HTTP?

On Tue, Jul 26, 2011 at 06:05, Aryeh Gregor wrote:

> 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)

[Arthur Barstow]

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  
and/or ping public-webapps.


-AB

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Aryeh Gregor]

On Mon, Jul 25, 2011 at 4:58 PM, Adrian Bateman  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)

[Adrian Bateman]

On Monday, July 25, 2011 1:32 PM, Aryeh Gregor wrote:
> On Thu, Jul 21, 2011 at 1:02 PM, 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.
>
> 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)

[Aryeh Gregor]

On Thu, Jul 21, 2011 at 1:02 PM, 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.

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)

[Greg Wilkins]

On 22 July 2011 03:16, Anne van Kesteren  wrote:
> On Thu, 21 Jul 2011 19:02:31 +0200, 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.
>
> 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)

[Takeshi Yoshino]

Resending. I've made mistake in processing public-webapps@w3.org confirmation
page.

On Fri, Jul 22, 2011 at 19:45, Takeshi Yoshino  wrote:

> On Fri, Jul 22, 2011 at 18:54, Anne van Kesteren  wrote:
>
>> On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino 
>> 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)

[Anne van Kesteren]

On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino   
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)

[Ian Hickson]

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)

[Ian Hickson]

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)

[イアンフェッティ]

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  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)

[Adrian Bateman]

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 Hickson]

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)

[Anne van Kesteren]

On Thu, 21 Jul 2011 19:02:31 +0200, 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.


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)

[Adrian Bateman]

On Thursday, July 21, 2011 8:31 AM, Anne van Kesteren wrote:
> On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow 
> 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)

[Ian Hickson]

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)

[Anne van Kesteren]

On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow   
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)

[Arthur Barstow]

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)

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'

[websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Adrian Bateman]

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.