Subject: [hybi] Subprotocol and Control Frames

From: Hapner mark <[email-masked]>
Date: Tue, 04 Oct 2011 20:23:08 +0000

In my reading of draft 17, I do not find a definition of subprotocol that puts any restrictions on the WebSocket extensibility features a subprotocol may use. If the sense of the WG is that subprotocols are restricted to use only extension data and message format/schema restrictions, this is not apparent in the content of this draft.

It is my observation that there will be a number of WebSocket usecases that could benefit from the ability to define usecase-specific control frames to mediate message flow. Telling developers to stuff this mediation protocol into extension data rather than in control frames does not appear to increase security; rather, it likely decreases security because it intermixes control with data which is a fundamentally bad thing for a protocol design to do.

The two control frames defined by MBWS are fairly simple and are likely representative of what other subprotocols would need. It would be far better to allow MBWS to properly factor its control and data than force it to put control in its data.

It is true that TCP does not support application control extension; however, HTTP clearly does support this with a very open-ended extension of the HTTP header. The WG needs to think carefully about this. I hope there is room to resolve this issue in this version of WebSocket.

It is up to the W3C WebSocket API to insure it provides the functionality that both native users of WebSocket and implementors of WebSocket subprotocols require. In looking over what is currently defined, this API does not yet provide an API sufficient for the later. Possibly later it will. I don't believe that the design of WebSocket needs to be restricted by the current limitations of this API.

---

From: John Tamplin <[email-masked]>
Date: Tue, 4 Oct 2011 16:33:33 -0400

On Tue, Oct 4, 2011 at 4:23 PM, Hapner mark <[email-masked]> wrote:
>
>  In my reading of draft 17, I do not find a definition of subprotocol that
> puts any restrictions on the WebSocket extensibility features a subprotocol
> may use. If the sense of the WG is that subprotocols are restricted to use
> only extension data and message format/schema restrictions, this is not
> apparent in the content of this draft.
>

So where do you see that a subprotocol may define new opcodes or change the
framing?  There are an infinite number of things the spec doesn't say can't
be done.

>  It is my observation that there will be a number of WebSocket usecases
> that could benefit from the ability to define usecase-specific control
> frames to mediate message flow. Telling developers to stuff this mediation
> protocol into extension data rather than in control frames does not appear
> to increase security; rather, it likely decreases security because it
> intermixes control with data which is a fundamentally bad thing for a
> protocol design to do.
>

WS control frames are there for WS implementations, not for higher-level
protocols.  Similarly, you can't directly control ICMP frames from your UDP
connection.  If you want your own control frames, you layer them on top of
the lower level protocols.

>  The two control frames defined by MBWS are fairly simple and are likely
> representative of what other subprotocols would need. It would be far better
> to allow MBWS to properly factor its control and data than force it to put
> control in its data.
>

There are very few available opcodes.  If every subprotocol allocates a
couple that it needs, there won't be many subprotocols.

>  It is true that TCP does not support application control extension;
> however, HTTP clearly does support this with a very open-ended extension of
> the HTTP header. The WG needs to think carefully about this. I hope there is
> room to resolve this issue in this version of WebSocket.
>

HTTP doesn't send a separate control frame, it is sent as a prefix to the
higher-level payload, exactly as we are suggesting you do.

>  It is up to the W3C WebSocket API to insure it provides the functionality
> that both native users of WebSocket and implementors of WebSocket
> subprotocols require. In looking over what is currently defined, this API
> does not yet provide an API sufficient for the later. Possibly later it
> will. I don't believe that the design of WebSocket needs to be restricted by
> the current limitations of this API.
>

There are many examples where the protocol is not restricted by the API --
for example, the JS API did not even support binary frames when they were
present in the wire protocol.

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

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 5 Oct 2011 09:19:36 +1100

On 5 October 2011 07:23, Hapner mark <[email-masked]> wrote:
> may use.

Mark,

in section 5.8 Extensibility:

   This specification provides opcodes 0x3 through 0x7 and
   0xB through 0xF, the extension data field, and the frame-rsv1, frame-
   rsv2, and frame-rsv3 bits of the frame header for use by extensions.

So while there is no explicit restriction on subprotocols using
opcodes, the only allowance given is to extensions.

> If the sense of the WG is that subprotocols are restricted to use

The specification also describes subprotocols in section 1.3 as

   ... used to indicate what subprotocols (application-level protocols
   layered over the WebSocket protocol) are acceptable to the client.

