[hybi] [Fwd: Comments on draft-hixie-thewebsocketprotocol-35]
Julian Reschke <julian.reschke@gmx.de> Sun, 30 August 2009 08:03 UTC
Return-Path: <julian.reschke@gmx.de>
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 CA3193A698D for <hybi@core3.amsl.com>; Sun, 30 Aug 2009 01:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.727
X-Spam-Level:
X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-2.128, 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 nOBCm-iyiW85 for <hybi@core3.amsl.com>; Sun, 30 Aug 2009 01:03:27 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4ADCB3A6778 for <hybi@ietf.org>; Sun, 30 Aug 2009 01:03:26 -0700 (PDT)
Received: (qmail invoked by alias); 30 Aug 2009 08:03:33 -0000
Received: from p508FC310.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.195.16] by mail.gmx.net (mp069) with SMTP; 30 Aug 2009 10:03:33 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+Brrwb+CmBtn+C+Bs3SDtGjszcU4Xd8odE9oiSsv 5YYWcLeBcpnJTz
Message-ID: <4A9A3255.90408@gmx.de>
Date: Sun, 30 Aug 2009 10:03:33 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: hybi@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.52
Subject: [hybi] [Fwd: Comments on draft-hixie-thewebsocketprotocol-35]
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: Sun, 30 Aug 2009 08:03:28 -0000
(FYI) -------- Original Message -------- Date: Tue, 25 Aug 2009 20:54:03 +0100 From: Graham Klyne <ietf-discuss-apps@ninebynine.org> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Apps Discuss <discuss@apps.ietf.org> Subject: Comments on draft-hixie-thewebsocketprotocol-35 [I've tried sending this twice to the HYBI list, but for some reason it's not getting through (this doesn't augur well for traditional IETF values of openness). So I'm sending it here in the expectation that someone will be able to relay it to the proper forum. #g.] Dear all, re: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-35 [Summary: in its present form, a thumbs down.] I was prompted to review this spec by this comment posted to the W3C technical architecture group (TAG) mailing list: [[ What's the point of this new protocol? To bum a small constant in network performance? Seems shortsighted given the enormous amount of effort it takes to tool up for and specify a new protocol. Not to mention one that looks to essentially end a platform on which to build a further babel of ad hoc protocols. And considering Moores law. Definitely worth a review, if you ask me. URN versus URI seems the least issue here. ]] I thought this comment missed what I thought was the point, and that maybe it needed to be corrected. But on reading the spec in its current form, I can see why someone would say this. ... So, what's the problem, in two parts: (a) what problem is being solved? (b) what is the problem with the spec? My understanding of the problem to be solved, based on what I understand about the goals of HYBI, is that in its present form the Web has no common way to "push" information to a browser application. There are a number of solutions/workarounds based on HTTP long-polling or variants, but these have variousbproblems with proxies, etc., and there is as yet no single accepted solution. My expectation is that the websockets protocol proposes to be such a solution. I think the specification, in its current form, completely fails to present itself as such a solution. To me, it reads less like an open protocol specification, and rather more like a programming team internal design memo. From reading it, I can't tell if it addresses the problem I expected it to address. It seems to me that you need to understand websockets in some detail in order to understand this spec with a reasonable amount of effort - I want to be able to pick out the "high points" on a single read though, but instead I find myself plunged into a level of detail that I can't relate to. For example, take the very first sentence of the Introduction (sic): "The Web Socket protocol is designed on the principle that there should be minimal framing (the only framing that exists is to make the protocol frame-based instead of stream-based, and to support a distinction between Unicode text and binary frames)" - this very first sentence introduces a number of lower-level techncial issues (framing, frame-based, stream-based, unicode text, binary frames) without providing any context. Even the abstract isn't very helpful here (the second sentence, starting with "It is intended to fail ..." doesn't exactly engender confidence). None of this means that I think this is a bad protocol: the truth is, I can't tell if it is or not. So, yes, my comments could be construed as being about style rather than substance, but if we're in the business of forging consensus I think some consideration needs to be given to the readers of a specification in order to get meaningful review. I'll try and make a few suggestions, which I don't claim are best or complete: 1. Provide some context and motivation. Start the introduction by stating the problem that is being solved, and why it is not solved by existing standard protocols. Also, alomng the way, it might be worth mentioning efforts like cometd/bayeux and BOSH and saying how this proposal is similar and/or different. 2. Indicate some specific types of applications for which the problem exists (my favourites include: real-time web page updates, synchronization of displays between multiple web pages, on-the-fly persisting of user interactions, ...). 3. [nit] Abstract: talk about "graceful fallback" instead of "intended to fail" 4. Introduce key concepts before delving into details about them: I don't mean in textboook fashion, but indicating how they relate to the problem at hand (e.g. why is framing an issue, how does it relate to Unicode bvs binary data?). 5. Move most of the current "introduction" text into a high-level protocol description section. 6. Provide a protocol state diagram or similar overview. 7. Section 3: why is this based on [WEBADDRESSES] rather than [RFC3986]? I can't offhand tell if [WEBADDRESSES] is acceptable as a normative reference. I have not read sections 4 and 5 in detail, as they seem to be concerned entirely with very low-level and rather wordy protocol processing descriptions, but I find myself asking: why not just specify a hand-off extension to HTTP that allows bidirectional communication to proceed using a protocol such as BEEP? I fear there's a certain amount of reinvention going on here. But I could be wrong. I wish I could be more constructive, but in its present form I can't see anything that helps me in this current specification. Maybe this can be improved, as I think the goals of HYBI are important. #g _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
- [hybi] [Fwd: Comments on draft-hixie-thewebsocket… Julian Reschke
- Re: [hybi] [Fwd: Comments on draft-hixie-thewebso… Greg Wilkins
- Re: [hybi] [Fwd: Comments on draft-hixie-thewebso… Graham Klyne
- Re: [hybi] [Fwd: Comments on draft-hixie-thewebso… Ian Hickson
- Re: [hybi] Comments on draft-hixie-thewebsocketpr… SM
- Re: [hybi] [Fwd: Comments on draft-hixie-thewebso… Salvatore Loreto