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

Greg Wilkins <gregw@webtide.com> Fri, 29 January 2010 13:39 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 A9FF53A6A37 for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 05:39:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level:
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 8ZMKxNAuhUSS for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 05:39:24 -0800 (PST)
Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id 9B0023A6A3B for <hybi@ietf.org>; Fri, 29 Jan 2010 05:39:24 -0800 (PST)
Received: by gxk26 with SMTP id 26so114954gxk.8 for <hybi@ietf.org>; Fri, 29 Jan 2010 05:39:44 -0800 (PST)
Received: by 10.101.128.5 with SMTP id f5mr921453ann.125.1264772383899; Fri, 29 Jan 2010 05:39:43 -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 16sm1235061gxk.15.2010.01.29.05.39.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 05:39:42 -0800 (PST)
Message-ID: <4B62E516.2010003@webtide.com>
Date: Sat, 30 Jan 2010 00:39:34 +1100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>, 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> <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>
In-Reply-To: <Pine.LNX.4.64.1001291134350.22020@ps20323.dreamhostps.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [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 13:39:25 -0000

Ian Hickson wrote:
> On Fri, 29 Jan 2010, "Martin J. Dürst" wrote:
>> Ian, could you please explain how exactly *you* imagine such a 
>> cooperation should work, if not e.g. by cross-posting?
> 
> The same way it works with the HTML5 specification and the various Web 
> Apps specifications....


Ian,

the problem with this approach is that an internet protocol
is out of scope of for the WHATWG charter and the WHATWG
process is entirely inappropriate for forging a consensus
across all the interested parties.

The whatwg process relies on the consent of a single individual
(yourself) as editor.  This position is an appointment made by an
invitation only committee made up of 9 representatives from
various  browser manufacturers.   You are also on that committee,
the spokesman for the group and an employee of the company that
is shipping the first client implementation.

The whatwg self describes as having a main focus of HTML5,
plus work on Web Workers, Web Forms and Web Controls.   There
is nothing in the whatwg activities to suggest that it is
the right body to specify something that will affect web
servers, OS network stacks, firewalls, proxies, routers, bridges,
caches, connection aggregators, SSL offload, load balancers,
filters,  corporate security policies, web frameworks,
3G networks, mobile battery life, traffic analysis tools,
etc. etc.

I'm totally happy for a consortium of browser vendors
to use whatever process they like to define the
specifications for the mark up and javascript APIs
they will support in their own products.

I'm totally unhappy that such a consortium should
produce a "standard" internet protocol without
due process involving all of the industry and
community in a truly open decision making process.

You are an incredibly diligent guy and I really applaud
the effort you put in to consider and reply to the
vast amount of feedback that you get.  But at the
end of the day, if you personally are unconvinced, then
it's not going in the spec.   No one person is without
bias, conflicts of interest, areas of inexperience,
bad days at the office etc.




So the solution that I would like to suggest,
is that the WhatWG continue work on the current protocol
specification, and that will be 1.0.  The browser vendors and
other WhatWG participants can continue to work towards the
goal of interoperable  implementations.  This will be a
WhatWG document and will never be an IETF RFC.

In parallel, the IETF WG should focus on producing
a 1.1 version of the protocol/specification based on
an all-of-industry feedback and consensus.  This will
be built on 1.0 and have reasonable backwards
compatibility as a necessary requirement.  But it's
charter will directly address the concerns of the whole
internet and not just the browsers and app developers.
It will exposed to the full IETF process and will
eventually be an IETF RFC.

Each group will have editorial control over
their own document and they will need to
cooperate, so that they do not significantly
diverge on any points of substance.  The
whatwg would also participate in the IETF
process and their consent would be a vital
part of any rough consensus there.

This is not unlike the standardization of HTTP,
where HTTP/1.0 was more or less a codification of the
protocol that had been implemented by browsers.
HTTP/1.1 was the internet standard developed by
all of industry and addressed the concerns of all.


regards