Re: [hybi] Process, was: Technical feedback. was: Process!

Greg Wilkins <gregw@webtide.com> Sun, 31 January 2010 08: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 0A0F128C0DB for <hybi@core3.amsl.com>; Sun, 31 Jan 2010 00:16:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.262
X-Spam-Level:
X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
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 dWPbgQv16WG9 for <hybi@core3.amsl.com>; Sun, 31 Jan 2010 00:16:26 -0800 (PST)
Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id AD68028C0D8 for <hybi@ietf.org>; Sun, 31 Jan 2010 00:16:26 -0800 (PST)
Received: by ywh1 with SMTP id 1so1811462ywh.18 for <hybi@ietf.org>; Sun, 31 Jan 2010 00:16:51 -0800 (PST)
Received: by 10.91.19.27 with SMTP id w27mr2550130agi.118.1264925810378; Sun, 31 Jan 2010 00:16:50 -0800 (PST)
Received: from ?10.10.1.11? (60-242-119-126.tpgi.com.au [60.242.119.126]) by mx.google.com with ESMTPS id 14sm2413206gxk.2.2010.01.31.00.16.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Jan 2010 00:16:49 -0800 (PST)
Message-ID: <4B653C66.1050200@webtide.com>
Date: Sun, 31 Jan 2010 19:16:38 +1100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Maciej Stachowiak <mjs@apple.com>, Hybi <hybi@ietf.org>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <4B620B8F.6030706@gmx.de> <Pine.LNX.4.64.1001282217320.22053@ps20323.dreamhostps.com> <bbeaa26f1001281449q1a6e1813q3f537fe15a5a9d60@mail.gmail.com> <4B625733.2020907@webtide.com> <6.2.5.6.2.20100128225542.06fa8d68@resistor.net> <Pine.LNX.4.64.1001290817520.22020@ps20323.dreamhostps.com> <4B62C5FE.8090904@it.aoyama.ac.jp> <Pine.LNX.4.64.1001291134350.22020@ps20323.dreamhostps.com> <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com> <BBF3CE06-3276-4A7C-8961-7B3DDEE406D0@apple.com> <4B63DC2D.4090702@webtide.com> <4678E38C-EBD3-4867-B3A6-53A60F7F26C0@apple.com> <4B64BB99.8030906@webtide.com> <6A888E48-42AF-4476-8B41-3D3A08766D77@apple.com>
In-Reply-To: <6A888E48-42AF-4476-8B41-3D3A08766D77@apple.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Process, was: Technical feedback. was: Process!
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, 31 Jan 2010 08:16:28 -0000

Maciej Stachowiak wrote:

> I think you have raised some valid issues, and I personally think they should be addressed 
> (if not in 1.0 of the protocol, at least understand how a later protocol revision could handle it).
> However, I must admit that some of your comments sound like handwaving that assumes the solution
> without clearly stating the problem. For example, when you talk about the problem of figuring
> out your idle timeout, it seems like the problem statement is very clear. Whenever you talk
> about the desire to have arbitrary metadata, I haven't seen you clearly relate that back to a
> specific use case or concrete problem to be solved. I can see why feedback of that second sort
> might not get much of a hearing. I think if you focus on concrete problems you have run into
> as an implementor, you will have much better luck.

Maciej,

I think that is a pretty unfair comment.

I've not provided much detail this time around because the points have been
made so many times before.

I have previously provided many lengthy detailed discussions about these
points.  I have proposed several concrete enhancements to websocket, I've
blogged at length about some other ways to improve websocket

  http://blogs.webtide.com/gregw/entry/how_to_improve_websocket

and I've even drafted two versions of an alternative protocol BWTP
that has gained some interest:

  http://www.ietf.org/id/draft-wilkins-hybi-bwtp-00.txt
  http://bwtp.wikidot.com/

There are two implementations of BWTP available.

I've got deployed comet services with millions of users and am happy to
answer any questions asked about my experiences or comments expressed here.

There has been plenty of support expressed on this list for the issues
raised and plenty of other issues raised by others on this list as well.

This is not hand waiving.

>> Hence my strong words against the WHATWG process.  It has disenfranchised a
>> significant part of the internet community and is not addressing the concerns
>> that are being raised.
> 
> Now you have the opportunity to discuss these things under the IETF process. Go for it.

Well perhaps you are correct.
We should treat this a day 0 and start again and restate the problems, requirements
etc.  I do believe this is exactly the schedule outlined in the charter - which has
now been questioned by the WHATWG.


> It seems plausible that we may need a revision of the protocol down the line. But 
> I think that developing the two versions in two separate standards organizations,
> and doing so simultaneously and without trying to agree together on the right
> outcome, is not likely to lead to a coherent outcome.

The WHATWG have not expressed any interest in further extending the protocol.
They say their current goal is to achieve interoperability, which I assume means
solving  any ambiguities of misunderstandings of the current document.

If that truly is their only current objective, then don't see a particular
problem if the IETF moves forward with proposals/discussion/consideration of
how to improve websocket to deal with issues like orderly close and idle
timeouts.  Of course coordination will be required and the whatwg need to
be part of any consensus on new features.

regards