Subject: [hybi] HyBi Design Space

From: Salvatore Loreto <[email-masked]>
Date: Thu, 08 Oct 2009 23:50:42 +0300

Hi there,

at the breakfast BoF in Stockholm it was brought up that it would have been helpful to more
clearly describe the design space, including the programming environments (client, server, 
library, etc.), deployed infrastructure (routers, proxies, etc.).

here the analysis that we have written down and we are going to insert in the 
draft-loreto-http-bidirectional.

comments, feedbacks and suggestions are very welcome

cheers
Sal
www.sloreto.com

6.  Design Space

   In order to define additions to HTTP that could enable improved
   mechanisms for bidirectional HTTP or new bidirectional protocols, it
   is important to map out the design space and potential design
   alternatives, with special attention to deployed infrastructure and
   programming environments.

   In existing HTTP-based systems, the typical semantic is client-server
   Representational State Transfer (REST), where the resources served
   are closely associated with an entity known by a URI or URL.
   However, the introduction of bidirectionality can significantly
   change the normal HTTP patterns.

   As one example, the standard roles of client and server can be
   reversed and a server can request resources from a client.
   Unfortunately, due to a lack of client addressability URL's may not
   be applicable to client entities and new addressing paradigms may be
   required.

   Furthermore, bidirectionality introduces a message passing pattern
   into the traditional REST style.

   These additional semantics will influence the design of the
   bidirecitonal protocols, addressing, and APIs.  Without a strong
   association between an identified entity and a resource, new
   mechanisms for content distribution and caching messages might need
   to be considered.

   In the next sections we analyse the design space from several
   different sides of the HTTP deployed infrastructure, including
   clients, servers, and intermediaries such as proxies, caching
   servers, and load balancers.

   The process of evaluating eventual improvements to the bidirectional
   solutions or development of new bidirection protocols should take
   into consideration the following concerns and criteria:

   Complexity:  enables ease of implementation, understanding, and
      debugging

   Capability:  addresses all/most known bidirectional use-cases

   Extensibility:  has the capacity to handle new use-cases

   Latency:  defines minimal, average, and maximal latency for message
      delivery

   Bandwidth overhead:  minimizes overhead for idle and busy usage

   Scalability:  has the ability to handle large scale usage

   Footprint:  has the ability to handle small devices and/or massive
      replication ("cloud")

   AAA:  enables proper Authentication, Authorization and Accounting

   Security:  enables strong security for integral, confidential,
      endorsed, and cross domain deployments.

   Interoperability:  can work with and/or be integrated with existing
      bidirectional implementations

   Compatibility:  can work with existing web infrastructure for
      distributing, caching, manipulating, and displaying content.

6.1.  Server side

   The server side can be decomposed into three categories:

   In-band HTTP:  Bidirectionality is part of the normal HTTP/Web server
      responsibilities.  HTTP is used for transporting server events.
      Examples include Comet and (in some deployments) BOSH.

   Out-of-band HTTP:  Here two servers are involved: bidirectionality is
      not part of the normal HTTP/Web server responsibilities, but the
      backend service is offered by a separate server that might not
      even be on the same machine of the HTTP/Web server.  HTTP is used
      for transporting server events.  When a browser is used on the
      client side, a cross-domain solution is needed to overcome the
      "same-source" web service restriction.  Examples include BOSH (in
      some deployments) and Lightstreamer.

   In-band non-HTTP:  Bidirectionality is part of the normal HTTP/Web
      server responsibilities.  However, server events are transported
      on an upgraded HTTP connection.  Examples include Bidirectional
      Web Transfer Protocol (BWTP) and WebSockets.

   Out-of-band non-HTTP:  Bidirectionality is offered by a dedicated
      server using non HTTP protocol for transport server events.
      Examples include WebSockets.

   The HTTP transport based servers (in-band and out-of-band) can work
   with existing HTTP standards or enhanced HTTP.  Enhanced HTTP would
   be a standardized set of headers and behaviours to assist with
   bidirectionality and cross domain concerns.

   At present, a protocol that interacts heavily with JavaScript on the
   client side implies some constraints also on the server side, such
   that they have to use XML or JSON encapsulation.

6.2.  Clients

   Clients can be involved in bidirectional transport in the following
   capacities:

   In browser open standards with HTTP transport:  For applications
      written in a web browser scripting language (e.g.  JavaScript)
      within a browser client.  Examples include Comet and BOSH.

   In browser open standards with enhanced HTTP transport:  For
      applications written in a web browser scripting language (e.g.
      JavaScript) within a browser client.  Examples include Comet with
      cross domain extensions.

      Browsers using either standard HTTP transport or enhanced HTTP
      transport typically use XMLHttpRequest (XHR) API
      [W3C.WD-XMLHttpRequest2-20090820] allowing scripts to perform HTTP
      client functionality.  The XHR object can be used to perform
      bidirectional HTTP using both "long polling" and "HTTP streaming"
      mechanisms.

      XHR also supports the cross domain extension
      [W3C.WD-cors-20090317], which overcomes the same-origin
      restrictions that prevent a Web application running from one
      origin from obtaining data retrieved from another origin.
      However, XHR presents some limitations on the headers that can be
      set by the user.

      An alternative to XMLHttpRequest is using the Server-Sent Events
      API [W3C.WD-eventsource-20090423].  This "EventSource: interface
      enables servers to push data to Web pages over HTTP or using
      dedicated server-push protocols.

   In browser open standards with non HTTP transport:  For applications
      written in JavaScript within a browser client.  Examples include
      BWTP and WebSockets.

   In browser with plugin:  This is not of particular interest to IETF,
      but should be noted as part of the design space.  Examples include
      BlazeDS.

   Non-browser HTTP:  A bidirectional client may be written outside of a
      browser and use bidirectional web transports.  Typically this is
      done so that a rich or minimal client can bypass firewalls to
      access public servers over HTTP transports.  Examples include the
      Comet Java client and the Second Life Viewer.

   Non browser enhanced HTTP:  [Definition and examples to follow.]

   Non browser non-HTTP:  [Definition and examples to follow.]

6.3.  Intermediaries

   Intermediaries (e.g. proxies, gateways, caching servers, load
   balancers, etc) can be involved in bidirectional transport in several
   capacities:

   Legal HTTP relay:  Transports such as long polling use intermediaries
      to carry legal HTTP requests and response.  Any capabilities that
      may interfere with bidirectional flow (e.g. caching) are
      controlled with standard headers or cookies.  The intermediary may
      be a participant in the transport (e.g., changing framing or
      encapsulation).

   Defacto HTTP relay:  Some streaming transports use the common
      behavior of HTTP intermediaries to forward content packet-by-
      packet.  This relies on intermediaries to not cache or buffer
      content.

   Enhanced HTTP relay:  Uses yet-to-be-defined HTTP headers to assist
      HTTP based bidirectional transports.  The intermediary may be a
      participant in the transport (e.g., changing framing or
      encapsulation).

   Upgraded HTTP relay:  Uses HTTP upgrade to relay a non-HTTP protocol.

   Tunneled relay:  Uses (or abuses?) the CONNECT mechanism to simulate
      an SSL connection to be used as a tunnel for a non-HTTP transport.

   [W3C.WD-XMLHttpRequest2-20090820]
              Kesteren, A., "XMLHttpRequest Level 2", World Wide Web
              Consortium WD WD-XMLHttpRequest2-20090820, August 2009,
              <http://www.w3.org/TR/2009/WD-XMLHttpRequest2-20090820>.

   [W3C.WD-cors-20090317]
              Kesteren, A., "Cross-Origin Resource Sharing", World Wide
              Web Consortium WD WD-cors-20090317, March 2009,
              <http://www.w3.org/TR/2009/WD-cors-20090317>.

   [W3C.WD-eventsource-20090423]
              Hickson, I., "Server-Sent Events", World Wide Web
              Consortium WD WD-eventsource-20090423, April 2009,
              <http://www.w3.org/TR/2009/WD-eventsource-20090423>.

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Thu, 8 Oct 2009 16:00:09 -0700

thx salvatore for typing this up. it looks good, but i have one very
minor nit and a comments/question.

the nit is that when we use the verbiage in section 6.2:

"Non-browser HTTP:  A bidirectional client may be written outside of a
browser and use bidirectional web transports.  Typically this is done
so that a rich or minimal client can bypass firewalls to access public
servers over HTTP transports.  Examples include the Comet Java client
and the Second Life Viewer."

it could be interpreted that the reason we use HTTP is exclusively to
move through firewalls easily. the main reason we layer some of our
protocol over HTTP is that we wanted / needed a protocol with request
/ response + metadata semantics. that it goes through firewalls is a
pleasant side-effect. i suspect that other users of HTTP as a
substrate might have come to the idea for the same reasons. could i
recommend the minor change of:

"Non-browser HTTP:  A bidirectional client may be written outside of a
browser and use bidirectional web transports.  Typically this is done
when a rich or minimal client requires a mature transport for
application protocol with request / response semantics and/or the
ability to bypass firewalls to access public servers over HTTP
transports.  Examples include the Comet Java client and the Second
Life Viewer."

and the comment/question:

1. towards the end of the breakfast bof we discussed... for lack of a
better term... "features" like message multiplexing so that when
independent components on the server want to send an unsolicited
message to independent components on the client may use the same
connection. in other words, allowing a single connection to carry
messages for multiple channels. that's still being discussed, right?

we sorta figured that it won't be an unusual case to find you have a
large number of components on the client that need to be addressable
by independent components on the server. my read of websockets seems
to imply it punts on the issue, requiring application developers to
design such a scheme for themselves. that sorta makes me a little
uneasy. when your client is a web browser that downloads a web page,
instantiates a number of javascript objects described by javascript
files on the server, i can see that this provides a great deal of
flexibility. but the SL viewer won't be downloading and executing
javascript for something as critical as server to client messaging,
and i would venture to guess that other applications that use HTTP as
a substrate will find this idea concerning.

if we were to implement messaging over websockets, i believe we would
be inclined to define a static client service that consumes the
protocol, but assumes a payload with a field that identifies a
uniquely addressable destination component in the client.

if we're going to define such a scheme and enshrine it in c++ on our
client, it would be very nice, since it's not going to change very
much, if it were vaguely standardized so we could get intermediaries
to understand the request and potentially cache them.

this is my round-about way of saying, we like rhttp and bwtp because
they allow intermediaries to reason about reverse-requests, caching
reverse responses when appropriate, routing around firewalls when
appropriate (like a bwtp aware socks stack) and allow us to use design
patterns we're familiar with (like web capabilities) in the reverse
direction.

since i've rambled, let me repeat my question.. "we're still going to
add message multiplexing, right?"

if yes, i'll just shut up now and wait to comment when the draft is published.

if no, i'd love to chat about it a little more.

-cheers
-meadhbh / infinity

--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Thu, Oct 8, 2009 at 13:50, Salvatore Loreto
<[email-masked]> wrote:
> clearly describe the design space, including the programming environments
> (client, server, library, etc.), deployed infrastructure (routers, proxies,
> etc.).
>
> here the analysis that we have written down and we are going to insert in
> the draft-loreto-http-bidirectional.
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Oct 2009 22:15:00 -0500

While I agree that constraining the design space is probably a necessary part of our work, there are aspects to this text that concern me.

I like the effort that is going into identifying the servers, clients and intermediaries that are involved and the constraints that are involved.  That part of the text seems valuable.

However, it seems like there was consensus to address two problems in the WG:

 A - right here and now, HTTP extensions
 B - sometime later, new protocols that interact somehow with HTTP

From the abstract and early sections of the document, the draft right now seems to be concentrated on the side of A.

This analysis seems divorced from this goal, so much so that it seems a little unfocussed.

For instance, the usual laundry list of desires surfaces: Complexity, Capability, Extensibility, Latency, Bandwidth, Scalability, Footprint, AAA, Security, Interoperability (!), Compatibility.

These are constraints on any design exercise.  They don't add any value unless they are directly related to the work at hand.

My initial view of this document was a problem statement for A.  To that end, this could all be much more specific.  For instance, compatibility is highly important for solution A.  Or, more specifically yet: it is important that solution A can be deployed to the web in the short-term, so compatibility with existing implementations is crucial.

The example of "Non-browser, non-HTTP" immediately jumps out as a problem for this document.  A reasonable reaction might be that this is way out of scope.  But then, I know that it isn't necessarily the case.   Insufficient context has been provided to assess this item rationally because it's talking about B, not A.

Because the constraints are significantly different on A vs. B, a separate problem statement for B seems appropriate.  That would help this be a little less vague.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Salvatore Loreto
> Sent: Friday, 9 October 2009 7:51 AM
> To: [email-masked]
> Subject: [hybi] HyBi Design Space
> 
> Hi there,
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 09 Oct 2009 16:53:25 +0300

Hi Meadhbh,

see my answers in line

cheers
Sal

> minor nit and a comments/question.
the credits have to go to the right place,
the text is a collaborative work of all the authors of 
draft-loreto-http-bidirectional: Greg, Peter, Salvatore and Stefano.
> transports.  Examples include the Comet Java client and the Second
I agree that the current text could be misleading. thanks for the 
suggestion, it will be included for sure
in the text that will be included in the draft
> messages for multiple channels. that's still being discussed, right?
sure, at least IMO the HyBi wg should concentrate on the broad scope of 
bidirectional communication

