IETF Logo Mail Archive

Re: [hybi] Extensibility mechanisms?

Scott Ferguson <ferg@caucho.com> Thu, 22 July 2010 00:31 UTC

Return-Path: <ferg@caucho.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 A9DDB3A6964 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 17:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.264
X-Spam-Level:
X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 y4H-xua+q28M for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 17:30:45 -0700 (PDT)
Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 21B9E3A6978 for <hybi@ietf.org>; Wed, 21 Jul 2010 17:30:32 -0700 (PDT)
Received: (qmail 43850 invoked from network); 22 Jul 2010 00:30:46 -0000
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 21 Jul 2010 17:30:46 -0700 PDT
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: B0ss9BgVM1mUVJol_y4tEl68xqcFwIeh5HfA293HZMA4nhI rbSH3fTONRY.RrdIxscXdL9bM1Vy8xfqwPb6cEVZbC05rXhXoqYxyDGnH.vj sFJnBS_ogyYIiqLrYzMuYodEK7_YINwqu5jsSTIyeoq5PQWXQIKxBSC44hOY cJioOtwLsbq0276beRrWAeZbz6zvxawDqn68.5An2MpVZleTlb2i27pphUMn 2exAqjgdIYW16g7JvfAx_XRta7hIbQOIl_PDMxqlelxUi12hv7inP71_xktY HYtIG3t2efILKeFWp_YM2rnsReI7a2lDVJ99zxTg6QmrnVnPB9PR8aQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C479130.4020500@caucho.com>
Date: Wed, 21 Jul 2010 17:30:40 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Mike Belshe <mike@belshe.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <4BCAB2C1.2000404@webtide.com> <B9DC25B0-CD21-44E7-BD9B-06D0C9440933@apple.com> <4BCB7829.9010204@caucho.com> <Pine.LNX.4.64.1004182349240.751@ps20323.dreamhostps.com> <4BCC0A07.9030003@gmx.de> <Pine.LNX.4.64.1004190753510.23507@ps20323.dreamhostps.com> <4BCC111C.90707@gmx.de> <Pine.LNX.4.64.1004190837570.23507@ps20323.dreamhostps.com> <4BCC204D.30004@gmx.de> <z2gad99d8ce1004190822ne4dd36b6v54d63efcc448e840@mail.gmail.com> <Pine.LNX.4.64.1007202204270.7242@ps20323.dreamhostps.com> <AANLkTikkfdlUxQ0MGNvVQKa5gfovkGHWdCgyN9juKSQJ@mail.gmail.com> <4C462F9E.9030207@caucho.com> <Pine.LNX.4.64.1007212153110.7242@ps20323.dreamhostps.com> <AANLkTiku76oSucTNDFdwgsFBNFa_cCpC-YktTnMfX47-@mail.gmail.com>
In-Reply-To: <AANLkTiku76oSucTNDFdwgsFBNFa_cCpC-YktTnMfX47-@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Thu, 22 Jul 2010 00:31:44 -0000
X-List-Received-Date: Thu, 22 Jul 2010 00:31:44 -0000

Mike Belshe wrote:
>
>
> On Wed, Jul 21, 2010 at 3:17 PM, Ian Hickson <ian@hixie.ch 
> <mailto:ian@hixie.ch>> wrote:
>
>
>     I disagree that the protocol's development has been in any way
>     held up by
>     this. I agree that we've talked about it a lot in the working
>     group, but
>     the spec itself hasn't been affected by this as far as I can tell.
>
>
> To be specific, our earlier discussions about error handling, large 
> frames, and binary frames were all cut short under the "too hard for 
> amateur programmers".
The entire spec has frozen in a broken state for months because of Ian's 
intransigence (frozen = "not affected"), and the chairs' unwillingness 
to address the issue.

* It doesn't have any support for binary data.

* It doesn't have any support for basic protocol concepts like chunking.

* It doesn't have any way of extending to the multiplexing/flow control 
that's been brought up numerous times.

* It doesn't have any to handle error frames.

* It doesn't address the keepalive/ping issue at all.

* It doesn't address the RTT issues.

* It doesn't even conform to the HTTP specification correctly.

The current spec is a joke.

The only reason discussion started up again was because of the 
possibility of getting a real editor for the spec and moving on.

If the chairs decide to do nothing -- again --  we'll be stuck with a 
bad spec that solves no problem well.

>
>     And what did the protocol amateurs you spoke to say? It seems
>     unsurprising
>     that people whose careers are based on being able to solve complicated
>     protocol problems should want protocols to be complicated.
>
FFS. Nice combination ad-hom/strawman there.  [Chairs? This is your editor.]

The counterproposal at

  
http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest.html

not complicated at all: it's a trivial protocol, and yet it solves the 
HyBi requirements, including requirements that the current draft 
ignores, as well as being extensible to muxing requirements.

A dozen members of this list could come up with proposals as simple as 
that one and most would improve on it.

-- Scott

v2.23.0 | Report a Bug | By Email