idnits 2.17.1 draft-ietf-bfcpbis-bfcp-websocket-08.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 draft header indicates that this document updates RFC4582bis, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC4582, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2016) is 2886 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) == Outdated reference: A later version (-27) exists of draft-ietf-bfcpbis-rfc4583bis-13 == Outdated reference: A later version (-09) exists of draft-ietf-bfcpbis-sdp-ws-uri-03 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPBIS Working Group V. Pascual 3 Internet-Draft Oracle 4 Updates: 4582bis, 4583bis (if approved) A. Roman 5 Intended status: Standards Track Quobis 6 Expires: December 2, 2016 S. Cazeaux 7 France Telecom Orange 8 G. Salgueiro 9 R. Ravindranath 10 Cisco 11 S. Garcia Murillo 12 Medooze 13 May 31, 2016 15 The WebSocket Protocol as a Transport for the Binary Floor Control 16 Protocol (BFCP) 17 draft-ietf-bfcpbis-bfcp-websocket-08 19 Abstract 21 The WebSocket protocol enables two-way realtime communication between 22 clients and servers. This document specifies a new WebSocket sub- 23 protocol as a reliable transport mechanism between Binary Floor 24 Control Protocol (BFCP) entities to enable usage of BFCP in new 25 scenarios. This document updates RFC4582bis and RFC4583bis. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 2, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 4 65 4. The WebSocket BFCP Sub-Protocol . . . . . . . . . . . . . . . 4 66 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. BFCP Encoding . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Transport Reliability . . . . . . . . . . . . . . . . . . . . 6 69 6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. Updates to RFC4583bis . . . . . . . . . . . . . . . . . . 6 71 6.2. Updates to RFC4582bis . . . . . . . . . . . . . . . . . . 6 72 6.3. SDP Media Attributes . . . . . . . . . . . . . . . . . . 7 73 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 74 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.2. Example Usage of 'wss-uri' SDP Attribute . . . . . . . . 7 76 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 10 80 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 81 'proto' Values . . . . . . . . . . . . . . . . . . . . . 10 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 12.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The WebSocket [RFC6455] protocol enables two-way message exchange 91 between clients and servers on top of a persistent TCP connection, 92 optionally secured with Transport Layer Security (TLS) [RFC5246]. 93 The initial protocol handshake makes use of Hypertext Transfer 94 Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol 95 to reuse existing HTTP infrastructure. 97 The Binary Floor Control Protocol (BFCP) is a protocol to coordinate 98 access to shared resources in a conference. It is defined in 99 [I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants 100 and floor control servers, and between floor chairs (i.e., 101 moderators) and floor control servers. 103 Modern web browsers include a WebSocket client stack complying with 104 the WebSocket API [WS-API] as specified by the W3C. It is expected 105 that other client applications (those running in personal computers 106 and devices such as smartphones) will also make a WebSocket client 107 stack available. This document updates [I-D.ietf-bfcpbis-rfc4582bis] 108 and [I-D.ietf-bfcpbis-rfc4583bis] in order to enable the usage of 109 BFCP in these scenarios. 111 The transport over which BFCP entities exchange messages depends on 112 how the clients obtain information to contact the floor control 113 server (e.g. using an Session Description Protocol (SDP) offer/answer 114 exchange per [I-D.ietf-bfcpbis-rfc4583bis] or the procedure described 115 in RFC5018 [RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two 116 transports for BFCP: TCP and UDP. This specification defines a new 117 WebSocket sub-protocol (as defined in Section 1.9 in [RFC6455]) for 118 transporting BFCP messages between a WebSocket client and server. 119 This sub-protocol provides a reliable and boundary preserving 120 transport for BFCP when run on top of TCP. Since WebSocket provides 121 a reliable transport, the extensions defined in 122 [I-D.ietf-bfcpbis-rfc4582bis] for sending BFCP over unreliable 123 transports are not applicable. This document normatively updates 124 [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis]. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2.1. Definitions 134 BFCP WebSocket Client: Any BFCP entity capable of opening outbound 135 connections to WebSocket servers and communicating using the 136 WebSocket BFCP sub-protocol as defined by this document. 138 BFCP WebSocket Server: Any BFCP entity capable of listening for 139 inbound connections from WebSocket clients and communicating 140 using the WebSocket BFCP sub-protocol as defined by this 141 document. 143 3. The WebSocket Protocol 145 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 146 (optionally secured with TLS [RFC5246]) in which both client and 147 server exchange message units in both directions. The protocol 148 defines a connection handshake, WebSocket sub-protocol and extensions 149 negotiation, a frame format for sending application and control data, 150 a masking mechanism, and status codes for indicating disconnection 151 causes. 153 The WebSocket connection handshake is based on HTTP [RFC7230] and 154 utilizes the HTTP GET method with an "Upgrade" request. This is sent 155 by the client and then answered by the server (if the negotiation 156 succeeded) with an HTTP 101 status code. Once the handshake is 157 completed the connection upgrades from HTTP to the WebSocket 158 protocol. This handshake procedure is designed to reuse the existing 159 HTTP infrastructure. During the connection handshake, client and 160 server agree on the application protocol to use on top of the 161 WebSocket transport. Such an application protocol (also known as a 162 "WebSocket sub-protocol") defines the format and semantics of the 163 messages exchanged by the endpoints. This could be a custom protocol 164 or a standardized one (as the WebSocket BFCP sub-protocol defined in 165 this document). Once the HTTP 101 response is processed both client 166 and server reuse the underlying TCP connection for sending WebSocket 167 messages and control frames to each other. Unlike plain HTTP, this 168 connection is persistent and can be used for multiple message 169 exchanges. 171 The WebSocket protocol defines message units to be used by 172 applications for the exchange of data, so it provides a message 173 boundary-preserving transport layer. These message units can contain 174 either UTF-8 text or binary data, and can be split into multiple 175 WebSocket text/binary transport frames as needed by the WebSocket 176 stack. 178 The WebSocket API [WS-API] for web browsers only defines callbacks 179 to be invoked upon receipt of an entire message unit, regardless 180 of whether it was received in a single WebSocket frame or split 181 across multiple frames. 183 4. The WebSocket BFCP Sub-Protocol 185 The term WebSocket sub-protocol refers to an application-level 186 protocol layered on top of a WebSocket connection. This document 187 specifies the WebSocket BFCP sub-protocol for carrying BFCP messages 188 over a WebSocket connection. 190 4.1. Handshake 192 The BFCP WebSocket Client and BFCP WebSocket Server negotiate usage 193 of the WebSocket BFCP sub-protocol during the WebSocket handshake 194 procedure as defined in Section 1.3 of [RFC6455]. The Client MUST 195 include the value "bfcp" in the Sec-WebSocket-Protocol header in its 196 handshake request. The 101 reply from the Server MUST contain "bfcp" 197 in its corresponding Sec-WebSocket-Protocol header. 199 Below is an example of a WebSocket handshake in which the Client 200 requests the WebSocket BFCP sub-protocol support from the Server: 202 GET / HTTP/1.1 203 Host: bfcp-ws.example.com 204 Upgrade: websocket 205 Connection: Upgrade 206 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 207 Origin: http://www.example.com 208 Sec-WebSocket-Protocol: BFCP 209 Sec-WebSocket-Version: 13 211 The handshake response from the Server accepting the WebSocket BFCP 212 sub-protocol would look as follows: 214 HTTP/1.1 101 Switching Protocols 215 Upgrade: websocket 216 Connection: Upgrade 217 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 218 Sec-WebSocket-Protocol: BFCP 220 Once the negotiation has been completed, the WebSocket connection is 221 established and can be used for the transport of BFCP messages. The 222 WebSocket messages transmitted over this connection MUST conform to 223 the negotiated WebSocket sub-protocol. 225 4.2. BFCP Encoding 227 BFCP messages use a TLV (Type-Length-Value) binary encoding, 228 therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be 229 transported in unfragmented binary WebSocket frames 230 (FIN:1,opcode:%x2) to exchange BFCP messages. The WebSocket frame 231 data MUST be a valid BCFP message, so the length of the payload of 232 the WebSocket frame MUST be lower than the maximum size allowed (2^16 233 +12 bytes) for a BCFP message as described in 234 [I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for 235 reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be 236 followed. 238 While this specification assumes that BFCP encoding is only TLV 239 binary, future documents may define other mechanisms like JSON 240 serialization. 242 5. Transport Reliability 244 WebSocket [RFC6455] provides a reliable transport and therefore the 245 BFCP WebSocket sub-protocol defined by this document also provides 246 reliable BFCP transport. Thus, client and server transactions using 247 WebSocket for transport MUST follow the procedures for reliable 248 transports as defined in [I-D.ietf-bfcpbis-rfc4582bis] and 249 [I-D.ietf-bfcpbis-rfc4583bis]. 251 BFCP WebSocket clients cannot receive incoming WebSocket connections 252 initiated by any other peer. This means that a BFCP WebSocket client 253 MUST actively initiate a connection towards a BFCP WebSocket server. 255 Each BFCP message MUST be carried within a single WebSocket message, 256 and a WebSocket message MUST NOT contain more than one BFCP message. 258 6. SDP Considerations 260 6.1. Updates to RFC4583bis 262 Rules to generate an 'm' line for a BFCP stream are described in 263 [I-D.ietf-bfcpbis-rfc4583bis], Section 3 265 New values are defined for the transport field: TCP/WS/BFCP and 266 TCP/WSS/BFCP. 268 TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn 269 runs on top of TCP. 271 TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn 272 runs on top of TLS and TCP. 274 6.2. Updates to RFC4582bis 276 When TCP is used as the transport, the port field is set following 277 the rules in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis]. Depending 278 on the value of the SDP 'setup' attribute defined in [RFC4145], the 279 port field contains the port to which the remote endpoint will direct 280 BFCP messages or is irrelevant (i.e., the endpoint will initiate the 281 connection towards the remote endpoint) and should be set to a value 282 of 9, which is the discard port. Connection attribute and port MUST 283 follow the rules of [RFC4145] 284 Some web browsers do not allow non-secure WebSocket connections to be 285 made. So, while the recommendation to use Secure WebSockets (i.e. 286 TCP/WSS) is for security reasons, it is also to achieve maximum 287 compatibility among clients. 289 6.3. SDP Media Attributes 291 [I-D.ietf-bfcpbis-sdp-ws-uri] defines a new SDP attribute to indicate 292 the connection Uniform Resource Identifier (URI) for the WebSocket 293 Client. The SDP attribute 'ws-uri' defined in Section 3.1 of 294 [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be used when BFCP runs on top of 295 WS, which in turn runs on top of TCP. The SDP attribute 'wss-uri' 296 defined in Section 3.2 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be used 297 when BFCP runs on top of WSS, which in turn runs on top of TLS and 298 TCP. When the 'ws-uri' or 'wss-uri' attribute is present in the 299 media section of the SDP, the IP and port information provided in the 300 'c' lines SHALL be ignored and the full URI SHALL be used instead to 301 open the WebSocket connection. The port provided in the 'm' line 302 SHALL be ignored too, as the a=ws-uri or a=wss-uri SHALL provide port 303 number when needed. 305 7. SDP Offer/Answer Procedures 307 7.1. General 309 An endpoint (i.e., both the offerer and the answerer) MUST create an 310 SDP media description ("m=" line) for each BFCP-over-WebSocket media 311 stream and MUST assign either TCP/WSS/BFCP or TCP/WS/BFCP value to 312 the "proto" field of the "m=" line depending on whether the endpoint 313 wishes to use secure WebSocket or WebSocket. Furthermore, the server 314 side, which could be either the offerer or answerer, MUST add an 315 "a=ws-uri" or "a=wss-uri" attribute in the media section depending on 316 whether it wishes to use WebSocket or secure WebSocket. This new 317 attribute MUST follow the syntax defined in 318 [I-D.ietf-bfcpbis-sdp-ws-uri]. Additionally, the SDP Offer/Answer 319 procedures defined in Section 4 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST 320 be followed for the "m=" line associated with a BFCP-over-WebSocket 321 media stream. 323 7.2. Example Usage of 'wss-uri' SDP Attribute 325 The following is an example of an "m=" line for a BFCP connection. 326 In this example, the offerer sends the SDP with the "proto" field 327 having a value of TCP/WSS/BFCP * indicating that the offerer wishes 328 to use secure WebSocket as a transport for the media stream. 330 Offer (browser): 331 m=application 9 TCP/WSS/BFCP * 332 a=setup:active 333 a=connection:new 334 a=floorctrl:c-only 335 m=audio 55000 RTP/AVP 0 336 m=video 55002 RTP/AVP 31 338 Answer (server): 339 m=application 50000 TCP/WSS/BFCP * 340 a=setup:passive 341 a=connection:new 342 a=wss-uri:wss://bfcp-ws.example.com?token=3170449312 343 a=floorctrl:s-only 344 a=confid:4321 345 a=userid:1234 346 a=floorid:1 m-stream:10 347 a=floorid:2 m-stream:11 348 m=audio 50002 RTP/AVP 0 349 a=label:10 350 m=video 50004 RTP/AVP 31 351 a=label:11 353 It is possible that an endpoint (e.g., a browser) sends an offerless 354 INVITE to the server. In such cases the server will act as SDP 355 offerer. The server MUST assign the SDP "setup" attribute with a 356 value of "passive". The server MUST have an "a=ws-uri" or "a=wss- 357 uri" attribute in the media section depending on whether the server 358 wishes to use WebSocket or secure WebSocket. This attribute MUST 359 follow the syntax defined in Section 3. For BFCP application, the 360 "proto" value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is 361 over TLS, else it MUST be TCP/WS/BFCP. 363 8. Authentication 365 Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients 366 and floor control servers SHOULD authenticate each other prior to 367 accepting messages, and RECOMMENDS that mutual TLS/DTLS 368 authentication be used. However, browser-based WebSocket clients 369 have no control over the use of TLS in the WebSocket API [WS-API], so 370 it is RECOMMENDED that standard Web-based methods for client and 371 server authentication are used, as follows. 373 When a BFCP WebSocket client connects to a BFCP WebSocket server, it 374 SHOULD use TCP/WSS as its transport. The WebSocket client SHOULD 375 inspect the TLS certificate offered by the server and verify that it 376 is valid. 378 Since the WebSocket API does not distinguish between certificate 379 errors and other kinds of failure to establish a connection, it is 380 expected that browser vendors will warn end users directly of any 381 kind of problem with the server certificate. 383 A floor control server that receives a message over TCP/WS can 384 request the use of TCP/WSS by generating an Error message, as 385 described in Section 13.8 of [I-D.ietf-bfcpbis-rfc4582bis], with an 386 Error code with a value of 9 (use TLS). 388 Prior to sending BFCP requests, a BFCP WebSocket client connects to a 389 BFCP WebSocket server and performs the connection handshake. As 390 described in Section 3 the handshake procedure involves a HTTP GET 391 method request from the client and a response from the server 392 including an HTTP 101 status code. 394 In order to authorize the WebSocket connection, the BFCP WebSocket 395 server MAY inspect any cookie [RFC6265] headers present in the HTTP 396 GET request. For many web applications the value of such a cookie is 397 provided by the web server once the user has authenticated themselves 398 to the web server, which could be done by many existing mechanisms. 399 As an alternative method, the BFCP WebSocket Server could request 400 HTTP authentication by replying to the Client's GET method request 401 with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers 402 this usage in Section 4.1: 404 If the status code received from the server is not 101, the 405 WebSocket client stack handles the response per HTTP [RFC7230] 406 procedures, in particular the client might perform authentication 407 if it receives 401 status code. 409 9. Security Considerations 411 Considerations from [I-D.ietf-bfcpbis-rfc4582bis], 412 [I-D.ietf-bfcpbis-rfc4583bis] and RFC5018 [RFC5018] apply. 414 BFCP relies on lower-layer security mechanisms to provide replay and 415 integrity protection and confidentiality. It is RECOMMENDED that the 416 BFCP traffic transported over a WebSocket communication be protected 417 by using a secure WebSocket connection (using TLS [RFC5246] over 418 TCP). 420 10. IANA Considerations 421 10.1. Registration of the WebSocket BFCP Sub-Protocol 423 This specification requests IANA to register the WebSocket BFCP sub- 424 protocol under the "WebSocket Subprotocol Name" Registry with the 425 following data: 427 Subprotocol Identifier: bfcp 429 Subprotocol Common Name: WebSocket Transport for BFCP (Binary Floor 430 Control Protocol) 432 Subprotocol Definition: RFCXXXX 434 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 435 this specification, and remove this paragraph on publication.]] 437 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' 438 Values 440 This document defines two new values for the SDP 'proto' field under 441 the Session Description Protocol (SDP) Parameters registry. The 442 resulting entries are shown in Figure 1 below: 444 Value Reference 445 ---------- ----------- 446 TCP/WS/BFCP RFCXXXX; 447 TCP/WSS/BFCP RFCXXXX; 449 Figure 1: Values for the SDP 'proto' Field 451 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 452 this specification, and remove this paragraph on publication.]] 454 11. Acknowledgements 456 The authors want to thank Robert Welbourn, from Acme Packet, who made 457 significant contributions to the first version of this document. 458 This work benefited from the thorough review and constructive 459 comments of Charles Eckel, Christer Holmberg and Paul Kyzivat. 461 12. References 463 12.1. Normative References 465 [I-D.ietf-bfcpbis-rfc4582bis] 466 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 467 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 468 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 469 2015. 471 [I-D.ietf-bfcpbis-rfc4583bis] 472 Camarillo, G., Kristensen, T., and P. Jones, "Session 473 Description Protocol (SDP) Format for Binary Floor Control 474 Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-13 475 (work in progress), February 2016. 477 [I-D.ietf-bfcpbis-sdp-ws-uri] 478 R, R. and G. Salgueiro, "Session Description Protocol 479 (SDP) WebSocket Connection URI Attribute", draft-ietf- 480 bfcpbis-sdp-ws-uri-03 (work in progress), May 2016. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, 484 DOI 10.17487/RFC2119, March 1997, 485 . 487 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 488 the Session Description Protocol (SDP)", RFC 4145, 489 DOI 10.17487/RFC4145, September 2005, 490 . 492 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 493 Floor Control Protocol (BFCP)", RFC 5018, 494 DOI 10.17487/RFC5018, September 2007, 495 . 497 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 498 RFC 6455, DOI 10.17487/RFC6455, December 2011, 499 . 501 12.2. Informative References 503 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 504 (TLS) Protocol Version 1.2", RFC 5246, 505 DOI 10.17487/RFC5246, August 2008, 506 . 508 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 509 DOI 10.17487/RFC6265, April 2011, 510 . 512 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 513 Protocol (HTTP/1.1): Message Syntax and Routing", 514 RFC 7230, DOI 10.17487/RFC7230, June 2014, 515 . 517 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 519 Authors' Addresses 521 Victor Pascual 522 Oracle 524 Email: victor.pascual.avila@oracle.com 526 Anton Roman 527 Quobis 529 Email: anton.roman@quobis.com 531 Stephane Cazeaux 532 France Telecom Orange 534 Email: stephane.cazeaux@orange.com 536 Gonzalo Salgueiro 537 Cisco Systems, Inc. 538 7200-12 Kit Creek Road 539 Research Triangle Park, NC 27709 540 US 542 Email: gsalguei@cisco.com 544 Ram Mohan Ravindranath 545 Cisco Systems, Inc. 546 Cessna Business Park, 547 Kadabeesanahalli Village, Varthur Hobli, 548 Sarjapur-Marathahalli Outer Ring Road 549 Bangalore, Karnataka 560103 550 India 552 Email: rmohanr@cisco.com 553 Sergio Garcia Murillo 554 Medooze 556 Email: sergio.garcia.murillo@gmail.com