idnits 2.17.1 draft-loreto-design-space-bidirectional-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 19, 2009) is 5304 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-76) exists of draft-hixie-thewebsocketprotocol-48 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Loreto 3 Internet-Draft Ericsson 4 Intended status: Informational P. Saint-Andre 5 Expires: April 22, 2010 Cisco 6 G. Wilkins 7 Webtide 8 S. Salsano 9 Univ. of Rome "Tor Vergata" 10 Oct 19, 2009 12 Design Space for Bidirectional protocols 13 draft-loreto-design-space-bidirectional-00 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 22, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 As technologies that enable bidirectional communication over HTTP 52 have become more pervasive, interest has grown in (1) defining 53 improved mechanisms for support of existing technologies (short-term 54 solutions such as new HTTP headers) and (2) laying the foundation for 55 development of new bidirectional protocols (long-term solutions such 56 as WebSocket, Bidirectional Web Transfer Protocol, and Reverse HTTP). 57 In order to provide context for such work, this document provides a 58 first tentative map of the design space for bidirectional HTTP, with 59 special attention to deployed infrastructure (e.g. web clients, 60 intermediaries, firewalls, NATs, web servers) and programming 61 environments. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Concerns and criteria . . . . . . . . . . . . . . . . . . . . . 3 67 3. Server side . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 9. Informative References . . . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 As technologies that enable bidirectional communication over HTTP 79 have become more pervasive, interest has grown in (1) defining 80 improved mechanisms for support of existing technologies (short-term 81 solutions such as new HTTP headers) and (2) laying the foundation for 82 development of new bidirectional protocols (long-term solutions such 83 as WebSocket, Bidirectional Web Transfer Protocol, and Reverse HTTP). 84 In order to provide context for such work, this document provides a 85 first tentative map of the design space for bidirectional HTTP, with 86 special attention to deployed infrastructure (e.g. web clients, 87 intermediaries, firewalls, NATs, web servers) and programming 88 environments. 90 In existing HTTP-based systems, the typical semantic is client-server 91 Representational State Transfer (REST), where the resources served 92 are closely associated with an entity known by a URI or URL. 93 However, the introduction of bidirectionality can significantly 94 change the normal HTTP patterns. 96 As one example, the standard roles of client and server can be 97 reversed and a server can request resources from a client. 98 Unfortunately, due to a lack of client addressability URL's may not 99 be applicable to client entities and new addressing paradigms may be 100 required. 102 Furthermore, bidirectionality introduces a message passing pattern 103 into the traditional REST style. 105 These additional semantics will influence the design of the 106 bidirectional protocols, addressing, and APIs. Without a strong 107 association between an identified entity and a resource, new 108 mechanisms for content distribution and caching messages might need 109 to be considered. 111 In the following sections we analyse the design space from the 112 perspective of clients, servers, and intermediaries such as proxies, 113 caching servers, and load balancers. 115 2. Concerns and criteria 117 The process of evaluating eventual improvements to the bidirectional 118 solutions or development of new bidirection protocols should take 119 into consideration the following concerns and criteria: 121 Complexity: enables ease of implementation, understanding, and 122 debugging 124 Capability: addresses all/most known bidirectional use-cases 126 Extensibility: has the capacity to handle new use-cases 128 Latency: defines minimal, average, and maximal latency for message 129 delivery 131 Bandwidth overhead: minimizes overhead for idle and busy usage 133 Scalability: has the ability to handle large scale usage 135 Footprint: has the ability to handle small devices and/or massive 136 replication ("cloud") 138 AAA: enables proper Authentication, Authorization and Accounting 140 Security: enables strong security for integral, confidential, 141 endorsed, and cross domain deployments. 143 Interoperability: can work with and/or be integrated with existing 144 bidirectional implementations 146 Compatibility: can work with existing web infrastructure for 147 distributing, caching, manipulating, and displaying content. 149 3. Server side 151 The server side can be decomposed into three categories: 153 Standard HTTP In this category two scenarios are possible: 155 In the first scenario the bidirectionality is part of the normal 156 HTTP/Web server responsibilities. HTTP is used for transport the 157 server events. Examples include Comet and (in some deployments) 158 BOSH. 160 In the second scenario two servers are involved: bidirectionality 161 is not part of the normal HTTP/Web server responsibilities; the 162 push service is offered by a separate server that might not even 163 be on the same machi ne of the HTTP/Web server, neither written in 164 the same language. HTTP is used for transport the server events. 166 In the latter scenario, when a browser is used in the client side, 167 a cross domain solution is needed to overcome the "same-source" 168 web service restriction. Examples include BOSH (in some 169 deployments) and Lightstreamer. 171 In-band non-HTTP: Bidirectionality is part of the normal HTTP/Web 172 server responsibilities. However, server events are transported 173 on an upgraded HTTP connection. Examples include Bidirectional 174 Web Transfer Protocol (BWTP) and WebSockets 175 [I-D.hixie-thewebsocketprotocol]. 177 Out-of-band non-HTTP: Bidirectionality is offered by a dedicated 178 server using non HTTP protocol for transport server events. 179 Examples include WebSockets [I-D.hixie-thewebsocketprotocol]. 181 The Standard HTTP based servers can work with existing HTTP standards 182 or enhanced HTTP. Enhanced HTTP would be a standardized set of 183 headers and behaviours to assist with bidirectionality and cross 184 domain concerns. 186 At present, a protocol that interacts heavily with JavaScript on the 187 client side implies some constraints also on the server side, such 188 that they have to use XML or JSON encapsulation. 190 4. Clients 192 Clients can be involved in bidirectional transport in the following 193 capacities: 195 In browser open standards with HTTP transport: For applications 196 written in a web browser scripting language (e.g. JavaScript) 197 within a browser client. Examples include Comet and BOSH. 199 In browser open standards with enhanced HTTP transport: For 200 applications written in a web browser scripting language (e.g. 201 JavaScript) within a browser client. Examples include Comet with 202 cross domain extensions. 204 Browsers using either standard HTTP transport or enhanced HTTP 205 transport typically use XMLHttpRequest (XHR) API 206 [W3C.WD-XMLHttpRequest2-20090820] allowing scripts to perform HTTP 207 client functionality. The XHR object can be used to perform 208 bidirectional HTTP using both "long polling" and "HTTP streaming" 209 mechanisms. 211 XHR also supports the cross domain extension 212 [W3C.WD-cors-20090317], which overcomes the same-origin 213 restrictions that prevent a Web application running from one 214 origin from obtaining data retrieved from another origin. 215 However, XHR presents some limitations on the headers that can be 216 set by the user. 218 An alternative to XMLHttpRequest is using the Server-Sent Events 219 API [W3C.WD-eventsource-20090423]. This "EventSource: interface 220 enables servers to push data to Web pages over HTTP or using 221 dedicated server-push protocols. 223 In browser open standards with non HTTP transport: For applications 224 written in JavaScript within a browser client. Examples include 225 BWTP and WebSockets [I-D.hixie-thewebsocketprotocol]. 227 In browser with plugin: This is not of particular interest to IETF, 228 but should be noted as part of the design space. Examples include 229 BlazeDS. 231 Non-browser HTTP: A bidirectional client may be written outside of a 232 browser and use bidirectional web transports. Typically this is 233 done when a rich or minimal client requires a mature transport for 234 application protocol with request / response semantics and/or the 235 ability to bypass firewalls to access public servers over HTTP 236 transports. Examples include the Comet Java client and the Second 237 Life Viewer. 239 Non browser enhanced HTTP: [Definition and examples to follow.] 241 Non browser non-HTTP: [Definition and examples to follow.] 243 5. Intermediaries 245 Intermediaries (e.g. proxies, gateways, caching servers, load 246 balancers, etc) can be involved in bidirectional transport in several 247 capacities: 249 Legal HTTP relay: Transports such as long polling use intermediaries 250 to carry legal HTTP requests and response. Any capabilities that 251 may interfere with bidirectional flow (e.g. caching) are 252 controlled with standard headers or cookies. The intermediary may 253 be a participant in the transport (e.g., changing framing or 254 encapsulation). 256 Defacto HTTP relay: Some streaming transports use the common 257 behavior of HTTP intermediaries to forward content packet-by- 258 packet. This relies on intermediaries to not cache or buffer 259 content. 261 Enhanced HTTP relay: Uses yet-to-be-defined HTTP headers to assist 262 HTTP based bidirectional transports. The intermediary may be a 263 participant in the transport (e.g., changing framing or 264 encapsulation). 266 Upgraded HTTP relay: Uses HTTP upgrade to relay a non-HTTP protocol. 268 Tunneled relay: Uses (or abuses?) the CONNECT mechanism to simulate 269 an SSL connection to be used as a tunnel for a non-HTTP transport. 271 6. Acknowledgments 273 7. IANA Considerations 275 This document does not require any actions by the IANA. 277 8. Security Considerations 279 To follow. 281 9. Informative References 283 [I-D.hixie-thewebsocketprotocol] 284 Hickson, I., "The Web Socket protocol", 285 draft-hixie-thewebsocketprotocol-48 (work in progress), 286 October 2009. 288 [W3C.WD-XMLHttpRequest2-20090820] 289 Kesteren, A., "XMLHttpRequest Level 2", World Wide Web 290 Consortium WD WD-XMLHttpRequest2-20090820, August 2009, 291 . 293 [W3C.WD-cors-20090317] 294 Kesteren, A., "Cross-Origin Resource Sharing", World Wide 295 Web Consortium WD WD-cors-20090317, March 2009, 296 . 298 [W3C.WD-eventsource-20090423] 299 Hickson, I., "Server-Sent Events", World Wide Web 300 Consortium WD WD-eventsource-20090423, April 2009, 301 . 303 Authors' Addresses 305 Salvatore Loreto 306 Ericsson 307 Hirsalantie 11 308 Jorvas 02420 309 Finland 311 Email: salvatore.loreto@ericsson.com 313 Peter Saint-Andre 314 Cisco 316 Email: psaintan@cisco.com 318 Greg Wilkins 319 Webtide 321 Email: gregw@webtide.com 323 Stefano Salsano 324 Univ. of Rome "Tor Vergata" 325 Via del Politecnico, 1 326 Rome 00133 327 Italy 329 Email: stefano.salsano@uniroma2.it