Subject: [hybi] BEEP

From: Rob Sayre <[email-masked]>
Date: Mon, 13 Apr 2009 20:05:55 -0400

Most of the BEEP RFCs are 8 years old now, and there hasn't been a lot 
of adoption. There might be good ideas there, but something is clearly 
amiss. It might be the XML dependency, it might be something else.

- Rob

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 10:30:47 +1000

> amiss. It might be the XML dependency, it might be something else.

I think BEEP suffers from the same problem that all alternative protocols
suffer from: firewalls, gateways and browsers don't let them through.

For example, XMPP has great market share - except when it comes to
webchat - where there are now a plethora of alternative protocols
for chat - all trying to work out there own way to tunnel through
firewalls/gateways and get into the browser DOM.

Thus I think these detail protocol discussions are very interesting
and a good exercise to share requirements, view points and solutions.

But fundamentally the issue we face is not *what* protocol to use,
but how to get it through the internet and into the browser DOM.

Websocket has done a great job of considering this full journey
solution. It realizes that both a wire protocol supported by gateways
and an API supported by browsers is needed.

But I think there will only be 1 opportunity this decade to make
significant changes to the firewalls/gateways of the internet.
If that is true, then is websocket the best change to make?

We could do a lot worse and the binary websocket datagrams could
at least serve as the basis for building other protocols that
can transit firewalls/gateways.   But I think we could also do
somewhat better.

cheers

PS. I love your round wheel quote!

---

From: Rob Sayre <[email-masked]>
Date: Mon, 13 Apr 2009 20:37:06 -0400

> suffer from: firewalls, gateways and browsers don't let them through.

Maybe protocols are considered "alternative" because they suck for some 
reason. Some of these alternative protocols might even be an 
improvement, but not enough of one to justify making all of the changes 
necessary to enable them.

- Rob

---

From: Ian Hickson <[email-masked]>
Date: Tue, 14 Apr 2009 00:42:38 +0000 (UTC)

> significant changes to the firewalls/gateways of the internet.

If significant changes can be made at all, I see no reason to believe 
there would be a ten year cool-down period between changes. I think this 
is an artificial concern.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 11:01:17 +1000

> is an artificial concern.

Ian,

RFC2616 is dated June 1999 and governs the basic
behaviour of firewalls and proxies that are the impediment
to any of the protocols we are talking about.

Even if changes can be made faster than that, we should
not be proposing a change to the network infrastructure that is
not extensible to a reasonable set of anticipated requirements.

RFC2616 has lasted a decade because it is flexible and extensible
enough to adapt to changing demands.  It's not that other protocols
have not been better, it just that HTTP has been good enough to
prevent any other protocol establishing dominance.

This is a good thing and we should strive to emulate it!

cheers

---

From: Ian Hickson <[email-masked]>
Date: Tue, 14 Apr 2009 01:09:42 +0000 (UTC)

On Tue, 14 Apr 2009, Greg Wilkins wrote:
> > If significant changes can be made at all, I see no reason to believe there
> > would be a ten year cool-down period between changes. I think this is an
> > artificial concern.
> 
> RFC2616 is dated June 1999 and governs the basic behaviour of firewalls 
> and proxies that are the impediment to any of the protocols we are 
> talking about.
> 
> Even if changes can be made faster than that, we should not be proposing 
> a change to the network infrastructure that is not extensible to a 
> reasonable set of anticipated requirements.
> 
> RFC2616 has lasted a decade because it is flexible and extensible enough 
> to adapt to changing demands.  It's not that other protocols have not 
> been better, it just that HTTP has been good enough to prevent any other 
> protocol establishing dominance.
> 

There's a big difference between "I don't think we should be making 
changes more than once per decade" and "I don't think it's possible to 
make a change more than once a decade".

I think that "we should not be making changes more than once per decade" 
is a terrible reason to overengineer whatever protocol we come up with. I 
would much rather have incremental updates over a ten year period, leading 
to a massive protocol, than start with a massive protocol and hope we got 
it right without testing it as it is developed.

(I actually think the main reason that nothing has changed in the past 
decade is the same reason that nothing much has changed in HTML, CSS, the 
DOM, etc, in the past ten years. The browser vendors were out to lunch.)

---

From: Mark Baker <[email-masked]>
Date: Mon, 13 Apr 2009 21:20:37 -0400

On Mon, Apr 13, 2009 at 8:05 PM, Rob Sayre <[email-masked]> wrote:
> Most of the BEEP RFCs are 8 years old now, and there hasn't been a lot of
> adoption. There might be good ideas there, but something is clearly amiss.
> It might be the XML dependency, it might be something else.

The problem with any standardized protocol at that layer is that there
are essentially no network effects; multiple parties using a BEEP
based protocol cannot benefit from each other's deployed software in
the same way that Web publishers benefit from each new deployed
browser (and vice-versa).  Network effects of that kind come only from
agreement on an application protocol, not a framework for developing
application protocols.

Mark.

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 16:32:43 +0100

> but how to get it through the internet and into the browser DOM.

I foresee WebSocket in its current form will hit the same problem.
How to get past firewalls and transparent HTTP proxies.

