Re: [hybi] It's time to ship

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau <[e-mail]> wrote:

> Hello Adam,
>
> 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.
>
> 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.
>
>
I agree it is important to be able to identify between various resources on
a server. E.g. for our use, we will have multiple different websocket
endpoints, and we want our frontend to be able to dispatch to the
appropriate backend based on the information in the handshake. That said, I
think the draft allows for that (Sec-WebSocket-URL), or as pointed out on
another thread, it appears OPTIONS does allow for a path component. So, I
think we should be able to resolve that point.


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

It would be nice to understand if this is actually a hard constraint.
AES-128-CTR has the benefit of being well understood, as well as fast, as
demonstrated by Maciej in another thread. That said, I don't care strongly
one way or another here.


>
>  - 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.
>
>
There's nothing that would prevent you from writing an extension that would
disable the masking, from my understanding.


>  - 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.
>
>
I'm not sure why this would block the possibility of multiplexing. I would
agree that would be a problem if it were the case. However, a number of the
early proposals for multiplexing included something like a stream-id in the
frame. This could still be present. Though it would be masked, so would the
length and other things that a meaningful intermediary would care about, so
assuming the intermediary was capable of un-masking, is this an issue?


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

 - 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 draft Adam sent out is based on an intermediate version I had checked
into SVN, back when it looked like we were gaining speed on CONNECT. I
didn't yet get around to flipping MORE/FIN, but I don't have any ojbections
to this.


> Those are just a few notes, it's really not easy to changes :-/
>

There's a tool on the IETF to diff drafts. I find it quite helpful, that
said, a lot of text has changed because I had already started to make other
requested changes (including trying to resolve the HTTP compliance issue, by
stating the requirements of the handshake rather than stating send X bytes,
send Y bytes, ...). This makes the diff a bit harder to interpret, for sure.

That said, I do hope that this can spur some more targeted conversations and
drive progress.


>
> Thanks for this work,
> Willy
>
>
>
> >
> > As a working group, it's time to ship.
> >
> > Kind regards,
> > Adam
> > _______________________________________________
> > hybi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hybi
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>