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

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Aug 2009 10:03:33 +0200

(FYI)

-------- Original Message --------
Date: Tue, 25 Aug 2009 20:54:03 +0100
From: Graham Klyne <[email-masked]>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Apps Discuss <[email-masked]>
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
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 31 Aug 2009 15:12:39 +1000

> specification, and rather more like a programming team internal design

Julian,

I too have been very critical of the websocket protocol.
But I think that the IETF and specifically the hybi group should not
get become "captured" by trying to correct short comings of this
protocol and it's specification.   It is very difficult to critique
the protocol and/or proposal as the authors find it very suitable for
their specific purposes.

Instead, I believe that the websocket protocol should be viewed as just
one  use-case for a bidirectional protocol coming from the whatwg efforts
on HTML5.  I think it should consider it more of a requirements document
than a real proposal for an open protocol specification.

If the IETF were to move forward on a real open protocol specification that
met the use-case of the websocket proposal (among others), then surely
all parties would be content with the result.

> BEEP?  I fear there's a certain amount of reinvention going on here.  But I

I previously advocated BEEP as a possible protocol for the bidirection web.
See the thread "Is there a traffic jam?" in the hybi list, which briefly
discussed BEEP before going off topic.

The argument that eventually convinced me that BEEP was not entirely
suitable, was that while BEEP framing is simple and suitable, the channel
management of BEEP is rather complex and requires XML.

So I draw your attention again to the BWTP draft proposals.  The first
of these http://bwtp.wikidot.com/main:proposal, was very much influenced
by HTTP - but the feedback received was that it too was a bit too complex
for the features that it provided.

The second BWTP proposal: http://bwtp.wikidot.com/main:proposal1 is modeled
more off BEEP than HTTP.   I believe it provides a rich bidirectional
feature set, which maintaining the simplicity of BEEP style framing.

But even if you find BWTP inappropriate, I believe that the IETF
should be working from known successful protocols and protocol
experience to design, test and specify an new bidirectional protocol.

Surely the IETF should build from it's existing knowledge base
rather than adopt a binary protocol proposal for a very
specific purpose that is a radical departure from the style
and substance of past IETF protocols!

cheers