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, . [W3C.WD-cors-20090317] Kesteren, A., "Cross-Origin Resource Sharing", World Wide Web Consortium WD WD-cors-20090317, March 2009, . [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, . 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]