Re: [hybi] It's time to ship

[Willy Tarreau <[e-mail]>]

On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth wrote:
> On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau <[e-mail]> wrote:
> > On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote:
> >> Gentle people of hybi,
> >>
> >> There's been a lot of good discussion in this working group gathering
> >> consensus around the data framing and the handshake.  At some point we
> >> need to declare victory and ship the protocol, otherwise proprietary
> >> solutions will continue to eat our lunch.
> >>
> >> I've written up a more formal version of Pat's proposal based on the
> >> recent straw poll and subsequent discussion.  This protocol is by no
> >> means perfect, but it's good enough:
> >>
> >> http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt
> >
> > It would help a lot other WG participants if you could present suggestions,
> > ideas and changes instead of a full proposal. It's hard to spot the proposed
> > changes.
> 
> We've had plenty of suggestions, ideas, and changes.  It's time to ship.

Yesterday, Sal said that there were a number of points to discuss yet, why
this sudden hurry ?

> > At first glance, I'm noticing a few things :
> >
> >  - you're using the OPTIONS method. The WG's consensus was voted as using
> >    GET. While technically working, OPTIONS limits some possibilities since
> >    no path is sent to the server.
> 
> Be that as it may.  OPTIONS is good enough.

But on what basis are you trying to change what was adopted as a consensus ?
I mean, I *know* that OPTIONS can evict more broken intermediaries than GET,
but the participants here have been working on the GET hypothesis with its
capabilities. Noone has had the opportunity to talk about their expectations
and the implications such a change would have for them.

> >  - your proposal involves AES-128-CTR. As was discussed here, it seems there
> >    are still export regulations for certain countries eventhough they're
> >    apparently fading out. It could still be a problem for companies who want
> >    to export products to some countries and which never had to put crypto in
> >    them.
> 
> Frankly, the export restriction issue is a bunch of BS.  AES-128-CTR
> is good enough.

Good enough for what purpose precisely ? HTTP Upgrade is good enough for
Websocket without even any form of masking. Masking was added to address
specific issues that aren't precisely quantified.

> >  - several people on the list asked for the ability to be able to disable
> >    the masking in some well-controlled environments (eg: server-to-server
> >    communications). I see no provisions for this.
> 
> The protocol is good enough without this added flexibility.  If we
> find this is really important, we can add this ability in a future
> version of the protocol.

No, it will be too late because it will never be possible to mix masked
and non-masked frames later since there will be no way to distinguish them.

> >  - it has not yet been stated whether only the payload or also the framing
> >    should be masked. Your proposal masks both, which means that it definitely
> >    blocks any possibility of performing multiplexing later. There does not
> >    appear to have been a consensus in this area yet.
> 
> The protocol is good enough without this added flexibility.  If we
> find this is really important, we can add this ability in a future
> version of the protocol.

Adam, please I can understand that you're in a hurry, but you have
copy-pasted exactly the same response as to the question above. I would
have found it more polite to respond later when you have more time.

> >  - is was suggested that some (all ?) of the nonces could go away if masking
> >    is used. Surely this is something that needs to be rechecked.
> 
> I have checked this issue.  Each nonce in the protocol serves a
> specific purpose and is valuable.

Then would you please take care of explaining them to us in this context
when you have more time ?

> >  - Greg proposed to replace the MORE bit with a FIN bit so that the first
> >    hello frame from the server starts with a high bit set, thus ensuring
> >    that we can break the connection on non-HTTP compliant intermediaries
> >    which would expect a second response after the 101.
> 
> The protocol is good enough without this change.  The masking has us
> covered here.

No, I'm talking about the ability to ensure that a non-compliant intermediary
will fail early instead of remaining stuck waiting for the server to talk.
That once one of Hixie's major concerns and one of the reasons for the Hello
frames suggestion.

Regards,
Willy