> add message multiplexing, right?"
again the multipexing is something important for both server developers,
but as far I understood following the discussion in whatwg ml, also 
browser developers or at least
w3c people agree that WebSocket protocol as proposed could be improved, 
also with the help of HyBi,
to support other features and "in-protocol multiplexing sounds like one 
of the most valuable additional features"

> if no, i'd love to chat about it a little more.
I suggest you to start a different thread in the ML on the subject

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 09 Oct 2009 17:15:03 +0300

Hi Martin,

see in line.

Cheers
Sal

> I like the effort that is going into identifying the servers, clients and intermediaries that are involved and the constraints that are involved.  That part of the text seems valuable.
thanks
>  B - sometime later, new protocols that interact somehow with HTTP
right, there was consensus for both! and the HyBi will eventually work 
to address both!
> Because the constraints are significantly different on A vs. B, a separate problem statement for B seems appropriate.  That would help this be a little less vague.
the confusion most probably come from the fact that the draft was 
thought to address the problem -A- .
maybe instead of insert the Design Space analysis text in the existing 
draft it would be better include it in a new draft;
and then include in the existing draft (draft-loreto-http-bidirectional) 
a much more specific text for the "right here and now, HTTP extensions".
would it make sense?

---

From: Ian Hickson <[email-masked]>
Date: Fri, 9 Oct 2009 21:47:10 +0000 (UTC)

On Fri, 9 Oct 2009, Salvatore Loreto wrote:
> browser developers or at least w3c people agree that WebSocket protocol 
> as proposed could be improved, also with the help of HyBi, to support 
> other features and "in-protocol multiplexing sounds like one of the most 
> valuable additional features"

FWIW, so far I've concluded (based on long discussions with a number of 
developers and implementors) that multiplexing would actually not be that 
great. It could probably only be used for multiplexing to a single 
websocket path, without making the handshake highly asymmetric or breaking 
the HTTP compatibility. If it's intended for per-client multiplexing, it 
can easily be implemented at the application layer, where a much better 
job can be done that could be done at the protocol layer. If it's intended 
for multiclient multiplexing, then it's only helping server load, not 
client performance, and server load isn't especially an issue here.

It's not analogous to keepalive and pipelining in HTTP. In HTTP, the cost 
is in setting up the connection, which happens a lot. Multiple resources 
on one origin incur multiple TCP round trips just to get the connections 
set up, and this can severely impact performance. However, WebSocket 
connections are long lived by design, and the cost of setting up a 
connection therefore is insignificant compared to the cost of the protocol 
itself. There's also something to be said for relying on TCP's built in 
congestion control -- if you were to open two connections to a server, 
one sending vast amounts of data, and one sending just the occasional 
critically important notification, it would be best if the latter could 
avoid getting throttled along with the first.

As with anything, though, there's always the option of changing this if 
strong arguments one way or the other are put forward. We can also 
introduce multiplexing as a new version of the protocol in a future 
version.

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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 10 Oct 2009 11:52:49 +0200

Ian Hickson wrote:
> ...
> ...

...why exactly is server load not an issue?

BR, Julian

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Sat, 10 Oct 2009 08:53:57 -0700

the problem i have with doing addressing for multiplexing channels on
a single connection in the application layer is that it effectively
disallows intermediaries from reasoning about distinct messages on
distinct channels. i do agree that doing multiplexing in the
application layer is much more flexible and for many deployments "this
is a good thing." does it make sense to have a multiplexing option in
the protocol that can be used by people who want their intermediaries
to understand this sort of thing, but not make it mandatory? that way
i could hire someone to hack squid to recognize and cache multiplexed
reverse responses and people who want to do something more flexible at
the app layer can still do it.

fwiw. i'm coming at this from a "http as a substrate" perspective,
where (i suspect) we're going to have more client -> server responses
with large payloads than might be typical in a browser app. and since
client -> server communication is slower in may broadband models, for
the few protocol transactions where we're responding to the server
with large, cacheable payloads, i would be nice if we could have a
standard protocol understandable by intermediaries.

-cheers
-meadhbh

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 12 Oct 2009 19:05:39 +1100

Ian Hickson wrote:

> great.

Which developers/implementors?

So far the majority of opinions I've seen on this list and the whatwg list
have been favourable to multiplexing.   Can you invite them to post their
opinions here?

> However, WebSocket
> connections are long lived by design, 

I do not believe you can anticipate websocket usage over the long
term.  Just because you think now they will only be used for long
lived connections, that may not always be the case.  It is short
sighted to build such limitations into a once-in-a-decade chance to
upgrade the protocols we use on the web.

> and the cost of setting up a
> itself.

There is also a cost associated with maintaining and servicing a
connection.

> There's also something to be said for relying on TCP's built in

Some would argue that is improperly bypassing TCP's congestion control.

I have often seen the horrid argument put that if you use 8 connections
instead of 1, then you are more likely to get better service from
a router that is fair sharing capacity among connections.   That path
leads to an irrational arms race as once everybody uses 8 connections,
somebody will use 16 to get better service etc etc.

Implementing connection policies is not something that should
be left to the application developer. It is far far better that the
browsers implement connection control policies.

> introduce multiplexing as a new version of the protocol in a future 

Protocol versions come once maybe twice a decade.   Please consider
the future and not just short term needs of one particular interest
group.

regards

---

From: Graham Klyne <[email-masked]>
Date: Mon, 12 Oct 2009 10:17:49 +0100

To add just one voice among many...

(1) in the use-cases that I've considered for pushing messages/requests to a 
browser, multiplexing is not a requirement.  Other's mileage may, of course, vary.

(2) Looking at a multiplexing protocol such as BEEP, multiplexing adds a *lot* 
of complexity to the protocol specification and implementation.  I would say 
that the case for multiplexing in the base protocol needs to be made to justify 
that added complexity.

(3) It seems to me that, if needed, a multiplexing layer could be specified and 
standardized over a non-multiplexing substrate.

#g
--

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 13 Oct 2009 08:06:44 +1100

Graham Klyne wrote:
> (1) in the use-cases that I've considered for pushing messages/requests
> to a browser, multiplexing is not a requirement.  Other's mileage may,
> of course, vary.

Graham, it would be great if you could briefly describe
your use-cases.

Are you sure that they will never be mashed up into a webapp made
of many parts that originally were not designed to work together?

Are you sure that they would never run behind a transparent proxy
that might aggregate multiple connections into a single connection?

> (2) Looking at a multiplexing protocol such as BEEP, multiplexing adds a
> *lot* of complexity to the protocol specification and implementation.  I
> would say that the case for multiplexing in the base protocol needs to
> be made to justify that added complexity.

I totally agree that the multiplexing of BEEP is too complex for
the level of protocol that we are considering.

But multiplexing can be much much simpler.  At it simplest,
it just needs a channel id in each frame and the channel creation
can be automatic.   In the BWTP protocol proposal, I've added
a little bit of channel creation exchange, so as to well match
the explicit life cycle events of the websocket API.

> (3) It seems to me that, if needed, a multiplexing layer could be
> specified and standardized over a non-multiplexing substrate.

Normally I do believe layering protocols like you describe would be
a good approach. But...

The difficulty is that with websocket protocol, it has a hard binding
to the application websocket API.  There is no scope provided to inject
another layer.   The API has explicit  open/close events (which I think
should be mapped to channels), but that are currently mapped to connections.
Thus applications and/or frameworks will be doing explicit connection
management.

This is analogous to the advent of XHR in the browser. Every Ajax
books then started with a chapter about how to write your own Ajax
code directly using XHR.  But XHR is a too low level API for
applications and it has taken many years to abstract the average
ajax developer away from direct XHR access.  So now we have
frameworks such as dojo, jquery, yahoo, ext etc that provide an
abstraction on top of XHR.

Probably these frameworks will be able to provide good abstractions
on top of websocket API, and this may well include multiplexing
support.   But even if the frameworks implemented to same wire
protocol for multiplexing, they would not be able to:

  + share connections between frameworks
  + share connections with code written directly to the websocket API.
  + share connections with other iframes, tabs and/or windows.
  + implement a strong origin policy for security

I believe that these desirable things can only be achieved if
it is the browser rather than the application that implements
the multi-plexing.

The fundamental problem with websocket API is that is both
a connection API (open/close) and a messaging API (send/onMessage).
The API needs to be abstracted away from any hard relationship
to TCP/IP connections.   This can be done with a simple rename
of s/connection/channel/.     Applications can then manage channels
and the browser/server can manage mapping those channels to
connections - perhaps with multiplexing or perhaps without.

cheers

---

From: Stefano Salsano <[email-masked]>
Date: Tue, 13 Oct 2009 01:25:16 +0200

Dear Martin,

I understand the concerns you have expressed and I agree with the points 
  you made.

After your comments, now I think that is is better not to include this 
analyis of design space as it is in the draft-loreto-http-bidirectional 
and to keep it as a separate document instead.

As Salvatore has proposed in his reply to your mail, may be we can try 
to extract the text and the concepts that are directly related to che 
case "A - right here and now" and propose a reduced text to be inserted 
in draft-loreto-http-bidirectional...

Best regards,
Stefano

Thomson, Martin wrote:
> While I agree that constraining the design space is probably a
> necessary part of our work, there are aspects to this text that
> concern me.
> 
> I like the effort that is going into identifying the servers, clients
> and intermediaries that are involved and the constraints that are
> involved.  That part of the text seems valuable.
> 
> A - right here and now, HTTP extensions B - sometime later, new
> protocols that interact somehow with HTTP
> 
>> From the abstract and early sections of the document, the draft
>> right now seems to be concentrated on the side of A.
> 
> For instance, the usual laundry list of desires surfaces: Complexity,
> Capability, Extensibility, Latency, Bandwidth, Scalability,
> Footprint, AAA, Security, Interoperability (!), Compatibility.
> 
> These are constraints on any design exercise.  They don't add any
> value unless they are directly related to the work at hand.
> 
> My initial view of this document was a problem statement for A.  To
> that end, this could all be much more specific.  For instance,
> compatibility is highly important for solution A.  Or, more
> specifically yet: it is important that solution A can be deployed to
> the web in the short-term, so compatibility with existing
> implementations is crucial.
> 
> The example of "Non-browser, non-HTTP" immediately jumps out as a
> problem for this document.  A reasonable reaction might be that this
> is way out of scope.  But then, I know that it isn't necessarily the
> case.   Insufficient context has been provided to assess this item
> rationally because it's talking about B, not A.
> 
> Because the constraints are significantly different on A vs. B, a
> separate problem statement for B seems appropriate.  That would help
> this be a little less vague.
> 
> --Martin
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Salvatore Loreto Sent:
>> Friday, 9 October 2009 7:51 AM To: [email-masked] Subject: [hybi]
>> HyBi Design Space
>> 
>> Hi there,
>> 
>> at the breakfast BoF in Stockholm it was brought up that it would
>> have been helpful to more clearly describe the design space,
>> including the programming environments (client, server, library,
>> etc.), deployed infrastructure (routers, proxies, etc.).
>> 
>> here the analysis that we have written down and we are going to
>> insert in the draft-loreto-http-bidirectional.
>> 
>> cheers Sal www.sloreto.com
>> 
>> 
>> 
>> 6.  Design Space
>> 
>> mechanisms for bidirectional HTTP or new bidirectional protocols,
>> it is important to map out the design space and potential design 
>> In existing HTTP-based systems, the typical semantic is client- 
>> server Representational State Transfer (REST), where the resources
>> served are closely associated with an entity known by a URI or URL.
>>  be applicable to client entities and new addressing paradigms may
>> be required.
>> 
>> The process of evaluating eventual improvements to the
>> bidirectional solutions or development of new bidirection protocols
>> should take into consideration the following concerns and criteria:
>> 
>> 
>> Extensibility:  has the capacity to handle new use-cases  Latency:
>> defines minimal, average, and maximal latency for message delivery
>> 
>> In-band HTTP:  Bidirectionality is part of the normal HTTP/Web 
>> server responsibilities.  HTTP is used for transporting server
>> events. Examples include Comet and (in some deployments) BOSH.
>> 
>> Out-of-band HTTP:  Here two servers are involved: bidirectionality 
>> is not part of the normal HTTP/Web server responsibilities, but the
>> server responsibilities.  However, server events are transported on
>> an upgraded HTTP connection.  Examples include Bidirectional Web
>> Transfer Protocol (BWTP) and WebSockets.
>> 
>>  with existing HTTP standards or enhanced HTTP.  Enhanced HTTP
>> would be a standardized set of headers and behaviours to assist
>> with bidirectionality and cross domain concerns.
>> 
>> At present, a protocol that interacts heavily with JavaScript on
>> the client side implies some constraints also on the server side,
>> such that they have to use XML or JSON encapsulation.
>> 
>> 6.2.  Clients
>> 
>> restrictions that prevent a Web application running from one origin
>> from obtaining data retrieved from another origin. However, XHR
>> presents some limitations on the headers that can be set by the
>> user.
>> 
>> In browser open standards with non HTTP transport:  For
>> applications written in JavaScript within a browser client.
>> Examples include BWTP and WebSockets.
>> 
>> In browser with plugin:  This is not of particular interest to
>> IETF, but should be noted as part of the design space.  Examples 
>> include BlazeDS.
>> 
>> Non-browser HTTP:  A bidirectional client may be written outside of
>>  a browser and use bidirectional web transports.  Typically this is
>> balancers, etc) can be involved in bidirectional transport in 
>> several capacities:
>> 
>> Legal HTTP relay:  Transports such as long polling use 
>> intermediaries to carry legal HTTP requests and response.  Any
>> capabilities that may interfere with bidirectional flow (e.g.
>> caching) are controlled with standard headers or cookies.  The
>> intermediary may be a participant in the transport (e.g., changing
>> framing or encapsulation).
>> 
>> Tunneled relay:  Uses (or abuses?) the CONNECT mechanism to
>> simulate an SSL connection to be used as a tunnel for a non-HTTP 
>> transport.
>> 
>> 
>> 
>> 
>> [W3C.WD-XMLHttpRequest2-20090820] Kesteren, A., "XMLHttpRequest
>> Level 2", World Wide Web Consortium WD WD-XMLHttpRequest2-20090820,
>> August 2009, 
>> [W3C.WD-cors-20090317] Kesteren, A., "Cross-Origin Resource
>> Sharing", World Wide Web Consortium WD WD-cors-20090317, March
>> 2009, <http://www.w3.org/TR/2009/WD-cors-20090317>.
>> 
>> [W3C.WD-eventsource-20090423] Hickson, I., "Server-Sent Events",
>> World Wide Web Consortium WD WD-eventsource-20090423, April 2009, 