> It is my observation that there will be a number of WebSocket usecases that
> could benefit from the ability to define usecase-specific control frames to
> mediate message flow. Telling developers to stuff this mediation protocol
> into extension data rather than in control frames does not appear to
> increase security;

Firstly subprotocols can no more use extensions data than they can use
extension opcodes.
They can however use the payload and are free to define arbitrary
message semantics within that payload that may include application
control messages.

The restriction of subprotocols to not use opcodes is not done for
security.  It is done for protocol layering reasons.
The opcode is there to inform the WS implementation (and it's
extensions) how to handle the message.  There is no application
semantics associated with any of the opcodes.  For example the text vs
binary opcodes instructs the implementation if UTF-8 decoding is
required and to which part of the websocket API a message should be
delivered.  There is no semantic restriction imposed by a binary
message, which may actually be a text message, but one for which the
application or subprotocol has taken responsibility for character
encoding.

> rather, it likely decreases security because it
> protocol design to do. The two control frames defined by MBWS are fairly simple and are likely

Indeed there is a limitation in the current protocol of providing only
a single stream per connection, so there can be no separation of
control/data on a single connection.   However the solution is not to
allow applications to put their control messages into the protocols
control stream, but rather to better support multiple streams - ie
MUX.  For the protocol, it is clear that there are two streams of
frames: data and control,  but there is no reason why this taxonomy
will apply generally to all applications and subprotocols.  There may
be use cases where applications/subprotocols need n streams or control
frames larger than 125 bytes.

The solution is to not see that the protocols control frame mechanism
is somewhat like the applications need for control messages and thus
to attempt to expose the protocols control channel to the application.
 The solution is to allow applications to efficiently create their own
control channels - MUX!

> It is true that TCP does not support application control extension; however,
> HTTP clearly does support this with a very open-ended extension of the HTTP
> header. The WG needs to think carefully about this. I hope there is room to
> resolve this issue in this version of WebSocket.

This distinction between extensions and subprotocols has not been made
because of any API limitations.  It has been done for good protocol
layering reasons.

Consider if we open up the control channel to applications, then this
will make the task of creating things like MUX extensions much more
difficult. The mux solution would have to allow for extending control
frames with extension data so that they may be correctly routed to the
right application control channel.  But if a 125 byte application
control frame is sent, then there may not be sufficient room to add
the channel identifier!    Also if control frames are used to
implement MUX flow control, will applications use their application
control frames to attempt to get around this flow control?  We may end
up needing to put flow control on the control channel to limit the
number of application control frames.

Mixing application control frames with protocol control frames is a
far worse "solution" than mixing application control messages with
application data messages.

regards

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 05 Oct 2011 10:14:31 +0900

Hello Mark, others,

I think you are working on some great stuff, but I very much agree with 
John and Greg and the many others who have clearly explained that 
options are for extensions and not for subprotocols (and Greg even found 
the text in the spec that says so).

It would be really great if you gave WebSockets a chance to be deployed 
and used as designed in the WG. This means that when you design a 
subprotocol, you just pretend that there are no more free option bits 
available (just the same as in TCP).

If you really, really can't get things to work that way (which I highly 
doubt), please ask this WG for further advice. We can always change 
things in a future version of WebSockets if we see a really strong need 
to do so. But for the moment, we would really strongly prefer to get 
experience with WebSockets as designed and as described in the spec.

Many thanks in advance!

Regards,    Martin.

On 2011/10/05 7:19, Greg Wilkins wrote:
> On 5 October 2011 07:23, Hapner mark<[email-masked]>  wrote:
>>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Hapner mark <[email-masked]>
Date: Wed, 05 Oct 2011 01:36:26 +0000

Thanks for everyone's comments. Clebert and I are learning as we go ...

Greg,

Thanks for the clarifications ...

I agree that MBWS could define its own framing protocol within the WebSocket message payload, i.e. MBWS could be defined as a WebSocket subprotocol. (Sorry for my original confabulation of subprotocol and extension)

The option also exists to implement MBWS as it is currently defined as a WebSocket extension that adds extension data and extension control frame opcodes. 

WebSocket provides support for both subprotocols and extensions and I believe both are available for use by outside parties as long as the IANA registration mechanisms are followed. Is this correct?

