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

[Jamie Lokier <[e-mail]>]

Francis Brosnan Blazquez wrote:
> 1) It is possible to send binary content (that includes octets 0x00 and
> 0xFF) from a browser javascript?

No, the current WebSocket browser API does not support binary frames.

It has been suggested that it may in future, when:

    - Javascript acquires some additional data type for
      handling binary data (and WebSocket uses it)
or
    - the WebSocket API acquires methods for sending and receiving
      binary and interconverting it to something Javascript can use,
      like arrays of integers or octets re-represented as Unicode
      code points in a string.

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

It has been stated many times that the current WebSocket protocol is
designed to *intentionally* fail when it meets a proxy.  (Except a
WebSocket-aware proxy.)

This failure is not guaranteed, so you can't guarantee a fast fallback
to an alternative protocol, but that is a hard problem to solve.

So the answer is no, it does not use existing proxies.

> 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.

This is how it looks to me:

It's about different groups of people, so the term "consensus" is
being used to mean different things in this discussion; hence conflict
and emotion.  (There is also a mismatch of expectations, which I will
come to later.)

Prominent browser vendors *will* achieve consensus, as you can see on
this very thread, they are the ones keen to "avoid the politics" and
get straight to rolling it out.  They seem to have implemented it
already.  It's not surprising that substantive changes and delays are
unwelcome among that group - they want to use it in real products and
web services right away, and are waiting for minor issues to be agreed
and a signoff.  As far as they are concerned, the WebSocket design
phase happened quite a long time ago (perhaps years), and is now near
its end.

But (at least some) people working on other parts of the web
infrastructure have not been as as involved in WebSocket development,
and discovered it quite recently through other avenues.  It's clear
there is not a consensus which includes these people (I include myself).

Moreover, there is something of a fear from this side that new
protocol deployment over port 80 is not something to be done lightly,
because using port 80 for something other than HTTP (and which isn't
compatible with HTTP) has *many* infrastructure consequences, whether
we like it or not.  (The list of consequences is too long for this
email.  Greg gave a good list of relevant areas.)

Despite some wishes, there's a fair chance that proxies - including
"hidden" proxies (used by some ISPs and corporate and government
firewalls) - will have to learn to accomodate WebSocket, if it becomes
widely used.

Some fear that a change affecting infrastructure like that can only be
done every ten years or so (because it depends hugely on collective
adoption), and so should not be done without considerable analysis of
it's consequences for the infrastructure.

And, also, if such a change will happen, it is a *rare* opportunity to
combine the technical experience from different areas to make
something that works very well as a foundation for the future.  We
now have a *lot* of experience with web architecture, it's performance
characteristics, and what structures tend to lead to good implementations
of the whole application stack, these days.

> > 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".

Here's how I see it, from my perspective as *not* a WHATWG
participant, but a participant on the Hybi list only:

When the Hybi mailing list started, there was an invitation to discuss
development of future Hybi protocols on the list.

WebSocket appeared quickly on the list, with an invitation to
comments.  Nothing wrong with that.

However, all substantive comments on the Hybi list concerning possible
improvements to WebSocket were met with "no, I don't agree; your idea
will not be considered for WebSocket".  Wording changes and minor
tweaks were accomodated however.

It was, essentially, a frustrating waste of time to explore technical
protocol issues and ideas, and it became clear that WebSocket was
beyond that stage in its design.

I don't blame Ian; I think that WebSocket was simply already at a
later design stage - it had been gestating for quite a long time
before it arrived on the Hybi list already, and despite everything, it
does address a particular set of problems, even if some of us do not
agree on how well it does so.

=> To a large extent, I think there has been a mismatch of
expectations between what the Hybi list was set up to channel (the
expertise of interested parties from different backgrounds relating to
protocol design, network characteristics, etc. - IETF sort of stuff),
and the arrival of WebSocket which doesn't really satisfy the same goals.

And I think part of the emotion comes from the fear that we might end
up with *only* that as our available bidirectional transport through
web browsers for many years to come, and some of us foresee unwelcome
limitations or unintended consequences from that.

Mismatched expectations are often frustrating, but they aren't
necessarily anyone's fault.

And fears that we'll be stuck with one thing for years to come may not
be founded.  I think Greg has shown a promising way forward by
suggesting that we settle on WebSocket/1.0 largely as it is, and apply
collective knowledge to moving it forwards into WebSocket/1.1.

(If we go down that route, I would remind us to try hard to make it
easy to comply with than HTTP/1.1 did (or harder to screw up!).)

-- Jamie