-- 
*******************************************************************
Stefano Salsano
Dipartimento Ingegneria Elettronica
Universita' di Roma "Tor Vergata"
Via del Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770  (Fax.) +39 06 72597435
*******************************************************************

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 12 Oct 2009 18:43:03 -0500

Hi Sal,

> a much more specific text for the "right here and now, HTTP

That would make more sense.  That will help us move on the problem that has greater urgency.  

Obviously, it will take some time for us to reach consensus on certain aspects of the long term solution [c.f. multiplexing discussion].

--Martin

---

From: Graham Klyne <[email-masked]>
Date: Tue, 13 Oct 2009 10:28:11 +0100

> Graham, it would be great if you could briefly describe

Primarily event delivery for real-time control and monitoring.  A few more notes 
are here: http://code.google.com/p/webbrick-events/wiki/EventModel.

Also, as noted there, providing notification that data has changed so that web 
pages can refresh themselves.

These applications are essentially channel-free, being more 
datagram/message/event oriented than session oriented, using some kind of global 
identifier space (e.g. URIs) for disambiguation where needed.

I'm also in conversation with the Wookie Widgets team 
(http://getwookie.org/Welcome.html) for another project I'm working on 
(http://code.google.com/p/shuffl/).

> of many parts that originally were not designed to work together?

No, I'm not, but I'm also prepared to consider using multiple TCP connections in 
such circumstances.  Typically, I've seen requirements to put up to about 5 
different semi-independent widgets on a page.

I fully accept that your mileage may vary here.

Also, I seem to recall there was some IETF work on congestion control that could 
  reduce some of the problems with running multiple TCP channels ...

[Googling...]
http://tools.ietf.org/html/rfc2914
http://tools.ietf.org/html/rfc2481
http://tools.ietf.org/html/rfc4336
http://tools.ietf.org/html/rfc3124

I think the last one is the one I recall.

> that might aggregate multiple connections into a single connection?

No I'm not, but any transparent proxy that does that must surely ensure that 
multiple connections still appear to the application as independent connections, 
or it's fundamentally broken.  I think that such multiple connection tunneling 
might be the right way to go.  I could imagine server-to-server BEEP being used 
to tunnel multiple WebSocket sessions over a single connection - and here, the 
complexity of BEEP might be justified.

> the explicit life cycle events of the websocket API.

I guess that I'm not convinced that you can make multiplexing much simpler than 
BEEP and not end up being broken.  When I reviewed BEEP a few years back, I 
thought about trying to avoid the complexities of per-channel flow control, but 
in the end I couldn't see any way of doing that without running the risk that 
one channel could starve all the others.  But with per-channel flow control 
comes the need for some quite complex buffering arrangements.

> Thus applications and/or frameworks will be doing explicit connection

Hmmm... in principle, I understand that HTTP can be run over any full-duplex 
connection.  I see nothing in WebSockets that prevents similar behaviour.

> abstraction on top of XHR.

While I can agree that the XHR interface is too low-level, and that there are 
better abstractions, and I could agree that the API makes it harder to multiplex 
on a connection, I don;t see anything in the API that actually makes such 
multiplexing impossible.

Also, I haven't really studied a WebSocket API as such - I have looked at a 
protocol spec.  I might agree that an API design should not make it hard to 
multiplex, but that's a different question to what I understood to be under 
discussion here.

> connections - perhaps with multiplexing or perhaps without.

These are reasonable points, but see above my comments of API vs protocols.

I can also see that there may be aspects of the protocol I've not noticed that 
make such abstraction harder, and which can be fixed relatively cheaply.  (I'm 
thinking of examples like the original FTP protocol being hard to run through 
NAT - not that I claim that's a good example of desirability).

#g

---

From: Ian Hickson <[email-masked]>
Date: Tue, 13 Oct 2009 23:33:31 +0000 (UTC)

On Sat, 10 Oct 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> >
> > FWIW, so far I've concluded (based on long discussions with a number 
> > of developers and implementors) that multiplexing would actually not 
> > be that great. It could probably only be used for multiplexing to a 
> > single websocket path, without making the handshake highly asymmetric 
> > or breaking the HTTP compatibility. If it's intended for per-client 
> > multiplexing, it can easily be implemented at the application layer, 
> > where a much better job can be done that could be done at the protocol 
> > layer. If it's intended for multiclient multiplexing, then it's only 
> > helping server load, not client performance, and server load isn't 
> > especially an issue here.
> 

Why would it be an issue? Anyone who is expecting high levels of load 
would presumably just use a platform on which TCP connections are cheap, 
just as they do today with HTTP.

---

From: Ian Hickson <[email-masked]>
Date: Tue, 13 Oct 2009 23:35:32 +0000 (UTC)

On Sat, 10 Oct 2009, Infinity Linden (Meadhbh Hamrick) wrote:
>
> the problem i have with doing addressing for multiplexing channels on a 
> single connection in the application layer is that it effectively 
> distinct channels. i do agree that doing multiplexing in the application 
> layer is much more flexible and for many deployments "this is a good 
> thing." does it make sense to have a multiplexing option in the protocol 
> that can be used by people who want their intermediaries to understand 
> this sort of thing, but not make it mandatory? that way i could hire 
> someone to hack squid to recognize and cache multiplexed reverse 
> responses and people who want to do something more flexible at the app 
> layer can still do it.

I don't understand the use case wherein one would ever want caching at the 
Web Socket layer. Could you expand on this?

If there are specific application level protocols layered on top of Web 
Socket that could benefit from caching, then nothing stops intermediaries 
from understanding that sub-protocol, including any multiplexing it might 
itself support.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 14 Oct 2009 10:44:23 +1100

> from understanding that sub-protocol, including any multiplexing it might 

Ian,

you often cite "protocols layered on top of Web Socket" as a panacea.

While layered protocols are theoretically possible (and even
desirable), I do not see that websocket is being setup in a way
to make this practically possible.

So can you describe how you foresee such protocols being layered
on top?

If you think this can be done in javascript libraries, then how
do you see multiple frames, tabs and windows being handled in
a secure way?

If your vision of the server side occurs - where developers write
websocket implementations themselves (like CGI scripts), then
are they going to have to all write these layered protocols as well?

regards

---

From: Ian Hickson <[email-masked]>
Date: Wed, 14 Oct 2009 00:00:45 +0000 (UTC)

On Mon, 12 Oct 2009, Greg Wilkins wrote:
> > be that great.

A number of people from various teams at Google and Mozilla in person, and 
also on IRC with people from other browser vendors and Web authors who 
participate in the WHATWG work.

> So far the majority of opinions I've seen on this list and the whatwg 
> list have been favourable to multiplexing.

I don't think that's entirely accurate. Don't forget, also, that since the 
spec doesn't have multiplexing, people who don't want multiplexing aren't 
likely to post... Just like you haven't been posting in favour of the spec 
not supporting DRM.

> Can you invite them to post their opinions here?

I do so, yes. That they don't is why I go and seek them out. :-)

> > However, WebSocket connections are long lived by design,
> 
> I do not believe you can anticipate websocket usage over the long term.  
> Just because you think now they will only be used for long lived 
> connections, that may not always be the case.

Well using Web Socket for a short request-response burst would be pretty 
stupid (given HTTP)... What other uses do you have in mind?

While we can't know what the protocol will be used for, we _can_ know what 
it is _intended_ to be used for, and that's what we should optimise for. 
We don't have to preclude other uses, but we also don't have to optimise 
for them... especially at the cost of the intended uses.

> It is short sighted to build such limitations into a once-in-a-decade 
> chance to upgrade the protocols we use on the web.

This is not a once-in-a-decade chance.

> > and the cost of setting up a connection therefore is insignificant 
> > compared to the cost of the protocol itself.
> 

This would be the same cost associated with maintaining and servicing a 
channel in a multiplexed connection.

> > critically important notification, it would be best if the latter 
> > could avoid getting throttled along with the first.
> 
> instead of 1, then you are more likely to get better service from a 
> router that is fair sharing capacity among connections.  That path leads 
> to an irrational arms race as once everybody uses 8 connections, 
> Implementing connection policies is not something that should be left to 
> the application developer. It is far far better that the browsers 
> implement connection control policies.

I disagree. I think it's far better that the _server_ decide the 
connection control policies. That's the model Web Sockets follows (as an 
author you'll do whatever the server expects).

> > As with anything, though, there's always the option of changing this 
> > if strong arguments one way or the other are put forward. We can also 
> Protocol versions come once maybe twice a decade.  Please consider the 
> future and not just short term needs of one particular interest group.

I see no reason why we can't rev it more often. If you are basing this on 
the stagnation of 1998-2008, then I think you are misinterpreting the 
events.

On Tue, 13 Oct 2009, Greg Wilkins wrote:
> can be automatic.

Multiplexing at the per-path level would be of extremely limited use, 
IMHO. If there really are multiple widgets talking back to the same 
_server_, they certainly won't be talking back to the same _path_.

> The difficulty is that with websocket protocol, it has a hard binding to 
> the application websocket API.  There is no scope provided to inject 
> should be mapped to channels), but that are currently mapped to 
> connections. Thus applications and/or frameworks will be doing explicit 
> connection management.

Sure. You just build a library on top of this. It's not a problem as far 
as I can tell.

> But even if the frameworks implemented to same wire protocol for 
> multiplexing, they would not be able to:
> 

Even with multiplexing we wouldn't be able to share connections between 
server-side frameworks -- why would someone use two client-side frameworks 
but the same server-side framework?

>   + share connections with code written directly to the websocket API.

That's basically just another framework.

>   + share connections with other iframes, tabs and/or windows.

This seems far too infrequent an occurrance to really optimise for.

>   + implement a strong origin policy for security

I don't understand what situation would lead to multiple channels having 
different origins but talking to the same server with the same 
authentication cookies and the same path.

> The fundamental problem with websocket API is that is both a connection 
> API (open/close) and a messaging API (send/onMessage). The API needs to 
> be abstracted away from any hard relationship to TCP/IP connections.  
> This can be done with a simple rename of s/connection/channel/.  
> Applications can then manage channels and the browser/server can manage 
> mapping those channels to connections - perhaps with multiplexing or 
> perhaps without.

This seems far too abstract, frankly.

At this stage my recommendation if you think multiplexing is important 
would be to propose an alternative protocol and get browser vendor buy-in 
for that protocol. Browsers haven't committed to implementing Web Sockets 
yet (though some are experimenting with it), so now would be the best time 
to see if you can convince them that it is preferable to have that support 
in the protocol rather than layered on top of it.

Personally the more I think about what one would have to do to implement 
multiplexing at the Web Sockets level the more I am convinced that it's 
simply not worth it. It would easily double or even triple the complexity 
of the wire protocol, and it would add very little for authors.

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 14 Oct 2009 01:15:30 +0100

Graham Klyne wrote:
> datagram/message/event oriented than session oriented, using some kind of 
> global identifier space (e.g. URIs) for disambiguation where needed.

That *is* multiplexing.

There is some confusion about what multiplexing is about.  It
has nothing much to do with sessions.

I think this is what multiplexing (in BWTP etc.) is about:

  - Multiplexing is about delivering messages to addressable targets.

  - Messages that cannot be received or processed immediately should
    not block reception of other messages which _can_ be received
    immediately.

  - Large messages should be usable, without blocking small messages
    for a long time.

  - So that multiple message sources and targets can share TCP/IP
    connections efficiently and easily.  (And eventually, to do the
    same over SCTP/IP which is theoretically a better fit).

Multiplexing is *not* about:

  - Establishing lots of byte sessions or channels (whatever you want
    to call them), although that could be an optional additional feature.

The reason multiplexing protocols talk about channels is:

  - So that messages can be transmitted without blocking all
    other messages.  The protocol creates a channel for *every*
    (unordered) message, so they can be transmitted in parallel
    according to optimal transport strategies.

The reasons for parallelism are:

  - To allow large messages alongside smaller messages without blocking
    everything.

  - To allow message sinks (receivers) to continue receiving messages
    while other sinks are not in a state ready to receive or process
    more messages.

I think that's confusing matters, because channels of a kind are
involved in the protocol, but they are used primarily to allow
independent messages to flow efficiently, and don't need to be visible
above the protocol layer.

There are uses for channels visible to applications too, but
multiplexing is not especially about that.

> No, I'm not, but I'm also prepared to consider using multiple TCP 
> connections in such circumstances.  Typically, I've seen requirements to 
> put up to about 5 different semi-independent widgets on a page.

I've seen 3000. :-) Of course it's always possible to rewrite code so
it works differently.  But that seems opposite to one of the design
goals: to make it easy for independent application implementor tbo
send messages between their components.

> I could imagine server-to-server BEEP being used to tunnel multiple
> WebSocket sessions over a single connection - and here, the

BEEP is a poor fit for this.  We've looked at the details.

It appears to be faster to multiplex messages over HTTP long-polling
than over BEEP under some circumstances.

BEEP is connection-oriented, and has expensive connection setup, which
makes it quite unsuitable for sending independent messages to
independent targets without blocking.

> I guess that I'm not convinced that you can make multiplexing much simpler 
> than BEEP and not end up being broken.  When I reviewed BEEP a few years 
> back, I thought about trying to avoid the complexities of per-channel flow 
> control, but in the end I couldn't see any way of doing that without 
> running the risk that one channel could starve all the others.  But with 
> per-channel flow control comes the need for some quite complex buffering 
> arrangements.

You do need flow control, and yes buffering can be tricky.

I would say per-message flow control, rather than using pre-assigned
channels, if you have no need of channels.  I regard BWTP's channel
creation exchange as a weakness if you must use it.

But here's the mistake: If there isn't flow control in the protocol,
you _must_ implement flow control and buffering in another layer
instead - or get the problems you'd expect.

In WebSockets discussions, flow control tends to be *hidden* in things
like unspecified DOM event queue behaviour's relationship with the
TCP/IP socket.

For example, if a web browser receives hundreds of WebSocket frames of
different sizes before the Javascript can process the corresponding
DOM events, at what point does the browser stop reading from the
TCP/IP socket?  Does it ever stop reading, or does it lead to
out-of-memory conditions on some clients if the server is transmitting
faster than the client script is reading?

If a browser implementation of WebSockets _does_ make use of TCP/IP
flow control by stopping reading from a socket when it has too many
queued DOM events, what happens when a Javascript target is ready for
events to most targets, but cannot process events to one addressable
target right away because that target is busy?  Does it freeze the
whole web page until that single target can process the messages
queued to it, or does it use unbounded memory reading messages for
that single target so that other targets can receive messages?

That is more pertinent now that events can be sent to background
threads in web pages in modern browsers, but it's always been an issue
when some events cause large, slow page updates, while others are
small and should be processed at speed.  The current situation does
not handle that very well.

Generally, at the present time as far as I can tell, typically every
message must be fully processed as soon as it's available, before
moving to the next message.  The concept of targets which aren't ready
to receive a message hardly exists in current web applications, but
it's common in other applications.

In other words - _someone_ implements flow control, or there is no
flow control and memory usage is unbounded in clients, or flow control
is very coarse: every message must be processed fully before the next
message, even to independent targets.

There is no escape from that.

> Hmmm... in principle, I understand that HTTP can be run over any 
> full-duplex connection.  I see nothing in WebSockets that prevents similar 
> behaviour.

WebSockets cannot carry binary frames in any current or anticipated
implementation, so implementing HTTP over it isn't possible at
present, without first encoding the content into UTF-8 (plus escaping
NUL bytes).

> While I can agree that the XHR interface is too low-level, and that there 
> are better abstractions, and I could agree that the API makes it harder to 
> multiplex on a connection, I don;t see anything in the API that actually 
> makes such multiplexing impossible.

Not impossible, but somewhat tricky to do well.  See above - flow
control has to go somewhere, although it's easy to ignore the need and
just get unreliable or tighly-coupled behaviour.

-- Jamie

---

From: Ian Hickson <[email-masked]>
Date: Wed, 14 Oct 2009 00:40:11 +0000 (UTC)

On Wed, 14 Oct 2009, Greg Wilkins wrote:
> While layered protocols are theoretically possible (and even desirable), 
> I do not see that websocket is being setup in a way to make this 
> practically possible.
>
> So can you describe how you foresee such protocols being layered on top?

I don't really see any way to use WebSockets _except_ by layering a 
protocol on top of it.

Now for many people such protocols would be trivial, e.g. just a "you have 
new mail" notification, but that's still a protocol. For some, e.g. a chat 
program, one could imagine a huge protocol on the order of complexity of 
Jabber -- in fact, it could be Jabber itself, ported to Web Sockets.

> If you think this can be done in javascript libraries, then how do you 
> see multiple frames, tabs and windows being handled in a secure way?

Using Shared Workers, if that is really desired. Frankly though I don't 
think that multiple frames, tabs and windows are likely to all be 
connecting to the same Web Socket service on the same host, at least not 
enough to justify worrying about multiplexing, so it's not high on my list 
of concerns.

> websocket implementations themselves (like CGI scripts), then are they 
> going to have to all write these layered protocols as well?

How else can you use Web Sockets?

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 14 Oct 2009 13:56:10 +1100

Ian Hickson wrote:

> for that protocol.

which is exactly what I'm trying to do with BWTP.

but I do wish to understand your view point and what has influenced
your design decisions with websocket.     So while I appear to
disagree with you on many things, I do appreciate you taking the
time to argue your point of view and explain your reasoning.

As a result or your comments and others, the BWTP proposal has
already been greatly improved and hugely simplified.

I am entirely convinced that either a reasonable simple extension
to websocket or something like a refined BWTP is possible as a reasonable
compromise between the different points of view.

> stupid (given HTTP)... What other uses do you have in mind?

Which is why having a websocket be associated with 1 and only 1
server side resource is a problem.    A client may be interested
in many event sources from a server, but each might only exist
(or be of interest) for a short period of time.

Sure it is possible to create an aggregating resource to avoid
having to have multiple short lived connections to each real
resource as it comes and goes.... but only if all the resources
are from the same application/framework/development.

Making multiplexing a transport concern means that applications
and frameworks do not need to consider connection efficiency
when designing their event streams.

> This is not a once-in-a-decade chance.

I hope you a right.  But still no reason to not try to get it
right as possible in the next iteration.

> channel in a multiplexed connection.

Sorry but this is just wrong.

Both approaches need the application end point for the channel
and all its associated resources.

But only the multiple TCP/IP connection approach needs additional
kernel space buffers, file descriptors and larger select sets etc.

The key difference is that with multiple TCP/IP connections, the
server has to undertake to read a windows worth of data on each
of those connections.   With a multiplexed solution, only a single
window needs to be read before back pressure is asserted and
the flow of additional data slowed to match the rate of consumption.

> author you'll do whatever the server expects).

How can a server influence the connections that a client opens, other
than to refuse excess ones.   That is pretty course grained "control"

> _server_, they certainly won't be talking back to the same _path_.

If by path, you mean server side resource or URI, then I'm definitely
saying that we should be able to multiplex multiple paths over the
same TCP/IP connection.

HTTP is not limited to get the same URI over the same connection, so
why should websocket or similar?

> but the same server-side framework?

Because multiplexing should be built into the transport and will not
rely on a server side framework.

Currently HTTP requests get delivered to the appropriate server side
resource without the server-side framework or developer being at
all aware of what connection(s) were used.

why must routing of messages between client side components
and server side components be tied to a TCP/IP connection.  The
path is identified by a URL and neither the client nor server
should care if a dedicated or shared TCP/IP connection is used.

> That's basically just another framework.

except that it is one that you into which cannot easily insert
additional layered protocols.    Let's say RFC66666 comes out which
is the universally agreed best way to multiplex messages on top
of your proposed websocket protocol. How are you going to get
an implementation of that inserted into every direct usage of
the websocket API?

> This seems far too infrequent an occurrance to really optimise for.

Hello????  Do you ever use a browser????   Are you telling me you
have never opened two tabs/windows to the same website either
accidentally or on purpose???

One of the keen users of this technology that I have encountered
is traders, who habitually have 3 huge screens on their desks with
umpteen windows to their trading applications, all with slightly
different view.

> authentication cookies and the same path.

It is entirely plausible that a service might publish events, some
of which are only for code from the same origin and others are either
for code from any origin or from a specific set of origins.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 14 Oct 2009 14:01:14 +1100

Ian,

if multiplexing is supported, then sharing a TCP/IP connection does not
mean they are connected to the same service on the same host.

It only means they are connected to the same host (or proxy).

But imagine that you have a share trading application and that you
have multiple portfolios.   It is entirely plausible that you want
to watch each live portfolio in it's own window/tab/frame.

These may or may not talk to the same server resource (depending on
design, as each portfolio may be given it's own resource).  Why
shouldn't these windows share a TCP/IP connection?  They do so
for their normal content.

regards

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 09:14:09 +0200

> just as they do today with HTTP.

My feeling is that whatever the server architecture is, many connections 
per user are always worse than a single one.

I also doubt that, in case the choice of platform *is* relevant here, 
all server developers always will actually have the choice.

So, for clarity, it would probably be good to state in the draft that 
this question was considered not to be an issue.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 12:07:54 +0200

> participate in the WHATWG work.

If those people do not plan to participate over here, but *do* influence 
the spec, then it appears this is a candidate for an Informational RFC, 
not the standards track.

BR, Julian

---

From: "Michael(tm) Smith" <[email-masked]>
Date: Wed, 14 Oct 2009 19:21:05 +0900

Julian Reschke <[email-masked]>, 2009-10-14 12:07 +0200:

>  If those people do not plan to participate over here, but *do* influence the 
>  spec, then it appears this is a candidate for an Informational RFC, not the 
>  standards track.

Could you elaborate on bit on why that's the case? And/or provide
a URL for the relevant process document where it's explained?

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 13:10:30 +0200

> a URL for the relevant process document where it's explained?

The process document is RFC 2026.

What I wanted to point out is that if there's a desire to make web 
sockets a deliverable of this WG-to-be, the discussions about it should 
actually take place on the WG's mailing list.

BR, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 14 Oct 2009 13:50:44 +0200

>a URL for the relevant process document where it's explained?

In addition to The Internet Standards Process (BCP 0009, RFC 2026,
http://tools.ietf.org/html/rfc2026) you are looking for The Tao of
IETF (FYI 0017, RFC 4677, http://tools.ietf.org/html/rfc4677) and
there in particular section five, and their references like IETF
Working Group Guidelines and Procedures (BCP 0025, RFC 2418). They
won't answer your question, but help you understand why you asked it.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ian Hickson <[email-masked]>
Date: Wed, 14 Oct 2009 12:03:56 +0000 (UTC)

On Wed, 14 Oct 2009, Julian Reschke wrote:
> What I wanted to point out is that if there's a desire to make web sockets a
> deliverable of this WG-to-be, the discussions about it should actually take
> place on the WG's mailing list.

The Web Sockets API and protocol is a joint effort of the Web Apps WG in 
the W3C, the WHATWG, and this mailing list. Input is going to come from 
many places, including all those, as well as blogs, IRC, etc.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 14:02:31 +0200

> many places, including all those, as well as blogs, IRC, etc.

So how do you guarantee that all input that you take follows the IETF 
IPR rules? <http://www.ietf.org/about/note-well.html>

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Wed, 14 Oct 2009 12:29:16 +0000 (UTC)

On Wed, 14 Oct 2009, Julian Reschke wrote:
> > 
> > The Web Sockets API and protocol is a joint effort of the Web Apps WG 
> > in the W3C, the WHATWG, and this mailing list. Input is going to come 
> > from many places, including all those, as well as blogs, IRC, etc.
> 

Unless I'm mistaken, the IETF does not have a policy of ignoring feedback 
that comes from outside the IETF, so I don't see why the above would make 
this difficult. Did you have a specific rule in mind?

(It would be pretty stupid to ignore outside feedback!)

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 14:49:07 +0200

> (It would be pretty stupid to ignore outside feedback!)

Yes it would.

One good compromise is to report the outside feedback on the WG's 
mailing list, and to continue to discuss over there.

A bad approach is to say "I got outside feedback to do it that way, and 
that's what I'm doing. Take it or leave it". (Note: I'm not saying you did)

BR, Julian

---

From: SM <[email-masked]>
Date: Thu, 15 Oct 2009 11:10:25 -0700

>(It would be pretty stupid to ignore outside feedback!)

You are missing the point of Julian Reschke's message.  The contents 
of this message should not be considered as legal advice.

The process is covered by BCP 9 and a few other 
RFCs.  "Contributions" posted to the IETF mailing lists are subject 
to BCP 78 and BCP 79.  It is up to the authors to see that their 
Internet-Drafts are in full conformance with the provisions of BCP 78 
and BCP 79.

Regards,
-sm

---

From: Ian Hickson <[email-masked]>
Date: Sat, 17 Oct 2009 02:34:47 +0000 (UTC)

On Wed, 14 Oct 2009, Greg Wilkins wrote:
> >> lived connections, that may not always be the case.
> > 
> > Well using Web Socket for a short request-response burst would be 
> > pretty stupid (given HTTP)... What other uses do you have in mind?
> 
> Which is why having a websocket be associated with 1 and only 1 server 
> side resource is a problem.  A client may be interested in many event 
> sources from a server, but each might only exist (or be of interest) for 
> a short period of time.

Then the author really should just combine the event sources into one (or 
use the EventSource feature, which is probably more appropriate for this 
use case anyway). I certainly don't think we should be optimising this 
protocol for brief sessions, that would just encourage people to use it 
for that purpose. It performs much better with long-lived sessions.

> Sure it is possible to create an aggregating resource to avoid having to 
> have multiple short lived connections to each real resource as it comes 
> and goes.... but only if all the resources are from the same 
> application/framework/development.

Could you describe the scenario in which you imagine an application 
needing multiple two-way communication channels one after the other, each 
for short periods of time, each with a different server-side development 
team? I'm not really seeing the use case here.

> > Even with multiplexing we wouldn't be able to share connections 
> > between server-side frameworks -- why would someone use two 
> > client-side frameworks but the same server-side framework?
> 

You are assuming monolithic servers like Apache, with multiple frameworks 
plugged into those servers. I'm imagining 100-line perl scripts. While we 
have such differing goals, I don't think we can come to an agreement on 
this. I want the protocol to be so simple that the frameworks are 
unnecessary; that if they are used, they would be the ones implementing 
the entire protocol on the server-side. In this world, there is no server 
to handle the multiplexing across multiple frameworks.

> Making multiplexing a transport concern means that applications and 
> frameworks do not need to consider connection efficiency when designing 
> their event streams.

If the channels are multiplexed, then we're assuming that the server-side 
is an "aggregating resource" as you put it. If it's possible to use an 
aggregating resource with a multiplexed connection, then why would it not 
be possible to do it with a Web Socket connection? I don't understand.

> I hope you a right.  But still no reason to not try to get it right as 
> possible in the next iteration.

Sure, so long as we don't sacrifice something else for perfection (such as 
time-to-market or simplicity of implementation).

> > This would be the same cost associated with maintaining and servicing 
> > a channel in a multiplexed connection.
> 
> The key difference is that with multiple TCP/IP connections, the server 
> has to undertake to read a windows worth of data on each of those 
> connections.  With a multiplexed solution, only a single window needs to 
> be read before back pressure is asserted and the flow of additional data 
> slowed to match the rate of consumption.

Servers already have to deal with multiple connections per user, for HTTP. 
I do not see how WebSocket makes things worse.

If your OS' kernel is badly optimised such that multiple connections are 
expensive, then instead of changing the protocol, fix the kernel. That way 
it'll also work better for multiple IMAP connections, multiple Jabber 
connections, multiple HTTP connections, etc.

> >> Implementing connection policies is not something that should be left 
> >> to the application developer. It is far far better that the browsers 
> > connection control policies. That's the model Web Sockets follows (as 
> > an author you'll do whatever the server expects).
> 

You don't need any finer grain control. You provide a service, and you 
provide the terms of service. If an author violates those terms of service 
(e.g. opening multiple connections instead of using a shared worker), then 
you terminate his connection, so that his app fails. His users will then 
exert pressure on the author to fix his app. There is no greater pressure.

> >> But multiplexing can be much much simpler.  At it simplest, it just 
> >> needs a channel id in each frame and the channel creation can be 
> >> automatic.
> > 
> saying that we should be able to multiplex multiple paths over the same 
> TCP/IP connection.

That would be incompatible with the goal of sharing the port with an HTTP 
server, since that requires the path name to be given up front.

> HTTP is not limited to get the same URI over the same connection, so why 
> should websocket or similar?

I assume it is a given that you would want a protocol to have the property 
that connecting with path A, then opening a channel for path B, should 
result in a connection with the same internal state as connecting with 
path B, then opening a channel for path A.

Given the HTTP Upgrade mechanism whereby an HTTP server can have a 
WebSocket script assigned to each path, you can end up in a situation 
where connecting to A and connecting to B establish connections with 
different server-side scripts.

Then, opening the other channel would not have the desired effect, as the 
HTTP process wouldn't be involved anymore.

> why must routing of messages between client side components and server 
> side components be tied to a TCP/IP connection.  The path is identified 
> by a URL and neither the client nor server should care if a dedicated or 
> shared TCP/IP connection is used.

The entire purpose of Web Socket is to provide a TCP connection to 
JavaScript. That's the goal.

> additional layered protocols.  Let's say RFC66666 comes out which is the 
> universally agreed best way to multiplex messages on top of your 
> proposed websocket protocol. How are you going to get an implementation 
> of that inserted into every direct usage of the websocket API?

The same way you got Web Socket use in the first place -- by writing it. 
Unless RFC66666 is more complicated than Web Sockets itself, it wouldn't 
be much of a burden.

> Hello????  Do you ever use a browser????  Are you telling me you have 
> never opened two tabs/windows to the same website either accidentally or 
> on purpose???

For sites that want to support this use case, we have shared workers.

> One of the keen users of this technology that I have encountered is 
> traders, who habitually have 3 huge screens on their desks with umpteen 
> windows to their trading applications, all with slightly different view.

Sure, and such systems would use shared workers. There's far more state 
that they'll want to share here than just the TCP connection -- common 
client-side database backends, common UI state, etc.

> > I don't understand what situation would lead to multiple channels 
> > having different origins but talking to the same server with the same 
> It is entirely plausible that a service might publish events, some of 
> which are only for code from the same origin and others are either for 
> code from any origin or from a specific set of origins.

Given the sensitivity of this kind of thing, I would feel _very_ 
uncomfortable relying on authors getting the server-side of this right, 
and even less comfortable relying on proxy implementings getting the proxy 
side of this right. I'd much rather have different connections for each 
origin, so that we can rely on the user agent to get this right. There are 
far fewer of them and they get more QA.

---

From: Martin Tyler <[email-masked]>
Date: Sat, 17 Oct 2009 09:54:34 +0100

> to handle the multiplexing across multiple frameworks.
Could you explain why you are 'imagining' this? It's not how things are done
now, so why do you think server side development is going to suddenly
totally change just because WebSocket is available?

Are these multiple 100 line scripts all going to be separate processes
listening on separate ports on the same server? This just doesn't sound
likely at all.

I'm imagining server side APIs that wrap this up for you, handling the
multiplexing if we go down Gregs route, but even if not you still want
something to handle the protocol for you. It would be nice if there could be
a single server side API, but that is unlikely due to the number of server
side technologies and frameworks - but something fairly consistent could be
developed.

I really don't get this 11 year olds writing perl scripts idea - have you
explained the reasons, use cases, benefits etc of this?

---

From: Ian Hickson <[email-masked]>
Date: Sat, 17 Oct 2009 09:37:40 +0000 (UTC)

> this question was considered not to be an issue.

I don't think it's not an issue. It's an issue like many others. I'm not 
going to start listing all the things that were considered in the design 
of the protocol, that'd just be a massive list of things.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Oct 2009 11:38:50 +0200

> client performance, and server load isn't especially an issue here.

So it appears that you aware of that drawback, but chose not to address 
this. I still think it would be helpful to document that.

BR, Julian

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 17 Oct 2009 19:39:16 -0700

Ian Hickson wrote:

> use the EventSource feature

But there might not be 1 author!   Mash-ups and portals and such things
will combine the work of many authors unknowingly onto the same page.
We want to encourage reuse of components and not require every webapp
to be rewritten from scratch with a shared messaging infrastructure.

> team? I'm not really seeing the use case here.

Consider the google home page.  This can be customized with lots
of widgets from third parties.

Imagine the same sort of site, but fronting an organization with
lots of real time data. A stock trading site for example.

They may allow a user to populate their pages with widgets supplied
by third parties that may perform all sorts of trading analysis,
monitoring and trading.   I widget may establish "connections" to:

    + receive live price information
    + monitor the state of orders placed
    + interact with others in a process to create a
      complex instrument, swap etc.

These "connections" may be short or long lived (who
knows how long an order might take to complete).

For scalability of the service, you don't want every
widget to be given it's own TCP/IP connection.  Even
if you can handle the load, it is an unfair allocation
of server resources to give more to those with more
widgets on their desktops

These widgets should all multiplex onto the same
TCP/IP connection per user.

Of course the organization could provide a js framework that
did that multiplexing - but widget developers would be highly
unlikely to use it.

If they use websocket directly, then the code they write can
access the service both in the portal site and from other sites
that don't have the framework. Plus if they don't use the framework,
they get their own dedicated TCP/IP connection and they will get
some latency/performance benefits of other widgets that are sharing
a connection.  Of course this creates an arms race as it only
works if everbody else is sharing. Soon all widgets will be
using their own dedicated connection, then each widget would
start opening multiple dedicated connections (eg 1 per share),
trying to get more and more resources allocated.

Developers and resources are like 3 years olds and toys!
There is no such thing as optional sharing!

> have such differing goals, 
> ...
> In this world, there is no server

I really do not think you should be using your influence over the
websocket protocol to drive some agenda to revolutionize
server side development.

We cannot design a protocol that is only suitable for some
imagined future scenario.

Trying to enforce this future by making future protocols badly
support monolithic servers strikes me as some Orwellian mind
control exercise!

> be possible to do it with a Web Socket connection? I don't understand.

Because in the real world, we have one set of developers writing
servers and user-agents and another set of developers writing
applications that run on them.

The infrastructure developers impose all sorts of restrictions on
the application developers:

  + sharing CPU and memory with other users/processes.
  + sharing connection and network infrastructure
  + enforcing origin policies, security sand boxes etc.
  etc. etc.

In your brave new world,  there are no infrastructure developers,
only application developers.

In this world, the application developers will throw off the
infrastructure shackles imposed on them, because indeed a
dedicated TCP/IP connections is better than a shared one.
Cross domain development is so much easier without security
models etc. Better let them run as root as well, because
then they can open any port and up their priority to
stop sharing CPU.

There are really really good reasons why infrastructure
is developed for application developers.    Infrastructure
is not only to enable applications, but it is to constrain
them and to force them to share resources fairly and to
respect security models.

But there is absolutely no way that any responsible organisation
is going to deploy a system where sockets opened by applications
programmers are exposed directly to the internet and run
with ad-hoc protocol implementations.

> I do not see how WebSocket makes things worse.

Multiple connections are allowed for HTTP as a necessary evil to get
around the intrinsic latency of the request/response protocol that
does not support message fragmentation or out of order responses.

Even then HTTP is meant to restricted to 2 connections.
Stupidly Recent user-agents have engaged in exactly the sort of
arms race I have describe above... lets have 8 connections and we
are faster than the other guys... doh! they have 8 too, ok lets
have 16.... doh! 32!  ... doh!

> expensive, then instead of changing the protocol, fix the kernel. 

it's not bad optimization.   If you have 1 connection, you need 1 set
of buffers and when it is full you give back pressure on that
TCP connection.

If you have 10 connections, you need 10 sets of buffers and you have to
wait until you have received 10x the data from one user before you
apply back pressure.

The optimization you are looking for is to make that user share 1
connection instead of using 10!   There is no other way to optimize
away the buffer requirements!

> different server-side scripts.

How so.

I'm advocating abstracting developers away from connections.
Handler A will send/receive messages for path A
Handler B will send/receive messages for path B

Neither handler has any need to know if a shared connection was
used or not.

> JavaScript. That's the goal.

Really?  If it was, then why not just expose the real socket API?

Surely the aim is to establish bidirectional communication with the
server.  Whose to say that TCP/IP will be the favoured transport for
the entire life span of the applications using the websocket API?

In any case,  if the IETF is to endorse a new web protocol, I believe
that their charter is to consider more than just the needs of
javascript developers.

regards

---

From: Wellington Fernando de Macedo <[email-masked]>
Date: Sun, 18 Oct 2009 17:39:55 -0200

Hi,

I would like to make a contribution to this discussion. I think the ws
protocol is good as it is right now. But I think multiplexing is a
valuable feature. I don't like the BWTP proposal because I think it is
expensive. Considering the current protocol, I suggest we introduce
"channel handshakes", using another frame type. Each WebSocket object
instance would be associated with one channel. I don't intend to make
another proposal, so I will illustrate what I'm thinking using an
example and I hope it can be useful someway :)

1. Suppose there is already a established connection:

User agent

-------------

GET /ws/script1.php HTTP/1.1

Upgrade: WebSocket

Connection: Upgrade

Host: www.myhost.com

Origin: file://

CR LF

Server

-------------

HTTP/1.1 101 Web Socket Protocol Handshake

Upgrade: WebSocket

Connection: Upgrade

websocket-origin: file://

websocket-location: ws://www.myhost.com/ws/script1.php

CR LF

2. A normal exchange of data.

User Agent

--------------

0x00 ping 0xff

Server

--------------

0x00 pong 0xff

3. In the meanwhile the user agent has to open
ws://www.myhost.com/ws/script2.php. Then, using the same connection,
the user agent could use the 0x01 frame type as a way to perform the
"channel handshake". Also, the request must have a websocket-channel-id
header (containing a two bytes number value) which would identity the
channel.

User Agent

--------------

0x01 GET /ws/script2.php HTTP/1.1

Upgrade: WebSocket

Connection: Upgrade

Host: www.myhost.com

Origin: file://

websocket-channel-id: 1

CR LF 0xff

Server

-------------

0x01 HTTP/1.1 101 Web Socket Protocol Handshake

Upgrade: WebSocket

Connection: Upgrade

websocket-origin: file://

websocket-location: ws://www.myhost.com/ws/script2.php

websocket-channel-id: 1

CR LF 0xff

4. Since that, both channels could exchange data using a third frame
type (0x02), followed by the channel id. The initial channel could
still use the 0x00 frame type, however. For instance, a exchange of
data on the initial channel would be:

User Agent

--------------

0x00 ping 0xff

Server

--------------

0x00 pong 0xff

or

User Agent

--------------

0x02 0x00 0x00 ping 0xff

Server

--------------

0x02 0x00 0x00 pong 0xff

4. And a exchange of data on the new channel:

User Agent

--------------

0x02 0x00 0x01 ping 0xff

Server

--------------

0x02 0x00 0x01 pong 0xff

It is all.

Wellington.

---

Wellington Fernando de Macedo

Engenharia de Computação

Telefone: +55 (16) 8144.8607

Greg Wilkins escreveu:

Ian Hickson wrote:

How so.

regards

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 19 Oct 2009 21:56:37 +0300

we have just submit the "Design Space for Bidirectional protocols" draft

Abstract

   As technologies that enable bidirectional communication over HTTP
   have become more pervasive, interest has grown in (1) defining
   improved mechanisms for support of existing technologies (short-term
   solutions such as new HTTP headers) and (2) laying the foundation for
   development of new bidirectional protocols (long-term solutions such
   as WebSocket, Bidirectional Web Transfer Protocol, and Reverse HTTP).
   In order to provide context for such work, this document provides a
   first tentative map of the design space for bidirectional HTTP, with
   special attention to deployed infrastructure (e.g. web clients,
   intermediaries, firewalls, NATs, web servers) and programming
   environments.

you can find the draft here
http://www.ietf.org/id/draft-loreto-design-space-bidirectional-00.txt

cheers
Sal
www.sloreto.com

---

From: Ian Hickson <[email-masked]>
Date: Thu, 22 Oct 2009 12:01:04 +0000 (UTC)

On Sat, 17 Oct 2009, Martin Tyler wrote:
> > You are assuming monolithic servers like Apache, with multiple 
> > frameworks plugged into those servers. I'm imagining 100-line perl 
> > scripts. While we have such differing goals, I don't think we can come 
> > to an agreement on this. I want the protocol to be so simple that the 
> > frameworks are unnecessary; that if they are used, they would be the 
> > ones implementing the entire protocol on the server-side. In this 
> > world, there is no server to handle the multiplexing across multiple 
> > frameworks.
>
> Could you explain why you are 'imagining' this?

Because I think that it would result in a healthier ecosystem.

> It's not how things are done now, so why do you think server side 
> development is going to suddenly totally change just because WebSocket 
> is available?

It is how things are done now, for CGI scripts. It's not how things are 
done for HTTP servers.

I don't think server-side development will totally change, but I think 
that it will enable a class of development that simply isn't possible 
today. Imagine how the world might be different if instead of having to 
twist Apache to do your bidding, you could just as easily write your own 
fully-conforming replacement HTTP server in a weekend. Some of the world's 
biggest Web sites have a competitive advantage because they can afford to 
roll their own HTTP server highly optimised for their own setup. By having 
a simpler protocol, with Web Socket, that advantage will be available to 
anyone, not just those who can afford a development team dedicated to 
implementing the big spec.

> listening on separate ports on the same server? This just doesn't sound 

That depends on what the author wants to do. I expect most sites will only 
need one Web Socket server, which might service multiple URLs.

> something to handle the protocol for you. It would be nice if there 
> could be a single server side API, but that is unlikely due to the 
> number of server side technologies and frameworks - but something fairly 
> consistent could be developed.

Having a simple protocol doesn't preclude this.

Having a complex protocol requires it.

> I really don't get this 11 year olds writing perl scripts idea - have 
> you explained the reasons, use cases, benefits etc of this?

Simplicity is its own benefit.

On Sat, 17 Oct 2009, Julian Reschke wrote:
> > > So, for clarity, it would probably be good to state in the draft 
> > > that this question was considered not to be an issue.
> > 
> > I don't think it's not an issue. It's an issue like many others. I'm 
> > not going to start listing all the things that were considered in the 
> > design of the protocol, that'd just be a massive list of things.
> 

I also chose not to support per-message addressing, per-message 
out-of-band metadata, priority channels, compression, connection close 
handshakes, and Gopher compatibility. However, I don't think it's valuable 
for the spec to have a section discussing all the things it doesn't 
support, since that list is infinite.

On Sat, 17 Oct 2009, Greg Wilkins wrote:
> Ian Hickson wrote:
> 
> > Then the author really should just combine the event sources into one 
> > (or use the EventSource feature
> 
> will combine the work of many authors unknowingly onto the same page. We 
> want to encourage reuse of components and not require every webapp to be 
> rewritten from scratch with a shared messaging infrastructure.

I don't buy that these widgets will all be communicating with the same 
backend.

> > needing multiple two-way communication channels one after the other, 
> > each for short periods of time, each with a different server-side 
> > development team? I'm not really seeing the use case here.
> 
> Consider the google home page.  This can be customized with lots of 
> widgets from third parties.

If the widgets are from third parties, then they wouldn't all talk back to 
the same server.

If the widgets are all talking back to the same server, then the server 
provider can also provide a common library that channels all communication 
over a single socket. Consider widgets used on sites like Yahoo! and 
MySpace, based on Caja -- they wouldn't allow direct access to WebSocket 
at all, and would channel everything through a single socket. This allows 
them to control the multiplexing.

> Imagine the same sort of site, but fronting an organization with lots of 
> real time data. A stock trading site for example.
> 
> They may allow a user to populate their pages with widgets supplied by 
> third parties that may perform all sorts of trading analysis, monitoring 
> and trading.  I widget may establish "connections" to:
> 
> These "connections" may be short or long lived (who knows how long an 
> order might take to complete).
> 
> For scalability of the service, you don't want every widget to be given 
> it's own TCP/IP connection.

Indeed -- and you wouldn't. You'd provide a shared worker that handled the 
connection management and which multiplexed all your messages for you, in 
a manner that makes the most sense for this site.

> Of course the organization could provide a js framework that did that 
> multiplexing - but widget developers would be highly unlikely to use it.

I don't see why. I think it's in fact far more likely that they'd use a 
provided library than try to reverse-engineer the site's protocol.

> If they use websocket directly, then the code they write can access the 
> service both in the portal site and from other sites that don't have the 
> framework. Plus if they don't use the framework, they get their own 
> dedicated TCP/IP connection and they will get some latency/performance 
> benefits of other widgets that are sharing a connection. Of course this 
> creates an arms race as it only works if everbody else is sharing. Soon 
> all widgets will be using their own dedicated connection, then each 
> widget would start opening multiple dedicated connections (eg 1 per 
> share), trying to get more and more resources allocated.
>
> Developers and resources are like 3 years olds and toys! There is no 
> such thing as optional sharing!

I disagree with your pessimism here. I think there is ample evidence that 
people are happy to use JS libraries to talk to services. Consider 
Google's GData API. Do you know anyone who uses this API without using the 
GData JS library?

> websocket protocol to drive some agenda to revolutionize server side 
> development.
> 
> We cannot design a protocol that is only suitable for some imagined 
> future scenario.
> 
> Trying to enforce this future by making future protocols badly support 
> monolithic servers strikes me as some Orwellian mind control exercise!

Web Sockets supports monolithic servers fine, it just doesn't require 
them.

I don't think you should be using _your_ influence by continuing the trend 
of over-engineered protocols that require monolithic servers. :-)

> > If the channels are multiplexed, then we're assuming that the 
> > server-side is an "aggregating resource" as you put it. If it's 
> > possible to use an aggregating resource with a multiplexed connection, 
> > then why would it not be possible to do it with a Web Socket 
> > connection? I don't understand.
> 
> Because in the real world, we have one set of developers writing servers 
> and user-agents and another set of developers writing applications that 
> run on them.

That can still happen. I just think we shouldn't artificially create a 
market for the server developers by making them necessary to application 
development. That's unhealthy.

> The infrastructure developers impose all sorts of restrictions on the 
> application developers

That pretty much summarises the problem with complex protocols.

> infrastructure shackles imposed on them, because indeed a dedicated 
> TCP/IP connections is better than a shared one. Cross domain development 
> is so much easier without security models etc. Better let them run as 
> root as well, because then they can open any port and up their priority 
> to stop sharing CPU.

The Web Socket protocol has a built-in security model. The rest of your 
comment is a wild exaggeration of what I'm saying.

> There are really really good reasons why infrastructure is developed for 
> application developers.  Infrastructure is not only to enable 
> applications, but it is to constrain them and to force them to share 
> resources fairly and to respect security models.
>
> But there is absolutely no way that any responsible organisation is 
> going to deploy a system where sockets opened by applications 
> programmers are exposed directly to the internet and run with ad-hoc 
> protocol implementations.

Web Sockets doesn't require this. It allows you to be as constraining as 
you like.

> > I assume it is a given that you would want a protocol to have the 
> > property that connecting with path A, then opening a channel for path 
> > B, should result in a connection with the same internal state as 
> > connecting with path B, then opening a channel for path A.
> > 

The model you describe is incompatible with light-weight self-contained 
servers without a monolithic controlling server. I'm not interested in 
artificially supporting such monolithic server development when we don't 
have to.

> Really?  If it was, then why not just expose the real socket API?

Because that wouldn't be Web-safe, and it wouldn't be compatible with the 
Web browser quantised event model.

Web Socket is the smallest delta I could find from TCP to be Web-safe and 
quantised. It adds a handshake to prevent connection to WebSocket-unaware 
servers; it adds a security layer to prevent XSS- and CSRF-like attacks; 
and it adds framing to change TCP from a stream model to a packet model. 
Other than that, it adds nothing.

> server.  Whose to say that TCP/IP will be the favoured transport for the 
> entire life span of the applications using the websocket API?

If something else becomes better, then let's introduce a new protocol. For 
now, though, that's not a problem.

> that their charter is to consider more than just the needs of javascript 
> developers.

The IETF is welcome to do whatever it likes. The only reason Web Sockets 
is here is that the IETF wanted it here.

Web Sockets has as its goal to safely expose TCP to JS developers. If 
there are other goals that need to be met, then other protocols should be 
developed. We shouldn't artificially try to jam multiple goals into one 
protocol just because we happen to be on one mailing list together.

On Sun, 18 Oct 2009, Wellington Fernando de Macedo wrote:
> ws://www.myhost.com/ws/script2.php. Then, using the same connection, the 
> user agent could use the 0x01 frame type as a way to perform the 
> type (0x02), followed by the channel id. The initial channel could still 
> use the 0x00 frame type, however. For instance, a exchange of data on 
> the initial channel would be:
> 
> User Agent
> --------------
> 0x00 ping 0xff
> 
> Server
> --------------
> 0x00 pong 0xff
> 
> or
> 
> User Agent
> --------------
> 0x02 0x00 0x00 ping 0xff
> 
> Server
> --------------
> 0x02 0x00 0x00 pong 0xff
> 

The problem with this model is that if the connections are being handed 
from an HTTP server to various Web Socket servers, one for each URL, the 
above wouldn't work -- you'd end up connecting to /ws/script1.php, and 
then asking _that_ script to connect to /ws/script2.php, which makes no 
sense.

It's also unclear how you would handle the security model in this world. 
What if the server returns a different origin for the nested channel? 
Also, how do you handle connection closure? What if the user opens a dozen 
tabs to a server, and then closes all but one -- does the server have to 
keep all the channels open?

This kind of model would introduce the possibility of a proxy that merges 
multiple Web Socket connections together, but what if the author tested 
without a proxy, and so never saw multiple connections from different 
users to the same TCP connection, and therefore assumed per-connection 
security? Also, how would a heavy-traffic site handle the one connection 
from a proxy at a large site, where channels were continually opened?

Generally, this introduces a host of thorny problems that TCP has already 
solved. I think rather than reinventing TCP inside WebSocket, we're better 
off leaving this as an application-layer problem, where authors are much 
better positioned to make educated choices for how to implement this.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 22 Oct 2009 09:32:07 -0700

> Having a complex protocol requires it.

I think this is a straw man.  Any protocol that is not
websocket is not by definition complex.

Something like BWTP could also be written over a weekend
in perl or similar.    It could also run in the many little
server mode that you think is best.

The hard part of "monolithic" servers is not implementing the
protocol.   It is implementing as scalable protocol, an application
environment, all the goop specified by JEE specs (if you are in java),
the security sandbox, etc

If you don't want all that, then even HTTP can be built in a
day or two - I've done so several times.

> I don't buy that these widgets will all be communicating with the same 

Why not?  if they are all on a portal page put together by www.bigCompany.com
then they all might be accessing the services of bigCompany.com

Currently companies put static content onto common CDN services, and
maybe in future there will be dynamic services on common services.

I've already seen social networking services, advertising services
and analytic services having common components on many many websites,
so it is increasingly likely that multiple unrelated pages from
different sites will access common services on common hosts.

> If the widgets are from third parties, then they wouldn't all talk back to 

Not if the widgets are all different ways of presenting the data/events
from the same server.

> Google's GData API. Do you know anyone who uses this API without using the 

If there was a performance advantage to be gained, then I'm sure they
would.    But with XHR based APIs, coding to the GData API or to XHR
gives you the same access to the underlying network resources.

If there was an API in the browser that gave me a dedicated HTTP
connection, I would certainly use it now for long polling - even
though I know that rationally that is not the best thing to do.

> comment is a wild exaggeration of what I'm saying.

True

> is here is that the IETF wanted it here.

And since you have accepted the IETFs invitation to submit a draft,
you should do so in good faith and not expect the IETF to rubber stamp
what you've done simply because you have no intention of changing it.

Remember, it is not just the browser vendors that websocket must
win over.      In order for it to be a success, then all kinds
of web infrastructure needs to be updated to support it - firewalls,
proxies, web caches, corporate policies etc. etc.    Having IETF
endorsed standard is going to greatly increase the chances of
success.

You can open a real socket from a web browser now with commonly
installed plugins - but it is not that useful because the network
community does not allow arbitrary sockets to traverse the network.

regards

regards

---

From: Ian Hickson <[email-masked]>
Date: Fri, 23 Oct 2009 03:57:03 +0000 (UTC)

On Thu, 22 Oct 2009, Greg Wilkins wrote:
> I think this is a straw man.  Any protocol that is not websocket is not 
> by definition complex.

I didn't mean to imply that, my apologies.

> Something like BWTP could also be written over a weekend in perl or 
> similar.  It could also run in the many little server mode that you 
> think is best.
> 
> The hard part of "monolithic" servers is not implementing the protocol.  
> It is implementing as scalable protocol, an application environment, all 
> the goop specified by JEE specs (if you are in java), the security 
> sandbox, etc
> 
> If you don't want all that, then even HTTP can be built in a day or two 
> - I've done so several times.

I am skeptical that a _fully conforming_ HTTP server can be implemented in 
a weekend by most Web devs.

> then they all might be accessing the services of bigCompany.com

Then they could just use a common JS library that multiplexed for them. 
Why would www.bigCompany.com open multiple connections to itself, if it 
wanted to save on the number of TCP connections to its servers?

> I've already seen social networking services, advertising services and 
> analytic services having common components on many many websites, so it 
> is increasingly likely that multiple unrelated pages from different 
> sites will access common services on common hosts.

Sure; but then they would almost certainly also want common resources 
locally, and could therefore just use a common shared worker with a single 
TCP connection.

> > If the widgets are from third parties, then they wouldn't all talk 
> > back to the same server.
> 

I do not believe this is the 80% case, and thus do not think it is worth 
addressing in the first version.

> > I disagree with your pessimism here. I think there is ample evidence 
> > that people are happy to use JS libraries to talk to services. 
> > Consider Google's GData API. Do you know anyone who uses this API 
> > without using the GData JS library?
> 
> would.  But with XHR based APIs, coding to the GData API or to XHR gives 
> you the same access to the underlying network resources.
> 
> connection, I would certainly use it now for long polling - even though 
> I know that rationally that is not the best thing to do.

I think authors are lazier than that, personally.

> > The IETF is welcome to do whatever it likes. The only reason Web 
> > Sockets is here is that the IETF wanted it here.
> 
> And since you have accepted the IETFs invitation to submit a draft, you 
> should do so in good faith and not expect the IETF to rubber stamp what 
> you've done simply because you have no intention of changing it.

I've made lots of changes to the WebSocket protocol -- heck, I've made so 
many changes based on feedback here and elsewhere that people have started 
complaining that I've made too many!

There is a difference between not making any changes, and not making the 
changes you want me to make. I do not believe that multiplexing is a good 
idea in this protocol.

> Remember, it is not just the browser vendors that websocket must win 
> over.  In order for it to be a success, then all kinds of web 
> infrastructure needs to be updated to support it - firewalls, proxies, 
> web caches, corporate policies etc. etc.

Actually, as designed, WebSocket does an end-run around most of these. The 
only case I'm aware of where WebSocket would need help is in environments 
that do not even allow port 443 traffic to pass through unmolested.

> community does not allow arbitrary sockets to traverse the network.

Actually commonly installed plugins have security models to prevent 
arbitrary port connections, just like WebSockets. Personally I think the 
WebSocket security model is better than, say, Flash's, but at the end of 
the day it has much the same effect and provides much the same feature. 
The difference between Flash and WebSocket is the same as between Flash 
and HTML5 <video>: one is proprietary, the other is vendor-neutral.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Oct 2009 08:41:21 +0200

> complaining that I've made too many!

As far as I can tell, the complaints have been about the number of I-Ds 
being posted, not about the changes itself. Nobody stops you from 
collecting a reasonable amount of changes, and *then* publish a new draft.

BR, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Oct 2009 08:40:59 -0600

On 10/23/09 12:41 AM, Julian Reschke wrote:
> Ian Hickson wrote:
>> ...
>> I've made lots of changes to the WebSocket protocol -- heck, I've made
>> so many changes based on feedback here and elsewhere that people have
>> started complaining that I've made too many!
>> ...
> 

And I wonder if there is a "v3d" ("version three digits") problem
lurking in the tools we use to process Internet-Drafts. I've never seen
an I-D with a version greater than 99.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 23 Oct 2009 10:22:33 -0700

> complaining that I've made too many!

My comment was directed at your statement that the IETF can "do whatever
it likes" in response to my suggestion that there may be wider concerns
considered than just the narrow js case that you have considered in HTML5.

> that do not even allow port 443 traffic to pass through unmolested.

And this is exactly the sort of wider concern that the IETF might want
to consider.

You can tunnel bidirectional traffic over DNS if you want, but that
does not mean the IETF will sanction such a protocol.
Having a long term solution that essentially misuses the CONNECT
mechanism of proxies is far from ideal.

Considering how intermediaries can interact with bidirectional
connections is extremely important - even if only at the level
of how to stop them closing what they think are idle connections.

> On Thu, 22 Oct 2009, Joshua Bell wrote:
>> * I seem to recall that one of the desires for sentinel-based frames was 
>> to allow octet streams for which the length was not known in advance. 
> 
> No; the only reason for sentinel-based frames was to not rely on authors 
> having to determine the length of their UTF-8-encoded strings, which in 
> many environments can be easy to get wrong.

Authors that can't determine the length of a UTF-8 string are not exactly
the sort of developers that should be implementing network protocols.

When sending this utf-8, buffers will be used and lengths must be
checked - else there will be buffer overruns and associated failures
and/or security issues.

It seams an entirely reasonable simplification of websocket to
use only length limited framing and to use the type byte to indicate
such things as content charset

regards

---

From: Ian Hickson <[email-masked]>
Date: Fri, 23 Oct 2009 21:57:00 +0000 (UTC)

On Fri, 23 Oct 2009, Greg Wilkins wrote:
> >> * I seem to recall that one of the desires for sentinel-based frames 
> >> was to allow octet streams for which the length was not known in 
> >> advance.
> > 
> > No; the only reason for sentinel-based frames was to not rely on 
> > authors having to determine the length of their UTF-8-encoded strings, 
> > which in many environments can be easy to get wrong.
> 
> Authors that can't determine the length of a UTF-8 string are not 
> exactly the sort of developers that should be implementing network 
> protocols.

Wow.

I cannot stand behind such a judgmental statement. Personally I would like 
to make this kind of thing accessible to as many people as possible.

> It seams an entirely reasonable simplification of websocket to use only 
> length limited framing and to use the type byte to indicate such things 
> as content charset

What's the use case for doing anything other than UTF-8?

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 23 Oct 2009 16:34:18 -0700

> to make this kind of thing accessible to as many people as possible.

I don't understand your Wow.  Buffer overflows have historically
been one of the biggest security issues with any services exposed
to the internet.

Utf-8 will mostly have a 1 character to 1 byte mapping (at least
for english speakers), so many programmers will write code
that they think works by allocating byte buffers the same
size as their characters strings.  But then when giving
multi-byte characters they will suffer buffer overflows.

I've made this programming error myself many times! So perhaps
I too am one of the authors that should not be writing network
protocols.

The level of programming skill needed to manage meta data
or channels is entirely of the same order of magnitude as
managing utf-8 encoding.

So my point is probably better expressed by saying that
programmers who are able to write a websocket implementation
that correctly handles multi-byte utf-8 characters, will
be entirely capable of handling the additional "complexity"
of some of the additional capabilities being discussed here.

> What's the use case for doing anything other than UTF-8?

Even limiting myself to js in the browser, I can think of
of reasons that a content type other than UTF-8 would be
desirable.

* Compressed UTF-8

* UTF-16 for those whose language happens to use a lot of >2 byte
  utf-8 characters

* UTF-16 for those that can't deal with the uncertainty and/or
  unpredictability of the length of a UTF-8 string

If we consider what a browser itself might like to do with
websocket, or a none- browser client might like, then we have:

* Mime encoded content for those that want to send other
  content types down a stream.  Images, sounds etc.

* Some other framed content for those that want to implement
  multiplexing on top of websocket (as you advocate) but don't
  want to have to do it with text based framing.

* Anybody that wants to send any content with 0xFF in it
  and does not want to base64 code their entire content
  as a result

* A mobile phone that is restricted to a single outgoing
  connection (not uncommon) so the browser wants to
  transport HTTP over the websocket connection

* Something that none of us has thought of yet

You also say that future multiplexing (or other complex
things), should be built on top of websocket. Yet  when
anybody asks for additional content types to help do that,
you say they are not needed and it all can be done in UTF-8.

I find this amusing, because Websocket has gone against the common
convention for web protocols being humanly readable ascii encoded.
Instead it is a byte squeezed binary protocol.

Yet when it comes to building protocols on top of websocket, then
all of a sudden you are an advocate of text encoded protocols.

To send a stream of images with websocket, you will need to
have a sentinel framed UTF-8 message that contains a JSON or
mime header to give the content type of the base64 or hex
encoded image.     That's 3 envelopes around each image!
Ouch!!!

regards

---

From: Ian Hickson <[email-masked]>
Date: Sat, 24 Oct 2009 11:09:07 +0000 (UTC)

On Fri, 23 Oct 2009, Greg Wilkins wrote:
> >>>> * I seem to recall that one of the desires for sentinel-based 
> >>>> frames was to allow octet streams for which the length was not 
> >>>> known in advance.
> >>>
> >>> authors having to determine the length of their UTF-8-encoded 
> >>> strings, which in many environments can be easy to get wrong.
> >>
> > I cannot stand behind such a judgmental statement. Personally I would 
> > like to make this kind of thing accessible to as many people as 
> > possible.
> 
> I don't understand your Wow.  Buffer overflows have historically been 
> one of the biggest security issues with any services exposed to the 
> internet.

My "Wow" was to your comment saying that someone might not be the sort of 
developers that should be implementing something.

WebSocket is actually intentionally designed to make buffer overruns 
harder to accidentally write into code. For binary data, there is no 
sentinel, so you can allocate the given amount of memory and fill it, 
without any risk of overrunning anything. Indeed, you can't do anything 
else, since there's no way to detect the end of the frame other than by 
its length. The only risk is with null length frames, but there no data is 
written into them, so the damage, if any, is limited. For text data, there 
is no length marker, so the only way way to have an overrun is to decide 
on a fixed maximum size and then have someone send you a frame that's 
larger. Provided you don't make that mistake, there's no way to be tricked 
into a buffer overrun as far as I can tell, since there's no up-front 
length declaration.

> Utf-8 will mostly have a 1 character to 1 byte mapping (at least for 
> english speakers), so many programmers will write code that they think 
> works by allocating byte buffers the same size as their characters 
> strings.  But then when giving multi-byte characters they will suffer 
> buffer overflows.

The way the protocol is designed, they don't need to allocate those 
buffers. If they use UTF-8 internally, they can just output the string 
straight into the I/O layer, with a 0x00 byte first, and a 0xFF byte 
after. That's the reason for the server-to-client data not having a length 
field for UTF-8, actually.

(The protocol wasn't intended to be symmetric, it just ended up that way 
because that design made sense given the goals of making parsing and 
serialising easy for the server side.)

> I've made this programming error myself many times! So perhaps I too am 
> one of the authors that should not be writing network protocols.

If you don't think you should be writing one, you almost certainly 
shouldn't be designing one. :-)

> The level of programming skill needed to manage meta data or channels is 
> entirely of the same order of magnitude as managing utf-8 encoding.

The main difference is that most people won't manage UTF-8 encoding. In 
Perl, for instance, there's the "Encode" library that you can just pass 
byte strings to to have them converted into UTF-8, and vice-versa.

> So my point is probably better expressed by saying that programmers who 
> are able to write a websocket implementation that correctly handles 
> multi-byte utf-8 characters, will be entirely capable of handling the 
> additional "complexity" of some of the additional capabilities being 
> discussed here.

Complexity in one part of the protocol is not a license to make the 
protocol complicated everywhere.

That's a red herring, though. Multiplexing (for one) isn't omitted just, 
or even primarily, because it would be complicated, but because the 
cost-benefit ratio doesn't make it worth it. We can push the complexity of 
multiplexing (say) to the application level, so that authors who need it 
can use it, and others don't need to worry about it.

This is very much in line with the Unix philosophy of making small self- 
contained building blocks, instead of monolithic solutions.

> >> It seams an entirely reasonable simplification of websocket to use 
> >> only length limited framing and to use the type byte to indicate such 
> >> things as content charset
> > 
> Even limiting myself to js in the browser, I can think of of reasons 
> that a content type other than UTF-8 would be desirable.
> 
> * Compressed UTF-8

Binary data will be supported in v2, once the JS side supports it. Then 
you can compress your data easily.

If it turns out that short messages would in fact benefit from compression 
(which personally I am skeptical about), then we can easily add it in a 
future version as a dedicated feature, too.

> * UTF-16 for those whose language happens to use a lot of >2 byte

If we were worried about bandwidth, gzip compressing UTF-8 would give 
better results across the board than allowing the author to switch between 
UTF-8 and UTF-16.

>   unpredictability of the length of a UTF-8 string

UTF-16 is far worse than UTF-8 when it comes to character-to-byte length 
issues, in practice.

> If we consider what a browser itself might like to do with websocket, or 
> a non-browser client might like, then we have:
> 

We have binary frames already staked out in the protocol, waiting for 
support in JS for binary.

>   want to have to do it with text based framing.

Again, binary data will be support in v2. The protocol already supports 
it, it's just not in the API.

>   and does not want to base64 code their entire content

Same.

>   transport HTTP over the websocket connection

Could you elaborate on this use case?

> * Something that none of us has thought of yet

Once we think of it, we can address it. There's no point trying to 
optimise for something we don't know about; we have no way to know if we 
are optimising in the right way.

> You also say that future multiplexing (or other complex things), should 
> be built on top of websocket. Yet when anybody asks for additional 
> content types to help do that, you say they are not needed and it all 
> can be done in UTF-8.

I stand by that. Multiplexing can be done in UTF-8 easily.

> Instead it is a byte squeezed binary protocol.

I'm glad you think IP, TCP, and DNS are unconventional. :-)

WebSocket's handshake is ASCII based. It makes no sense to make the 
framing ASCII based; that would just make the error handling really 
complicated. One byte to introduce the frame and one byte to end it is 
simpler.

> Yet when it comes to building protocols on top of websocket, then all of 
> a sudden you are an advocate of text encoded protocols.

WebSocket supports both text and binary equally. The only reason the 
binary part is a second-class citizen right now is that JS doesn't support 
binary yet.

> To send a stream of images with websocket, you will need to have a 
> sentinel framed UTF-8 message that contains a JSON or mime header to 
> give the content type of the base64 or hex encoded image.  That's 3 
> envelopes around each image! Ouch!!!

To send a stream of images with WebSocket, you will need to wait until 
JavaScript gives you a way to get the image data in a usable form. I 
certainly wouldn't recommend sending it as text, that would be stupid.

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 24 Oct 2009 19:21:33 +0100

>   unpredictability of the length of a UTF-8 string

Careful.  UTF-16 is a variable length encoding too.

It is possibly worse than UTF-8 for this, because everyone knows that
UTF-8 is variable length, but many people seem to think UTF-16 is not.

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 25 Oct 2009 01:02:02 -0700

> UTF-8 is variable length, but many people seem to think UTF-16 is not.

OK that's worth a Wow!

I had assigned UTF-16 was fixed length because the java implementation
for it is.  But now I see in the java documentations:

 "The char data type (and therefore the value that a Character object
  encapsulates) are based on the original Unicode specification, which
  defined characters as fixed-width 16-bit entities. The Unicode standard
  has since been changed to allow for characters whose representation
  requires more than 16 bits. The range of legal code points is now
  U+0000 to U+10FFFF, known as Unicode scalar value. (Refer to the
  definition of the U+n notation in the Unicode standard.)

  The set of characters from U+0000 to U+FFFF is sometimes referred
  to as the Basic Multilingual Plane (BMP). Characters whose code
  points are greater than U+FFFF are called supplementary characters.
  The Java 2 platform uses the UTF-16 representation in char arrays
  and in the String and StringBuffer classes. In this representation,
  supplementary characters are represented as a pair of char
  values, the first from the high-surrogates range, (\uD800-\uDBFF),
  the second from the low-surrogates range (\uDC00-\uDFFF)."

So I'll modify my original point to

 * UTF-16 for java programmers and other BMP users that don't want to
   deal with the uncertainty and/or unpredictability of the length of
   a UTF-8 string

Thanks for the learning experience!

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 25 Oct 2009 01:51:38 -0700

> shouldn't be designing one. :-)

touche!   :)

