[hybi] HyBi Design Space

[Salvatore Loreto <[e-mail]>]

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>.