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

[Ian Hickson <[e-mail]>]

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.   `._.-(,_..'--(,_..'`-.;.'