[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                    J. Moffitt, Ed.
Internet-Draft                                                  Collecta
Intended status: Informational                                 S. Loreto
Expires: December 30, 2010                                      Ericsson
                                                          P. Saint-Andre
                                                                   Cisco
                                                              S. Salsano
                                             Univ. of Rome "Tor Vergata"
                                                            Jun 28, 2010


                Design Space for Bidirectional Protocols
                    draft-ietf-hybi-design-space-00

Abstract

   As technologies for bidirectional communication over HTTP have become
   pervasive, interest has grown in (1) defining improved mechanisms for
   support of existing technologies (short-term solutions such as new
   HTTP headers) and (2) the 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 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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 30, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Moffitt, et al.         Expires December 30, 2010               [Page 1]


Internet-Draft         Bidirectional Design Space               Jun 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Concerns and criteria . . . . . . . . . . . . . . . . . . . . . 3
   3.  Server side . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Intermediaries  . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Informative References  . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8




























Moffitt, et al.         Expires December 30, 2010               [Page 2]


Internet-Draft         Bidirectional Design Space               Jun 2010


1.  Introduction

   As technologies for bidirectional communication over HTTP have become
   pervasive, interest has grown in (1) defining improved mechanisms for
   support of existing technologies (short-term solutions such as new
   HTTP headers) and (2) the 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 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.

   In existing HTTP-based systems, the typical architecture 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.

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

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

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

   In the following sections, the design space is analysed from the
   perspective of clients, servers, and intermediaries.


2.  Concerns and criteria

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

   Complexity:  enables ease of implementation, understanding, and
      debugging







Moffitt, et al.         Expires December 30, 2010               [Page 3]


Internet-Draft         Bidirectional Design Space               Jun 2010


   Capability:  addresses a wide range of known bidirectional use-cases

   Extensibility:  has the capacity to handle new use-cases

   Latency:  minimizes latency and 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


3.  Server side

   The server side can be decomposed into three categories:

   Standard HTTP  In this category two scenarios are possible:

      In the first scenario, the bidirectionality is part of the normal
      HTTP server responsibilities.  HTTP is used for transport of the
      server events.  Examples include Comet and (in some deployments)
      BOSH.

      In the second scenario two servers are involved.  Bidirectionality
      is not part of the normal HTTP server responsibilities, and a push
      service is offered by a separate server that may reside on a
      different machine from the HTTP server.  HTTP is used for
      transport of the server events.

      In the latter scenario, when a browser is used on the client side,
      a cross-domain solution is needed to overcome the same-origin
      policy [I-D.abarth-origin].  Examples include BOSH (in some
      deployments) and Lightstreamer.




Moffitt, et al.         Expires December 30, 2010               [Page 4]


Internet-Draft         Bidirectional Design Space               Jun 2010


   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
      [I-D.hixie-thewebsocketprotocol].

   Out-of-band non-HTTP:  Bidirectionality is offered by a dedicated
      server using non HTTP protocol for transport server events.
      Examples include WebSockets [I-D.hixie-thewebsocketprotocol].

   The Standard HTTP based servers can work with existing HTTP standards
   or an enhanced HTTP.  The enhanced HTTP would be a standardized set
   of headers and behaviours that assist bidirectionality and cross-
   domain concerns.

   At present, a protocol that interacts heavily with JavaScript on the
   client side often implies some constraints on the server side, such
   that they have to use XML or JSON encapsulation or specific Unicode
   encodings.  JavaScript currently has no native ability to interact
   with binary data as anything more than a blob.


4.  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 and
      BOSH 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 regular polling or long polling.

      Some XHR implementations also support the cross-domain extension
      [W3C.WD-cors-20090317], which overcomes the same-origin policy
      [I-D.abarth-origin].  The same-origin policy restricts an
      application running at one origin from interacting with another
      origin.  However, XHR and the CORS extension impose some
      limitations on the headers that can be set by client-side code.



Moffitt, et al.         Expires December 30, 2010               [Page 5]


Internet-Draft         Bidirectional Design Space               Jun 2010


      An alternative to developing with XHR directly is the Server-Sent
      Events API [W3C.WD-eventsource-20090423].  The 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 [I-D.hixie-thewebsocketprotocol].

   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.  Several of the other protocols have also used plugins to
      circumvent the same-origin policy.

   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 or the
      ability to bypass restrictive firewalls.  Examples include the
      Comet Java client, the Second Life Viewer, and several XMPP
      clients.

   Non browser non-HTTP:  These are the typical non-HTTP protocol
      clients like mail readers and file transfer utilities.

      Non browser clients may also interact with servers using web
      focused protocols such as WebSocket.

   Browser based client logic must be implemented in JavaScript in
   general, and this currently restricts the form of data which can be
   manipulated by the client.  A binary data API for JavaScript may
   remove this restriction in the future. [open issue].


5.  Intermediaries

   Intermediaries (e.g. proxies, gateways, caching servers, load
   balancers) 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 responses.  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).





Moffitt, et al.         Expires December 30, 2010               [Page 6]


Internet-Draft         Bidirectional Design Space               Jun 2010


   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 the CONNECT mechanism to simulate an SSL
      connection to be used as a tunnel for a non-HTTP transport.


6.  Acknowledgments

   The bulk of this document was created by its original authors:
   Salvatore Loreto, Peter Saint-Andre, Stefano Salsano, and Greg
   Wilkins.


7.  IANA Considerations

   This document does not require any actions by the IANA.


8.  Security Considerations

   There are several security issues to consider with the types of
   protocols mentioned:

   Cross protocol attacks are an issue for browser based clients.  An
   attacker would attempt to initiate a connection to a service by
   mimicking one protocol with another.  For example, an attacker would
   attempt to fake a WebSocket connection by misuse of XMLHttpRequest.

   For protocols which span multiple TCP or HTTP connections (e.g.  BOSH
   and Comet), some consideration is needed to protect against data
   injection.  Each request may come from a different TCP connection or
   even IP address, so the server must have some way to tell which
   requests belong to the session.  This is typically solved with
   difficult to guess sequence numbers and session termination when
   rogue sequence numbers are used.

   Since browser based clients are the most common, and JavaScript has
   no facilities for binary data manipulation, cryptographic security



Moffitt, et al.         Expires December 30, 2010               [Page 7]


Internet-Draft         Bidirectional Design Space               Jun 2010


   must be handled solely by the browser and server.  This limits the
   security possible with solutions that expose an existing service over
   another protocol as the client cannot ensure secure transport for
   anything but the immediate peer.


9.  Informative References

   [I-D.abarth-origin]
              Barth, A., Jackson, C., and I. Hickson, "The Web Origin
              Concept", draft-abarth-origin-06 (work in progress),
              November 2009.

   [I-D.hixie-thewebsocketprotocol]
              Hickson, I., "The WebSocket protocol",
              draft-hixie-thewebsocketprotocol-76 (work in progress),
              May 2010.

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


Authors' Addresses

   Jack Moffitt (editor)
   Collecta

   Email: jack@collecta.com











Moffitt, et al.         Expires December 30, 2010               [Page 8]


Internet-Draft         Bidirectional Design Space               Jun 2010


   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: salvatore.loreto@ericsson.com


   Peter Saint-Andre
   Cisco

   Email: psaintan@cisco.com


   Stefano Salsano
   Univ. of Rome "Tor Vergata"
   Via del Politecnico, 1
   Rome  00133
   Italy

   Email: stefano.salsano@uniroma2.it





























Moffitt, et al.         Expires December 30, 2010               [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/