Re: [hybi] updated Charter proposal (WebSocket)

Julian Reschke <julian.reschke@gmx.de> Tue, 27 October 2009 13:57 UTC

Return-Path: <julian.reschke@gmx.de>
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 4A9773A6969 for <hybi@core3.amsl.com>; Tue, 27 Oct 2009 06:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.904
X-Spam-Level:
X-Spam-Status: No, score=-3.904 tagged_above=-999 required=5 tests=[AWL=-1.435, BAYES_00=-2.599, SARE_RMML_Stock10=0.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 ZfoGL8c0m6F8 for <hybi@core3.amsl.com>; Tue, 27 Oct 2009 06:57:45 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2CD6D3A6955 for <hybi@ietf.org>; Tue, 27 Oct 2009 06:57:44 -0700 (PDT)
Received: (qmail invoked by alias); 27 Oct 2009 13:57:57 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 27 Oct 2009 14:57:57 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1//YukFSMf/+oqZrFR2LYkf4LPzalAKm7xdb0WjJl Hj0n1c+HWpxX66
Message-ID: <4AE6FC61.3070201@gmx.de>
Date: Tue, 27 Oct 2009 14:57:53 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
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> <Pine.LNX.4.62.0910270011060.13521@hixie.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.62.0910270011060.13521@hixie.dreamhostps.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.67
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: Tue, 27 Oct 2009 13:57:46 -0000

Ian Hickson wrote:
> On Mon, 26 Oct 2009, Greg Wilkins wrote:
>> Maciej Stachowiak wrote:
>>> I agree with that point of view. It seems sensible to use WebSocket 
>>> Protocol as the starting point, even if we see the need to add 
>>> features or otherwise change the protocol. There doesn't seem to be a 
>>> strong case for starting from scratch.
>> [...] 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.
> 
> I agree with Greg that it would be inappropriate for the WG to be bound to 
> adopt a particular proposal or rubber-stamp a particular proposal.
> 
> What matters much more is that the group's deliverables have the buy-in of 
> the relevant implementors -- if we write a technology that is intended to 
> be implemented by proxy vendors, then proxy vendors need to be willing to 
> implement it. If we write a technology that is intended to be implemented 
> by Web browsers, then Web browsers need to be willing to implement it. 
> Otherwise, we're just wasting our time writing boring science fiction.

My understanding is that you want the protocol to be implemented by Web 
browsers, right? In which case the WG should make sure that those people 
actually intend to join the working group.

Having a consensus-driven process that doesn't involve those who are 
supposed to implement the protocol would be a problem.

BR, Julian