Re: [hybi] Proposed way forward for WebSockets

Greg Wilkins <gregw@webtide.com> Tue, 27 July 2010 04:56 UTC

Return-Path: <gregw@webtide.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 7C78D3A6845 for <hybi@core3.amsl.com>; Mon, 26 Jul 2010 21:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 AqJK1KRJypq3 for <hybi@core3.amsl.com>; Mon, 26 Jul 2010 21:56:08 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5E8CB3A69AA for <hybi@ietf.org>; Mon, 26 Jul 2010 21:56:06 -0700 (PDT)
Received: by fxm1 with SMTP id 1so444793fxm.31 for <hybi@ietf.org>; Mon, 26 Jul 2010 21:56:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.106.132 with SMTP id x4mr7411367fao.15.1280206587952; Mon, 26 Jul 2010 21:56:27 -0700 (PDT)
Received: by 10.223.112.129 with HTTP; Mon, 26 Jul 2010 21:56:27 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.64.1007270030120.24444@ps20323.dreamhostps.com>
References: <ECF0E97F-1DA2-4662-BA48-F68B65AA8179@apple.com> <4C4D66AF.9030905@opera.com> <Pine.LNX.4.64.1007270030120.24444@ps20323.dreamhostps.com>
Date: Tue, 27 Jul 2010 14:56:27 +1000
Message-ID: <AANLkTi=fx=Yfm_pe9-pdCc=5sKRP=dNfDEBYCKNHFOmH@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="0016367ed6a2e9fceb048c575208"
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 04:56:10 -0000

Ian,

I'm generally in agreement with the outline of your plan - specifically I
think it
worthwhile to get a minimalistic solution deployed sooner rather than later.

But a couple of points in-line below:


On 27 July 2010 10:56, Ian Hickson <ian@hixie.ch> wrote:

>
> 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.
>

I would add 4: to support  the deployment of future extended versions of the
protocol.

Thus having a mechanism for versions and feature negotiation is key in a 1.0

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)*


I would also add (for consideration at least)

      - allowing connections to be annotated with metadata, If we don't,
        developers will just misuse the sub-protocol field for this.
      - chunking of large messages into multiple frames
      - keep alive messages
      - error handling and graceful shutdown (although this is already
somewhat improved).

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.
>

I don't necessarily agree with this evaluation criteria as features like
sharing
connections between tabs/windows is very much more difficult to achieve in
script than in browser.  So I don't think lack of wide implementations in
script
is a good indication of desirability of these features.  But  I do agree
that they
are not necessarily required in 1.0, so long as we can see how they could be
added.


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.)
>

With regards to the support for binary data, I agree that can mostly wait
until
the API is in javascript to handle it.  But I would also like to have one
final discussion
to see if we could agree to support only a single framing type that supports
both
binary and text - rather than enshrining multiple framing types for all
time.
For example,  we could switch to only supporting binary data with the
assumption
that unless otherwise specified the binary content is UTF-8 encoded text.



> 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.
>

agreed.   But I do think we need to at least discuss some proposals for the
extra features before a 1.0 so that we can test that we have the right
extensibility to be able to add them later without breaking.

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
>