> byte strings to to have them converted into UTF-8, and vice-versa.

Forgive my total lack of knowledge of perl, but given the availability
of the encode library in perl, I see little difference in the complexity
of sentinel marked code which is:

  $octets = encode("utf-8", $message)
  write ($octets)
  write (oxff)

versus length encoding code which is

  $octets = encode("utf-8", $message)
  write ($octets.length)
  write ($octets)

They will need a method to correctly encode the length
as an unlimited integer, but they will probably need that
anyway as  you currently specify that length encoded
framing is part of the standard (stacked out).

> support in JS for binary.

I don't see why an IETF protocol proposal needs to wait for
the js implementation?

Since the binary framing is about the same level of
complexity, is more capable and is already stacked
out - they why not avoid the complexity to two
different framings and just use length?

JS is free to limit it's usage to just utf-8 as long
as it likes.   But JS is not the only client language
that is going to use an IETF sanctioned bidirectional
protocol.

> Could you elaborate on this use case?

I unfortunately don't have all the details, but I have
been a little involved in the development of a comet
system for a large mobile phone company for global
deployment.

One of the issues that we had to deal with was a single
connection limit that apparently affects many millions
of phones.  This was a restriction for a non
browser application running on the phone with direct
access to the TCP/IP layer.

However I'm unclear if the limit was imposed by firmware
in the phone or carriers.

