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

Francis Brosnan Blazquez <francis@aspl.es> Fri, 29 January 2010 15:39 UTC

Return-Path: <francis@aspl.es>
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 74F713A680E for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 07:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.674
X-Spam-Level: ***
X-Spam-Status: No, score=3.674 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, 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 Dj93vPzouwsY for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 07:39:37 -0800 (PST)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by core3.amsl.com (Postfix) with ESMTP id 0F4C73A67AC for <hybi@ietf.org>; Fri, 29 Jan 2010 07:39:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id A98E81170003; Fri, 29 Jan 2010 16:39:55 +0100 (CET)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTOWLaI00kMB; Fri, 29 Jan 2010 16:39:53 +0100 (CET)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id 93A481170001; Fri, 29 Jan 2010 16:39:53 +0100 (CET)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: Ian Hickson <ian@hixie.ch>
In-Reply-To: <Pine.LNX.4.64.1001291140440.22020@ps20323.dreamhostps.com>
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> <6.2.5.6.2.20100129023917.06806000@resistor.net> <Pine.LNX.4.64.1001291140440.22020@ps20323.dreamhostps.com>
Content-Type: text/plain
Organization: ASPL
Date: Fri, 29 Jan 2010 16:39:53 +0100
Message-Id: <1264779593.4450.230.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
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 15:39:38 -0000

Hi Ian,

> IMHO it's the interoperable implementations that matter, but if we can 
> get consensus as well then so much the better.

This is circular; without consensus it will be more difficult to get
interoperable implementations...and at this moment all the politics
created comes more from not having such consensus (rather than whatwg
vs. ietf).

We are really interested on getting Websocket integrated in our products
but we have found some limitations [1]. 

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg00977.html

Maybe we have missed something, so I ask again:

1) It is possible to send binary content (that includes octets 0x00 and
0xFF) from a browser javascript?

2) Will be Websocket protocol be able to use existing HTTP proxies? 

> > > But it doesn't mention the WHATWG, which is working on this spec.
> > 
> > Yes, it doesn't.  The Working Group would have to recharter if it wants 
> > to add that.
> 
> If the charter is to be relevant, it seems that acknowledging what is 
> actually being done is important. Personally I do not put much stock in 
> charters, so it's not a priority for me, but if people are going to refer 
> to the charter, then we should make sure they refer to something that 
> reflects reality.

Not taking into consideration part of the ietf procress (the charter)
doesn't sound like consensus.

> > > By whom?
> > 
> > This charter was discussed on this mailing list by some of the people 
> > who are part of the Working Group and that was what they agreed to.
> 
> Does it not seem odd that the people who discussed where the spec should 
> be edited did not include the person editing the spec?

Agreed.

> (I did not at any point see agreement on this list that the HyBi group 
> should take over the WHATWG work without working with the WHATWG. I've 
> read every e-mail sent to this list since it was created.)
> 
> 
> > > One could equally say:
> > > 
> > > People from the IETF are welcome to participate in the WHATWG process.
> > 
> > Yes, we could say that.  But the WHATWG process will not get the 
> > document published as a RFC.
> 
> Getting the document published as an RFC is not a goal. Getting 
> interoperable implementations is the goal.

Again this is somehow circular and it conflicts with Websocket target.
Having Websocket as a RFC is an additional warranty it has completed a
process ensuring that there was consensus and that experts have reviewed
the work.

You want consensus but at the same time it's not a goal having Websocket
published as RFC. I don't understand this.

> > To put it differently, you will still have to get the document through 
> > the IETF process.
> 
> That's fine, it's not mutually exclusive with working with the WHATWG.  
> HTML5 and many other specs are going through both the W3C and WHATWG 
> processes together, and are published simultaneously through both groups.
> 
> 
> > > However, instead, I suggest we work together, just like the W3C and 
> > > the WHATWG are cooperating on a dozen other specs.
> > 
> > I think that is an excellent suggestion.  It is unlikely that there can 
> > be a formal agreement between the different groups.  However, the 
> > individuals may be able to work something out.
> 
> I don't see the difference between a formal agreement and individuals 
> working something out. I'd be glad to work something out. The first step 
> would be to change from the attitude of "the HyBi group is working on this 
> and the WHATWG is welcome to work on something similar as well" to "the 
> HyBi group and the WHATWG are working together on this".

I agree with this but you can't say at the same time that is not a goal
to complete the RFC procress..which is the same to say "the WHATWG is
working on this and the HyBi group is welcome to work on something
similar as well".

> > > I sent feedback on Wed, 6 Jan 2010, to iesg@ietf.org. I received no 
> > > reply.
> > 
> > The IESG reads the feedback.  If I am not mistaken, the IESG generally 
> > does not send out individual replies for feedback they receive.
> 
> The feedback had no effect on the charter, either.

The IESG should had reply you but that's not the point. 

> > > Actually, I was asked to submit it by the IETF. I agreed to do so 
> > > while simultaneously publishing it through the WHATWG. At no point was 
> > > it suggested that the WHATWG should stop working on it.
> > 
> > The WHATWG can continue working on the specifications.  This Working 
> > Group will probably work on their own version of the specification too.  
> 
> No, that's not "working together".

Agreed.

> > The outcome will be two different specifications for the same 
> > technology.  I don't think that is in the interest of the Internet 
> > community.
> 
> It's not. Let's work together to create one set of normative requirements, 
> not two.

Agreed.

I think websocket is a big opportunity to move web development to the
next level but it has to solve, at least, its compatibility with
existing HTTP infrastructure as pointed by HTTP experts.

Cheers!
-- 
Francis Brosnan Blazquez <francis@aspl.es>
ASPL