Re: [hybi] Fwd: The MessageBroker WebSocket Subprotocol

I agree that this should be a protocol rather than an extension and
that new opcodes are not required.

Subprotocols should be defined in terms of their message payload only.
To give an analogy, WebSocket subprotocols should not require opcodes
just as protocols on top of TCP should not new require control bits.

Other notes so far:

3.4 "WebSocket uses the HTTP origin model to identify clients. MBWS
uses the same client identity model."

Origin cannot be used to identify clients.

4.2/5 "Client or Broker may initiate/respond to Ping/Pong during
session as defined by WebSocket."

Subprotocols shouldn't be aware of ping/pong, since they aren't
exposed in the API.

-Frank Salim

On Sun, Oct 2, 2011 at 5:45 PM, Greg Wilkins <gregw@intalio.com> wrote:
> On 3 October 2011 05:21, Bruce Atherton <bruce@callenish.com> wrote:
>> As I pointed out in my example with HTTP (which required Request and
>> Response message types), it is going to be very common for subprotocols to
>> want to define new opcodes. They are the right fit for defining message
>> types in a subprotocol.
>
> Bruce,
>
> I do not think  opcodes are the right fit for defining messages in a
> subprotocol (at least not in the ws protocol as we have designed it).
>
> While I can imagine some subprotocols would desire to have opcode like
> metadata associated with a message, I  can also imagine many
> subprotocols will use JSON/XML as their message exchange format and
> thus will better use fields/elements/attributes to convey message
> type.
>
> The way we have defined the protocol, opcodes are a constrained and
> regulated resource that must be allocated by IANA. They may be used by
> extensions, which themselves have a high barrier to deployment as they
> need to be implemented in the browsers and servers, since the
> application API is insufficient (and inappropriate) for implementing
> extensions.
>
> Subprotocols are exposed to the application in the browser API, so I
> believe that sub protocol designs need to be restricted to what can be
> achieved without API changes or IANA allocations.   I think this is a
> good thing and keeps the barrier low for sub protocol development.
>
> regards
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>