> are optimising in the right way.

I fundamentally disagree - and I think that this difference is
probably at the root of most/all our other differences on the
protocol.

I think the wait and see position you advocate is entirely
correct for the websocket API.

But i think it is entirely wrong for the websocket protocol.

A flexible and extensible protocol can be restricted to known
uses by the API.  You then do not need to update the entire
network infrastructure for each and every new idea.   Your
attempt to "stack out" the binary protocol is justified
by avoiding exactly this type of breakage.

> certainly wouldn't recommend sending it as text, that would be stupid.

I think this is another fundamental disagreement.

I think the IETF should be considering a bidirectional solution for all
web clients - not just for HTML5 JS clients

Again, from my mobile experience, I have seen comet protocols
stream a users thumbnail image with a chat message, because of the
latencies involved with a separate fetch.   For the corresponding
web browser solution, the comet stream just sends a URL of the
thumbnail.

So I think it is really important for the IETF BOF/WG to resolve
these fundamental differences.   If you are designing a non-extensible
protocol that only supports HTML5 websocket API, then you may well
end up with something like the websocket protocol.   But if you
want something that is extensible and supports bidirectionality
for any web client, then I think then it will look substantially
different.

regards

---

From: Ian Hickson <[email-masked]>
Date: Tue, 27 Oct 2009 02:04:05 +0000 (UTC)