My primary concern is that implementing MBWS as a subprotocol will add complexity and overhead. The only rationale I can see for defining MBWS as a subprotocol would be if, for some reason, browsers/proxies/firewalls blocked WebSocket extensions, i.e. MBWS has to use a 'subprotocol tunnel' through them.

The core point in favor of using an extension is that WebSocket already defines an excellent framing protocol. There is simply no need for MBWS to layer yet another framing protocol over it. It would be equivalent to a REST service defining a request-response framing protocol within the HTTP request-response body when all it needed was to add a few new header fields. Let me see, I think I remember this being done, it was called WS* :>)

The point about control frame opcodes being 'scarce' is an issue; however, the spec already suggests the use of an extension bit to resolve this. 

The spec does not describe how the opcode space will be distributed across extensions. It does not say whether or not an extension opcode value can be 'redefined' by different extensions. Since a session can only be operating under one extension, there does not appear to be a technical reason why extensions could not redefine extension opcodes. If this is possible, then MBWS does not 'use up' any extension opcodes.

Perhaps the fact that WebSocket itself does not reserve any of the opcode extension space for itself is an issue. There seems to be an implication in the comments so far that, in effect, they are all reserved and none are available for 'outside' use. I don't believe this is the case.

I think subprotocols and extensions are both useful. For an application specific case, say the transport of Insurance Policies and Quotes, defining a subprotocol for transport of this Insurance Message Schema would be sensible. I believe that MBWS is case where the use of an extension is sensible.

Again, I think this issue is worthy of some serious debate. I'm not ready to concede, as yet, that defining MBWS as a WebSocket extension is wrong.

-- Mark

---

From: John Tamplin <[email-masked]>
Date: Tue, 4 Oct 2011 21:54:10 -0400

On Tue, Oct 4, 2011 at 9:36 PM, Hapner mark <[email-masked]> wrote:

> WebSocket provides support for both subprotocols and extensions and I
> believe both are available for use by outside parties as long as the IANA
> registration mechanisms are followed. Is this correct?
>

Yes, but there are very very few available, and they were intended for WS
infrastructure needs.  If the first WS subprotocol allocates two of them, do
we tell people in a couple of months "sorry, we are all out", and not have
any left for the purpose for which they are intended?  This is
notwithstanding the fact that current APIs make no provision for using other
opcodes, and as we have explained, we don't think they should.

> The core point in favor of using an extension is that WebSocket already
> defines an excellent framing protocol. There is simply no need for MBWS to
> layer yet another framing protocol over it. It would be equivalent to a REST
> service defining a request-response framing protocol within the HTTP
> request-response body when all it needed was to add a few new header fields.
> Let me see, I think I remember this being done, it was called WS* :>)
>

In most cases, such services *do* define a framing layer on top of HTTP --
for example, JSON, which defines how the payload carried by HTTP should be
interpreted.  They even have things like an opcode or message type inside
them.

> The point about control frame opcodes being 'scarce' is an issue; however,
> the spec already suggests the use of an extension bit to resolve this.
>
> The spec does not describe how the opcode space will be distributed across
> extensions. It does not say whether or not an extension opcode value can be
> 'redefined' by different extensions. Since a session can only be operating
> under one extension, there does not appear to be a technical reason why
> extensions could not redefine extension opcodes. If this is possible, then
> MBWS does not 'use up' any extension opcodes.
>

No, arbitrary extensions can be supported at the same time -- there is only
one subprotocol.

> Perhaps the fact that WebSocket itself does not reserve any of the opcode
> extension space for itself is an issue. There seems to be an implication in
> the comments so far that, in effect, they are all reserved and none are
> available for 'outside' use. I don't believe this is the case.
>

That was the intent of requiring registration of new opcodes and reserved
bits -- to basically require standards action for them to be assigned, since
they are so scarce.

Again, I think this issue is worthy of some serious debate. I'm not ready to
> concede, as yet, that defining MBWS as a WebSocket extension is wrong.

Let's say you did define it as an extension.  For it to be useful, the API
would have to be modified to suit your need and the browsers would have to
implement your extension.  What are the odds that will happen in a short
time period, vs. just using the facility already available via the
subprotocol?

@Ian - clearly, we need to add some text to the spec explaining the
distinction between subprotocols and extensions so others don't get the same
misconceptions.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 5 Oct 2011 14:45:16 +1100

Mark,

I think MBWS could be considered either as a subprotocol or as an
extension, depending somewhat on what your requirements for reliable
delivery are.

