idnits 2.17.1 draft-ietf-hybi-design-space-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (Jun 28, 2010) is 5022 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-abarth-origin-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moffitt, Ed. 3 Internet-Draft Collecta 4 Intended status: Informational S. Loreto 5 Expires: December 30, 2010 Ericsson 6 P. Saint-Andre 7 Cisco 8 S. Salsano 9 Univ. of Rome "Tor Vergata" 10 Jun 28, 2010 12 Design Space for Bidirectional Protocols 13 draft-ietf-hybi-design-space-00 15 Abstract 17 As technologies for bidirectional communication over HTTP have become 18 pervasive, interest has grown in (1) defining improved mechanisms for 19 support of existing technologies (short-term solutions such as new 20 HTTP headers) and (2) the development of new bidirectional protocols 21 (long-term solutions such as WebSocket, Bidirectional Web Transfer 22 Protocol, and Reverse HTTP). In order to provide context for such 23 work, this document provides a tentative map of the design space for 24 bidirectional HTTP, with special attention to deployed infrastructure 25 (e.g. web clients, intermediaries, firewalls, NATs, web servers) and 26 programming environments. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 30, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Concerns and criteria . . . . . . . . . . . . . . . . . . . . . 3 64 3. Server side . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 9. Informative References . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 As technologies for bidirectional communication over HTTP have become 76 pervasive, interest has grown in (1) defining improved mechanisms for 77 support of existing technologies (short-term solutions such as new 78 HTTP headers) and (2) the development of new bidirectional protocols 79 (long-term solutions such as WebSocket, Bidirectional Web Transfer 80 Protocol, and Reverse HTTP). In order to provide context for such 81 work, this document provides a tentative map of the design space for 82 bidirectional HTTP, with special attention to deployed infrastructure 83 (e.g. web clients, intermediaries, firewalls, NATs, web servers) and 84 programming environments. 86 In existing HTTP-based systems, the typical architecture is client- 87 server Representational State Transfer (REST), where the resources 88 served are closely associated with an entity known by a URI or URL. 89 However, the introduction of bidirectionality can significantly 90 change the normal HTTP patterns. 92 For example, the standard roles of client and server can be reversed, 93 and a server can request resources from a client. Unfortunately, due 94 to the lack of client addressability, URLs may not be applicable to 95 client entities and new addressing paradigms may be required. 97 Furthermore, bidirectionality often introduces a message passing 98 pattern into the traditional REST style. 100 These additional semantics influence the design of bidirectional 101 protocols, addressing, and APIs. Without a strong association 102 between an identified entity and a resource, new mechanisms for 103 content distribution and caching messages will need to be considered. 105 In the following sections, the design space is analysed from the 106 perspective of clients, servers, and intermediaries. 108 2. Concerns and criteria 110 The process of evaluating improvements to existing bidirectional 111 solutions or development of new bidirectional protocols should take 112 into consideration the following concerns and criteria: 114 Complexity: enables ease of implementation, understanding, and 115 debugging 117 Capability: addresses a wide range of known bidirectional use-cases 119 Extensibility: has the capacity to handle new use-cases 121 Latency: minimizes latency and defines minimal, average, and maximal 122 latency for message delivery 124 Bandwidth overhead: minimizes overhead for idle and busy usage 126 Scalability: has the ability to handle large scale usage 128 Footprint: has the ability to handle small devices and/or massive 129 replication ("cloud") 131 AAA: enables proper Authentication, Authorization and Accounting 133 Security: enables strong security for integral, confidential, 134 endorsed, and cross-domain deployments 136 Interoperability: can work with and/or be integrated with existing 137 bidirectional implementations 139 Compatibility: can work with existing web infrastructure for 140 distributing, caching, manipulating, and displaying content 142 3. Server side 144 The server side can be decomposed into three categories: 146 Standard HTTP In this category two scenarios are possible: 148 In the first scenario, the bidirectionality is part of the normal 149 HTTP server responsibilities. HTTP is used for transport of the 150 server events. Examples include Comet and (in some deployments) 151 BOSH. 153 In the second scenario two servers are involved. Bidirectionality 154 is not part of the normal HTTP server responsibilities, and a push 155 service is offered by a separate server that may reside on a 156 different machine from the HTTP server. HTTP is used for 157 transport of the server events. 159 In the latter scenario, when a browser is used on the client side, 160 a cross-domain solution is needed to overcome the same-origin 161 policy [I-D.abarth-origin]. Examples include BOSH (in some 162 deployments) and Lightstreamer. 164 In-band non-HTTP: Bidirectionality is part of the normal HTTP/Web 165 server responsibilities. However, server events are transported 166 on an upgraded HTTP connection. Examples include Bidirectional 167 Web Transfer Protocol (BWTP) and WebSockets 168 [I-D.hixie-thewebsocketprotocol]. 170 Out-of-band non-HTTP: Bidirectionality is offered by a dedicated 171 server using non HTTP protocol for transport server events. 172 Examples include WebSockets [I-D.hixie-thewebsocketprotocol]. 174 The Standard HTTP based servers can work with existing HTTP standards 175 or an enhanced HTTP. The enhanced HTTP would be a standardized set 176 of headers and behaviours that assist bidirectionality and cross- 177 domain concerns. 179 At present, a protocol that interacts heavily with JavaScript on the 180 client side often implies some constraints on the server side, such 181 that they have to use XML or JSON encapsulation or specific Unicode 182 encodings. JavaScript currently has no native ability to interact 183 with binary data as anything more than a blob. 185 4. Clients 187 Clients can be involved in bidirectional transport in the following 188 capacities: 190 In browser open standards with HTTP transport: For applications 191 written in a web browser scripting language (e.g. JavaScript) 192 within a browser client. Examples include Comet and BOSH. 194 In browser open standards with enhanced HTTP transport: For 195 applications written in a web browser scripting language (e.g. 196 JavaScript) within a browser client. Examples include Comet and 197 BOSH with cross-domain extensions. 199 Browsers using either standard HTTP transport or enhanced HTTP 200 transport typically use XMLHttpRequest (XHR) API 201 [W3C.WD-XMLHttpRequest2-20090820] allowing scripts to perform HTTP 202 client functionality. The XHR object can be used to perform 203 bidirectional HTTP using regular polling or long polling. 205 Some XHR implementations also support the cross-domain extension 206 [W3C.WD-cors-20090317], which overcomes the same-origin policy 207 [I-D.abarth-origin]. The same-origin policy restricts an 208 application running at one origin from interacting with another 209 origin. However, XHR and the CORS extension impose some 210 limitations on the headers that can be set by client-side code. 212 An alternative to developing with XHR directly is the Server-Sent 213 Events API [W3C.WD-eventsource-20090423]. The EventSource 214 interface enables servers to push data to Web pages over HTTP or 215 using dedicated server-push protocols. 217 In browser open standards with non HTTP transport: For applications 218 written in JavaScript within a browser client. Examples include 219 BWTP and WebSockets [I-D.hixie-thewebsocketprotocol]. 221 In browser with plugin: This is not of particular interest to IETF, 222 but should be noted as part of the design space. Examples include 223 BlazeDS. Several of the other protocols have also used plugins to 224 circumvent the same-origin policy. 226 Non-browser HTTP: A bidirectional client may be written outside of a 227 browser and use bidirectional web transports. Typically this is 228 done when a rich or minimal client requires a mature transport for 229 application protocol with request-response semantics or the 230 ability to bypass restrictive firewalls. Examples include the 231 Comet Java client, the Second Life Viewer, and several XMPP 232 clients. 234 Non browser non-HTTP: These are the typical non-HTTP protocol 235 clients like mail readers and file transfer utilities. 237 Non browser clients may also interact with servers using web 238 focused protocols such as WebSocket. 240 Browser based client logic must be implemented in JavaScript in 241 general, and this currently restricts the form of data which can be 242 manipulated by the client. A binary data API for JavaScript may 243 remove this restriction in the future. [open issue]. 245 5. Intermediaries 247 Intermediaries (e.g. proxies, gateways, caching servers, load 248 balancers) can be involved in bidirectional transport in several 249 capacities: 251 Legal HTTP relay: Transports such as long polling use intermediaries 252 to carry legal HTTP requests and responses. Any capabilities that 253 may interfere with bidirectional flow (e.g. caching) are 254 controlled with standard headers or cookies. The intermediary may 255 be a participant in the transport (e.g. changing framing or 256 encapsulation). 258 Defacto HTTP relay: Some streaming transports use the common 259 behavior of HTTP intermediaries to forward content packet-by- 260 packet. This relies on intermediaries to not cache or buffer 261 content. 263 Enhanced HTTP relay: Uses yet-to-be-defined HTTP headers to assist 264 HTTP based bidirectional transports. The intermediary may be a 265 participant in the transport (e.g. changing framing or 266 encapsulation). 268 Upgraded HTTP relay: Uses HTTP upgrade to relay a non-HTTP protocol. 270 Tunneled relay: Uses the CONNECT mechanism to simulate an SSL 271 connection to be used as a tunnel for a non-HTTP transport. 273 6. Acknowledgments 275 The bulk of this document was created by its original authors: 276 Salvatore Loreto, Peter Saint-Andre, Stefano Salsano, and Greg 277 Wilkins. 279 7. IANA Considerations 281 This document does not require any actions by the IANA. 283 8. Security Considerations 285 There are several security issues to consider with the types of 286 protocols mentioned: 288 Cross protocol attacks are an issue for browser based clients. An 289 attacker would attempt to initiate a connection to a service by 290 mimicking one protocol with another. For example, an attacker would 291 attempt to fake a WebSocket connection by misuse of XMLHttpRequest. 293 For protocols which span multiple TCP or HTTP connections (e.g. BOSH 294 and Comet), some consideration is needed to protect against data 295 injection. Each request may come from a different TCP connection or 296 even IP address, so the server must have some way to tell which 297 requests belong to the session. This is typically solved with 298 difficult to guess sequence numbers and session termination when 299 rogue sequence numbers are used. 301 Since browser based clients are the most common, and JavaScript has 302 no facilities for binary data manipulation, cryptographic security 303 must be handled solely by the browser and server. This limits the 304 security possible with solutions that expose an existing service over 305 another protocol as the client cannot ensure secure transport for 306 anything but the immediate peer. 308 9. Informative References 310 [I-D.abarth-origin] 311 Barth, A., Jackson, C., and I. Hickson, "The Web Origin 312 Concept", draft-abarth-origin-06 (work in progress), 313 November 2009. 315 [I-D.hixie-thewebsocketprotocol] 316 Hickson, I., "The WebSocket protocol", 317 draft-hixie-thewebsocketprotocol-76 (work in progress), 318 May 2010. 320 [W3C.WD-XMLHttpRequest2-20090820] 321 Kesteren, A., "XMLHttpRequest Level 2", World Wide Web 322 Consortium WD WD-XMLHttpRequest2-20090820, August 2009, 323 . 325 [W3C.WD-cors-20090317] 326 Kesteren, A., "Cross-Origin Resource Sharing", World Wide 327 Web Consortium WD WD-cors-20090317, March 2009, 328 . 330 [W3C.WD-eventsource-20090423] 331 Hickson, I., "Server-Sent Events", World Wide Web 332 Consortium WD WD-eventsource-20090423, April 2009, 333 . 335 Authors' Addresses 337 Jack Moffitt (editor) 338 Collecta 340 Email: jack@collecta.com 341 Salvatore Loreto 342 Ericsson 343 Hirsalantie 11 344 Jorvas 02420 345 Finland 347 Email: salvatore.loreto@ericsson.com 349 Peter Saint-Andre 350 Cisco 352 Email: psaintan@cisco.com 354 Stefano Salsano 355 Univ. of Rome "Tor Vergata" 356 Via del Politecnico, 1 357 Rome 00133 358 Italy 360 Email: stefano.salsano@uniroma2.it