Re: [hybi] new version hybi-requirements

Greg Wilkins <gregw@webtide.com> Wed, 17 March 2010 10:16 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 4EFEB3A6861 for <hybi@core3.amsl.com>; Wed, 17 Mar 2010 03:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.727
X-Spam-Level:
X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=-1.858, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 sMdMjL9L80PX for <hybi@core3.amsl.com>; Wed, 17 Mar 2010 03:16:29 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 766F53A67E3 for <hybi@ietf.org>; Wed, 17 Mar 2010 03:16:28 -0700 (PDT)
Received: by wwf26 with SMTP id 26so615959wwf.31 for <hybi@ietf.org>; Wed, 17 Mar 2010 03:16:34 -0700 (PDT)
Received: by 10.216.91.76 with SMTP id g54mr346042wef.2.1268820994751; Wed, 17 Mar 2010 03:16:34 -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 n12sm18873988gve.0.2010.03.17.03.16.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Mar 2010 03:16:33 -0700 (PDT)
Message-ID: <4BA0ABFF.10405@webtide.com>
Date: Wed, 17 Mar 2010 11:16:31 +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: <4B9554A0.1000909@ericsson.com> <20100317092706.GD14108@voodoowarez.com>
In-Reply-To: <20100317092706.GD14108@voodoowarez.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] new version hybi-requirements
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: Wed, 17 Mar 2010 10:16:30 -0000

rektide wrote:
> On Mon, Mar 08, 2010 at 09:48:48PM +0200, Salvatore Loreto wrote:
>> Hi there,
>>
>> I have submitted a new version of the "HyBi Requirements and Features"
>> http://www.ietf.org/id/draft-loreto-hybi-requirements-01.txt
> 
> Forgive me for apparently not understanding the purpose of this working group, but why are
> hybi's requirements all tied directly to WebSocket?  Is this group bound 100% to evolving
> WebSocket and its current implementation?  Are no other options tennable?

Rektide,

When I joined the hybi effort at the IETF, I did advocate that we look at
other options to fit the needs at hand.

However, to paraphrase my understanding of IETF process, it is all about
rough consensus and working code and it is not about designing new solutions
by committee. So the rough consensus at the BOF in Hiroshima, was that the
WG should focus on standardizing the working code that is at hand - ie websocket.

I do not think that means that other options like SPDY and BWTP are not
able to be consider at some stage by the IETF - just that they are not
the immediate focus of this working group.

Note also, that while I am a vocal critic of the websocket protocol,
I do recognize that it has the interest of the browser vendors and
developer community.   So I actually believe that the best path to
a workable solution is to take that momentum and incrementally
improve the protocol/specification.   So I now share this working
groups focus on websocket.

In my current version of a perfect world, websocket's framing
would be rationalized somewhat,  the intermediaries on the internet
would be upgraded to well support it, and then richer protocols
like SPDY and BWTP could build on websockets rather than
re-invent ways to bidirectionally traverse the web.

cheers