If it was done as a subprotocol without additional layer of framing,
the major issue I see from lacking control frame semantics is that the
timeliness of an ack may be poor if there is a large message being
sent over the channel in the same direction as the ack.   Your
protocol would still be reliable and able to recover from connection
loss, but it may have some undue latency when informing the
application of a successful delivery.

Conversely, reliable messaging with timely acknowledgement is a good
candidate for a websocket extension, that could be of use to MBWS and
other protocols.  So it may be that the MBWS concept of a connection
spanning multiple WS connections is something that should be
implemented in a subprotocol, while the message sequencing and
acknowledgement part could be implemented in an extension.

cheers

---

From: Hapner mark <[email-masked]>
Date: Wed, 05 Oct 2011 04:00:44 +0000

John,

Thanks for the further clarifications/corrections ...

So if I understand correctly, extension opcodes are globally defined and extensions are required to be defined such that they can be combined in adhoc combinations.

I would disagree that most users of HTTP put a framing protocol in HTTP bodies. They put MIME types (i.e. content types) in bodies. Content types do not contain protocol control - only the HTTP header contains (should contain) protocol control.

The MessageBroker use case is not an 'application' usecase; it is an extended element of the messaging infrastructure. Much like a firewall or proxy is an extended element of the HTTP infrastructure.

Within the phone home restriction, I believe AJAX clients have free rein to construct HTTP headers as they require. WebSocket needs something equivalent to this. If extensions are not this mechanism perhaps subprotocols can be extended a bit to provide this level of flexibility.

To be specific, providing one extension control frame opcode for overloaded use by a subprotocol, combined with allowing subprotocols to use extension data (or append 'subprotocol extension data' to the end of protocol extension data) would likely resolve this issue (MBWS would definitely use it). Also, the API would need to be extended to provide access to these subprotocol features so AJAX clients could access them.

