idnits 2.17.1 draft-ietf-hybi-websocket-requirements-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 10, 2010) is 5097 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 (-07) exists of draft-loreto-http-bidirectional-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HYBI G. Wilkins, Ed. 3 Internet-Draft Webtide.com 4 Intended status: Informational M. Stachowiak, Ed. 5 Expires: November 11, 2010 Apple 6 May 10, 2010 8 HyBi WebSocket Requirements and Features 9 draft-ietf-hybi-websocket-requirements-00 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 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 11, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. HyBi Terminology . . . . . . . . . . . . . . . . . . . . . 3 55 3. WebSocket Requirements . . . . . . . . . . . . . . . . . . . . 4 56 3.1. WebSocket Client Requirements . . . . . . . . . . . . . . . 5 57 3.2. WebSocket Server Requirements . . . . . . . . . . . . . . . 6 58 3.3. WebSocket Proxies Requirements . . . . . . . . . . . . . . 6 59 3.4. WebSocket Security Requirements . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 HTTP [RFC2616] is a client/server protocol, where the HTTP servers 69 store the data and provide it when it is requested by clients. When 70 used to used to retrieve data from an HTTP server, the client sends 71 HTTP requests to the server, and the server returns the requested 72 data in HTTP responses. So the client has to poll continuously the 73 server in order to receive new data. 75 Recently techniques that enable bidirectional communication over HTTP 76 have become more pervasive. Those techniques reduce the need to poll 77 continuously the server thanks to the usage of HTTP hanging requests 78 and multiple connections between the client and the server 79 [I-D.loreto-http-bidirectional]. 81 The goal of HyBi is to provide an efficient and clean two-way 82 communication channel between client and server. 84 The communication channel will: 86 o allow each side to, independently from the other, send data when 87 is willing and ready to do it; 89 o rely on a single TCP connection for traffic in both the 90 directions. 92 o reduce the high overhead produced by HTTP headers in each request/ 93 response. 95 The goal of this work is to provide the set of requirements the 96 WebSocket Protocol MUST meet. 98 In the following sections we list and analyse the requirements from 99 the perspective of clients and servers. 101 2. Terminology 103 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 104 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 105 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 106 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 107 levels for compliant implementations. 109 2.1. HyBi 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. 124 origin server: The server on which a given resource resides or is to 125 be created. 127 3. WebSocket Requirements 129 The following requirements fro WebSocket Protocol have been 130 identified both in the HyBi wg input document 131 [I-D.hixie-thewebsocketprotocol] and in the HyBi mailing list 132 dicussion. 134 REQ. 1: The WebSocket Protocol MUST run directly on top of a 135 transport protocol (e.g. TCP, UDP or SCTP, DCCP). 137 REQ. 2: The WebSocket Protocol MUST be able to handle (send and 138 receive) messages on top of a TCP data stream connection. 140 Reason: transfer data as message prevents the receiver to parse/ 141 handle partial content. 143 REQ. 3: It MUST be possible to sent a message when the total size is 144 either unknown or exceeds a fixed buffer size. 146 Reason: This will allow dynamic messages to be constructed and sent 147 without the need to buffer the entire message. 149 REQ. 4: Textual data MUST be encoded as UTF-8. 151 REQ. 5: The protocol MUST be designed to support different frame 152 types (e.g. binary). 154 REQ. 6: The WebSocket protocol MUST allow HTTP and WebSocket 155 connections to be served from the same port. Consideration MUST 156 be given: 158 * to provide WebSocket services via modules that plug in to 159 existing web infrastructure. 161 * to making it possible and practical to implement standalone 162 implementations of the protocol without requiring a fully 163 conforming HTTP implementation. 165 Reason: Some server developers would like to integrate WebSocket 166 support into existing HTTP servers. In addition, the default HTTP 167 and HTTPS ports are ofter favoured for traffic that has to go through 168 a firewall, so service providers will likely want to be able to use 169 WebSocket over ports 80 and 443, even when running a We server on the 170 same host. However there could be scenarios where it is not 171 opportune or possible to setup a proxy on the same HTTP server. 173 REQ. 7: When sharing host and "well known" port with HTTP, the 174 WebSocket protocol MUST be HTTP compatible until both ends have 175 established the WebSocket protocol. 177 Reason: when operating on the standard HTTP ports, existing web 178 infrastructure may handle according to existing standards prior to 179 the establishment of the new protocol. 181 REQ. 8: The protocol SHOULD make it possible and practical to reuse 182 existing HTTP components where appropriate. 184 Reason: the re-usage of existing well-debugged software decreases the 185 number of implementation errors as well as the possibility to 186 introduce security holes especially and at the same time speed up the 187 development especially when the Web Socket server is implemented as 188 modules that plug in to existing popular Web servers. 190 3.1. WebSocket Client Requirements 192 REQ. 9: The WebSocket Client MUST be able to set up a communication 193 channel sending to a WebSocket Server a well defined handshake. 195 REQ. 10: WebSocket Protocol MUST provide for graceful close of an 196 active WebSocket connection on request from the user Application. 198 Reason: a clean shutdown signals that the other endpoint has 199 definitely received all the messages sent prior the the close, so 200 there is no protocol uncertainty about what has been processed / what 201 can be retried on another connection. 203 OPEN ISSUE: WebSocket Protocol MUST also allow ungraceful close, 204 either on request from the user application or as a result of a 205 detected error condition. 207 REQ. 11: The WebSocket Client MUST be able to request the server, 208 during the handshake, to use a specific WebSocket sub-protocol. 210 REQ. 12: The WebSocket Client MUST have the ability to send 211 arbitrary text content to the server on the established 212 communication channel, in the form of ordered discrete blocks. 214 REQ. 13: The WebSocket Client MUST have the ability to send 215 arbitrary binary content to the server on the established 216 communication channel, in the form of ordered discrete blocks. 218 3.2. WebSocket Server Requirements 220 REQ. 14: The WebSocket Server that accept to set up, with a 221 WebSocket Client, a communication channel MUST send back to the 222 WebSocket Client a well defined handshake. 224 REQ. 15: The WebSocket Server MUST have the ability to send 225 arbitrary text content to the client on the established 226 communication channel, in the form of ordered discrete blocks. 228 REQ. 16: The WebSocket Server MUST have the ability to send 229 arbitrary binary content to the client on the established 230 communication channel, in the form of ordered discrete blocks. 232 3.3. WebSocket Proxies Requirements 234 Todo 236 3.4. WebSocket Security Requirements 238 REQ. 17: The WebSocket Protocol MUST use the Origin-based security 239 model commonly used by Web browsers to restrict which Web pages 240 can contact a WebSocket sever when the WebSocket protocol is used 241 from a Web page. 243 REQ. 18: When used directly (not from a Web page), the WebSocket 244 Protocol MUST use an equivalent security model. 246 REQ. 19: WebSocket should be designed to be robust against cross- 247 protocol attacks. The protocol design should consider and 248 mitigate the risk presented by WebSocket clients to existing 249 servers (including HTTP servers). It should also consider and 250 mitigate the risk to WebSocket servers presented by clients for 251 other protocols (including HTTP). 253 Reason: As the Web Socket protocol is expected to be mainly used in 254 browsers, a careful design is necessary to mitigate the chances for 255 hostile JavaScript to use WebSocket for a cross-protocol attack 256 against vanilla HTTP resources or non-HTTP servers. More the design 257 should prevent the possibility for cross-site XMLHttpRequest (using 258 CORS or XDomainRequest) to be used for a cross-protocol attack 259 against WebSocket resources, potentially violating integrity (though 260 not confidentiality). 262 4. Security Considerations 264 5. IANA Considerations 266 This requirements document does not mandate any immediate IANA 267 actions. However, such IANA considerations may arise from future 268 HyBi specification documents which try to meet the requirements given 269 here. 271 6. Acknowledgments 273 The initial requirements were created by the HyBi chair Salvatore 274 Loreto . 276 7. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 282 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 283 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 285 [I-D.loreto-http-bidirectional] 286 Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 287 "Best Practices for the Use of Long Polling and Streaming 288 in Bidirectional HTTP", draft-loreto-http-bidirectional-02 289 (work in progress), February 2010. 291 [I-D.hixie-thewebsocketprotocol] 292 Hickson, I., "The WebSocket protocol", 293 draft-hixie-thewebsocketprotocol-76 (work in progress), 294 May 2010. 296 Authors' Addresses 298 Greg Wilkins (editor) 299 Webtide.com 300 644 Emerson Street,Suite 200 301 Palo Alto 94301 302 USA 304 Email: gregw@webtide.com 306 Maciej Stachowiak (editor) 307 Apple 309 Email: mjs@apple.com