idnits 2.17.1 draft-ietf-hybi-websocket-requirements-01.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 (August 23, 2010) is 4967 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-17) exists of draft-ietf-hybi-thewebsocketprotocol-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HYBI Working Group G. Montenegro, Ed. 3 Internet-Draft Microsoft Corporation 4 Intended status: Informational M. Stachowiak, Ed. 5 Expires: February 24, 2011 Apple 6 August 23, 2010 8 HyBi WebSocket Requirements and Features 9 draft-ietf-hybi-websocket-requirements-01 11 Abstract 13 This document considers the requirements and resulting features 14 needed for the design of the WebSocket Protocol. The goal of the 15 document is to provide a stable base for protocol design and related 16 discussion. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 24, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. WebSocket Requirements . . . . . . . . . . . . . . . . . . . . 4 61 3.1. WebSocket Client Requirements . . . . . . . . . . . . . . . 5 62 3.2. WebSocket Server Requirements . . . . . . . . . . . . . . . 6 63 3.3. WebSocket Proxies Requirements . . . . . . . . . . . . . . 6 64 3.4. WebSocket Security Requirements . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Appendix A. Change Log (to be removed by RFC Editor before 72 publication) . . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 HTTP [RFC2616] is a client/server protocol, where the HTTP servers 78 store the data and provide it when it is requested by clients. When 79 used to retrieve data from an HTTP server, the client sends HTTP 80 requests to the server, and the server returns the requested data in 81 HTTP responses. So the client has to poll continuously the server in 82 order to receive new data. 84 Recently, techniques that enable bidirectional communication over 85 HTTP have become more pervasive. Those techniques reduce the need to 86 poll continuously the server thanks to the usage of HTTP hanging 87 requests and multiple connections between the client and the server 88 [I-D.ietf-hybi-design-space]. 90 The goal of HyBi is to provide an efficient and clean two-way 91 communication channel between client and server. 93 The communication channel will: 95 o Allow each side to, independently from the other, send data when 96 it is willing and ready to do so. 98 o Rely on a single TCP connection for traffic in both directions. 100 o Reduce the high overhead produced by HTTP headers in each request/ 101 response. 103 The goal of this work is to provide the set of requirements the 104 WebSocket Protocol MUST meet. 106 In the following sections we list and analyse the requirements from 107 the perspective of clients and servers. 109 2. Terminology 111 This document uses the following HyBi-related terms: 113 connection: A transport layer virtual circuit established between a 114 client and a server for the purpose of communication. 116 frame: The basic unit of WebSocket communication, consisting of a 117 structured sequence of octets matching the syntax defined in the 118 actual protocol and transmitted on the established communication 119 channel. 121 message: user message: a block of related data with identified 122 boundaries. A message may comprise multiple frames. 124 origin server: The server on which a given resource resides or is to 125 be created. 127 WebSocket handshake: The process (and associated capability 128 negotiation) that sets up the WebSocket communication channel. 130 WebSocket communication channel: After the WebSocket handshake is 131 complete, the resultant bi-directional communication path between 132 client and server over the transport (e.g., TCP, or SSL over TCP). 134 WebSocket sub-protocol: The negotiated sub-protocol for use on a 135 WebSocket communication channel that dictates framing, encoding, 136 etc. 138 3. WebSocket Requirements 140 The following requirements for the WebSocket Protocol have been 141 identified both in the HyBi wg input document 142 [I-D.ietf-hybi-thewebsocketprotocol] and in the HyBi mailing list 143 dicussion. 145 REQ. 1: The WebSocket Protocol MUST run directly on top of the 146 transport protocol (over which the communication was running up to 147 and including the WebSocket handshake). 149 REQ. 2: The WebSocket Protocol MUST be able to handle (send and 150 receive) messages on the transport protocol (over which the 151 communication was running up to and including the WebSocket 152 handshake). 154 Reason: transfer data as message obviates the need for the receiver 155 to parse/handle partial content. 157 REQ. 3: The protocol MUST support the ability to fragment a message 158 into frames of a given length. 160 REQ. 4: It MUST be possible to send a message when the total size is 161 either unknown or exceeds a fixed buffer size. 163 Reason: This will allow dynamic messages to be constructed and sent 164 without the need to buffer the entire message. 166 REQ. 5: Textual data MUST be encoded as UTF-8. 168 REQ. 6: The protocol MUST support and clearly distinguish between 169 textual and binary data types (e.g. binary) via a common framing 170 with explicit length indication. 172 REQ. 7: The WebSocket protocol MUST allow HTTP and WebSocket 173 connections to be served from the same port. Consideration MUST 174 be given: 176 * to provide WebSocket services via modules that plug in to 177 existing web infrastructure. 179 * to making it possible and practical to implement standalone 180 implementations of the protocol without requiring a fully 181 conforming HTTP implementation. 183 Reason: Some server developers would like to integrate WebSocket 184 support into existing HTTP servers. In addition, the default HTTP 185 and HTTPS ports are ofter favoured for traffic that has to go through 186 a firewall, so service providers will likely want to be able to use 187 WebSocket over ports 80 and 443, even when running a Web server on 188 the same host. However there could be scenarios where it is not 189 opportune or possible to setup a proxy on the same HTTP server. 191 REQ. 8: If using an HTTP Upgrade exchange in the WebSocket 192 handshake, the protocol MUST be HTTP compatible up to and 193 including the Upgrade exchange. 195 REQ. 9: The protocol SHOULD make it possible and practical to reuse 196 existing HTTP components where appropriate. 198 Reason: Reusing existing well-debugged software decreases the number 199 of implementation errors as well as the possibility to introduce 200 security holes, and increases development speed, especially when the 201 WebSocket server is implemented as modules that plug in to existing 202 popular Web servers. 204 3.1. WebSocket Client Requirements 206 REQ. 10: The WebSocket Client MUST be able to set up a communication 207 channel with a WebSocket Server using a well-defined handshake. 209 REQ. 11: The WebSocket Protocol MUST provide for graceful close of 210 an active WebSocket connection on request from the user 211 Application. 213 Reason: a clean shutdown signals that the other endpoint has 214 definitely received all the messages sent prior to the close, so 215 there is no protocol uncertainty about what has been processed and 216 what can be retried on another connection. 218 REQ. 12: WebSocket Protocol MUST also allow ungraceful close, either 219 on request from the user application or as a result of a detected 220 error condition. 222 REQ. 13: The WebSocket Client MUST be able to request the server, 223 during the handshake, to use a specific WebSocket sub-protocol. 225 REQ. 14: The WebSocket Client MUST have the ability to send and 226 clearly distinguish between arbitrary text or binary content to 227 the server on the established communication channel. 229 3.2. WebSocket Server Requirements 231 REQ. 15: The WebSocket Server that accepts to set up a communication 232 channel with a WebSocket Client MUST use a well-defined handshake. 234 REQ. 16: The WebSocket Server MUST have the ability to send and 235 clearly distinguish between arbitrary text or binary content to 236 the client on the established communication channel. 238 3.3. WebSocket Proxies Requirements 240 Todo 242 REQ. 17: The WebSocket protocol MUST work over existing proxies to 243 the same extent as HTTP or HTTPS already does. 245 Reason: This is in line with Req on HTTP compliance. 247 3.4. WebSocket Security Requirements 249 REQ. 18: The WebSocket Protocol MUST use the Origin-based security 250 model commonly used by Web browsers to restrict which Web pages 251 can contact a WebSocket sever when the WebSocket protocol is used 252 from a Web page. 254 REQ. 19: When used directly (not from a Web page), the WebSocket 255 Protocol MUST use a security model equivalent to that of direct 256 HTTP or HTTPS usage. 258 REQ. 20: WebSocket should be designed to be robust against cross- 259 protocol attacks. The protocol design should consider and 260 mitigate the risk presented by WebSocket clients to existing 261 servers (including HTTP servers). It should also consider and 262 mitigate the risk to WebSocket servers presented by clients for 263 other protocols (including HTTP). 265 Reason: As the WebSocket protocol is expected to be often used in 266 browsers, a careful design is necessary to mitigate the chances for 267 hostile JavaScript to use WebSocket for a cross-protocol attack 268 against vanilla HTTP resources or non-HTTP servers. More the design 269 should prevent the possibility for cross-site XMLHttpRequest (using 270 CORS or XDomainRequest) to be used for a cross-protocol attack 271 against WebSocket resources, potentially violating integrity (though 272 not confidentiality). 274 4. Security Considerations 276 5. IANA Considerations 278 This requirements document does not mandate any immediate IANA 279 actions. However, such IANA considerations may arise from future 280 HyBi specification documents which try to meet the requirements given 281 here. 283 6. Acknowledgments 285 The initial requirements were created by Salvatore Loreto. Thanks to 286 Greg Wilkins for fulfilling previous editing duties. 288 7. References 290 7.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 296 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 297 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 299 [I-D.ietf-hybi-thewebsocketprotocol] 300 Hickson, I., "The WebSocket protocol", 301 draft-ietf-hybi-thewebsocketprotocol-00 (work in 302 progress), May 2010. 304 7.2. Informative References 306 [I-D.ietf-hybi-design-space] 307 Moffitt, J., Loreto, S., Saint-Andre, P., and S. Salsano, 308 "Design Space for Bidirectional Protocols", 309 draft-ietf-hybi-design-space-00 (work in progress), 310 June 2010. 312 Appendix A. Change Log (to be removed by RFC Editor before publication) 314 From version -00 to version -01: 316 o Modified definition of a Message to reflect recent consensus that 317 it may comprise multiple frames. 319 o Added definitions for WebSocket handshake, WebSocket communication 320 channel and WebSocket sub-protocol. 322 o Updated references to official IETF documents, moved "design- 323 space" to informational. 325 o Added a new requirement to support the ability to fragment a 326 message into frames of a given length 328 o Reworded Req 5 to reflect recent consensus on "binary+data" as 329 well as common framing with explicit length indication 331 o Reworded Req 7 to reflect recent consensus (declared in 332 Maastricht) on "HTTP compliance" 334 o Reworded Req 12 and 13 into a single Req on the client being able 335 to send text or binary content. Elided mention of "discrete 336 blocks" as the structure of messages is captured elsewhere. 338 o Reworded Req 15 and 16 into a single Req on the server being able 339 to send text or binary content. Elided mention of "discrete 340 blocks" as the structure of messages is captured elsewhere. 342 o Added a requirement in the proxies requirements section along the 343 lines of the HTTP compliance requirement, per consensus declared 344 in Maastricht. 346 o Modified security requirement when used from outside a browser to 347 avoid wording in terms of a security model equivalent to that of 348 browser-based usage. 350 o Various editorial changes. 352 Authors' Addresses 354 Gabriel Montenegro (editor) 355 Microsoft Corporation 356 One Microsoft Way 357 Redmond 98052 358 USA 360 Email: gabriel.montenegro@microsoft.com 362 Maciej Stachowiak (editor) 363 Apple 365 Email: mjs@apple.com