Re: [hybi] Proposed Charter for HyBi WG (rev.3)

[Ian Hickson <[e-mail]>]

On Fri, 30 Oct 2009, Greg Wilkins wrote:
> Ian Hickson wrote:
> > I think that's the wrong characterisation of the spaces that people 
> > want to work in. I think a better way to characterise it would be that 
> > there are three use cases people are interested in, with different 
> > needs:
> > 
> >  * Providing a standard way of doing two-way communication tunneled over 
> >    HTTP, for use by applications that cannot use TCP, Jabber, BEEP, or 
> >    other existing solutions in that space due to intermediaries, 
> >    firewalls, NATs, etc.
> >
> >  * Providing something as close to TCP as possible to Web applications 
> >    (i.e. JavaScript running in HTML on Web browsers), while maintaining 
> >    the Web origin security model and fitting the Web development model 
> >    (e.g. event-based, not stream-based).
> >
> >  * Providing a standard way of doing "hanging-GET" two-way communication 
> >    to HTTP servers along the lines of what interactive AJAX pages do.
> 
> I don't see why you consider the first two as entirely different 
> audiences.  Web applications (i.e. JavaScript running in HTML on Web 
> browsers) are just any other application (like Jabber, BEEP etc) that 
> wants two-way communication over the web.

They have different requirements, primarily due to the differing security 
models. The origin security model makes no sense for a standalone app, 
since it controls what it sends down the wire. Such a model only makes 
sense when the handshake is done by a different party than the application 
-- indeed, it only makes sense when the application is assumed to be 
hostile. Most environments assume the application is benign.


> From the point of view of server or an intermediary, there is very 
> little difference between any of the different client application types 
> that might be out there and I don't want to have to double my effort to 
> consider them differently.

Could you describe concretely what use case you have in mind here? I could 
imagine, e.g., a third-party native Google Mail client wanting to pretend 
to be the GMail Web app so that it can use the same API as the web app, 
but that seems likely to be relatively infrequent compared to the number 
of cases that would just be Web apps. (It would also work fine, if that 
was really desired.) However, it seems like a much better for such an app 
to just use IMAP directly, rather than trying to reverse-engineer Google's 
internal server-client protocol.


> I agree that webapps/browsers have some specific requirements - eg in 
> regards to the Web origin security model - but surely those extra 
> requirements should be layered on top of the protocol, not baked in as 
> assumptions that will force an entirely new protocol to be used for 
> non-browser clients.

That's exactly what WebSocket is -- it is the layer on top of TCP that 
adds just the features that are needed for browsers. It adds nothing else. 
TCP is the protocol on which this is being layered.

The protocol stack I'm proposing looks something like this:

   |\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
   | Application-level protocol | user application features
   +----------------------------+
   | WebSocket protocol         | browser security model, event wrapper
   +----------------------------+
   | TCP                        | reliability, connection wrapper
   +----------------------------+
   | IP                         | packet abstraction, routing
   +----------------------------+
   | Ethernet                   | link-level routing
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|


What is the protocol stack you are imagining? What are the features that 
TCP lacks that you think need to be added between the "IP" and 
"Application-level protocol" layers of the stack above? Where do you think 
features like the browser-level origin model should fit?


On Fri, 30 Oct 2009, Salvatore Loreto wrote:
> Ian Hickson wrote:
> > 
> > We should also liason with the WHATWG, since that's where most of the 
> > WebSockets work has happened. (The W3C Web Apps working group hasn't 
> > worked on the protocol at all, and they already liase with the WHATWG 
> > for the API.)
>
> what about the following text?
> 
>    In particular, the working group will liaison with:
>    - the W3C WebApps working group around the requirements to support      the
> WebSocket API;    - the WHATWG around the WebSockets protocol    if agreed by
> both parties, the HyBi working group may take on prime    responsibility on
> the specification of the WebSockets protocol.
>
> one question: how IETF can become aware if WHATWG agrees or not?

The WHATWG is happy to work with anyone. I don't understand what you mean 
by "liason with" juxtaposed by "take on prime responsibility", though. In 
what sense is it a liason if the other group no longer has responsibility? 
Surely a joint effort implies joint responsibility.

It should be noted that the WHATWG's work is based on technical merit and 
not on consensus. If even just one person raises a valid technical issue 
in the WHATWG, they cannot be overridden by the rest of the group having 
complete agreement that they should just ignore the technical issue. There 
is also a firm philosophy that the specs match interoperable deployed 
implementations, and that the specs not leave things undefined.

Does the IETF/Hybi agree?

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