Re: [hybi] Extensibility mechanisms?

[Mike Belshe <[e-mail]>]

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!)

Mike


>
> regards
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>