Re: [hybi] Proposed way forward for WebSockets
Micheil Smith <micheil@brandedcode.com> Tue, 27 July 2010 07:40 UTC
Return-Path: <micheil@brandedcode.com>
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 5D3D63A69A5 for <hybi@core3.amsl.com>; Tue, 27 Jul 2010 00:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 1ype7tuD+mW4 for <hybi@core3.amsl.com>; Tue, 27 Jul 2010 00:40:36 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C59683A6A0D for <hybi@ietf.org>; Tue, 27 Jul 2010 00:40:36 -0700 (PDT)
Received: by pwj1 with SMTP id 1so432274pwj.31 for <hybi@ietf.org>; Tue, 27 Jul 2010 00:40:58 -0700 (PDT)
Received: by 10.114.25.18 with SMTP id 18mr2158073way.183.1280216458166; Tue, 27 Jul 2010 00:40:58 -0700 (PDT)
Received: from [192.168.46.181] (124-170-55-41.dyn.iinet.net.au [124.170.55.41]) by mx.google.com with ESMTPS id c10sm8298026wam.1.2010.07.27.00.40.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 00:40:57 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1081)
From: Micheil Smith <micheil@brandedcode.com>
Date: Tue, 27 Jul 2010 17:40:51 +1000
Content-Transfer-Encoding: 7bit
Message-Id: <CD6A695A-20B4-416E-8448-82554A7719F5@brandedcode.com>
References: <24C8BBF4-E8AE-4ECA-BFEF-7C7BBC1405D2@brandedcode.com>
To: hybi@ietf.org
X-Mailer: Apple Mail (2.1081)
Subject: Re: [hybi] Proposed way forward for WebSockets
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: Tue, 27 Jul 2010 07:40:41 -0000
Good plan, let's hope it goes to plan. Yours, Micheil Smith -- BrandedCode.com On 27/07/2010, at 10:56 AM, Ian Hickson wrote: > On Mon, 26 Jul 2010, James Graham wrote: >> >> I think a different goal would be a better statement of Ian's intent: >> >> "Websockets should be the minimal layer on top of TCP needed to meet the >> additional requirements of browsers" > > Yes, I think that's an accurate description of what I mean. > > > There are two parts to the protocol: the handshake, and the framing. > > The handshake has basically three purposes: 1: allowing the protocol to be > served by a server that also serves HTTP on the same port; 2: protecting > existing servers and future WebSocket servers from cross-protocol attacks; > 3: allowing servers to host multiple domains and resources on the same > IP/port combination, while supporting the browser origin security model. > > The framing has one purpose: provide JavaScript applications running in > Web browsers with a way to send and receive text messages to and from > WebSocket servers. > > > There are a number of ways that we can make the protocol also support > other goals: > > - Compression of frame data > - Sending and receiving binary data > - Allowing messages to be annotated with metadata* > - Allowing multiple JavaScript applications from the same browser to > share a connection to a server (multiplexing)* > > All of these could be supported by future backwards-compatible changes to > the protocol, by having the client advertise support for each feature in > the handshake, and having the server opt-in to using that feature. None of > these changes require fundamental changes to the handshake. > > Two of these, marked with an asterisk above, can also be implemented by > script; therefore a good way of determining if they are truly needed is to > deploy the protocol as is, and to see if people work around the lack of > that feature by implementing it themselves. If they do, then the feature > is needed and we should add it. > > The other two features are clearly needed regardless, and we should add > them in the near future. (Adding features piecemeal leads to more > compliant client-side implementations, so we should not add them now.) > > > Here's a proposed timeline for adding these features: > > - We fix any critical bugs (not feature additions) in the protocol as it > stands today (next 4 weeks). > > - We deploy the protocol in four or more major browser vendors (next 4 > months). > > - When binary support in WebGL is stable, we add binary support to XHR, > WebSocket, etc (a matter of months?). > > - We look at how the protocol is used (another couple of months). > > - During this time, we build client and server test suites for the > protocol. > > - We add built-in support for the features that are needed based on > implementation experience (about 6 months from now), including > compression, multiplexing, per-frame metadata annotation, etc, as > needed. > > - We update the test suites. > > > I think it would be a mistake to add every feature we can think of right > away, because doing so would mean that we added features before their need > was proven, and it would lead to much less conforming client > implementations. This dynamic has been proven time and time again with Web > technologies; we should not repeat that mistake. > > It would also be advantageous to allow implementors to experiment with > ideas like multiplexing before we add the feature to the protocol, since > it would let us use their implementation experience when designing the > extensions to the protocol. Only by first getting the basic protocol out > there and then experimenting with it can we really find how these ideas > work out in real deployments. > > > (Thanks to Ian Fette for providing a sounding board for some of this.) > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi
- Re: [hybi] Proposed way forward for WebSockets Micheil Smith