Re: [hybi] Extensibility mechanisms?

Greg Wilkins <gregw@webtide.com> Sun, 18 April 2010 07:28 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 C26DC3A6B86 for <hybi@core3.amsl.com>; Sun, 18 Apr 2010 00:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.865
X-Spam-Level:
X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_20=-0.74]
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 kEBB3lnALb3Y for <hybi@core3.amsl.com>; Sun, 18 Apr 2010 00:28:17 -0700 (PDT)
Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 789743A67B2 for <hybi@ietf.org>; Sun, 18 Apr 2010 00:28:17 -0700 (PDT)
Received: by bwz25 with SMTP id 25so4389708bwz.28 for <hybi@ietf.org>; Sun, 18 Apr 2010 00:28:06 -0700 (PDT)
Received: by 10.204.152.2 with SMTP id e2mr3524760bkw.81.1271575685693; Sun, 18 Apr 2010 00:28:05 -0700 (PDT)
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 14sm2589654bwz.6.2010.04.18.00.28.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Apr 2010 00:28:04 -0700 (PDT)
Message-ID: <4BCAB481.2030206@webtide.com>
Date: Sun, 18 Apr 2010 09:28:01 +0200
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Hybi <hybi@ietf.org>
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> <r2x5c902b9e1004170013o79f0b998v35a459c3fe648fb1@mail.gmail.com> <Pine.LNX.4.64.1004180232330.751@ps20323.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.64.1004180232330.751@ps20323.dreamhostps.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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 07:28:18 -0000

Ian Hickson wrote:

> For all intents and purposes, the server is everything under control of 
> the end point authority. 

Even the smallest deployment will have to deal with
ISPs, Data centres or even home routers, which are not under
the authority of the application developer.


> The spec explicitly
> states that conformance requirements are essentially "black box" 
> conformance requirements. It doesn't require the server to use a single 
> processor; the TLS, Web Socket, and subprotocol handshakes could all be 
> handled by completely different machines on different coasts, so long as 
> the end result is indistinguishable from what the spec requires.

End points are always going to be assembled from
multiple "boxes" black, grey and white, probably
from different vendors, that interoperate using
open standards.    These "boxes" may just be language
libraries, or ISP provided firewalls or full
corporate DMZ layers.

If interoperability is to be achieved, the standard
cannot end at the first box.

So back to the original objection I raised.  If
an intermediary sees a HTTP connection upgraded to
websocket, then it should be able to make the
reasonable assumption that protocol it will
subseqently see will be that described in the
websocket specification.   Allowing arbitrary
framing by sub protocols will break that
reasonable assumption.


regards