Re: [hybi] updated Charter proposal (WebSocket)

[Ian Hickson <[e-mail]>]

On Tue, 27 Oct 2009, Greg Wilkins wrote:
> 
> However, the authors of the [WebSocket] protocol have so far been very 
> resistant to change (not even using BNF or allocating a type byte for 
> mime-encoded content).

ABNF is used three times in the WebSocket draft.

You and I have a disagreement about whether it is appropriate for the 
protocol to have a type byte for MIME-encoded content.

However, the draft itself has changed a lot in response to feedback over 
the years. The original proposal really has no resemblence to the current 
proposal:

   http://www.whatwg.org/specs/web-apps/2005-09-01/#network
   http://www.whatwg.org/specs/web-apps/2006-01-01/#scs-network

I don't adopt every proposed change, sure, but I think I have shown myself 
to be quite willing to change the proposal based on reasoned arguments and 
clearly demonstrated needs and problems.


> So will the WG have the ability to come up with it's own draft for a 
> websocket protocol - or will all it be able to do is huff and puff and 
> hope to convince the whatwg?

Say the WG adopted BWTP as the basis for its work. Will you drop 
Multiplexing and MIME typing from the BWTP proposal? If not, does that 
mean you are resistant to change and then will the WG only be able to huff 
and puff and hope to convince you?


> The problem with that approach is that the whatwg have a different world 
> view (js only, not so hard to release new versions, run around 
> intermediaries, keep it totally simple) to many view expressed in the 
> IETF forum (many client types, hard to release new versions, involve the 
> intermediaries, make it extensible).
> 
> It maybe that the websocket protocol is perfect for the whatwg's 
> objectives, but insufficient for the IETF's.  I'm not sure how we get 
> past that log jam if the WG is not able to author its own protocol or 
> variations?

If the WG were to adopt an approach that was based on not having JS as the 
primary client type, assuming that we couldn't update the protocol 
frequently, assuming that the protocol would have to be implemented in 
intermediaries to be successful, and assuming that extensibility at the 
protocol user level (rather than layered on top of the protocol, or done 
through updates to the protocol) was desireable, then I don't think I'd be 
interested in the group's deliverables, to be honest.

What I'm looking for is something that is designed for JS clients, that 
can be updated regularly, that can be adopted today without bootstrapping 
through intermediaries, and that is kept as simple as possible (while 
allowing the protocol to be extended by future updates).

I don't mind what the working group works on, but if it's not that, then 
it's not a working group I'm interested in working with, as it wouldn't 
be addressing the needs that I'm trying to address.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'