(As an aside, it isn't clear to me how different extensions that define different extension data can be composed.)

I realize I'm a newbie to this WG so you are free to take my opinion with a grain of salt; however, I hope the WG will carefully consider extending subprotocol to allow MBWS to be defined without requiring it to define yet another message framing protocol.

-- Mark
________________________________
From: John Tamplin [[email-masked]]
Sent: Tuesday, October 04, 2011 6:54 PM
To: Hapner mark
Cc: Greg Wilkins; [email-masked]
Subject: Re: [hybi] Subprotocol and Control Frames

On Tue, Oct 4, 2011 at 9:36 PM, Hapner mark <[email-masked]<mailto:[email-masked]>> wrote:
WebSocket provides support for both subprotocols and extensions and I believe both are available for use by outside parties as long as the IANA registration mechanisms are followed. Is this correct?

Yes, but there are very very few available, and they were intended for WS infrastructure needs.  If the first WS subprotocol allocates two of them, do we tell people in a couple of months "sorry, we are all out", and not have any left for the purpose for which they are intended?  This is notwithstanding the fact that current APIs make no provision for using other opcodes, and as we have explained, we don't think they should.

In most cases, such services *do* define a framing layer on top of HTTP -- for example, JSON, which defines how the payload carried by HTTP should be interpreted.  They even have things like an opcode or message type inside them.

No, arbitrary extensions can be supported at the same time -- there is only one subprotocol.

That was the intent of requiring registration of new opcodes and reserved bits -- to basically require standards action for them to be assigned, since they are so scarce.

Let's say you did define it as an extension.  For it to be useful, the API would have to be modified to suit your need and the browsers would have to implement your extension.  What are the odds that will happen in a short time period, vs. just using the facility already available via the subprotocol?

@Ian - clearly, we need to add some text to the spec explaining the distinction between subprotocols and extensions so others don't get the same misconceptions.

---

From: John Tamplin <[email-masked]>
Date: Wed, 5 Oct 2011 00:18:01 -0400

On Wed, Oct 5, 2011 at 12:00 AM, Hapner mark <[email-masked]> wrote:

>  So if I understand correctly, extension opcodes are globally defined and
> extensions are required to be defined such that they can be combined in
> adhoc combinations.
>

They are globally defined, but it is yet to be determined whether they can
be allocated in overlapping fashion or dynamically.  We couldn't reach
agreement on those, so we left it the way it is now, which basically means
they can't be used without getting some agreement on them.  For example, one
proposal was that each extension specify how many opcodes and reserved bits
it needs, and those are allocated as needed per connection.  If we go with
that approach, we could create a spec that defines the mechanism
for dynamically allocating these resources, and then extension specs that
want to make use of this could simply refer to that spec.

Basically, the intent is to cross that bridge when we get there, and
hopefully we will have real use cases to consider to guide that decision.

>  I would disagree that most users of HTTP put a framing protocol in HTTP
> bodies. They put MIME types (i.e. content types) in bodies. Content types do
> not contain protocol control - only the HTTP header contains (should
> contain) protocol control.
>

Most JSON or SOAP-based services I have used do in fact have some sort of
message type in the payload, but YMMV.

>  To be specific, providing one extension control frame opcode for
> overloaded use by a subprotocol, combined with allowing subprotocols to use
> extension data (or append 'subprotocol extension data' to the end of
> protocol extension data) would likely resolve this issue (MBWS would
> definitely use it). Also, the API would need to be extended to provide
> access to these subprotocol features so AJAX clients could access them.
>

I really don't see the difference -- if MBWS were to say "I want 20 bytes of
extension data", how is that any different than just using the first 20
bytes of the WS payload as its extension data, and the remainder of the WS
payload as the upper-level payload?

>  (As an aside, it isn't clear to me how different extensions that define
> different extension data can be composed.)
>

In the order they are declared.

>  I realize I'm a newbie to this WG so you are free to take my opinion with
> a grain of salt; however, I hope the WG will carefully consider extending
> subprotocol to allow MBWS to be defined without requiring it to define yet
> another message framing protocol.
>

Multiple layers of framing is the norm -- Ethernet has its own framing, IP
on top of that, TCP or UDP on top of that, HTTP on top of that, etc.  Each
layer peels off their part and passes the rest on to the next layer -- that
is the way the network stack works.  I am not sure why you are resisting
this.

---

From: Hapner mark <[email-masked]>
Date: Wed, 05 Oct 2011 05:36:37 +0000

>Sent: Tuesday, October 04, 2011 9:18 PM
 >To: Hapner mark
 >They are globally defined, but it is yet to be determined whether they can be allocated in overlapping fashion or dynamically.  We couldn't reach agreement on those, so we left it the way it is now, which basically means they can't be used without getting some agreement on them.  For example, one proposal was that each extension specify how many opcodes and reserved bits it needs, and those are allocated as needed per connection.  If we go with that approach, we could create a spec that defines the mechanism for dynamically allocating these resources, and then extension specs that want to make use of this could simply refer to that spec.
 >
 >Basically, the intent is to cross that bridge when we get there, and hopefully we will have real use cases to consider to guide that decision.
 > 
 >Most JSON or SOAP-based services I have used do in fact have some sort of message type in the payload, but YMMV.
 > 
 >I really don't see the difference -- if MBWS were to say "I want 20 bytes of extension data", how is that any different than just using the first 20 bytes of the WS payload as its extension data, and the remainder of the WS payload as the upper-level payload?

My main issue is with putting MBWS control frames into WebSocket message payloads. 

Putting MBWS message metadata into its associated message payload is a lesser issue. It requires the definition of an extension data mechanism within text message payloads and binary message payloads that mirrors what already exists in WebSocket.

You equate WebSocket with TCP. I equate it with HTTP. Possibly neither of us is fully correct. 

HTTP added a framing protocol over TCP so does WebSocket. If all extended use of WebSocket has to treat it like TCP, then Clebert and I should get on with implementing our MBWS message framing protocol and stop annoying the WG. 

On the other hand, there is great potential to reuse/extend the WebSocket protocol in much the same way that the web community has with HTTP. If the community had treated HTTP like it was TCP it would be worse off (as WS* did and is). Possibly the TCP analogy with WebSocket is not the most productive mental model of WebSocket's role in web architecture.

What would be the harm in considering extending the functionality of WebSocket subprotocol in the way I'm suggesting? Wouldn't having one less layer be a useful result. 

 >Multiple layers of framing is the norm -- Ethernet has its own framing, IP on top of that, TCP or UDP on top of that, HTTP on top of that, etc.  Each layer peels off their part and passes the rest on to the next layer -- that is the way the network stack works.  I am not sure why you are resisting this. 
 >
 >-- 
 >John A. Tamplin

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 4 Oct 2011 23:04:57 -0700

On Tue, Oct 4, 2011 at 10:36 PM, Hapner mark <[email-masked]> wrote:

>  >They are globally defined, but it is yet to be determined whether they
> can be allocated in overlapping fashion or dynamically.  We couldn't reach
> that approach, we could create a spec that defines the mechanism for
> dynamically allocating these resources, and then extension specs that want
> to make use of this could simply refer to that spec.
>  >
>  >I really don't see the difference -- if MBWS were to say "I want 20 bytes
> of extension data", how is that any different than just using the first 20
> Putting MBWS message metadata into its associated message payload is a
> lesser issue. It requires the definition of an extension data mechanism
> within text message payloads and binary message payloads that mirrors what
> already exists in WebSocket.
>
> HTTP added a framing protocol over TCP so does WebSocket. If all extended
> use of WebSocket has to treat it like TCP, then Clebert and I should get on
> with implementing our MBWS message framing protocol and stop annoying the
> WG.
>
> On the other hand, there is great potential to reuse/extend the WebSocket
> protocol in much the same way that the web community has with HTTP. If the
> community had treated HTTP like it was TCP it would be worse off (as WS* did
> and is). Possibly the TCP analogy with WebSocket is not the most productive
> mental model of WebSocket's role in web architecture.
>
> What would be the harm in considering extending the functionality of
> WebSocket subprotocol in the way I'm suggesting? Wouldn't having one less
> layer be a useful result.

At the end of the day, the way I think of it is that extensions are for
protocol level things that the client and server software must support.
subprotocols are contracts between the application software running in the
client and server, but the client and server are blissfully unaware of any
of these semantics. It would be hell if you had to recompile Apache to
understand the semantics of each website you wanted to serve.

If you're changing the framing in a meaningful way (e.g. changing message
opcodes), then servers and intermediaries need to be altered and recompiled
to deal with those changes. At that point, you've defined an extension. If
you're not meaningfully changing the framing, but you're simply instructing
the other endpoint "Here's how to interpret the data contained in the
payload of the message", the servers and intermediaries don't need to be
recompiled and you are defining a subprotocol.

