IETF Logo Mail Archive

[hybi] Process! was: [whatwg] HttpOnly cookie for WebSocket?

Greg Wilkins <gregw@webtide.com> Fri, 29 January 2010 03:34 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 7BD4E3A6853 for <hybi@core3.amsl.com>; Thu, 28 Jan 2010 19:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, PLING_QUERY=1.39]
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 hgQ3fGsue2yx for <hybi@core3.amsl.com>; Thu, 28 Jan 2010 19:34:06 -0800 (PST)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 9AD4D3A67F0 for <hybi@ietf.org>; Thu, 28 Jan 2010 19:34:06 -0800 (PST)
Received: by qw-out-2122.google.com with SMTP id 9so332916qwb.31 for <hybi@ietf.org>; Thu, 28 Jan 2010 19:34:22 -0800 (PST)
Received: by 10.224.66.41 with SMTP id l41mr92891qai.307.1264736059468; Thu, 28 Jan 2010 19:34:19 -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 5sm5900808qwg.8.2010.01.28.19.34.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 19:34:18 -0800 (PST)
Message-ID: <4B625733.2020907@webtide.com>
Date: Fri, 29 Jan 2010 14:34:11 +1100
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: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <4B614CEC.2050400@ericsson.com> <Pine.LNX.4.64.1001280856380.22020@ps20323.dreamhostps.com> <4B616F17.4030402@ericsson.com> <4B619223.60408@webtide.com> <Pine.LNX.4.64.1001282141080.22020@ps20323.dreamhostps.com> <4B620B8F.6030706@gmx.de> <Pine.LNX.4.64.1001282217320.22053@ps20323.dreamhostps.com> <bbeaa26f1001281449q1a6e1813q3f537fe15a5a9d60@mail.gmail.com>
In-Reply-To: <bbeaa26f1001281449q1a6e1813q3f537fe15a5a9d60@mail.gmail.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: [hybi] Process! was: [whatwg] HttpOnly cookie for 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: Fri, 29 Jan 2010 03:34:07 -0000

Ian Fette (イアンフェッティ) wrote:
> Instead, we are bogged down in politics.

Work is proceeding on all fronts on the actual implementations,
so I don't think we are bogged down.   Nobody is saying hold
any releases for this.   In fact I think it will be good to
get experience from wider usage of the protocol as it currently
stands.

But there are important issues to be discussed here and they
should not be derided as just unproductive politics.
Who will edit the specification document is a key question that
needs to be answered (but probably not in the HttpOnly cookie
thread).

For me (and my company, project & community), I have a problem
with the WhatWG process as it is not sufficiently open. It boils
down to:

 0) Ian has been appointed AFAICT by an industry consortium
    of browser vendors.
 1) you can talk all you like
 2) but you have to convince Ian to change anything
 3) you have to be prepared to be unhappy if you can't
    convince Ian

I don't mean to dis Ian or the whatwg and I understand they've
done great work on HTML5.  But this is hardly the right
process to standardize a protocol that will fundamentally
affect the entire network infrastructure, with many components
that cannot easily as easily updated as issuing a new point
release on a browser.  I don't see how we can put 1 person
(any person) as the sole final arbiter of such a important
decisions.

The IETF has a proven process for producing internet standards
that the entire industry follow.    Why is websocket so special
that it needs a different process?


> If we can't figure out how to move forward on such a simple issue, it
> seems to me that we are in an unworkable situation, and should probably
> just continue the work in WHATWG through to a final spec, let
> implementations settle for a while, and then hand it off to IETF for
> refinement and finalization in a v2 spec... (my $0.02)

I'm not a IETF process expert, but what I do know indicates
that the IETF is just as unlikely to rubber stamp a V2 as they
are to rubber stamp a V1.

The whatwg is perfectly entitle to keep the specification
under their own auspices, but if they want the specification
to be given the gravitas of an official IETF document, then it
has to be  exposed to the IETF process and achieve a rough
consensus of all who are involved - including the whatwg.

Delaying the IETF process to v2 is unlikely to change many
of those voices from whom rough consensus is required.
The "it's deploy now, so it's too late to change", is not
a great argument to rely on.

The whatwg has done a great job getting it this far,
but I really think they should trust (and be involved in)
the IETF process to take it to the next stage.


regards

v2.23.0 | Report a Bug | By Email