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

From: Graham Klyne <[email-masked]>
Date: Wed, 02 Sep 2009 09:39:29 +0100

Greg,

[Julian kindly forwarded my comments to this list, as I have been having trouble 
getting messages through (maybe it will work this time)).]

Your comments about viewing this specification as a requirements document is 
fair enough, except that I have no idea from reading the document what 
requirements it is trying to address.  But I do agree it would be helpful to 
have an articulated set of requirements and problems to be avoided to assist 
evaluations.

Although I mentioned BEEP as an example, I can also see why it would be a hard 
candidate to sell.  It seems to me that easy browser-side implementation using 
Javascript would be a requirement, and my intuition is that BEEP requires quite 
a lot of state management that might make a solid browser implementation hard to 
achieve.

BTW, while candidates are being tossed around, I have done some implementation 
work in this area that is entirely open source.  I know it has many 
shortcomings.  The project is at http://code.google.com/p/webbrick-events/.  The 
main use-case for this was using a browser as a real-time control and monitoring 
interface for home automation, etc., which I think is rather like a presence 
protocol. I have aimed for the simplest content model that would support the 
protocol requirements, which is described at 
http://code.google.com/p/webbrick-events/wiki/EventModel.  Mainly, I think that 
if a requirements document were being assembled, I might be able to fillet out 
some thoughts to contribute.

FWIW, my favourite candidate to date is BOSH, mainly as it focuses on protocol 
requirements without imposing much content model, *and* that it works over 
unmodified HTTP.  But I haven't properly reviewed the alternatives.

I took a quick look at your BWTP and my immediate off-the-cuff thoughts are:
  * the spec seems quite easy to read and follow :)
  * it doesn't really indicate the requirements or use-cases it aims to satisfy 
(but it does say that it's intended to provide bi-directional transfers, so 
maybe that's enough, though I'd like to see asynchronous delivery to the client 
explained).
  * I'm not sure that there's an easy migration path from unenhanced HTTP for 
applications that need bidirectional data capabilities.  For example, I'd need 
to think a lot harder than I have time for right now to decide if this could be 
implemented using Javascript in a browser.

Cheers,

#g
--

Greg Wilkins wrote:
> Julian Reschke wrote:
> 
>> 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.
> 
> 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.
> 
> 
> 
>> 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 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Ian Hickson <[email-masked]>
Date: Thu, 3 Sep 2009 11:16:00 +0000 (UTC)

On Sun, 25 Aug 2009, Graham Klyne wrote:
>
> 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.

Done.

> Also, along the way, it might be worth mentioning efforts like 
> cometd/bayeux and BOSH and saying how this proposal is similar and/or 
> different.

I'm not really sure what I would say here.

> 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, ...).

Done.

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

No, it's really intended to fail in those cases, not fall back to 
anything.

> 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?).

I've reordered the introduction sections a bit to help with this.

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

Is the new introduction section ok?

> 6. Provide a protocol state diagram or similar overview.

I'm not sure I understand what that would look like for this protocol.

Do you mean something like this?:

   HANDSHAKE --> FRAME TYPE <-------------------------.
                      |                               |
                      +---0x00---> DATA --> 0x00 --->-+
                      |                               |
                      `---0x80---> LENGTH -> DATA -->-'

> 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.

RFC3986 doesn't define how to handle errors when parsing URIs.

> 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.

BEEP is about six orders of magnitude too complicated for what we're doing 
here.

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

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 07 Sep 2009 11:21:57 +0300

Hi Graham,

as a first tentative to put some order in the discussion about how to 
"PUSH" information to a client and/or browser application,
we have write down a draft that focuses on best practices for 
bidirectional HTTP in the context of HTTP as it exists today.
The document envisions also possible additions to HTTP that could enable 
improved mechanisms for bidirectional HTTP
(for what we call, the short term solution to the bidirectional 
communication, where the long term is supposed to be something
like WebSocket or BWTP)

here the link: http://www.ietf.org/id/draft-loreto-http-bidirectional-00.txt

it would great if you have time to review it and provide 
comments/suggestions.

Moreover as we are now working on a new version where we are trying to 
more clearly describe the design space, including
the programming environments (client, server, library, etc.), deployed 
infrastructure (routers, proxies, etc.).
Any help coming from your implementation experience is welcome.

cheers
Sal

www.sloreto.com

Graham Klyne wrote:
> Greg,
>
> [Julian kindly forwarded my comments to this list, as I have been 
> having trouble getting messages through (maybe it will work this time)).]
>
> Your comments about viewing this specification as a requirements 
> document is fair enough, except that I have no idea from reading the 
> document what requirements it is trying to address.  But I do agree it 
> would be helpful to have an articulated set of requirements and 
> problems to be avoided to assist evaluations.
>
> Although I mentioned BEEP as an example, I can also see why it would 
> be a hard candidate to sell.  It seems to me that easy browser-side 
> implementation using Javascript would be a requirement, and my 
> intuition is that BEEP requires quite a lot of state management that 
> might make a solid browser implementation hard to achieve.
>
> BTW, while candidates are being tossed around, I have done some 
> implementation work in this area that is entirely open source.  I know 
> it has many shortcomings.  The project is at 
> http://code.google.com/p/webbrick-events/.  The main use-case for this 
> was using a browser as a real-time control and monitoring interface 
> for home automation, etc., which I think is rather like a presence 
> protocol. I have aimed for the simplest content model that would 
> support the protocol requirements, which is described at 
> http://code.google.com/p/webbrick-events/wiki/EventModel.  Mainly, I 
> think that if a requirements document were being assembled, I might be 
> able to fillet out some thoughts to contribute.
>
> FWIW, my favourite candidate to date is BOSH, mainly as it focuses on 
> protocol requirements without imposing much content model, *and* that 
> it works over unmodified HTTP.  But I haven't properly reviewed the 
> alternatives.
>
>  * it doesn't really indicate the requirements or use-cases it aims to 
> satisfy (but it does say that it's intended to provide bi-directional 
> transfers, so maybe that's enough, though I'd like to see asynchronous 
> delivery to the client explained).
>  * I'm not sure that there's an easy migration path from unenhanced 
> HTTP for applications that need bidirectional data capabilities.  For 
> example, I'd need to think a lot harder than I have time for right now 
> to decide if this could be implemented using Javascript in a browser.
>
> Cheers,
>
> #g
> -- 
>
> Greg Wilkins wrote:
>> Julian Reschke wrote:
>>