Re: [hybi] Extensibility mechanisms?

[Adam Barth <[e-mail]>]

On Sun, Apr 18, 2010 at 2:06 PM, Mike Belshe <[e-mail]> wrote:
> On Sun, Apr 18, 2010 at 1:47 PM, Greg Wilkins <[e-mail]> wrote:
>>
>> Ian Hickson wrote:
>>
>> > Why would a large scale deployments with complex infrastructure that
>> > can't
>> > handle BEEP framing opt-in to an experimental non-standard feature that
>> > uses BEEP framing?
>>
>> because experiments are a precursor to real deployments.
>>
>> >
>> >> If you want to send BEEP over a HTTP connection, then you should
>> >> upgrade
>> >> to BEEP, not websocket.
>> >
>> > If the handshake involves an optional opt-in to a non-standard
>> > experimental feature, and you accept it, then you're not upgrading to
>> > Web
>> > Socket, you're upgrading to a non-standard protocol influenced by Web
>> > Sockets, as defined by the convention you and the client are using.
>>
>> My point is that an intermediary can't possible know about
>> all subprotocols (experimental or otherwise), nor be expected
>> to upgrade everytime a new subprotocol is invented.
>>
>> Intermediaries can know about websocket framing and so long as
>> all sub protocols and extensions are restricted to adhere to
>> websocket framing, then intermediaries can continue to work
>> regardless of sub protocols.
>
> Should intermediaries know about these protocols?  Why?
> In my view, new protocols should be thinking not just about "right now" but
> also about the future.  It takes a long time for protocols to be adopted, so
> thinking only of 2010 is a mistake.  Think about 2020.
> In the year 2020, should the guy sitting next to you in the coffee shop be
> able to sniff your traffic to see what you're doing?  Sure, maybe you're
> only watching a movie, but who's business is it but yours?  Should common
> users be expected to understand when their data is private and when it is
> not?  Why should they?  Is it realistic to expect them to?
>
> If we run all websockets through SSL, the protocol is stronger.  And poor
> users aren't left holding the bag wondering why they just got hacked.
> But, even if we don't care about end-user security, surely we care about
> deployability of the protocol.  Unlike any protocol layering on top of port
> 80, running with SSL is deployable today without updating the intermediaries
> at all.
> So, to review you get:
>    a) A protocol designed for the future.
>    b) A deployable protocol
>    c) A more reliable and robust protocol, because it can't be accidentally
> broken by intermediaries making incorrect assumptions about what it is
> transporting.  (We've seen this so often in history, we ought to learn the
> lesson!)

Indeed.  SSL is on the cusp of being universally deployable today.  We
should be planning for a world where SSL is ubiquitous.

Now, we can have a discussion about certificates being a hassle and
the follies of PKI.  It's probably still worth having two modes: one
where we verify the servers certificate and one where we don't.

Adam