idnits 2.17.1 draft-ietf-hybi-websocket-multiplexing-11.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6455]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2013) is 3951 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HyBi Working Group J. Tamplin 3 Internet-Draft T. Yoshino 4 Intended status: Standards Track Google, Inc. 5 Expires: January 3, 2014 July 2, 2013 7 A Multiplexing Extension for WebSockets 8 draft-ietf-hybi-websocket-multiplexing-11 10 Abstract 12 The WebSocket Protocol [RFC6455] requires a new transport connection 13 for every WebSocket connection. This presents a scalability problem 14 when many clients connect to the same server, and is made worse by 15 having multiple clients running in different tabs of the same user 16 agent. This extension provides a way for separate logical WebSocket 17 connections to share an underlying transport connection. 19 Please send feedback to the hybi@ietf.org mailing list. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 3, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Physical Connection and Logical Channels . . . . . . . . . 3 57 1.2. Usecase . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 4 59 3. Multiplexed Connections . . . . . . . . . . . . . . . . . . . 5 60 4. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 7 61 5. Interaction with other Extensions / Framing Mechanisms . . . . 8 62 5.1. Ordering Extensions . . . . . . . . . . . . . . . . . . . 8 63 5.1.1. Efficiency . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. New Channel Slot . . . . . . . . . . . . . . . . . . . . . 10 67 6.2. Send Quota . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 8. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9. Multiplex Control Messages . . . . . . . . . . . . . . . . . . 16 71 9.1. Number Encoding in Multiplex Control Blocks . . . . . . . 17 72 9.2. AddChannelRequest . . . . . . . . . . . . . . . . . . . . 17 73 9.3. AddChannelResponse . . . . . . . . . . . . . . . . . . . . 19 74 9.4. FlowControl . . . . . . . . . . . . . . . . . . . . . . . 20 75 9.5. DropChannel . . . . . . . . . . . . . . . . . . . . . . . 21 76 9.5.1. Drop Reason Codes . . . . . . . . . . . . . . . . . . 23 77 9.6. NewChannelSlot . . . . . . . . . . . . . . . . . . . . . . 25 78 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 11. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 30 80 12. Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . 31 81 13. Fairness among Logical Channels . . . . . . . . . . . . . . . 32 82 14. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 83 15. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 84 16. Close the Logical Channel . . . . . . . . . . . . . . . . . . 35 85 17. Fail the Logical Channel . . . . . . . . . . . . . . . . . . . 36 86 18. Fail the Physical Connection . . . . . . . . . . . . . . . . . 37 87 19. Operations and Events on Multiplexed Connection . . . . . . . 38 88 20. Security Considerations . . . . . . . . . . . . . . . . . . . 39 89 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 90 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 91 22.1. Normative References . . . . . . . . . . . . . . . . . . . 41 92 22.2. Informative References . . . . . . . . . . . . . . . . . . 41 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 95 1. Overview 97 This document describes a multiplexing extension for the WebSocket 98 Protocol. With this extension, one TCP connection can provide 99 multiple virtual WebSocket connections by encapsulating messages 100 tagged with a channel ID. A client that supports this extension will 101 advertise support for it in the client's opening handshake using the 102 "Sec-WebSocket-Extensions" header. If a server supports this 103 extension and configuration offered by the extension parameters in 104 the peer client's request, the server accepts the use of this 105 extension by including a response in the "Sec-WebSocket-Extensions" 106 header in the server's opening handshake. 108 1.1. Physical Connection and Logical Channels 110 Under use of this extension, one transport connection is shared by 111 multiple application-level instances. The WebSocket connection which 112 lies directly on the TCP connection and negotiated this multiplexing 113 extension is called "physical connection". Virtual WebSocket 114 connections established for each application-level instance are 115 called "multiplexed connections". Data channels virtually 116 established by ID tagging are called "logical channels". This 117 extension assigns a non-zero integer ID for each multiplexed 118 connection. Each logical channel with a non-zero integer ID 119 exchanges frames of the multiplexed connection of that ID. The 120 logical channel with an ID of 0 exchanges data to control 121 multiplexing. 123 The ID used for distinguishing data for different logical channels is 124 attached to each encapsulated frames. It is placed at the head of a 125 message that encapsulates the original frame of a multiplex 126 connection. The field is called "logical channel ID tag field". 128 1.2. Usecase 130 Multiplexing could be done by using Web Workers. One limitation of 131 Web Workers is that it cannot multiplex traffic for different 132 origins. WebSocket protocol level multiplexing enables that. Large 133 scale service provides may employ layer-7 load balancing system. For 134 such system, it's good that multiplexing is specified at the protocol 135 level, not application level. 137 2. Conformance Requirements 139 All diagrams, examples, and notes in this specification are non- 140 normative, as are all sections explicitly marked non-normative. 141 Everything else in this specification is normative. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC2119 [RFC2119]. 147 Requirements phrased in the imperative as part of algorithms (such as 148 "strip any leading space characters" or "return false and abort these 149 steps") are to be interpreted with the meaning of the key word 150 ("must", "should", "may", etc) used in introducing the algorithm. 152 Conformance requirements phrased as algorithms or specific steps MAY 153 be implemented in any manner, so long as the end result is 154 equivalent. (In particular, the algorithms defined in this 155 specification are intended to be easy to follow, and not intended to 156 be performant.) 158 3. Multiplexed Connections 160 This multiplexing extension maintains separate logical channels, each 161 of which provides fully the logical equivalent of an independent 162 WebSocket connection, including separate handshake headers. If the 163 multiplexing extension is successfully negotiated, one multiplexed 164 connection is automatically established, and the headers on the 165 client's and server's opening handshake of the physical connection 166 are automatically taken to mean ones for the multiplexed connection 167 after removing physical connection specific header entries. This 168 automatically opened multiplexed connection is called "Implicitly 169 Opened Connection". It's served by the logical channel with ID of 1 170 which is also implicitly opened on completion of the opening 171 handshake. 173 New logical channels are added by the client issuing the 174 AddChannelRequest multiplex control message. Note that only the 175 client may initiate new WebSocket connections. An AddChannelRequest 176 contains any handshake headers for the corresponding new multiplexed 177 connection. The server's AddChannelResponse likewise contains any 178 handshake headers for the corresponding new multiplexed connection. 180 Logical channel with an ID of 0 is reserved and called "control 181 channel". It's automatically opened for exchanging multiplex control 182 messages. 184 If there're existing connections between a client and a peer server 185 where this multiplexing extensions was successfully negotiated, and 186 the client wants to create a new logical channel, the client chooses 187 one from them and add a new logical channel to the connection. 188 Otherwise, the client SHOULD attempt to open a new underlying 189 connection to the server and open a new WebSocket connection on it. 191 Once the multiplexing extension is negotiated on a connection, all 192 frames of multiplexed connection are tagged with a channel ID number 193 and encapsulated into binary messages. Channel IDs are assigned by 194 the client on issuing an AddChannelRequest. 196 A receiver MAY process frames of different multiplexed connections in 197 parallel. A receiver MUST process multiplex control messages 198 exclusively. 200 A receiver MUST _Fail the Physical Connection_ if any of these rules 201 are violated by the sender. 203 If the tuple of /secure/ flag, /port/ [RFC6455] and the IP address 204 which /host/ [RFC6455] resolves to is the same for multiple 205 application instances, their connections may be multiplexed onto the 206 same physical connection by creating logical channels for each of the 207 instances. 209 A logical channel with /secure/ flag [RFC6455] and one without 210 /secure/ flag MUST NOT be multiplexed onto the same physical 211 connection. An endpoint may be required to open another physical 212 connection for this case even if there's an existing physical 213 connection with multiplexing extension successfully negotiated. For 214 example, if a client is configured to use different TLS client 215 certificates for each logical channel, the client needs to establish 216 separate TLS connections. 218 4. Extension Negotiation 220 The registered extension token for this extension is "mux". 222 To request use of the WebSocket Multiplexing Extension, a client 223 includes an element with the "mux" extension token as its extension 224 identifier in the "Sec-WebSocket-Extensions" header in the client's 225 opening handshake. The element MAY contain an extension parameter 226 named "quota". The value of the "quota" extension parameter 227 specifies the server's send quota for the "Implicitly Opened 228 Connection". 230 A server accepts use of the WebSocket Multiplexing Extension by 231 including an element with the "mux" extension token in the 232 "Sec-WebSocket-Extensions" header in the server's opening handshake. 233 The element has no extension parameter. 235 A server rejects use of the WebSocket Multiplexing Extension by not 236 including the element for the extension in the 237 "Sec-WebSocket-Extensions" header in the server's opening handshake. 238 If any elements were listed after the element for the WebSocket 239 Multiplexing Extension in the "Sec-WebSocket-Extensions" from the 240 client, they MUST also be rejected. 242 5. Interaction with other Extensions / Framing Mechanisms 244 If any extension (e.g. compression) is placed before this extension 245 in the "Sec-WebSocket-Extensions" header of the physical connection, 246 that extension is applied to multiplexed connections unless otherwise 247 noted in the extension's spec. 249 If any extension is placed after this extension in the 250 "Sec-WebSocket-Extensions" header of the physical connection, on the 251 sender side that extension is applied to frames after multiplexing, 252 and on the receiver side that extension is applied to frames before 253 demultiplexing, unless otherwise noted in the extension's spec. 255 A client MAY request an extension for both the physical connection 256 and the "Implicitly Opened Connection" by placing extension entries 257 before and after the entry of this multiplexing extension. If 258 enabling the extension for both the physical connection and 259 "Implicitly Opened Connection" doesn't make sense, the server rejects 260 either of them. 262 For example, if we have an extension called foobar that can be used 263 either the physical connection or multiplexed connections, the client 264 sends 266 Sec-WebSocket-Extensions: foobar, mux, foobar 268 in the client's opening handshake of the physical connection to 269 request use of the foobar extension for both physical and multiplexed 270 connections. Then, the server would send back 272 Sec-WebSocket-Extensions: mux, foobar 274 to apply the foobar extension for the _Implicitly Opened Connection_, 275 or 277 Sec-WebSocket-Extensions: foobar, mux 279 to apply the foobar extension to the physical connection. 281 5.1. Ordering Extensions 283 5.1.1. Efficiency 285 Where to apply a compression extension makes difference to resource 286 consumption and flexibility. Compression algorithms often use some 287 memory to keep its context. Some of compression extensions may keep 288 using the same context for all the messages on the same connection. 290 If such a compression extension is applied to the physical 291 connection, intermediaries that want to demultiplex or multiplex the 292 connection need to decompress (before demultiplexing) and recompress 293 (before multiplexing again) all the frames. 295 If such a compression extension is applied to each multiplexed 296 connection, we can control to which multiplexed connection we apply 297 the compression, so we can avoid applying compression to multiplexed 298 connections transferring incompressible data. For intermediaries 299 that want to demultiplex a connection with this extension and forward 300 encapsulating messages to different backends, it's also useful 301 because each encapsulating message can be forwarded without 302 uncompressing. However, compressing each multiplexed connection is 303 expensive in terms of memory consumption. 305 5.1.2. Security 307 If any history-based compression extension such as DEFLATE is applied 308 to the physical connection that is tunneled over Transport Layer 309 Security (TLS) [RFC2818], it may spoil TLS's confidentiality [CRIME]. 310 If the client may run malicious script such as a web browser, it MUST 311 NOT request use of the multiplexing extension and such a compression 312 extension in the order in which the compression extension is applied 313 to the physical connection side. 315 6. Flow Control 317 6.1. New Channel Slot 319 A client has a pool of slots called "new channel slots". It's 320 initialized to be empty on establishment of the physical connection. 322 A NewChannelSlot multiplex control message sent by the server adds 323 slots to the pool. 325 Each slot has a non-negative integer value called "initial send 326 quota". Its function is explained in the later subsection. 328 When sending an AddChannelRequest, a client picks the oldest new 329 channel slot from the pool and remove it from the pool. If there are 330 no slots in the pool, the client MUST NOT issue an AddChannelRequest 331 until a slot becomes available. An endpoint MUST _Fail the Logical 332 Channel_ with drop reason code of 2007 when it's clear that the other 333 peer violates this rule about new channel slots. 335 A server can regulate the rate of AddChannelRequests by not 336 replenishing the pool. 338 6.2. Send Quota 340 For each logical channel with non-zero ID, a server and client are 341 respectively given a non-negative integer value called "send quota". 343 For the logical channel created for the "Implicitly Opened 344 Connection", the client's "send quota" is initialized to 0 on 345 establishment of the physical connection. The server's "send quota" 346 for the logical channel is initialized when it sends its opening 347 handshake for the physical connection. The "quota" extension 348 parameter included in the extension offer for this multiplexing 349 extension in the client's opening handshake for the physical 350 connection specifies the initial value of the server's send quota. 351 If the "quota" extension parameter is not specified, the initial 352 value is set to 0. If the "quota" extension parameter is specified, 353 the initial value is the parameter's value parsed as a non-negative 354 integer in decimal. 356 For a logical channel added by issuing an AddChannelRequest, a client 357 gets "send quota" equal to the "initial send quota" value on the "new 358 channel slot" picked for that AddChannelRequest. Initialization 359 timing is when the client completes sending the AddChannelRequest. 361 For a logical channel added by accepting an AddChannelRequest, a 362 server gets "send quota" of 0. Initialization timing is when the 363 server completes sending the corresponding AddChannelResponse. 365 When an endpoint receives a FlowControl for a logical channel, its 366 "send quota" for the channel gets replenished. 368 An endpoint MUST NOT send a frame on a logical channel with non-zero 369 ID while the "send quota" of the endpoint for that logical channel is 370 less than the cost of the frame. The cost of a frame is sum of the 371 following two values: 373 o The length of the "Payload data" of the frame. 375 o Per-message extra cost. It's 1 if the frame is the first fragment 376 of a message. Otherwise, it's 0. 378 An endpoint MUST _Fail the Logical Channel_ with drop reason code of 379 3005 when it's clear that the other peer violates this rule about 380 send quota. 382 When a frame is sent on a logical channel with non-zero ID, the cost 383 of the frame is subtracted from the "send quota" of the endpoint for 384 that logical channel. 386 An endpoint SHOULD NOT delay replenishment of the other peer's "send 387 quota" for a logical channel when it has more room for accepting new 388 data for the channel unless the size of quota it can replenish is too 389 small and therefore replenishing it pushes down overall performance. 391 7. Framing 393 The multiplexing extension uses binary messages to transfer both data 394 for controlling multiplexing and data of multiplexed connections. 395 These binary messages are called "encapsulating messages" and have 396 the logical channel ID tag field at the head of them. Logical 397 channel ID of 0 is designated for control channel where multiplex 398 control messages are exchanged. Non-zero logical channel IDs are 399 used for non-control channels transferring data for multiplexed 400 connections. 402 The ID in the logical channel ID tag field is encoded as variable 403 number of bytes (1, 2, 3 or 4 octets), as follows: 405 0 1 2 3 4 5 6 7 406 +-+-------------+ 407 |0|Channel ID(7)| 408 +-+-------------+ 410 0 1 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 412 +-+-+---------------------------+ 413 |1|0| Channel ID (14) | 414 +-+-+---------------------------+ 416 0 1 2 417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 418 +-+-+-+-----------------------------------------+ 419 |1|1|0| Channel ID (21) | 420 +-+-+-+-----------------------------------------+ 422 0 1 2 3 423 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 424 +-+-+-+---------------------------------------------------------+ 425 |1|1|1| Channel ID (29) | 426 +-+-+-+---------------------------------------------------------+ 428 This encoding is also used by multiplex control messages where we 429 need to specify the ID of the objective channel. 431 A field for which it's specified to use this encoding is considered 432 to be invalid when more than the minimal number of bytes necessary to 433 represent the integer is used. 435 Unless any other negotiated extension defines the meaning of 436 encapsulating messages with data opcodes other than binary, endpoints 437 MUST NOT send any data message other than "binary". An endpoint 438 received such a message MUST _Fail the Physical Connection_ with drop 439 reason code of 2001. 441 An endpoint received a binary message with an incomplete or invalid 442 logical channel ID tag field at the head of the message MUST _Fail 443 the Physical Connection_ with drop reason code of 2002. 445 See Section 8 (non-control channel) and Section 9 (control channel) 446 for more details about fields that follow the logical channel ID tag 447 field. 449 8. Encapsulation 451 This extension encapsulates each frame of a multiplexed connection 452 into an encapsulating message. Payload Data of an encapsulating 453 message is obtained by concatenating the following data in the order 454 they are listed: 456 1. The logical channel ID tag field representing the ID of the 457 logical channel for the multiplexed connection. 459 2. FIN, RSV1, RSV2, RSV3 and opcode of the original frame. 461 3. Unmasked "Payload Data" of the original frame. 463 0 1 2 3 464 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 465 +---------------------------------------------------------------+ 466 | Logical channel ID tag | 467 | (8/16/24/32) | 468 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 469 | Logical channel ID tag continued | 470 +-+-+-+-+-------+-----------------------------------------------+ 471 |F|R|R|R| opcode| Payload Data of original frame | 472 |I|S|S|S| (4) | | 473 |N|V|V|V| | | 474 | |1|2|3| | | 475 +-+-+-+-+-------+ - - - - - - - - - - - - - - - - - - - - - - - + 476 : Payload Data of original frame continued ... : 477 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 478 : Payload Data of original frame continued ... : 479 +---------------------------------------------------------------+ 481 A receiver restores the original frame from the Payload Data and 482 deliver the restored frame to the corresponding multiplexed 483 connection based on the ID in the logical channel ID tag field in the 484 order they are received. 486 This extension MAY change the fragmentation of the original message 487 before encapsulation in order to insert multiplex control messages or 488 adjust the amount of data to flush along with flow control. 490 When an encapsulated frame with non continuation data opcode is 491 received though the last encapsulated data message of that logical 492 channel has not yet been terminated by an encapsulated frame with the 493 FIN bit set, the endpoint MUST _Fail the Logical Channel_ with drop 494 reason code of 3009. 496 When an encapsulated frame with the continuation opcode is received 497 though there's no preceding encapsulated message that has not yet 498 been terminated on that logical channel, the endpoint MUST _Fail the 499 Logical Channel_ with drop reason code of 3009. 501 On logical channels, control messages MAY also be fragmented. 502 Fragmented control messages are delivered to the corresponding 503 multiplexed connection after receiving all fragments and 504 defragmenting them. For non-first fragments of a control message, 505 the continuation opcode (%x0) MUST be used for the opcode field as 506 well as data messages. On the same logical channel, fragments for 507 any other message MUST NOT be injected between fragments of a control 508 message. A demultiplexer received an encapsulated frame with a 509 control opcode and the FIN bit unset MUST process the following 510 encapsulated frames on the same logical channel as the encapsulated 511 fragments of that control message until it encounters one with the 512 FIN bit set. A demultiplexer encountered any encapsulated frame 513 whose opcode is not continuation injected between fragments of a 514 control message on the same logical channel MUST _Fail the Logical 515 Channel_ with drop reason code of 3009. 517 To allow for adjustment of fragmentation, this multiplexing extension 518 MUST NOT be used after any extension that does any of the followings: 520 o Require frame boundary on its output to be preserved. 522 o Use the "Extension data" field or any of the reserved bits on the 523 WebSocket header as per-frame attribute. 525 Intermediaries that don't understand the WebSocket Multiplexing 526 Extension MAY fragment the encapsulating messages. 528 When received a binary message with a non-zero logical channel ID of 529 an inactive channel (e.g. no channel has been opened for the logical 530 channel ID, or the channel has been closed (by a DropChannel or an 531 AddChannelResponse with the failure bit set) and not yet reopened), 532 the endpoint MUST ignore the message. 534 When received a binary message with a non-zero logical channel ID 535 which contains no octets in its payload after octets for the logical 536 channel ID tag field, the endpoint _Fail the Physical Connection_ 537 with drop reason code of 2003. 539 9. Multiplex Control Messages 541 A binary message with the logical channel ID of 0 contains one 542 multiplex control block in the "Payload data" portion. 544 0 1 2 3 4 5 6 7 545 +---------------+ 546 |Channel ID of 0| 547 +---------------+ 548 |Multiplex | 549 :control block : 550 | | 551 +---------------+ 553 Each multiplex control block has fields as follows: 555 0 1 2 3 4 5 6 7 556 +-----+---------+ 557 | Opc | | 558 +-----+ : 559 | Opc specific : 560 : data : 561 | | 562 +---------------+ 564 Opc 566 A multiplex control opcode as defined in the following 567 subsections. Opc of 5-7 are reserved for future use. 569 Opc specific data 571 Data interpreted according to that opcode. 573 Each of the following subsections describes one multiplex control 574 opcode and how to interpret opc specific data for that opcode. 576 If any reserved opcode is set to opc, the endpoint MUST _Fail the 577 Physical Connection_ with drop reason code of 2004. 579 If any truncated multiplex control message is found, the endpoint 580 MUST _Fail the Physical Connection_ with drop reason code of 2005 581 unless _Fail the Physical Connection_ is already done for any other 582 error. 584 RSVs in the field diagrams of multiplex control blocks in this 585 section means reserved bits. If any multiplex control block with any 586 of the reserved bits set is found, the endpoint MUST _Fail the 587 Physical Connection_ with drop reason code of 2005 unless _Fail the 588 Physical Connection_ is already done for any other error. 590 9.1. Number Encoding in Multiplex Control Blocks 592 In addition to the logical channel ID encoding defined in the 593 Section 7, we reuse the number encoding defined for payload length in 594 the Section 5.2 of [RFC6455] for multiplex control blocks with a 595 little modification. We call this number encoding "1/3/9 number 596 encoding". Integers up to 0x7D MUST be encoded into 1 octet field 597 containing the integer as is. Integers from 0x7E to 0xFFFF MUST be 598 encoded into an octet of 0x7E followed by two octets containing the 599 integer in network byte order. Integers from 0x10000 to 600 0x7FFFFFFFFFFFFFFF MUST be encoded into an octet of 0x7F followed by 601 eight octets containing the integer in network byte order. A field 602 using the 1/3/9 number encoding is considered to be invalid when any 603 of the following conditions is violated. 605 o The most significant bit of the first octet MUST be 0. 607 o The minimal number of bytes necessary to represent the integer 608 MUST be used. 610 o If the first byte is 0x7F, the most significant bit of the next 611 octet MUST be 0. 613 When received a multiplex control block with an invalid field using 614 the 1/3/9 number encoding, the endpoint MUST _Fail the Physical 615 Connection_ with drop reason code of 2005 unless _Fail the Physical 616 Connection_ is already done for any other error. 618 9.2. AddChannelRequest 620 AddChannelRequest is sent only by clients to create a new logical 621 channel, as if a new WebSocket connection were received on a separate 622 transport connection. 624 When a client received an AddChannelRequest, it MUST _Fail the 625 Physical Connection_ with drop reason code of 2005 unless _Fail the 626 Physical Connection_ is already done for any other error. 628 Multiplex control opcode of AddChannelRequest is 0. 630 AddChannelRequest has fields as follows: 632 0 1 2 3 4 5 6 7 633 +-+-+-+---------+ 634 |0|0|0| RSV | 635 +-+-+-+---------+ 636 |Objective | 637 :channel ID : 638 |(1-4 octet) | 639 +---------------+ 640 |Handshake | 641 : : 642 | | 643 +---------------+ 645 Objective channel ID 647 The ID of the logical channel objective to this operation. 648 Encoding is the same as one used for the logical channel ID tag 649 field. An endpoint MUST _Fail the Physical Connection_ with drop 650 reason code of 2005 if this field is invalid. 652 Handshake 654 The rest is the handshake field. The client's opening handshake 655 as defined in Section 4 of RFC 6455 [RFC6455] for the new 656 multiplexed connection including the CRLF following the last 657 header. The "Upgrade", "Sec-WebSocket-Key" and 658 "Sec-WebSocket-Version" header are excluded. The 659 "Sec-WebSocket-Extensions" header contains only extensions applied 660 to the multiplexed connection. An endpoint MUST _Fail the 661 Physical Connection_ with drop reason code of 2009 if any problem 662 is found in parsing this field. 664 If the logical channel ID specified by an AddChannelRequest is in use 665 (including 0 for the control channel), it MUST _Fail the Physical 666 Connection_ with drop reason code of 2006. 668 To accept an AddChannelRequest, the endpoint MUST send an 669 AddChannelResponse with the failure bit unset and the objective 670 channel ID field set to the objective channel ID specified in the 671 AddChannelRequest. In this case, the channel becomes active. 673 To respond to an AddChannelRequest with status meaning handshake 674 failure, the endpoint MUST send an AddChannelResponse with the 675 failure bit set and its objective channel ID field set to the 676 objective channel ID specified in the AddChannelRequest. In this 677 case, the channel stays inactive. 679 An endpoint MAY reject an AddChannelRequest also by doing _Fail the 680 Logical Channel_ with drop reason code of 3000. In this case, the 681 channel stays inactive. 683 A server MAY delay responding to an AddChannelRequest and proceed to 684 process subsequent multiplex control blocks or frames for multiplexed 685 connections. 687 Channel ID assignment is done by client side. A client MAY use any 688 algorithm to choose logical channel IDs for new channels. Note that 689 logical channel ID assignment might be changed by intermediaries, so 690 it's not guaranteed that the value of logical channel ID is the same 691 on the other peer. 693 Different from non-multiplexed WebSocket connection, a client MAY 694 send frames of multiplexed connections except for "Implicitly Opened 695 Connection" before receiving AddChannelResponse as far as there's 696 sufficient send quota. In case the AddChannelRequest fails, those 697 frames are discarded by the peer server. This doesn't mean that 698 users of this protocol such as the WebSocket API are required to 699 allow their users to send frames before receiving the server's 700 opening handshake. 702 9.3. AddChannelResponse 704 AddChannelResponse is sent only by servers in response to the 705 AddChannelRequest. 707 When a server received an AddChannelResponse, it MUST _Fail the 708 Physical Connection_ with drop reason code of 2005 unless _Fail the 709 Physical Connection_ is already done for any other error. 711 Multiplex control opcode of the AddChannelResponse is 1. 713 AddChannelResponse has fields as follows: 715 0 1 2 3 4 5 6 7 716 +-+-+-+-+-------+ 717 |0|0|1|F| RSV | 718 +-+-+-+-+-------+ 719 |Objective | 720 :channel ID : 721 |(1-4 octet) | 722 +---------------+ 723 |Handshake | 724 : : 725 | | 726 +---------------+ 728 F 730 Failure bit. 732 If the failure bit is not set, then the server has accepted the 733 AddChannelRequest. The handshake field contains a response to the 734 request made by the AddChannelRequest, In this case, the channel 735 becomes active. 737 If the failure bit is set, then the server has rejected the 738 AddChannelRequest and this SHOULD be treated exactly the same as 739 if a separate connection was attempted and the connection was 740 closed after receiving the server's handshake. Enc MUST be set to 741 identity in this case. The handshake field contains a response to 742 the request made by the AddChannelRequest. In this case, the 743 channel stays inactive. The sender of the AddChannelResponse with 744 the failure bit set doesn't have to send a DropChannel following 745 the AddChannelResponse. 747 Objective channel ID 749 Same as one in the AddChannelRequest. If an inactive channel is 750 specified, the endpoint MUST ignore this AddChannelResponse. 752 An endpoint MUST _Fail the Physical Connection_ with drop reason 753 code of 2005 if this field is invalid. 755 Handshake 757 The rest is the handshake field. The server's opening handshake 758 as defined in Section 4 of RFC 6455 [RFC6455] for this multiplexed 759 connection. The "Upgrade" and "Sec-WebSocket-Accept" header are 760 excluded. The "Sec-WebSocket-Extensions" header contains only 761 extensions applied to the multiplexed connection. This field is 762 encoded using the encoding specified by the Enc field. 764 An endpoint MUST _Fail the Physical Connection_ with drop reason 765 code of 2011 if any problem is found in parsing this field. 767 If the server's opening handshake is validated, the client MUST take 768 this as _The WebSocket Connection is Established_. 770 9.4. FlowControl 772 FlowControl is used to replenish the other peer's send quota for the 773 specified logical channel. 775 Multiplex control opcode of FlowControl is 2. 777 FlowControl has fields as follows. 779 0 1 2 3 4 5 6 7 780 +-+-+-+---------+ 781 |0|1|0| RSV | 782 +-+-+-+---------+ 783 |Objective | 784 :channel ID : 785 |(8-32 bit) | 786 +---------------+ 787 |Replenished | 788 :send quota : 789 |(1-9 octet) | 790 +---------------+ 792 Objective channel ID 794 Same as one in the AddChannelRequest. If an inactive channel is 795 specified, the endpoint MUST ignore this FlowControl. An endpoint 796 MUST _Fail the Physical Connection_ with drop reason code of 2005 797 if this field is invalid. 799 Replenished quota 801 The number of bytes the receiver can have outstanding towards the 802 sender of the FlowControl message. It's encoded by the 1/3/9 803 number encoding. 805 An endpoint MUST _Fail the Logical Channel_ with drop reason code of 806 3006 if its send quota for the channel exceeds 0x7FFFFFFFFFFFFFFF 807 when the replenished quota is added. The endpoint MAY delay this 808 _Fail the Logical Channel_ operation to process following multiplex 809 control blocks and encapsulating messages that don't affect this 810 logical channel. When received a FlowControl with an invalid value 811 in the replenished quota field, the endpoint MUST _Fail the Physical 812 Connection_ as specified above rather than taking it as overflow. 814 9.5. DropChannel 816 DropChannel is used to close a logical channel. 818 Multiplex control opcode of DropChannel is 3. 820 DropChannel has fields as follows: 822 0 1 2 3 4 5 6 7 823 +-+-+-+---------+ 824 |0|1|1| RSV | 825 +-+-+-+---------+ 826 |Objective | 827 :channel ID : 828 |(1-4 octet) | 829 +---------------+ 830 |Reason | 831 : : 832 | | 833 +---------------+ 835 Objective channel ID 837 Same as one in the AddChannelRequest. An endpoint MUST _Fail the 838 Physical Connection_ with drop reason code of 2005 if this field 839 is invalid. 841 Reason size 843 The size of the reason field encoded by the 1/3/9 number encoding. 844 A DropChannel block with 1-octet reason field MUST be considered 845 as a truncated multiplex control block. 847 Reason 849 The rest is the reason of closure. Reason MAY be empty. If 850 reason is not empty, the first two bytes MUST be a 2-byte unsigned 851 integer (in network byte order) representing a drop reason code. 852 Following the 2-byte integer, reason MAY contain UTF-8-encoded 853 human readable drop reason phrase. 855 When an endpoint received a DropChannel for an active non-control 856 channel, the endpoint MUST tear down the logical channel, and the 857 application instance that used the logical channel MUST treat this as 858 closure of underlying transport. 860 When an endpoint received a DropChannel in response to an 861 AddChannelRequest, the endpoint MUST abort creation of the logical 862 channel, and the application instance that requested creation of the 863 logical channel MUST treat this as closure of underlying transport 864 without receiving reply for the creation request. 866 When an endpoint sent or received a DropChannel for an active non- 867 control channel, the endpoint MUST mark the channel as inactive. If 868 the endpoint is server and it has not already sent a DropChannel for 869 the channel, it MUST send a DropChannel with drop reason code of 3008 870 so that the client can mark the ID of the channel available for a new 871 AddChannelRequest. 873 Once received a DropChannel for a non-control channel, the ID of the 874 logical channel becomes available again for a new AddChannelRequest. 876 9.5.1. Drop Reason Codes 878 Drop reason codes are 4 digit unsigned integers. 880 1000-1999 are for normal closure on a logical channel without any 881 multiplexing level error. These codes are used for dropping non- 882 control channels. 884 1000 Normal closure 886 DropChannel with this drop reason code is commonly sent when 887 _Close the WebSocket Connection_ is made on the multiplexed 888 connection. 890 2000-2999 are for errors that _Fail the Physical Connection_. These 891 codes are used for dropping the control channel. 893 2000 Physical connection failed 895 Used if a more specific error is not available. 897 2001 Invalid encapsulating message 899 Received a data message with non binary opcode. 901 2002 Channel ID is truncated or invalid 903 Received an encapsulating message with a logical channel ID which 904 is truncated or invalid. 906 2003 Encapsulated frame is truncated 908 Received an encapsulating message that contains only the logical 909 channel ID tag field with non-zero value. 911 2004 Unknown multiplex control opcode 913 Encountered a multiplex control block with unknown multiplex 914 opcode. 916 2005 Invalid multiplex control block 918 Encountered an invalid multiplex control block. E.g. objective 919 channel ID is truncated, reserved bit is raised. 921 2006 Channel already exists 923 Received an AddChannelRequest for an active logical channel. 925 2007 New channel slot violation 927 Received an AddChannelRequest though the other peer has no new 928 channel slot. 930 2008 New channel slot overflow 932 Received a NewChannelSlot that overflows the number of new channel 933 slots. 935 2009 Bad request 937 Received an AddChannelRequest with a malformed handshake. 939 2010 Unknown request encoding 941 Received an AddChannelRequest with an unknown encoding type. 943 2011 Bad response 945 Received an AddChannelResponse with a malformed handshake. 947 2012 Unknown response encoding 949 Received an AddChannelResponse with an unknown encoding type. 951 3000-3999 are for errors that _Fail the Logical channel_. These 952 codes are used for dropping non-control channels. 954 3000 Logical channel failed 956 Used if a more specific error is not available. 958 3005 Send quota violation 960 Received an encapsulating message exceeding send quota. 962 3006 Send quota overflow 964 Received a FlowControl that overflows send quota. 966 3007 Idle timeout 968 Terminating an idle logical channel. 970 3008 DropChannel acknowledged 972 Used for a DropChannel sent in response to received DropChannel. 973 When a server received a DropChannel and it hasn't sent any 974 DropChannel for that logical channel, the server MUST send a 975 DropChannel with this reason code so that the client can release 976 the channel ID and reuse it for a new AddChannelRequest safely. 978 3009 Bad fragmentation 980 Received an encapsulating message with bad fragmentation that 981 cannot be delivered to the corresponding multiplexed connection. 983 4000-4999 are for requesting the other peer to take some actions. 984 These codes are used for dropping non-control channels. 986 4001 Use another physical connection 988 The server is requesting the client to open a new physical 989 connection and use it than adding any more logical channel until 990 receiving a NewChannelSlot. A client received this reason code 991 SHOULD NOT issue an AddChannelRequest on this physical connection 992 until receiving a NewChannelSlot. 994 4002 Busy 996 The server is requesting the client to stop issuing an 997 AddChannelRequest until receiving a NewChannelSlot. A client 998 received this reason code SHOULD NOT issue an AddChannelRequest on 999 this physical connection until receiving a NewChannelSlot. 1001 9.6. NewChannelSlot 1003 NewChannelSlot is sent only by servers to add new slots to the 1004 client's new channel pool. 1006 When a server received an NewChannelSlot, it MUST _Fail the Physical 1007 Connection_ with drop reason code of 2005 unless _Fail the Physical 1008 Connection_ is already done for any other error. 1010 Multiplex control opcode of NewChannelSlot is 4. 1012 NewChannelSlot has fields as follows: 1014 0 1 2 3 4 5 6 7 1015 +-+-+-+-------+-+ 1016 |1|0|0| RSV |F| 1017 +-+-+-+-------+-+ 1018 |Number of slots| 1019 :(1-9 octet) : 1020 | | 1021 +---------------+ 1022 |Initial send | 1023 :quota : 1024 |(1-9 octet) | 1025 +---------------+ 1027 F 1029 Fallback bit. 1031 If the fallback bit is false, normal slot is added. 1033 If the fallback bit is true, fallback suggestion slot is added. 1034 Number of slots field and initial quota field MUST be 0 for 1035 fallback suggestion slot. When a client encounters a fallback 1036 suggestion slot, it MUST open a new physical connection and use it 1037 than adding any more logical channel on this physical connection 1038 until any normal slot is available. 1040 When received a NewChannelSlot block with the fallback bit set and 1041 any of the number of slots field or the initial quota field is not 1042 zero, the endpoint MUST _Fail the Physical Connection_ with drop 1043 reason code of 2005 unless _Fail the Physical Connection_ is 1044 already done for any other error. 1046 Number of slots 1048 The number of slots to add. It's encoded by the 1/3/9 number 1049 encoding. This value MAY be 0 when it makes sense. 1051 Initial quota 1053 The initial quota each of slots added by this NewChannelSlot gets. 1054 It's encoded by the 1/3/9 number encoding. 1056 When a client received a NewChannelSlot, the client MUST add new 1057 slots of the specified number. Each of new slots gets the specified 1058 initial send quota. 1060 10. Examples 1062 _This section is non-normative._ 1064 The examples below assume the handshake has already completed and the 1065 multiplexing extension was negotiated. Quotes are for clarity. 1067 Frames of encapsulating messages from client to server MUST be 1068 masked. The examples below are not masked for simplicity. 1070 0x82 0x0d 0x01 0x81 "Hello world" 1072 This is a non-fragmented text message of "Hello world" on logical 1073 channel 1 encapsulated into a non-fragmented encapsulating 1074 message. 1076 0x82 0x07 0x01 0x01 "Hello" 0x82 0x08 0x01 0x80 " world" 1078 This is a text message of "Hello world" fragmented into two frames 1079 of "Hello" and " world" on logical channel 1 encapsulated into two 1080 non-fragmented encapsulating messages. A multiplexer may change 1081 fragmentation of a message before encapsulation like this so that 1082 frames of other logical channels (including the control channel) 1083 can be injected in the middle of the message. 1085 0x82 0x07 0x01 0x01 "Hello" 0x82 0x05 0x02 0x81 "bye" 0x82 0x08 0x01 1086 0x80 " world" 1088 This example shows how data for two logical channels are 1089 interleaved. There're three non-fragmented encapsulating 1090 messages. As explained in the previous example, the text message 1091 of "Hello world" is split into two frames before encapsulation. 1092 The first and third frame in this example contain each of the two 1093 fragments of the text message of "Hello world" on logical channel 1094 1. The second frame contains a non-fragmented text message of 1095 "bye" on logical channel 2. 1097 0x82 0x04 0x01 0x01 "Te" 0x82 0x04 0x01 0x09 "Pi" 0x82 0x04 0x01 0x80 1098 "ng" 0x82 0x04 0x01 0x80 "xt" 1100 A ping message "Ping" is injected in the middle of a text message 1101 "Text" on the original connection. The multiplexer fragmented the 1102 ping message due to some reason into two fragments. 1104 0x02 0x07 0x01 0x81 "Hello" 0x80 0x06 " world" 1106 Encapsulating messages output from the multiplexer can be 1107 fragmented by intermediaries without knowledge of the Multiplexing 1108 Extension. This is an example of a fragmented encapsulating 1109 message. It's equivalent to the first example as a message. 1111 --- To be fixed --- 1113 This is a message on the control channel carrying one 1114 AddChannelRequest. The first two octets are the WebSocket 1115 headers. The 3rd octet is logical channel ID field of 0. The 4th 1116 octet has opcode and RSV field. Objective channel ID is 2. 1118 11. Client Behavior 1120 When a client is asked to _Establish a WebSocket Connection_ by some 1121 WebSocket application instance, it MAY choose to share an existing 1122 WebSocket connection if all of the following are true: 1124 o the multiplexing extension was successfully negotiated on that 1125 connection 1127 o the scheme portions of the URIs match exactly 1129 o the host portions of the URIs either match exactly or resolve to 1130 the same IP address (TBD: consider DNS rebind attacks) 1132 o the port portions of the URIs (either explicit or implied by the 1133 scheme) match exactly 1135 o the connection has an availablle logical channel ID 1137 If a client chooses to share the existing WebSocket connection with 1138 multiplexing, it sends an AddChannelRequest as described above. If 1139 an AddChannelRequest is accepted, WebSocket frames may be sent over 1140 that logical channel as normal. If the server rejects the 1141 AddChannelRequest, the client SHOULD attempt to open a new physical 1142 WebSocket connection (for example, in a shared hosting environment a 1143 server may not be prepared to multiplex connections from different 1144 customers despite having a single IP address for them). 1146 12. Buffering 1148 For data frames, a sender also SHOULD attempt to aggregate fragments 1149 into one packet of the underlying transport. However, care must be 1150 taken to avoid introducing excessive latency - the exact heuristics 1151 for delaying in order to aggregate blocks is TBD. 1153 13. Fairness among Logical Channels 1155 A multiplexing implementation may be requested to ensure reasonable 1156 fairness among the logical channels. This is accomplished in several 1157 ways: 1159 Receiver side 1161 o The receiver MAY limit the send quota of a logical channel by not 1162 replenishing it to make sure that any logical channel doesn't 1163 dominate the connection. 1165 o Determine send quota for a logical channel considering the 1166 processing capacity (buffer size, processing power, throughput, 1167 etc.) of that logical channel. For example, when a logical 1168 channel with excess load cannot drain data from the connection 1169 smoothly, the other logical channels get stuck even when they have 1170 room of processing capacity. Unless there's special need to give 1171 such a big quota for the channel, such condition just makes 1172 overall performance low. 1174 Sender side 1176 o Use a fair algorithm to select which logical channel's data to 1177 send in the next WebSocket message. Simple implementations may 1178 choose a round-robin scheduler, while more advanced 1179 implementations may adjust priority based on the amount or 1180 frequency of data sent by each logical channel. 1182 o Fragment a large message into smaller frames to prevent a large 1183 message in a logical channel occupying the physical connection and 1184 thus delaying messages in other logical channels. 1186 14. Proxies 1188 Proxies which do not multiplex/demultiplex are not affected by the 1189 presence of this extension -- they simply process WebSocket frames as 1190 usual. Proxies which filter or monitor WebSocket traffic will need 1191 to understand the multiplexing extension in order to extract the data 1192 from logical connections or to terminate individual logical 1193 connections when policy is violated. Proxies which actively 1194 multiplex connections or demultiplex them (for example, a mobile 1195 network might have a proxy which aggregates WebSocket connections at 1196 a single cell to conserve bandwidth to the main gateway) will require 1197 additional configuration (perhaps including the client) that is 1198 outside the scope of this document. 1200 15. Timeout 1202 When all the logical channels are closed, each endpoint MAY _Start 1203 the WebSocket Closing Handshake_ on the physical connection. Such 1204 _Start the WebSocket Closing Handshake_ operation SHOULD be delayed 1205 assuming the physical connection may be reused after some idle 1206 period. 1208 16. Close the Logical Channel 1210 To _Close the Logical Channel_, an endpoint MUST send a DropChannel 1211 multiplex control block with drop reason code of 1000. 1213 17. Fail the Logical Channel 1215 To _Fail the Logical Channel_, an endpoint MUST send a DropChannel 1216 multiplex control block with drop reason code in the range of 3000- 1217 3999, tear down the logical channel, and the application instance 1218 that used the logical channel MUST treat this as closure of 1219 underlying transport. 1221 18. Fail the Physical Connection 1223 To _Fail the Physical Connection_, an endpoint MUST send a 1224 DropChannel multiplex control block with objective channel ID of 0 1225 and drop reason code in the range of 2000-2999, and then _Fail the 1226 WebSocket Connection_ on the physical connection with status code of 1227 1011. 1229 19. Operations and Events on Multiplexed Connection 1231 When an endpoint is asked to perform any operation defined in the 1232 WebSocket Protocol except for _Close the WebSocket Connection_ by 1233 some application instance, the endpoint MUST perform the operation on 1234 the corresponding logical channel. 1236 Any event on a logical channel except for _The WebSocket Connection 1237 is Closed_, MUST be taken as one for the corresponding application 1238 instance. 1240 When an endpoint is asked to do _Close the WebSocket Connection_ by 1241 some application instance, it MUST perform _Close the Logical 1242 Channel_ on the corresponding logical channel. 1244 When a DropChannel is received, or the physical connection is closed, 1245 it MUST be taken as _The WebSocket Connection is Closed_ event for 1246 the corresponding application instance(s). 1248 What to set to _Extension In Use_ for each multiplexed connection is 1249 TBD. 1251 20. Security Considerations 1253 A client MUST be prepared to receive a NewChannelSlot with huge value 1254 on the number of slots field. 1256 As noted in the Section 5.1.2, be careful in using combination of any 1257 compression extensions and this extension. 1259 21. IANA Considerations 1261 This specification is registering a value of the Sec-WebSocket- 1262 Extension header field in accordance with Section 11.4 of the 1263 WebSocket protocol [RFC6455] as follows: 1265 Extension Identifier 1267 mux 1269 Extension Common Name 1271 Multiplexing Extension for WebSockets 1273 Extension Definition 1275 This document 1277 Known Incompatible Extensions 1279 None 1281 22. References 1283 22.1. Normative References 1285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1286 Requirement Levels", BCP 14, RFC 2119, March 1997. 1288 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1290 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1291 RFC 6455, December 2011. 1293 22.2. Informative References 1295 [CRIME] Rizzo, J. and T. Duong, "The CRIME attack", Ekoparty 2012, 1296 September 2012. 1298 Authors' Addresses 1300 John A. Tamplin 1301 Google, Inc. 1303 Email: jat@jaet.org 1305 Takeshi Yoshino 1306 Google, Inc. 1308 Email: tyoshino@google.com