Re: [hybi] updated Charter proposal (WebSocket)

Greg Wilkins <gregw@webtide.com> Mon, 26 October 2009 23:52 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 B704B3A69D8 for <hybi@core3.amsl.com>; Mon, 26 Oct 2009 16:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 Pn6HyLsOSmtq for <hybi@core3.amsl.com>; Mon, 26 Oct 2009 16:52:13 -0700 (PDT)
Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 7B7B128C1AB for <hybi@ietf.org>; Mon, 26 Oct 2009 16:52:13 -0700 (PDT)
Received: by ewy4 with SMTP id 4so4165400ewy.37 for <hybi@ietf.org>; Mon, 26 Oct 2009 16:52:23 -0700 (PDT)
Received: by 10.216.86.213 with SMTP id w63mr2369847wee.71.1256601143721; Mon, 26 Oct 2009 16:52:23 -0700 (PDT)
Received: from ?10.10.1.9? (60-242-119-126.tpgi.com.au [60.242.119.126]) by mx.google.com with ESMTPS id u14sm18285785gvf.3.2009.10.26.16.52.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 16:52:22 -0700 (PDT)
Message-ID: <4AE6362B.4030305@webtide.com>
Date: Tue, 27 Oct 2009 10:52:11 +1100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Lisa Dusseault <lisa.dusseault@gmail.com>
References: <4ADEC7A0.7040307@ericsson.com> <4AE4CCBB.10001@webtide.com> <Pine.LNX.4.62.0910260006420.9145@hixie.dreamhostps.com> <4AE553A0.9030208@ericsson.com> <73F5E810-F40F-42B8-81A9-4AD1306E360F@apple.com> <4AE57B62.4030209@webtide.com> <ca722a9e0910261139q27a3241aieae39a6a0525b290@mail.gmail.com>
In-Reply-To: <ca722a9e0910261139q27a3241aieae39a6a0525b290@mail.gmail.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] updated Charter proposal (WebSocket)
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: Mon, 26 Oct 2009 23:52:14 -0000

Lisa Dusseault wrote:
> On Mon, Oct 26, 2009 at 3:35 AM, Greg Wilkins <gregw@webtide.com> wrote:
>> ...
>> However, I don't think the charter should mandate the WebSocket protocol
>> as the outcome.
>>
>> The protocol should be able to be selected on it's own merits - and
>> that includes the effort that many have put towards it already.
>>
> 
> Hi Greg,
> 
> Asking WGs to run beauty contests typically turns out to be
> problematic.  I think we get better success at asking whether it's
> appropriate to form a WG around a specific proposal, and that doesn't
> exclude other WGs and other proposals.  It's really the WG formation
> process that lets the entire IETF decide if a WG working on the
> WebSocket protocol is the right thing to do.   That process does
> address the merits, and it avoids the "there can be only one" fallacy.

OK if that's the process, then that's the process.

However, the authors of the protocol have so far been very
resistant to change (not even using BNF or allocating a
type byte for mime-encoded content).

So will the WG have the ability to come up with it's own
draft for a websocket protocol - or will all it be able
to do is huff and puff and hope to convince the whatwg?

The problem with that approach is that the whatwg
have a different world view (js only, not so hard
to release new versions, run around intermediaries, keep it
totally simple) to many view expressed in the IETF forum
(many client types, hard to release new versions, involve
the intermediaries, make it extensible).

It maybe that the websocket protocol is perfect
for the whatwg's objectives, but insufficient for
the IETF's.   I'm not sure how we get past that
log jam if the WG is not able to author its
own protocol or variations?


regards