[hybi] [Fwd: Comments on draft-hixie-thewebsocketprotocol-35]

[Julian Reschke <julian.reschke at gmx.de>]

(FYI)

-------- Original Message --------
Date: Tue, 25 Aug 2009 20:54:03 +0100
From: Graham Klyne <ietf-discuss-apps at ninebynine.org>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Apps Discuss <discuss at apps.ietf.org>
Subject: Comments on draft-hixie-thewebsocketprotocol-35

[I've tried sending this twice to the HYBI list, but for some reason 
it's not
getting through (this doesn't augur well for traditional IETF values of
openness).  So I'm sending it here in the expectation that someone will 
be able
to relay it to the proper forum.  #g.]


Dear all,

re: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-35

[Summary:  in its present form, a thumbs down.]

I was prompted to review this spec by this comment posted to the W3C
technical architecture group (TAG) mailing list:

[[
What's the point of this new protocol? To bum a small constant in
network performance? Seems shortsighted given the enormous amount of
effort it takes to tool up for and specify a new protocol. Not to
mention one that looks to essentially end a platform on which to build
a further babel of ad hoc protocols. And considering Moores law.

Definitely worth a review, if you ask me. URN versus URI seems the
least issue here.
]]

I thought this comment missed what I thought was the point, and that 
maybe it
needed to be corrected.  But on reading the spec in its current form, I 
can see
why someone would say this.

...

So, what's the problem, in two parts:
(a) what problem is being solved?
(b) what is the problem with the spec?

My understanding of the problem to be solved, based on what I understand 
about
the goals of HYBI, is that in its present form the Web has no common way to
"push" information to a browser application.  There are a number of
solutions/workarounds based on HTTP long-polling or variants, but these have
variousbproblems with proxies, etc., and there is as yet no single accepted
solution.  My expectation is that the websockets protocol proposes to be 
such a
solution.

I think the specification, in its current form, completely fails to present
itself as such a solution.  To me, it reads less like an open protocol
specification, and rather more like a programming team internal design memo.
From reading it, I can't tell if it addresses the problem I expected it 
to address.

It seems to me that you need to understand websockets in some detail in 
order to
understand this spec with a reasonable amount of effort - I want to be 
able to
pick out the "high points" on a single read though, but instead I find 
myself
plunged into a level of detail that I can't relate to.

For example, take the very first sentence of the Introduction (sic): 
"The Web
Socket protocol is designed on the principle that there should be minimal
framing (the only framing that exists is to make the protocol frame-based
instead of stream-based, and to support a distinction between Unicode 
text and
binary frames)" - this very first sentence introduces a number of 
lower-level
techncial issues (framing, frame-based, stream-based, unicode text, binary
frames) without providing any context.

Even the abstract isn't very helpful here (the second sentence, starting 
with
"It is intended to fail ..." doesn't exactly engender confidence).

None of this means that I think this is a bad protocol:  the truth is, I 
can't
tell if it is or not.  So, yes, my comments could be construed as being 
about
style rather than substance, but if we're in the business of forging 
consensus I
think some consideration needs to be given to the readers of a 
specification in
order to get meaningful review.  I'll try and make a few suggestions, 
which I
don't claim are best or complete:

1. Provide some context and motivation.  Start the introduction by 
stating the
problem that is being solved, and why it is not solved by existing standard
protocols.  Also, alomng the way, it might be worth mentioning efforts like
cometd/bayeux and BOSH and saying how this proposal is similar and/or 
different.

2. Indicate some specific types of applications for which the problem 
exists (my
favourites include: real-time web page updates, synchronization of displays
between multiple web pages, on-the-fly persisting of user interactions, 
...).

3. [nit] Abstract: talk about "graceful fallback" instead of "intended 
to fail"

4. Introduce key concepts before delving into details about them:  I 
don't mean
in textboook fashion, but indicating how they relate to the problem at hand
(e.g. why is framing an issue, how does it relate to Unicode bvs binary 
data?).

5. Move most of the current "introduction" text into a high-level protocol
description section.

6. Provide a protocol state diagram or similar overview.

7. Section 3:  why is this based on [WEBADDRESSES] rather than [RFC3986]?  I
can't offhand tell if [WEBADDRESSES] is acceptable as a normative reference.

I have not read sections 4 and 5 in detail, as they seem to be concerned
entirely with very low-level and rather wordy protocol processing 
descriptions,
but I find myself asking:  why not just specify a hand-off extension to HTTP
that allows bidirectional communication to proceed using a protocol such as
BEEP?  I fear there's a certain amount of reinvention going on here.  But I
could be wrong.

I wish I could be more constructive, but in its present form I can't see
anything that helps me in this current specification.  Maybe this can be
improved, as I think the goals of HYBI are important.

#g






_______________________________________________
Apps-Discuss mailing list
Apps-Discuss at ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss