Re: [hybi] Extensibility mechanisms?

Ian Hickson <ian@hixie.ch> Sun, 18 April 2010 23:48 UTC

Return-Path: <ian@hixie.ch>
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 6FF3C3A6877 for <hybi@core3.amsl.com>; Sun, 18 Apr 2010 16:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.833
X-Spam-Level:
X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.766, 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 7CpMSjNMPnnn for <hybi@core3.amsl.com>; Sun, 18 Apr 2010 16:48:56 -0700 (PDT)
Received: from looneymail-a2.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 626E93A67A6 for <hybi@ietf.org>; Sun, 18 Apr 2010 16:48:56 -0700 (PDT)
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a2.g.dreamhost.com (Postfix) with ESMTP id 6E3B416D43A; Sun, 18 Apr 2010 16:48:48 -0700 (PDT)
Date: Sun, 18 Apr 2010 23:48:48 +0000
From: Ian Hickson <ian@hixie.ch>
To: Greg Wilkins <gregw@webtide.com>
In-Reply-To: <4BCB6FD0.7080003@webtide.com>
Message-ID: <Pine.LNX.4.64.1004182111180.751@ps20323.dreamhostps.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <Pine.LNX.4.64.1004160701250.751@ps20323.dreamhostps.com> <4BC860FD.8080007@webtide.com> <Pine.LNX.4.64.1004161952530.751@ps20323.dreamhostps.com> <4BC96A0D.4080904@webtide.com> <Pine.LNX.4.64.1004180246380.751@ps20323.dreamhostps.com> <4BCAB2C1.2000404@webtide.com> <B9DC25B0-CD21-44E7-BD9B-06D0C9440933@apple.com> <Pine.LNX.4.64.1004181812370.751@ps20323.dreamhostps.com> <4BCB6641.70408@webtide.com> <Pine.LNX.4.64.1004182010070.751@ps20323.dreamhostps.com> <4BCB6FD0.7080003@webtide.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Extensibility mechanisms?
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: Sun, 18 Apr 2010 23:48:57 -0000

On Sun, 18 Apr 2010, Greg Wilkins wrote:
> Ian Hickson wrote:
> > 
> > Why would a large scale deployments with complex infrastructure that 
> > can't handle BEEP framing opt-in to an experimental non-standard 
> > feature that uses BEEP framing?
> 
> because experiments are a precursor to real deployments.

I'm having great trouble understanding your scenario.

You are concerned that a browser might deploy an experimental non-standard 
feature that changes the framing of Web Sockets, because it is possible 
that large scale deployments with complex infrastructure that can't handle 
the new framing might want to opt in to such experiments because 
eventually they will want to do a real deployment of this new framing?


> >> If you want to send BEEP over a HTTP connection, then you should 
> >> upgrade to BEEP, not websocket.
> > 
> > If the handshake involves an optional opt-in to a non-standard 
> > experimental feature, and you accept it, then you're not upgrading to 
> > Web Socket, you're upgrading to a non-standard protocol influenced by 
> > Web Sockets, as defined by the convention you and the client are 
> > using.
> 
> My point is that an intermediary can't possible know about all 
> subprotocols (experimental or otherwise), nor be expected to upgrade 
> everytime a new subprotocol is invented.

We're not talking about subprotocols here, we're talking about Web Socket 
protocol extensions.

A server-side intermediary only needs to know about the protocol features 
and options that are in use at the site. This is similar to how the 
server-side intermediaries need to know about the version of HTTP in use 
at the site. If someone deploys a new experimental compression scheme in a 
Web browser, deployment sites that don't opt-in to using that compression 
scheme need not know anything about it.


> Intermediaries can know about websocket framing and so long as all sub 
> protocols and extensions are restricted to adhere to websocket framing, 
> then intermediaries can continue to work regardless of sub protocols.

What do you mean by "restricted"?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'