Re: [hybi] Proposed way forward for WebSockets

Greg Wilkins <gregw@webtide.com> Tue, 27 July 2010 13:38 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 4ADB83A6802 for <hybi@core3.amsl.com>; Tue, 27 Jul 2010 06:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.755
X-Spam-Level:
X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.221, 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 uErOiMF+sbYw for <hybi@core3.amsl.com>; Tue, 27 Jul 2010 06:38:31 -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 F26A33A690F for <hybi@ietf.org>; Tue, 27 Jul 2010 06:38:30 -0700 (PDT)
Received: by fxm1 with SMTP id 1so674339fxm.31 for <hybi@ietf.org>; Tue, 27 Jul 2010 06:38:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.104.148 with SMTP id p20mr8128917fao.11.1280237932170; Tue, 27 Jul 2010 06:38:52 -0700 (PDT)
Received: by 10.223.112.129 with HTTP; Tue, 27 Jul 2010 06:38:52 -0700 (PDT)
In-Reply-To: <op.vghpu5z464w2qv@annevk-t60>
References: <ECF0E97F-1DA2-4662-BA48-F68B65AA8179@apple.com> <4C4D66AF.9030905@opera.com> <Pine.LNX.4.64.1007270030120.24444@ps20323.dreamhostps.com> <AANLkTi=fx=Yfm_pe9-pdCc=5sKRP=dNfDEBYCKNHFOmH@mail.gmail.com> <op.vghnjpex64w2qv@annevk-t60> <AANLkTik5AB=UPJ47z8tEnVygJodPVAmppeXUymMBz+9n@mail.gmail.com> <op.vghpu5z464w2qv@annevk-t60>
Date: Tue, 27 Jul 2010 23:38:52 +1000
Message-ID: <AANLkTimFBzkijgaKtYjjwcqF2u65OOPDiNBfphMNB7m-@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Anne van Kesteren <annevk@opera.com>
Content-Type: multipart/alternative; boundary="001636c5b3122ccce5048c5e9fc7"
Cc: hybi@ietf.org
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 13:38:46 -0000

On 27 July 2010 17:03, Anne van Kesteren <annevk@opera.com> wrote:

> The solution is to not make breaking changes. Versioning is ignored by
> clients for HTTP, HTML has no versioning by design, CSS has no versioning by
> design, etc. Versioning does not work well on the Web.
>
> http://dbaron.org/log/2007-03#e20070325a explains some of this in more
> detail.



Versions are used extensively in HTTP on the server side, where the HTTP
version sets the default options and assumed behaviour that is then altered
by negotiation.

For example HTTP/1.0 connections are assumed non-persistent unless
negotiated otherwise, while HTTP/1.1 is assumed persistent unless otherwise
declared.


However,  I generally agree that having a good optional feature negotiation
mechanism is probably more important that a version.  However I think that a
version is at least helpful to define the known option space and is not
particularly harmful.


regards