So will any other proposal, including rHTTP and mine for
bidirectional/async HTTP.

"The problem of firewalls and transparent proxies in the existing
infrastructure" is an important topic to address and I think it
deserves analysis _independent_ of API and low-level protocol.

Here are a few things to consider:

    Corporate firewalls sometimes block all TCP connections,
    except for port 80 and 443.

    Some firewalls sniff HTTP URLs, HTTP headers and even the content
    (e.g. checking for viruses), and block based on those.

    Transparent HTTP proxies and proxy-caches on port 80 are common
    both in corporate settings and home internet connections.  Maybe
    not the majority of connections (I have no figures), but enough to
    matter.

    Explicit HTTP proxies which pass HTTP CONNECT requests often
    limit that to port 443.

    I would be surprised if any widely deployed HTTP proxies, explicit
    or transparent, currently work with HTTP UPGRADE.

    The Bayeaux people seem to have decided that long-GET is more
    reliable than slow-streaming-GET, because some HTTP proxies don't
    forward any of the response until they have received the whole
    response.  (Is that right?)

    Any apparently-binary protocol which is opaque to intermediate
    firewalls/proxies is likely to be blocked at many sites who are
    currently able to use protocols which tunnel over HTTP.  I suspect
    blanket blocking is more likely when there's no distinguishing
    metadata in the protocol for a firewall to match on.

> If that is true, then is websocket the best change to make?

I think there is 0 opportunity to change the whole internet quickly.

We need to at least _talk about_ whether we care about a new protocol
interoperating with the existing firewalls/gateways, and if we want to
provide an upgrade path to help those work with new protocols better.

Issues for specific protocols to consider which might be of concern:

    - Can you make it tunnel over HTTP when needed?
    - How easily?
    - What are the problems and other issues when doing that?

It's always possible to tunnel over HTTP, because you can tunnel TCP
over HTTP, even without CONNECT or UPGRADE), but for some protocols
it's a poor fit (TCP!), and some fit tunnelling relatively well.  Some
are even reasonable candidates for firewalls to filter selectively and
proxies to intercept and cache.

-- Jamie

---

From: Mario Balibrera <[email-masked]>
Date: Tue, 14 Apr 2009 10:18:25 -0700

Currently, js.io works that way with WebSocket. If there is a native browser
implementation available (none yet, obviousy), it uses that to connect
directly to the targeted WS server. Otherwise, it speaks WebSocket protocol
on top of a TCPConnection object (from Orbited, APE, or any other project
imported into the global scope that implements the API), which connects to
its own TCP proxy that in turn connects to the WebSocket server. Easy Peasy.

It would be trivial to add a graceful fallback mechanism, so that it tries
the native WebSocket (as soon as we get one...) and in case of timeout or
immediate connection closure, falls back to HTTP tunneling.

Mario Balibrera

On Tue, Apr 14, 2009 at 8:32 AM, Jamie Lokier <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 15 Apr 2009 08:37:18 +1000

> deserves analysis _independent_ of API and low-level protocol.

I've added your list of points to the wiki:
  http://trac.tools.ietf.org/bof/trac/wiki/HyBi

>     response.  (Is that right?)

That is right.
long-POST for same domain. log-GET for cross domain.

There is actually surprisingly little problem with firewalls
for the streaming solutions.   The main problem is transparent
proxies (and there are enough of these to cause problems - at least
from my personal experience) and browsers that do not execute
javascript until they have all of it OR a buffer overflow.

> proxies to intercept and cache.

So I'm adding capability negotiation and fallback to HTTP and
candidate requirements on the wiki

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 15 Apr 2009 08:58:14 +1000

Mario Balibrera wrote:
> Currently, js.io <http://js.io> works that way with WebSocket. If there 
> is a native browser implementation available (none yet, obviousy)

I find it really strange that there are no browsers that currently
implement Websocket.   It's been around for a while now and I've
frequently asked if there is a browser that supports it - even
a branch of one of the OS browsers.

So far I've drawn a blank... and because the browsers are not
implementing it, I've felt no great need to add it to my
Jetty server.

So there are some browser builders on this list - can any
of them volunteer why there has been no experimentation with
websocket?

Anybody know why the websocket designers have not tested their
proposal with an extension to firefox or similar?

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 14 Apr 2009 16:01:45 -0700

On Apr 14, 2009, at 3:58 PM, Greg Wilkins wrote:

> Mario Balibrera wrote:
>> Currently, js.io <http://js.io> works that way with WebSocket. If  
>> there is a native browser implementation available (none yet,  
>> obviousy)
>
>

We're pacing ourselves on adding new features. We can only add so much  
per release cycle, and WebSocket has been significantly redesigned  
fairly recently (from a state we would have considered unacceptable).  
However, I think most browser vendors / developers consider support  
for bidirectional communication a fairly high priority - certainly we  
are very interested in it for Safari and WebKit, and WebSocket seems  
like a good solution in this space.

Regards,
Maciej

---

From: Frank Salim <[email-masked]>
Date: Tue, 14 Apr 2009 16:49:38 -0700

There is a patch for Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=472529
-Frank