Re: [hybi] Fwd: The MessageBroker WebSocket Subprotocol

[John Tamplin <[e-mail]>]

On Sun, Oct 2, 2011 at 4:40 AM, Salvatore Loreto <
[e-mail]> wrote:

> -------- Original Message --------  Subject: The MessageBroker WebSocket
> Subprotocol  Date: Sun, 2 Oct 2011 00:33:52 +0200  From: Hapner mark
> <[e-mail]> <[e-mail]>  To: [e-mail]
> <[e-mail]> <[e-mail]>  CC: [e-mail]
> <[e-mail]> <[e-mail]>, Salvatore Loreto
> <[e-mail]> <[e-mail]>
>
>  Hi,
>
> Let me introduce myself since I have not posted to the list before.I've
> been involved with message brokers for some time. I was the engineer behind
> the creation of the Java Message Service API. I current work for Huawei's US
> Software Lab in Santa Clara, CA.
>
>  Clebert is the JBoss HornetQ lead.
>
>  Clebert and I are excited about the potential to bring the functionality
> of message brokers to the internet and we see WebSocket as the best message
> transport to enable this. We believe the WebSocket subprotocol described in
> the attached document provides the minimal extension to WebSocket needed for
> this purpose. We hope this subprotocol reflects well on the expectations the
> WG has for the use of WebSocket extensibility.
>
>  We are submitting this document informally to the WG for its comment. It
> is our hope that it will mature into a subprotocol that can be submitted for
> either inclusion into the WebSocket specification; or, as a separate RFC. We
> would like to get the WG's thoughts on how best to proceed in this
> direction.
>
>  http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-00.txt
>

It isn't entirely clear to me whether this is defining a subprotocol or a
WebSocket extension.  3.3 clearly makes it seem to be a subprotocol, but
then 2.1.2 defines two opcodes, which is something that can only be done by
an extension.  Also, if it is an extension, there should probably be more
care to reduce the number of opcodes used, as they are in very limited
supply.  Finally, since new opcodes can only be allocated by IANA, it is
hard to experiment with before it is standardized - an alternative would be
to define binary frames exchanged over the subprotocol as having a 1-byte
extended opcode in the first byte, which would not require a WebSocket
extension or allocation of scarce opcodes.  After gaining some experience
with the protocol, then we will have better information about whether
allocating scarce opcodes to this use is warranted.

-- 
John A. Tamplin
Software Engineer (GWT), Google