idnits 2.17.1 draft-ietf-bfcpbis-bfcp-websocket-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2016) is 2739 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 (-09) exists of draft-ietf-bfcpbis-sdp-ws-uri-05 == Outdated reference: A later version (-27) exists of draft-ietf-bfcpbis-rfc4583bis-16 -- 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) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 Intended status: Standards Track A. Roman 5 Expires: April 22, 2017 Quobis 6 S. Cazeaux 7 France Telecom Orange 8 G. Salgueiro 9 R. Ravindranath 10 Cisco 11 S. Garcia Murillo 12 Medooze 13 October 19, 2016 15 The WebSocket Protocol as a Transport for the Binary Floor Control 16 Protocol (BFCP) 17 draft-ietf-bfcpbis-bfcp-websocket-11 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. 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 April 22, 2017. 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. Transport Negotiation . . . . . . . . . . . . . . . . . . 6 71 6.2. SDP Media Attributes . . . . . . . . . . . . . . . . . . 7 72 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 73 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.2. Example Usage of 'wss-uri' SDP Attribute . . . . . . . . 7 75 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 10 79 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 80 'proto' Values . . . . . . . . . . . . . . . . . . . . . 10 81 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 12.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 The WebSocket [RFC6455] protocol enables two-way message exchange 90 between clients and servers on top of a persistent TCP connection, 91 optionally secured with Transport Layer Security (TLS) [RFC5246]. 92 The initial protocol handshake makes use of Hypertext Transfer 93 Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol 94 to reuse existing HTTP infrastructure. 96 The Binary Floor Control Protocol (BFCP) is a protocol to coordinate 97 access to shared resources in a conference. It is defined in 98 [I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants 99 and floor control servers, and between floor chairs (i.e., 100 moderators) and floor control servers. 102 Modern web browsers include a WebSocket client stack complying with 103 the WebSocket API [WS-API] as specified by the W3C. It is expected 104 that other client applications (those running in personal computers 105 and devices such as smartphones) will also make a WebSocket client 106 stack available. This document extends the applicability of 107 [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis] to 108 enable the usage of BFCP in these scenarios. 110 The transport over which BFCP entities exchange messages depends on 111 how the clients obtain information to contact the floor control 112 server (e.g. using an Session Description Protocol (SDP) offer/answer 113 exchange per [I-D.ietf-bfcpbis-rfc4583bis] or the procedure described 114 in RFC5018 [RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two 115 transports for BFCP: TCP and UDP. This specification defines a new 116 WebSocket sub-protocol (as defined in Section 1.9 in [RFC6455]) for 117 transporting BFCP messages between a WebSocket client and server. 118 This sub-protocol provides a reliable and boundary preserving 119 transport for BFCP when run on top of TCP. Since WebSocket provides 120 a reliable transport, the extensions defined in 121 [I-D.ietf-bfcpbis-rfc4582bis] for sending BFCP over unreliable 122 transports are not applicable. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 2.1. Definitions 132 BFCP WebSocket Client: Any BFCP entity capable of opening outbound 133 connections to WebSocket servers and communicating using the 134 WebSocket BFCP sub-protocol as defined by this document. 136 BFCP WebSocket Server: Any BFCP entity capable of listening for 137 inbound connections from WebSocket clients and communicating 138 using the WebSocket BFCP sub-protocol as defined by this 139 document. 141 3. The WebSocket Protocol 143 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 144 (optionally secured with TLS [RFC5246]) in which both client and 145 server exchange message units in both directions. The protocol 146 defines a connection handshake, WebSocket sub-protocol and extensions 147 negotiation, a frame format for sending application and control data, 148 a masking mechanism, and status codes for indicating disconnection 149 causes. 151 The WebSocket connection handshake is based on HTTP [RFC7230] and 152 utilizes the HTTP GET method with an "Upgrade" request. This is sent 153 by the client and then answered by the server (if the negotiation 154 succeeded) with an HTTP 101 status code. Once the handshake is 155 completed the connection upgrades from HTTP to the WebSocket 156 protocol. This handshake procedure is designed to reuse the existing 157 HTTP infrastructure. During the connection handshake, client and 158 server agree on the application protocol to use on top of the 159 WebSocket transport. Such an application protocol (also known as a 160 "WebSocket sub-protocol") defines the format and semantics of the 161 messages exchanged by the endpoints. This could be a custom protocol 162 or a standardized one (as the WebSocket BFCP sub-protocol defined in 163 this document). Once the HTTP 101 response is processed both client 164 and server reuse the underlying TCP connection for sending WebSocket 165 messages and control frames to each other. Unlike plain HTTP, this 166 connection is persistent and can be used for multiple message 167 exchanges. 169 The WebSocket protocol defines message units to be used by 170 applications for the exchange of data, so it provides a message 171 boundary-preserving transport layer. These message units can contain 172 either UTF-8 text or binary data, and can be split into multiple 173 WebSocket text/binary transport frames as needed by the WebSocket 174 stack. 176 The WebSocket API [WS-API] for web browsers only defines callbacks 177 to be invoked upon receipt of an entire message unit, regardless 178 of whether it was received in a single WebSocket frame or split 179 across multiple frames. 181 4. The WebSocket BFCP Sub-Protocol 183 The term WebSocket sub-protocol refers to an application-level 184 protocol layered on top of a WebSocket connection. This document 185 specifies the WebSocket BFCP sub-protocol for carrying BFCP messages 186 over a WebSocket connection. 188 4.1. Handshake 190 The BFCP WebSocket Client and BFCP WebSocket Server negotiate usage 191 of the WebSocket BFCP sub-protocol during the WebSocket handshake 192 procedure as defined in Section 1.3 of [RFC6455]. The Client MUST 193 include the value "bfcp" in the Sec-WebSocket-Protocol header in its 194 handshake request. The 101 reply from the Server MUST contain "BFCP" 195 in its corresponding Sec-WebSocket-Protocol header. 197 Below is an example of a WebSocket handshake in which the Client 198 requests the WebSocket BFCP sub-protocol support from the Server: 200 GET / HTTP/1.1 201 Host: bfcp-ws.example.com 202 Upgrade: websocket 203 Connection: Upgrade 204 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 205 Origin: http://www.example.com 206 Sec-WebSocket-Protocol: BFCP 207 Sec-WebSocket-Version: 13 209 The handshake response from the Server accepting the WebSocket BFCP 210 sub-protocol would look as follows: 212 HTTP/1.1 101 Switching Protocols 213 Upgrade: websocket 214 Connection: Upgrade 215 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 216 Sec-WebSocket-Protocol: BFCP 218 Once the negotiation has been completed, the WebSocket connection is 219 established and can be used for the transport of BFCP messages. The 220 WebSocket messages transmitted over this connection MUST conform to 221 the negotiated WebSocket sub-protocol. 223 4.2. BFCP Encoding 225 BFCP messages use a TLV (Type-Length-Value) binary encoding, 226 therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be 227 transported in unfragmented binary WebSocket frames 228 (FIN:1,opcode:%x2) to exchange BFCP messages. The WebSocket frame 229 data MUST be a valid BCFP message, so the length of the payload of 230 the WebSocket frame MUST be lower than the maximum size allowed (2^16 231 +12 bytes) for a BCFP message as described in 232 [I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for 233 reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be 234 followed. 236 While this specification assumes that BFCP encoding is only TLV 237 binary, future documents may define other mechanisms like JSON 238 serialization. 240 5. Transport Reliability 242 WebSocket [RFC6455] provides a reliable transport and therefore the 243 BFCP WebSocket sub-protocol defined by this document also provides 244 reliable BFCP transport. Thus, client and server transactions using 245 WebSocket for transport MUST follow the procedures for reliable 246 transports as defined in [I-D.ietf-bfcpbis-rfc4582bis] and 247 [I-D.ietf-bfcpbis-rfc4583bis]. 249 BFCP WebSocket clients cannot receive incoming WebSocket connections 250 initiated by any other peer. This means that a BFCP WebSocket client 251 MUST actively initiate a connection towards a BFCP WebSocket server. 252 The BFCP server is a server, on the Internet, and thus doesn't need 253 ICE and thus the clients always initiate connection to it, and the 254 clients only validate its certificate and the clients do not include 255 their certificate in TLS ClientHello. 257 Each BFCP message MUST be carried within a single WebSocket message, 258 and a WebSocket message MUST NOT contain more than one BFCP message. 260 6. SDP Considerations 262 6.1. Transport Negotiation 264 Rules to generate an 'm' line for a BFCP stream are described in 265 [I-D.ietf-bfcpbis-rfc4583bis], Section 3 267 New values are defined for the transport field: TCP/WS/BFCP and 268 TCP/WSS/BFCP. 270 TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn 271 runs on top of TCP. 273 TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn 274 runs on top of TLS and TCP. 276 When TCP is used as the transport, the port field is set following 277 the rules in Section 3 and Section 8.1 of 278 [I-D.ietf-bfcpbis-rfc4583bis]. Depending on the value of the SDP 279 'setup' attribute defined in [RFC4145], the port field contains the 280 port to which the remote endpoint will direct BFCP messages or is 281 irrelevant (i.e., the endpoint will initiate the connection towards 282 the remote endpoint) and should be set to a value of 9, which is the 283 discard port. Connection attribute and port MUST follow the rules of 284 [RFC4145] 286 Some web browsers do not allow non-secure WebSocket connections to be 287 made. So, while the recommendation to use Secure WebSockets (i.e. 288 TCP/WSS) is for security reasons, it is also to achieve maximum 289 compatibility among clients. 291 6.2. SDP Media Attributes 293 [I-D.ietf-bfcpbis-sdp-ws-uri] defines a new SDP attribute to indicate 294 the connection Uniform Resource Identifier (URI) for the WebSocket 295 Client. The SDP attribute 'ws-uri' defined in Section 3.1 of 296 [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be used when BFCP runs on top of 297 WS, which in turn runs on top of TCP. The SDP attribute 'wss-uri' 298 defined in Section 3.2 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be used 299 when BFCP runs on top of WSS, which in turn runs on top of TLS and 300 TCP. When the 'ws-uri' or 'wss-uri' attribute is present in the 301 media section of the SDP, the IP and port information provided in the 302 'c' lines SHALL be ignored and the full URI SHALL be used instead to 303 open the WebSocket connection. The port provided in the 'm' line 304 SHALL be ignored too, as the a=ws-uri or a=wss-uri SHALL provide port 305 number when needed. 307 7. SDP Offer/Answer Procedures 309 7.1. General 311 An endpoint (i.e., both the offerer and the answerer) MUST create an 312 SDP media description ("m=" line) for each BFCP-over-WebSocket media 313 stream and MUST assign either TCP/WSS/BFCP or TCP/WS/BFCP value to 314 the "proto" field of the "m=" line depending on whether the endpoint 315 wishes to use secure WebSocket or WebSocket. Furthermore, the server 316 side, which could be either the offerer or answerer, MUST add an 317 "a=ws-uri" or "a=wss-uri" attribute in the media section depending on 318 whether it wishes to use WebSocket or secure WebSocket. This new 319 attribute MUST follow the syntax defined in 320 [I-D.ietf-bfcpbis-sdp-ws-uri]. Additionally, the SDP Offer/Answer 321 procedures defined in Section 4 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST 322 be followed for the "m=" line associated with a BFCP-over-WebSocket 323 media stream. 325 7.2. Example Usage of 'wss-uri' SDP Attribute 327 The following is an example of an "m=" line for a BFCP connection. 328 In this example, the offerer sends the SDP with the "proto" field 329 having a value of TCP/WSS/BFCP * indicating that the offerer wishes 330 to use secure WebSocket as a transport for the media stream. 332 Offer (browser): 333 m=application 9 TCP/WSS/BFCP * 334 a=setup:active 335 a=connection:new 336 a=floorctrl:c-only 337 m=audio 55000 RTP/AVP 0 338 m=video 55002 RTP/AVP 31 340 Answer (server): 341 m=application 50000 TCP/WSS/BFCP * 342 a=setup:passive 343 a=connection:new 344 a=wss-uri:wss://bfcp-ws.example.com?token=3170449312 345 a=floorctrl:s-only 346 a=confid:4321 347 a=userid:1234 348 a=floorid:1 m-stream:10 349 a=floorid:2 m-stream:11 350 m=audio 50002 RTP/AVP 0 351 a=label:10 352 m=video 50004 RTP/AVP 31 353 a=label:11 355 It is possible that an endpoint (e.g., a browser) sends an offerless 356 INVITE to the server. In such cases the server will act as SDP 357 offerer. The server MUST assign the SDP "setup" attribute with a 358 value of "passive". The server MUST have an "a=ws-uri" or "a=wss- 359 uri" attribute in the media section depending on whether the server 360 wishes to use WebSocket or secure WebSocket. This attribute MUST 361 follow the syntax defined in Section 3. For BFCP application, the 362 "proto" value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is 363 over TLS, else it MUST be TCP/WS/BFCP. 365 8. Authentication 367 Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients 368 and floor control servers SHOULD authenticate each other prior to 369 accepting messages, and RECOMMENDS that mutual TLS/DTLS 370 authentication be used. However, browser-based WebSocket clients 371 have no control over the use of TLS in the WebSocket API [WS-API], so 372 it is RECOMMENDED that standard Web-based methods for client and 373 server authentication are used, as follows. 375 When a BFCP WebSocket client connects to a BFCP WebSocket server, it 376 SHOULD use TCP/WSS as its transport. The WebSocket client MUST 377 follow the procedures in [RFC7525] while setting up TLS connection 378 with webSocket server. The BFCP client validates the server by means 379 of verifying server certificate and this requires wss-uri contains a 380 hostname. a=fingerprint is not used here in the verification process. 382 Since the WebSocket API does not distinguish between certificate 383 errors and other kinds of failure to establish a connection, it is 384 expected that browser vendors will warn end users directly of any 385 kind of problem with the server certificate. 387 A floor control server that receives a message over TCP/WS can 388 request the use of TCP/WSS by generating an Error message, as 389 described in Section 13.8 of [I-D.ietf-bfcpbis-rfc4582bis], with an 390 Error code with a value of 9 (use TLS). 392 Prior to sending BFCP requests, a BFCP WebSocket client connects to a 393 BFCP WebSocket server and performs the connection handshake. As 394 described in Section 3 the handshake procedure involves a HTTP GET 395 method request from the client and a response from the server 396 including an HTTP 101 status code. 398 In order to authorize the WebSocket connection, the BFCP WebSocket 399 server SHOULD inspect any cookie [RFC6265] headers present in the 400 HTTP GET request. For many web applications the value of such a 401 cookie is provided by the web server once the user has authenticated 402 themselves to the web server, which could be done by many existing 403 mechanisms. As an alternative method, the BFCP WebSocket Server 404 could request HTTP authentication by replying to the Client's GET 405 method request with a HTTP 401 status code. The WebSocket protocol 406 [RFC6455] covers this usage in Section 4.1: 408 If the status code received from the server is not 101, the 409 WebSocket client stack handles the response per HTTP [RFC7230] 410 procedures, in particular the client might perform authentication 411 if it receives 401 status code. 413 9. Security Considerations 415 Considerations from [I-D.ietf-bfcpbis-rfc4582bis], 416 [I-D.ietf-bfcpbis-rfc4583bis] and RFC5018 [RFC5018] apply. 418 BFCP relies on lower-layer security mechanisms to provide replay and 419 integrity protection and confidentiality. It is RECOMMENDED that the 420 BFCP traffic transported over a WebSocket communication be protected 421 by using a secure WebSocket connection (using TLS [RFC5246] over 422 TCP). The security model here is a typical webserver-client model 423 where the client validates the server certificate and then connects 424 to the server. 426 10. IANA Considerations 428 10.1. Registration of the WebSocket BFCP Sub-Protocol 430 This specification requests IANA to register the WebSocket BFCP sub- 431 protocol under the "WebSocket Subprotocol Name" Registry with the 432 following data: 434 Subprotocol Identifier: bfcp 436 Subprotocol Common Name: WebSocket Transport for BFCP (Binary Floor 437 Control Protocol) 439 Subprotocol Definition: RFCXXXX 441 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 442 this specification, and remove this paragraph on publication.]] 444 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' 445 Values 447 This document defines two new values for the SDP 'proto' field under 448 the Session Description Protocol (SDP) Parameters registry. The 449 resulting entries are shown in Figure 1 below: 451 Value Reference 452 ---------- ----------- 453 TCP/WS/BFCP RFCXXXX; 454 TCP/WSS/BFCP RFCXXXX; 456 Figure 1: Values for the SDP 'proto' Field 458 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 459 this specification, and remove this paragraph on publication.]] 461 11. Acknowledgements 463 The authors want to thank Robert Welbourn, from Acme Packet, who made 464 significant contributions to the first version of this document. 465 This work benefited from the thorough review and constructive 466 comments of Charles Eckel, Christer Holmberg, Paul Kyzivat and Dan 467 Wing. 469 12. References 470 12.1. Normative References 472 [I-D.ietf-bfcpbis-rfc4582bis] 473 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 474 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 475 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 476 2015. 478 [I-D.ietf-bfcpbis-sdp-ws-uri] 479 R, R. and G. Salgueiro, "Session Description Protocol 480 (SDP) WebSocket Connection URI Attribute", draft-ietf- 481 bfcpbis-sdp-ws-uri-05 (work in progress), July 2016. 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, 485 DOI 10.17487/RFC2119, March 1997, 486 . 488 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 489 the Session Description Protocol (SDP)", RFC 4145, 490 DOI 10.17487/RFC4145, September 2005, 491 . 493 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 494 Floor Control Protocol (BFCP)", RFC 5018, 495 DOI 10.17487/RFC5018, September 2007, 496 . 498 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 499 RFC 6455, DOI 10.17487/RFC6455, December 2011, 500 . 502 12.2. Informative References 504 [I-D.ietf-bfcpbis-rfc4583bis] 505 Camarillo, G., Kristensen, T., and P. Jones, "Session 506 Description Protocol (SDP) Format for Binary Floor Control 507 Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-16 508 (work in progress), September 2016. 510 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 511 (TLS) Protocol Version 1.2", RFC 5246, 512 DOI 10.17487/RFC5246, August 2008, 513 . 515 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 516 DOI 10.17487/RFC6265, April 2011, 517 . 519 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 520 Protocol (HTTP/1.1): Message Syntax and Routing", 521 RFC 7230, DOI 10.17487/RFC7230, June 2014, 522 . 524 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 525 "Recommendations for Secure Use of Transport Layer 526 Security (TLS) and Datagram Transport Layer Security 527 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 528 2015, . 530 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 532 Authors' Addresses 534 Victor Pascual 535 Oracle 537 Email: victor.pascual.avila@oracle.com 539 Anton Roman 540 Quobis 542 Email: anton.roman@quobis.com 544 Stephane Cazeaux 545 France Telecom Orange 547 Email: stephane.cazeaux@orange.com 549 Gonzalo Salgueiro 550 Cisco Systems, Inc. 551 7200-12 Kit Creek Road 552 Research Triangle Park, NC 27709 553 US 555 Email: gsalguei@cisco.com 556 Ram Mohan Ravindranath 557 Cisco Systems, Inc. 558 Cessna Business Park, 559 Kadabeesanahalli Village, Varthur Hobli, 560 Sarjapur-Marathahalli Outer Ring Road 561 Bangalore, Karnataka 560103 562 India 564 Email: rmohanr@cisco.com 566 Sergio Garcia Murillo 567 Medooze 569 Email: sergio.garcia.murillo@gmail.com