I suspect that what you are trying to do, like many things, could be written
as either an extension or a subprotocol. We could define an extension for
google search - send a search opcode and the search terms and get back a
results opcode with the search results. Yes, it's a bit of a facetious
example, but I'm merely trying to illustrate a point. The mere fact that
something can be done that way doesn't make it necessarily appropriate or
desirable. It's not clear to me as a browser vendor why I would want to
implement either a google search extension or an MBWS extension, for
example, nor why I would want to agree to opcodes and reserved bits being
allocated for its use.

-Ian

---

From: Greg Longtin <[email-masked]>
Date: Wed, 5 Oct 2011 07:48:59 -0500

To all,

On Wed, Oct 5, 2011 at 1:05 AM, Ian Fette <[email-masked]> wrote:

At the end of the day, the way I think of it is that extensions are for protocol level things that the client and server software must support. subprotocols are contracts between the application software running in the client and server, but the client and server are blissfully unaware of any of these semantics. It would be hell if you had to recompile Apache to understand the semantics of each website you wanted to serve.

Having followed the progress of WS, my understanding of the distinction between subprotocols and extensions was as Ian has stated very well.

Conversely, the discussions about MBWS may show that the spec is not clear enough on the distinction.

When 17 was released, I tried to read the spec from the perspective of someone 'new' to WS, and felt there could a better description of the distinction.  This issue is also affected by the wording in the W3C 'The WebSocket API' document, which mentions both subprotocols and extensions.  To add to it, I speak English natively.

Not being familiar with changing/amending a 'Proposed Standard', I'm not sure if this can be addressed...

Thanks,

Greg Longtin

---

From: "Arman Djusupov" <[email-masked]>
Date: Fri, 7 Oct 2011 16:35:51 +0300

I believe that this sub-protocol is needed, as it can provide a common way
of message dispatching and connection recovery for various applicationσ
irrespective of what format they use for the message.

For example there are various JSON RPC or Protobuff RPC in development and
most of them are not interoperable with each other due to incompatible
message metadata format. Having a common message metadata format would be
very beneficial.

Message Extension Data Fields
   
   |    Address    |    base 128 varint   |   UTF-8 character string   |
   |  Content-Type |    base 128 varint   |   UTF-8 character string   |
   | Property List |    base 128 varint   |    Sequence of Property    |
   
In addition to the implicit sequence number, a MessageID/ReleatesTo field
could also be added to the message header. Most applications would need this
to associate the messages they receive with the messages they send. This
property can obviously be added to the property list or even be part of the
Address field but this would add additional overhead when processing the
message.

