Re: [hybi] Proposed Charter for HyBi WG (rev.3)
Ian Hickson <ian@hixie.ch> Sat, 31 October 2009 03:58 UTC
Return-Path: <ian@hixie.ch>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACFB3A679C for <hybi@core3.amsl.com>; Fri, 30 Oct 2009 20:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEWJC58U8-2i for <hybi@core3.amsl.com>; Fri, 30 Oct 2009 20:58:57 -0700 (PDT)
Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 5F0483A6849 for <hybi@ietf.org>; Fri, 30 Oct 2009 20:58:57 -0700 (PDT)
Received: from hixie.dreamhostps.com (hixie.dreamhost.com [208.113.210.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id C8DA115D7CF; Fri, 30 Oct 2009 20:59:13 -0700 (PDT)
Date: Sat, 31 Oct 2009 03:59:23 +0000
From: Ian Hickson <ian@hixie.ch>
To: Greg Wilkins <gregw@webtide.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, SM <sm@resistor.net>
In-Reply-To: <6.2.5.6.2.20091030120030.043cff78@resistor.net>
Message-ID: <Pine.LNX.4.62.0910310335580.25616@hixie.dreamhostps.com>
References: <4AE966CA.9090907@ericsson.com> <Pine.LNX.4.62.0910300047310.25608@hixie.dreamhostps.com> <4AEABDBF.80705@ericsson.com> <6.2.5.6.2.20091030120030.043cff78@resistor.net>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Proposed Charter for HyBi WG (rev.3)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2009 03:58:58 -0000
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. `._.-(,_..'--(,_..'`-.;.'
- [hybi] Proposed Charter for HyBi WG (rev.3) Salvatore Loreto
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Ian Hickson
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Greg Wilkins
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Salvatore Loreto
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) SM
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Ian Hickson
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Greg Wilkins
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) SM
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Ian Hickson
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Greg Wilkins
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Martin Tyler
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Salvatore Loreto