Re: [hybi] WS framing alternative

["Roy T. Fielding" <fielding at gbiv.com>]

On Nov 1, 2009, at 5:19 PM, Greg Wilkins wrote:
> The problem with what you say are the "we could add", "future version"
> and "if we decide" parts.
>
> Netscape didn't have to wait for any "we" to formulate HTTP/1.1 so  
> that
> persistent connections could be supported.   They came up with HTTP/ 
> 1.0
> keep-alive as a defacto standard that worked because HTTP supports
> arbitrary meta-data that can be ignored.

FTR, Netscape had very little to do with formulating keep-alive.

There were three research projects that showed potential value
in persistent connections.  There was also some list discussion
on how best to do that, culminating in at least three different
proposals that I presented at the IETF's HTTP BOF in December 1994.
None of those proposals were accepted.  The keep-alive header
came out of a compromise that Henrik and I came up with after the
BOF session, in response to the BOF comments, which I later
wrote-up as a set of notes and distributed to a few of the
primary HTTP implementors at the time, including the folks at
Netscape who had been more interested in a batch method (MGET)
but were eventually convinced to implement keep-alive along
the same lines as Apache httpd and W3C libwww.  After we had
demonstrated interoperability, the mechanism was added to a
late draft of HTTP/1.0 and eventually replaced by HTTP/1.1's
persistent connections (triggered by the version change).

...

Although I agree with most of Greg's design points (most of which
were included in the design of waka back in 2001), I still
see no reason for the IETF to standardize anything in the realm
of a hybi protocol at this time.  Simply put, there is not enough
agreement yet on what the goals should be, let alone the standard
way everyone should implement them.

I look at Websockets and what I see is a very limited mechanism to
tunnel arbitrary protocols through an HTTP-established connection,
in spite of the fact that arbitrary protocols are neither secure
nor architecturally scalable on the open Internet.  This is just
a slight twist on the old schemes of using CORBA or Java RMI that
Netscape tried to introduce and ultimately failed, and the DCOM
over HTTP crap that Microsoft tried to introduce and ultimately
failed.  Those schemes failed because they were architecturally
and socially incompatible with organizational trust boundaries
and the anarchic scalability required on the Web, not because the
protocols lacked some secret sauce.

I see no point in trying to convince Ian that he is on the
wrong track.  As long as Websockets isn't wedged into a more
established spec (like HTML), then it can succeed or fail on
its own terms.  The only risk to me is that Apache may have to
introduce code specifically blocking such requests being passed
through the server's extensibility interfaces (API, CGI, etc.),
because there is no effective difference between Ian's requirements
and an extended denial-of-service attack.

Likewise, I look at BWTP and I see it trying to adopt all of HTTP's
weaknesses regarding syntax and none of its strengths regarding
separation of concerns and simplicity.  I don't know if that is
fatal to the idea or not, since AFAICT the only use cases for hybi
that are not unacceptable, either socially or in terms of scale,
are already adequately covered by SMTP.

My advice is: stop trying to convince each other that your ideals,
use cases, and design theories are even remotely similar.  They
are not even comparable.  They do not belong in the same WG.
Neither one is suitable for standardization at this time.
They should demonstrate their viability first without being
designed in committee, just like all of the other successful
IETF protocols.

I think it is a mistake for hybi to continue as if there were
something to standardize here.  Waka could do all of this stuff
(in addition to replacing normal HTTP communication), but
I wouldn't dream of bringing waka to an IETF working group
without a half dozen working implementations and a very firm
grasp of why it should be standardized.  It is just such a
ridiculous waste of time to try to get consensus amongst
people who aren't implementing the same type of system,
let alone the same exact protocol.

A protocol is ready to be standardized when there is
no longer any need to explain what it is used for and why
people should want to implement it.  Standardization is only
needed when independent implementations already exist but
differ in their observed behavior.

....Roy