TOC 
Network Working GroupJ. Moffitt, Ed.
Internet-DraftCollecta
Intended status: InformationalS. Loreto
Expires: December 17, 2010Ericsson
 P. Saint-Andre
 Cisco
 S. Salsano
 Univ. of Rome "Tor Vergata"
 Jun 15, 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 17, 2010.

Copyright Notice

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

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
2.  Concerns and criteria
3.  Server side
4.  Clients
5.  Intermediaries
6.  Acknowledgments
7.  IANA Considerations
8.  Security Considerations
9.  Informative References
§  Authors' Addresses




 TOC 

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.



 TOC 

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



 TOC 

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] (Barth, A., Jackson, C., and I. Hickson, “The Web Origin Concept,” June 2010.). 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 [I‑D.hixie‑thewebsocketprotocol] (Hickson, I., “The WebSocket protocol,” May 2010.).
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] (Hickson, I., “The WebSocket protocol,” May 2010.).

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.



 TOC 

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] (Kesteren, A., “XMLHttpRequest Level 2,” August 2009.) 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] (Kesteren, A., “Cross-Origin Resource Sharing,” March 2009.), which overcomes the same-origin policy [I‑D.abarth‑origin] (Barth, A., Jackson, C., and I. Hickson, “The Web Origin Concept,” June 2010.). 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.
An alternative to developing with XHR directly is the Server-Sent Events API [W3C.WD‑eventsource‑20090423] (Hickson, I., “Server-Sent Events,” April 2009.). 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] (Hickson, I., “The WebSocket protocol,” May 2010.).
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].



 TOC 

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



 TOC 

6.  Acknowledgments

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



 TOC 

7.  IANA Considerations

This document does not require any actions by the IANA.



 TOC 

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



 TOC 

9. Informative References

[I-D.abarth-origin] Barth, A., Jackson, C., and I. Hickson, “The Web Origin Concept,” draft-abarth-origin-07 (work in progress), June 2010 (TXT).
[I-D.hixie-thewebsocketprotocol] Hickson, I., “The WebSocket protocol,” draft-hixie-thewebsocketprotocol-76 (work in progress), May 2010 (TXT).
[W3C.WD-XMLHttpRequest2-20090820] Kesteren, A., “XMLHttpRequest Level 2,” World Wide Web Consortium WD WD-XMLHttpRequest2-20090820, August 2009 (HTML).
[W3C.WD-cors-20090317] Kesteren, A., “Cross-Origin Resource Sharing,” World Wide Web Consortium WD WD-cors-20090317, March 2009 (HTML).
[W3C.WD-eventsource-20090423] Hickson, I., “Server-Sent Events,” World Wide Web Consortium WD WD-eventsource-20090423, April 2009 (HTML).


 TOC 

Authors' Addresses

  Jack Moffitt (editor)
  Collecta
Email:  jack@collecta.com
  
  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