On Sun, 25 Oct 2009, Greg Wilkins wrote:
> >
> > The main difference is that most people won't manage UTF-8 encoding. 
> > In Perl, for instance, there's the "Encode" library that you can just 
> > pass byte strings to to have them converted into UTF-8, and 
> > vice-versa.
> 

Yup, in Perl, once you have encoded the string correctly, getting the 
lenght is relatively easy. However, I expect many people won't be 
explicitly encoding the string at all; they'll just output the string 
straight to the socket and have the socket encode the UTF-8. Many servers 
don't need to know what is going on, since they can just be opaque to most 
of the data and just use ASCII for the "command" part of their API.

> They will need a method to correctly encode the length as an unlimited 
> integer, but they will probably need that anyway as you currently 
> specify that length encoded framing is part of the standard (stacked 
> out).

They only need to support that if they will be using the binary part of 
the protocol.

> I don't see why an IETF protocol proposal needs to wait for the js 
> implementation?

The only reason this protocol exists is for the JS API. If it wasn't for 
the JS API's requirements, TCP itself already addresses the needs.

> Since the binary framing is about the same level of complexity, is more 
> capable and is already stacked out - they why not avoid the complexity 
> to two different framings and just use length?

Getting the length of strings is non-trivial in many environments 
(certainly compared to getting the length of binary data). Most servers 
will never have to deal with the binary stuff at all. And you're much more 
likely to have buffer overrun bugs if you use a length prefix followed by 
a variable-length encoding of text.

