Network Working Group S. Loreto
Internet-Draft Ericsson
Intended status: Informational P. Saint-Andre
Expires: April 22, 2010 Cisco
G. Wilkins
Webtide
S. Salsano
Univ. of Rome "Tor Vergata"
Oct 19, 2009
Design Space for Bidirectional protocols
draft-loreto-design-space-bidirectional-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Loreto, et al. Expires April 22, 2010 [Page 1]
Internet-Draft Bidirectional Design Space Oct 2009
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.
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 . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Loreto, et al. Expires April 22, 2010 [Page 2]
Internet-Draft Bidirectional Design Space Oct 2009
1. Introduction
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.
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
bidirectional 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 following sections we analyse the design space from the
perspective of clients, servers, and intermediaries such as proxies,
caching servers, and load balancers.
2. Concerns and criteria
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:
Loreto, et al. Expires April 22, 2010 [Page 3]
Internet-Draft Bidirectional Design Space Oct 2009
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.
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/Web server responsibilities. HTTP is used for transport 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/Web server responsibilities; the
push service is offered by a separate server that might not even
be on the same machi ne of the HTTP/Web server, neither written in
the same language. HTTP is used for transport the server events.
Loreto, et al. Expires April 22, 2010 [Page 4]
Internet-Draft Bidirectional Design Space Oct 2009
In the latter scenario, when a browser is used in 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
[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 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.
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 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.
Loreto, et al. Expires April 22, 2010 [Page 5]
Internet-Draft Bidirectional Design Space Oct 2009
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 [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.
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.
Non browser enhanced HTTP: [Definition and examples to follow.]
Non browser non-HTTP: [Definition and examples to follow.]
5. 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).
Loreto, et al. Expires April 22, 2010 [Page 6]
Internet-Draft Bidirectional Design Space Oct 2009
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.
6. Acknowledgments
7. IANA Considerations
This document does not require any actions by the IANA.
8. Security Considerations
To follow.
9. Informative References
[I-D.hixie-thewebsocketprotocol]
Hickson, I., "The Web Socket protocol",
draft-hixie-thewebsocketprotocol-48 (work in progress),
October 2009.
[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
Loreto, et al. Expires April 22, 2010 [Page 7]
Internet-Draft Bidirectional Design Space Oct 2009
Consortium WD WD-eventsource-20090423, April 2009,
<http://www.w3.org/TR/2009/WD-eventsource-20090423>.
Authors' Addresses
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Peter Saint-Andre
Cisco
Email: psaintan@cisco.com
Greg Wilkins
Webtide
Email: gregw@webtide.com
Stefano Salsano
Univ. of Rome "Tor Vergata"
Via del Politecnico, 1
Rome 00133
Italy
Email: stefano.salsano@uniroma2.it
Loreto, et al. Expires April 22, 2010 [Page 8]