Re: [hybi] Requirement: extensions and sub protocols

Greg Wilkins <gregw@webtide.com> Fri, 05 March 2010 14:44 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 464F23A8FB2 for <hybi@core3.amsl.com>; Fri, 5 Mar 2010 06:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 D7wzG15K2dxC for <hybi@core3.amsl.com>; Fri, 5 Mar 2010 06:44:51 -0800 (PST)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 504513A8FB5 for <hybi@ietf.org>; Fri, 5 Mar 2010 06:44:51 -0800 (PST)
Received: by fxm5 with SMTP id 5so4185821fxm.29 for <hybi@ietf.org>; Fri, 05 Mar 2010 06:44:53 -0800 (PST)
Received: by 10.223.77.136 with SMTP id g8mr1207264fak.10.1267800293061; Fri, 05 Mar 2010 06:44:53 -0800 (PST)
Received: from [192.168.0.100] (host116-234-static.43-88-b.business.telecomitalia.it [88.43.234.116]) by mx.google.com with ESMTPS id 13sm1221984fxm.14.2010.03.05.06.44.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Mar 2010 06:44:52 -0800 (PST)
Message-ID: <4B9118DC.6030301@webtide.com>
Date: Fri, 05 Mar 2010 15:44:44 +0100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Hybi <hybi@ietf.org>
References: <4B8ECA2D.4050303@ericsson.com>
In-Reply-To: <4B8ECA2D.4050303@ericsson.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Requirement: extensions and sub protocols
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: Fri, 05 Mar 2010 14:44:52 -0000

I think we need to decide who will be doing the extending
and creating new subprotocols.

Ian appears to be advancing the position that if it can't
be done in javascript via the websocket API, then it can't
be done.  Moreover, that if you are not doing it in javascript
then you shouldn't be using websockets.


I disagree with that position (which is hopefully
somewhat close to what Ian actually is saying).

I think that extensions are most likely to be
implemented transparently below the API or
in the path to the server.


Examples that come to mind include:

  Browser implementing a simple multiplexing standard
  to make all websockets from the same tab/window share
  a common connection.

  Browser implementing compression.

  Firewalls acting as aggregators and combining
  multiple base connections into fewer multiplexed
  connections to the business servers.

  Appliances doing SSL offload and converting wss to ws
  connections with injected certificate information.


I also think that there will be extensions done
in javascript by frameworks/applications, but by
definition they work above the API and need no more
support from the base protocol than the API already
provides.

regards