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 <adrianba@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.

Received on Monday, 25 July 2011 21:06:29 UTC