> JS is free to limit it's usage to just utf-8 as long as it likes.  But 
> JS is not the only client language that is going to use an IETF 
> sanctioned bidirectional protocol.

I sure hope nobody is hoping to use WebSocket with anything other than JS 
-- it's be a complete waste of time to use WebSocket for anything if we're 
just talking about an arbitrary client-server protocol. We already have 
TCP for people who want to write their own subprotocol, and we already 
have BEEP, Jabber, and a multitude of other transports for people who want 
a more structured protocol to tunnel over.

Now, granted, some people might want to speak to WebSocket services that 
were originally intended for JS scripts from command-line tools, just like 
people talk to JSON services that use HTTP cookies for authentication from 
command-line tools, and that is supported by the protocol, but that's 
certainly not the primary use case. There'd be no point having features 
that are _only_ usable by people _not_ using JS scripts in Web pages -- if 
you want to do something WebSocket can't do, then just use raw TCP.

> I unfortunately don't have all the details, but I have been a little 
> involved in the development of a comet system for a large mobile phone 
> company for global deployment.
> 
> One of the issues that we had to deal with was a single connection limit 
> that apparently affects many millions of phones.  This was a restriction 
> for a non browser application running on the phone with direct access to 
> the TCP/IP layer.
> 
> However I'm unclear if the limit was imposed by firmware in the phone or 
> carriers.

