idnits 2.17.1 draft-loreto-hybi-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 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 (March 8, 2010) is 5156 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 == Outdated reference: A later version (-76) exists of draft-hixie-thewebsocketprotocol-75 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HYBI S. Loreto 3 Internet-Draft Ericsson 4 Intended status: Informational March 8, 2010 5 Expires: September 9, 2010 7 HyBi Requirements and Features 8 draft-loreto-hybi-requirements-01 10 Abstract 12 This document considers the requirements and resulting features 13 needed for the design of the WebSocket Protocol. The goal of the 14 document is to provide a stable base for protocol design and related 15 discussion. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 9, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. HyBi 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. Normative References . . . . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 HTTP [RFC2616] is a client/server protocol, where the HTTP servers 74 store the data and provide it when it is requested by clients. When 75 used to used to retrieve data from an HTTP server, the client sends 76 HTTP requests to the server, and the server returns the requested 77 data in HTTP responses. So the client has to poll continuously the 78 server in order to receive new data. 80 Recently techniques that enable bidirectional communication over HTTP 81 have become more pervasive. Those techniques reduce the need to poll 82 continuously the server thanks to the usage of HTTP hanging requests 83 and multiple connections between the client and the server 84 [I-D.loreto-http-bidirectional]. 86 The goal of HyBi is to provide an efficient and clean two-way 87 communication channel between client and server. 89 The communication channel will: 91 o allow each side to, independently from the other, send data when 92 is willing and ready to do it; 94 o rely on a single TCP connection for traffic in both the 95 directions. 97 o reduce the high overhead produced by HTTP headers in each request/ 98 response. 100 The goal of this work is to provide the set of requirements the 101 WebSocket Protocol MUST meet. 103 In the following sections we list and analyse the requirements from 104 the perspective of clients and servers. 106 2. Terminology 108 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 109 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 110 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 111 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 112 levels for compliant implementations. 114 2.1. HyBi Terminology 116 This document uses the following HyBi-related terms: 118 connection: A transport layer virtual circuit established between a 119 client and a server for the purpose of communication. 121 frame: The basic unit of WebSocket communication, consisting of a 122 structured sequence of octets matching the syntax defined in the 123 actual protocol and transmitted on the established communication 124 channel. 126 message: user message: a block of related data with identified 127 boundaries. 129 origin server: The server on which a given resource resides or is to 130 be created. 132 3. WebSocket Requirements 134 The following requirements fro WebSocket Protocol have been 135 identified both in the HyBi wg input document 136 [I-D.hixie-thewebsocketprotocol] and in the HyBi mailing list 137 dicussion. 139 REQ. 1: The WebSocket Protocol MUST run directly on top of a 140 transport protocol (e.g. TCP, UDP or SCTP, DCCP). 142 REQ. 2: The WebSocket Protocol MUST be able to handle (send and 143 receive) messages on top of a TCP data stream connection. 145 Reason: transfer data as message prevents the receiver to parse/ 146 handle partial content. 148 REQ. 3: It MUST be possible to sent a message when the total size is 149 either unknown or exceeds a fixed buffer size. 151 Reason: This will allow dynamic messages to be constructed and sent 152 without the need to buffer the entire message. 154 REQ. 4: Textual data MUST be encoded as UTF-8. 156 REQ. 5: The protocol MUST be designed to support different frame 157 types (e.g. binary). 159 REQ. 6: The WebSocket protocol MUST allow HTTP and WebSocket 160 connections to be served from the same port. Consideration MUST 161 be given: 163 * to provide WebSocket services via modules that plug in to 164 existing web infrastructure. 166 * to making it possible and practical to implement standalone 167 implementations of the protocol without requiring a fully 168 conforming HTTP implementation. 170 Reason: Some server developers would like to integrate WebSocket 171 support into existing HTTP servers. In addition, the default HTTP 172 and HTTPS ports are ofter favoured for traffic that has to go through 173 a firewall, so service providers will likely want to be able to use 174 WebSocket over ports 80 and 443, even when running a We server on the 175 same host. However there could be scenarios where it is not 176 opportune or possible to setup a proxy on the same HTTP server. 178 REQ. 7: When sharing host and "well known" port with HTTP, the 179 WebSocket protocol MUST be HTTP compatible until both ends have 180 established the WebSocket protocol. 182 Reason: when operating on the standard HTTP ports, existing web 183 infrastructure may handle according to existing standards prior to 184 the establishment of the new protocol. 186 REQ. 8: The protocol SHOULD make it possible and practical to reuse 187 existing HTTP components where appropriate. 189 Reason: the re-usage of existing well-debugged software decreases the 190 number of implementation errors as well as the possibility to 191 introduce security holes especially and at the same time speed up the 192 development especially when the Web Socket server is implemented as 193 modules that plug in to existing popular Web servers. 195 3.1. WebSocket Client Requirements 197 REQ. 9: The WebSocket Client MUST be able to set up a communication 198 channel sending to a WebSocket Server a well defined handshake. 200 REQ. 10: WebSocket Protocol MUST provide for graceful close of an 201 active WebSocket connection on request from the user Application. 203 Reason: a clean shutdown signals that the other endpoint has 204 definitely received all the messages sent prior the the close, so 205 there is no protocol uncertainty about what has been processed / what 206 can be retried on another connection. 208 OPEN ISSUE: WebSocket Protocol MUST also allow ungraceful close, 209 either on request from the user application or as a result of a 210 detected error condition. 212 REQ. 11: The WebSocket Client MUST be able to request the server, 213 during the handshake, to use a specific WebSocket sub-protocol. 215 REQ. 12: The WebSocket Client MUST have the ability to send 216 arbitrary text content to the server on the established 217 communication channel, in the form of ordered discrete blocks. 219 REQ. 13: The WebSocket Client MUST have the ability to send 220 arbitrary binary content to the server on the established 221 communication channel, in the form of ordered discrete blocks. 223 3.2. WebSocket Server Requirements 225 REQ. 14: The WebSocket Server that accept to set up, with a 226 WebSocket Client, a communication channel MUST send back to the 227 WebSocket Client a well defined handshake. 229 REQ. 15: The WebSocket Server MUST have the ability to send 230 arbitrary text content to the client on the established 231 communication channel, in the form of ordered discrete blocks. 233 REQ. 16: The WebSocket Server MUST have the ability to send 234 arbitrary binary content to the client on the established 235 communication channel, in the form of ordered discrete blocks. 237 3.3. WebSocket Proxies Requirements 239 Todo 241 3.4. WebSocket Security Requirements 243 REQ. 17: The WebSocket Protocol MUST use the Origin-based security 244 model commonly used by Web browsers to restrict which Web pages 245 can contact a WebSocket sever when the WebSocket protocol is used 246 from a Web page. 248 REQ. 18: When used directly (not from a Web page), the WebSocket 249 Protocol MUST use an equivalent security model. 251 REQ. 19: WebSocket should be designed to be robust against cross- 252 protocol attacks. The protocol design should consider and 253 mitigate the risk presented by WebSocket clients to existing 254 servers (including HTTP servers). It should also consider and 255 mitigate the risk to WebSocket servers presented by clients for 256 other protocols (including HTTP). 258 Reason: As the Web Socket protocol is expected to be mainly used in 259 browsers, a careful design is necessary to mitigate the chances for 260 hostile JavaScript to use WebSocket for a cross-protocol attack 261 against vanilla HTTP resources or non-HTTP servers. More the design 262 should prevent the possibility for cross-site XMLHttpRequest (using 263 CORS or XDomainRequest) to be used for a cross-protocol attack 264 against WebSocket resources, potentially violating integrity (though 265 not confidentiality). 267 4. Security Considerations 269 5. IANA Considerations 271 This requirements document does not mandate any immediate IANA 272 actions. However, such IANA considerations may arise from future 273 HyBi specification documents which try to meet the requirements given 274 here. 276 6. Acknowledgments 278 7. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 284 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 285 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 287 [I-D.loreto-http-bidirectional] 288 Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 289 "Best Practices for the Use of Long Polling and Streaming 290 in Bidirectional HTTP", draft-loreto-http-bidirectional-02 291 (work in progress), February 2010. 293 [I-D.hixie-thewebsocketprotocol] 294 Hickson, I., "The Web Socket protocol", 295 draft-hixie-thewebsocketprotocol-75 (work in progress), 296 February 2010. 298 Author's Address 300 Salvatore Loreto 301 Ericsson 302 Hirsalantie 11 303 Jorvas 02420 304 Finland 306 Email: salvatore.loreto@ericsson.com