Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt

Patrick McManus <mcmanus@ducksong.com> Tue, 21 June 2011 13:25 UTC

Return-Path: <mcmanus@ducksong.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476D721F843F for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz5OlyjmqmLz for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:25:21 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4C421F843D for <hybi@ietf.org>; Tue, 21 Jun 2011 06:25:21 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id 6E4E010193; Tue, 21 Jun 2011 09:25:19 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 0AEA510154; Tue, 21 Jun 2011 09:25:15 -0400 (EDT)
From: Patrick McManus <mcmanus@ducksong.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
In-Reply-To: <BANLkTik1qS=HS887b6DKPzCr-fEKZvv_jw@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <4E004D3D.3020305@it.aoyama.ac.jp> <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com> <4E00569E.4030400@ericsson.com> <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com> <BANLkTikhrkKjCbxJMuXLUMXSnXFmJ_2jjg@mail.gmail.com> <BANLkTik1qS=HS887b6DKPzCr-fEKZvv_jw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 21 Jun 2011 09:25:09 -0400
Message-ID: <1308662709.1944.278.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:25:22 -0000

It is likely that firefox 6 will be shipped with a websockets -09
implementation with the API prefixed under Moz*.

Hopefully Firefox 7 will be shipped with -09 under the normal WebSocket
namespace - we're waiting for the binary issue with the API to be fully
sorted out. That depends on what happens on the JS side of the fence.

On Tue, 2011-06-21 at 15:15 +0200, Iñaki Baz Castillo wrote:
> 2011/6/21 Greg Wilkins <gregw@intalio.com>:
> > Having the draft version in the handshake has proven a very workable
> > solution that prevents the heuristic version determination that was
> > previously necessary.  Is there any alternative solution?
> 
> Having experimental working implementations in order to improve a spec
> or detect/fix issues is great. Relying on such implementations is not
> so great, even less when you are talking about widely extended web
> browsers. In other words, I don't consider "polite" to experiment with
> the rest of the world just to realize of issues in a no mature
> specification (which is still a draft).
> 
> IMHO browser vendors could provide an experimental version with
> WebSocket support so developers and people in this WG can test it
> against the current specification. Ok, there it could make sense a
> *temporal* header like "X-WebSocket-TMP-Version". But such
> version/revision value should have no relationship with the final
> protocol version (i.e. "1.0") which will be submitted to the IETF.
> This is, don't mix experiments with the final spec.
> 
> Just my opinion. Regards.
> 
> 
>