Well if there's a limit of a single TCP connection, WebSocket is a lost 
cause anyway (since you'd block all XHR, HTTP, etc, while the page was 
open). WebSocket is intended for systems capable of running a full Web 
browser that can run XHR-based apps today.

> > optimise for something we don't know about; we have no way to know if 
> > we are optimising in the right way.
> 
> I fundamentally disagree - and I think that this difference is probably 
> at the root of most/all our other differences on the protocol.

Possibly.

> I think the wait and see position you advocate is entirely correct for 
> the websocket API.
> 
> A flexible and extensible protocol can be restricted to known uses by 
> the API.  You then do not need to update the entire network 
> infrastructure for each and every new idea.  Your attempt to "stack out" 
> the binary protocol is justified by avoiding exactly this type of 
> breakage.

I agree that if there are things we know we will need to support, that we 
should make sure we can support them. I agree that we should give 
ourselves forward- and backward-compatible extension points (e.g. the 
handshake is extensible and we have 253 frame types still available).

However, there's no point trying to design the protocol to support every 
possible extension mechanism, because I *guarantee* that you'll miss the 
one that you really need, however hard you try, and in the meantime you'll 
have a protocol with lots of extra complexity that never helps anyone.

Consider XML and XML Namespaces. It provides a variety of extension points 
-- you can add new elements in a new namespace, an element can have new 
attributes added, etc etc etc. However, XML doesn't support inline binary. 
It doesn't support an element having two element types. It doesn't support 
elements overlapping each other. It doesn't support attributes having 
multiple values. All of these are things that have been needed by various 
groups at one time or another, despite XML being branded as the ultimate 
extensible markup metalanguage.

So now we have XML and XML namespaces, together making a really expensive 
mechanism, and yet it doesn't do what people want, despite being designed 
to be extensible. I think that's not a good state to be in.

(PS. Stake out, not stack out. :-) )

> web clients - not just for HTML5 JS clients

What's wrong with TCP, BEEP, or Jabber?

> If you are designing a non-extensible protocol that only supports HTML5 
> websocket API, then you may well end up with something like the 
> websocket protocol.

WebSocket is extensible, just not in the ways you want it to be 
extensible. But other than that, yes, that's what I'm designing.

> But if you want something that is extensible and supports 
> bidirectionality for any web client, then I think then it will look 
> substantially different.

Wouldn't it look pretty much exactly like TCP, BEEP, or Jabber?

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 27 Oct 2009 21:46:18 +1100

> What's wrong with TCP, BEEP, or Jabber?

Once upon a time there was the internet and IP was God (even though
Al Gore invented the internet and he really should have been God).

But then somebody invented the Web (was it Bill Gates?) and now
port 80 is God.

The Web runs on top of the Internet, but restricts all the wonderful
features of IP to a one way port 80.

TCP, BEEP, or Jabber are really great Internet protocols, but
they don't generally work on the web.   Jabber (aka XMPP) has
to fall back to BOSH on HTTP in order to span the web.

cheers

---

From: Ian Hickson <[email-masked]>
Date: Tue, 27 Oct 2009 18:39:44 +0000 (UTC)

On Tue, 27 Oct 2009, Greg Wilkins wrote:
> Ian Hickson wrote:
> >> I think the IETF should be considering a bidirectional solution for 
> >> all web clients - not just for HTML5 JS clients
> > 
> Once upon a time there was the internet and IP was God (even though Al 
> Gore invented the internet and he really should have been God).
> 
> But then somebody invented the Web (was it Bill Gates?) and now port 80 
> is God.
> 
> TCP, BEEP, or Jabber are really great Internet protocols, but they don't 
> generally work on the web.  Jabber (aka XMPP) has to fall back to BOSH 
> on HTTP in order to span the web.

I'm not really sure what you mean by "the web" here.

If your requirement is for a protocol that can tunnel other bydirectional 
protocols over HTTP, then WebSocket isn't it. We should decouple the 
requirements for WebSockets (which were listed in one of the first 
messages to this list) from the requirements for a tunnel-over-HTTP 
protocol, because they aren't compatible requirements.