For example, multiple outbound requests were sent by one side and received
by the remote side in correct order, but processing each request took
different amounts of time so the responses may arrive in a different order.
In such cases the application that sent the requests would have to use a
Property list and search for e.g. "RelatesTo" in message properties. This
would definitely be slower than if there would be some sort of fixed
"Topic/ID" field in the message header that would associate requests with
responses. This field could be a variant integer number for faster
processing.

With best regards,
Arman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hapner mark
> Sent: Wednesday, October 05, 2011 4:36 AM
> To: Greg Wilkins
> Cc: [email-masked]
> I agree that MBWS could define its own framing protocol within the
> WebSocket message payload, i.e. MBWS could be defined as a WebSocket
> subprotocol. (Sorry for my original confabulation of subprotocol and
> extension)
> 
> The option also exists to implement MBWS as it is currently defined as a
> WebSocket extension that adds extension data and extension control frame
> opcodes.
> 
> My primary concern is that implementing MBWS as a subprotocol will add
> complexity and overhead. The only rationale I can see for defining MBWS as
> a subprotocol would be if, for some reason, browsers/proxies/firewalls
> blocked WebSocket extensions, i.e. MBWS has to use a 'subprotocol tunnel'
> through them.
> 
> request-response body when all it needed was to add a few new header
> fields. Let me see, I think I remember this being done, it was called WS*
:>)
> extension space for itself is an issue. There seems to be an implication
in the
> comments so far that, in effect, they are all reserved and none are
available
> for 'outside' use. I don't believe this is the case.
> 
> I think subprotocols and extensions are both useful. For an application
> specific case, say the transport of Insurance Policies and Quotes,
defining a
> subprotocol for transport of this Insurance Message Schema would be
> sensible. I believe that MBWS is case where the use of an extension is
> sensible.
> 
>  >> In my reading of draft 17, I do not find a definition of subprotocol
that  >>
>opcodes,
> the only allowance given is to extensions.
>  >
>  >> If the sense of the WG is that subprotocols are restricted to use  >>
only
> extension data and message format/schema restrictions, this is not  >>
>  >The specification also describes subprotocols in section 1.3 as  >
> that  >> could benefit from the ability to define usecase-specific control
> frames to  >> mediate message flow. Telling developers to stuff this
> mediation protocol  >> into extension data rather than in control frames
does
> not appear to  >> increase security;  >  >Firstly subprotocols can no more
use
> extensions data than they can use  >extension opcodes.
>required
> and to which part of the websocket API a message should be  >delivered.
> There is no semantic restriction imposed by a binary  >message, which may
> actually be a text message, but one for which the  >application or
> subprotocol has taken responsibility for character  >encoding.
>  >
>  >> rather, it likely decreases security because it  >> intermixes control
with
> data which is a fundamentally bad thing for a  >> protocol design to do.
The
> two control frames defined by MBWS are fairly simple and are likely  >>
> representative of what other subprotocols would need. It would be far
> better  >> to allow MBWS to properly factor its control and data than
force it
> to put  >> control in its data.
>  >
>a
> single stream per connection, so there can be no separation of
>control
> stream, but rather to better support multiple streams - ie  >MUX.  For the
> protocol, it is clear that there are two streams of
>will
> apply generally to all applications and subprotocols.  There may  >be use
> cases where applications/subprotocols need n streams or control  >frames
> larger than 125 bytes.
>  >
>is
> somewhat like the applications need for control messages and thus  >to
> attempt to expose the protocols control channel to the application.
>control
> channels - MUX!
> however,  >> HTTP clearly does support this with a very open-ended
> extension of the HTTP  >> header. The WG needs to think carefully about
> this. I hope there is room to  >> resolve this issue in this version of
> WebSocket.
> >> that both native users of WebSocket and implementors of WebSocket  >>
>> will. I
> don't believe that the design of WebSocket needs to be restricted by  >>
the
> current limitations of this API.
>  >
>will
> make the task of creating things like MUX extensions much more
>difficult.
> The mux solution would have to allow for extending control  >frames with
> extension data so that they may be correctly routed to the  >right
application
> control channel.  But if a 125 byte application  >control frame is sent,
then
> there may not be sufficient room to add
>far
> worse "solution" than mixing application control messages with
>application
> data messages.
>  >
>  >regards