Re: [hybi] [whatwg] HttpOnly cookie for WebSocket?

So, moving back to the original question... I am very concerned here. A
relatively straightforward question was asked, with rationale for the
question. "May/Should WebSocket use HttpOnly cookie while Handshaking?
I think it would be useful to use HttpOnly cookie on WebSocket so that we
could authenticate the WebSocket connection by the auth token cookie which
might be HttpOnly for security reason."

It seems reasonable to assume that Web Sockets will be used in an
environment where users are authenticated, and that in many cases the Web
Socket will be established once the user has logged into a page via
HTTP/HTTPS. It seems furthermore reasonable to assume that a server may
track the logged-in-ness of the client using a HttpOnly cookie, and that the
server-side logic to check whether a user is already logged in could easily
be leveraged for Web Sockets, since it starts as an HTTP connection that
includes cookies and is then upgraded. It seems like a very straightforward
thing to say "Yes, it makes sense to send the HttpOnly cookie for Web Socket
connections".

Instead, we are bogged down in politics.

How are we to move forward on this spec? We have multiple server
implementations, there are multiple client implementations, if a simple
question like this gets bogged down in discussions of WHATWG vs IETF we are
never going to get anywhere. Clearly there are people on both groups who
have experience in the area and valuable contributions to add, so how do we
move forward? Simply telling the folks on WHATWG that they've handed the
spec off to IETF is **NOT** in line with what I recall at the IETF, where I
recall agreeing to the two WGs working in concert with each other. What we
have before us is a very trivial question (IMO) that should receive a quick
response. Can we use this as a proof of concept that the two groups can work
together? If so, what are the concrete steps?

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)

-Ian

2010/1/28 Ian Hickson <ian@hixie.ch>

> On Thu, 28 Jan 2010, Julian Reschke wrote:
> > Ian Hickson wrote:
> > > ...
> > > > The WHATWG submitted the document to the IETF
> > >
> > > I don't think that's an accurate portrayal of anything that has
> occurred,
> > > unless you mean the way my commit script uploads any changes to the
> draft to
> > > the tools.ietf.org scripts. That same script also submits the varous
> > > documents generated from that same source document to the W3C and
> WHATWG
> > > source version control repositories.
> > > ...
> >
> > By submitting an Internet Draft according to BCP 78 you grant the IETF
> certain
> > rights; it's not relevant whether it was a script or yourself using a
> browser
> > or a MUA who posted it.
> >
> > You may want to check <http://tools.ietf.org/html/bcp78#section-5.3>.
>
> With the exception of the trademark rights, which I don't have and
> therefore cannot grant, the rights listed there are a subset of the rights
> the IETF was already granted by virtue of the WHATWG publishing the spec
> under a very liberal license. So that doesn't appear to be relevant.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>