idnits 2.17.1 draft-ietf-bfcpbis-bfcp-websocket-05.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2015) is 3117 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) == Unused Reference: 'RFC2818' is defined on line 562, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-bfcpbis-rfc4582bis-14 == Outdated reference: A later version (-27) exists of draft-ietf-bfcpbis-rfc4583bis-12 == Outdated reference: A later version (-03) exists of draft-ram-bfcpbis-sdp-ws-uri-00 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 6 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 Updates: rfc4582bis, rfc4583bis (if A. Roman 5 approved) Quobis 6 Intended status: Standards Track S. Cazeaux 7 Expires: April 15, 2016 France Telecom Orange 8 G. Salgueiro 9 R. Ravindranath 10 Cisco 11 S. Garcia Murillo 12 Medooze 13 October 13, 2015 15 The WebSocket Protocol as a Transport for the Binary Floor Control 16 Protocol (BFCP) 17 draft-ietf-bfcpbis-bfcp-websocket-05 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 15, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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. Generating the Initial Offer . . . . . . . . . . . . . . 7 76 7.3. Generating the Answer . . . . . . . . . . . . . . . . . . 8 77 7.4. Offerer Processing of the Answer . . . . . . . . . . . . 9 78 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 9 79 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 11 83 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 84 'proto' Values . . . . . . . . . . . . . . . . . . . . . 11 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 12.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 The WebSocket [RFC6455] protocol enables two-way message exchange 94 between clients and servers on top of a persistent TCP connection, 95 optionally secured with Transport Layer Security (TLS) [RFC5246]. 96 The initial protocol handshake makes use of Hypertext Transfer 97 Protocol (HTTP) [RFC2616] semantics, allowing the WebSocket protocol 98 to reuse existing HTTP infrastructure. 100 The Binary Floor Control Protocol (BFCP) is a protocol to coordinate 101 access to shared resources in a conference. It is defined in 102 [I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants 103 and floor control servers, and between floor chairs (i.e., 104 moderators) and floor control servers. 106 Modern web browsers include a WebSocket client stack complying with 107 the WebSocket API [WS-API] as specified by the W3C. It is expected 108 that other client applications (those running in personal computers 109 and devices such as smartphones) will also make a WebSocket client 110 stack available. This document updates [I-D.ietf-bfcpbis-rfc4582bis] 111 and [I-D.ietf-bfcpbis-rfc4583bis] in order to enable the usage of 112 BFCP in these scenarios. 114 The transport over which BFCP entities exchange messages depends on 115 how the clients obtain information to contact the floor control 116 server (e.g. using an Session Description Protocol (SDP) offer/answer 117 exchange per [I-D.ietf-bfcpbis-rfc4583bis] or the procedure described 118 in RFC5018 [RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two 119 transports for BFCP: TCP and UDP. This specification defines a new 120 WebSocket sub-protocol (as defined in section 1.9 in [RFC6455]) for 121 transporting BFCP messages between a WebSocket client and server. 122 This sub-protocol provides a reliable and boundary preserving 123 transport for BFCP when run on top of TCP. Since WebSocket provides 124 a reliable transport, the extensions defined in 125 [I-D.ietf-bfcpbis-rfc4582bis] for sending BFCP over unreliable 126 transports are not applicable. This document normatively updates 127 [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis]. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2.1. Definitions 137 BFCP WebSocket Client: Any BFCP entity capable of opening outbound 138 connections to WebSocket servers and communicating using the 139 WebSocket BFCP sub-protocol as defined by this document. 141 BFCP WebSocket Server: Any BFCP entity capable of listening for 142 inbound connections from WebSocket clients and communicating 143 using the WebSocket BFCP sub-protocol as defined by this 144 document. 146 3. The WebSocket Protocol 148 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 149 (optionally secured with TLS [RFC5246]) in which both client and 150 server exchange message units in both directions. The protocol 151 defines a connection handshake, WebSocket sub-protocol and extensions 152 negotiation, a frame format for sending application and control data, 153 a masking mechanism, and status codes for indicating disconnection 154 causes. 156 The WebSocket connection handshake is based on HTTP [RFC2616] and 157 utilizes the HTTP GET method with an "Upgrade" request. This is sent 158 by the client and then answered by the server (if the negotiation 159 succeeded) with an HTTP 101 status code. Once the handshake is 160 completed the connection upgrades from HTTP to the WebSocket 161 protocol. This handshake procedure is designed to reuse the existing 162 HTTP infrastructure. During the connection handshake, client and 163 server agree on the application protocol to use on top of the 164 WebSocket transport. Such an application protocol (also known as a 165 "WebSocket sub-protocol") defines the format and semantics of the 166 messages exchanged by the endpoints. This could be a custom protocol 167 or a standardized one (as the WebSocket BFCP sub-protocol defined in 168 this document). Once the HTTP 101 response is processed both client 169 and server reuse the underlying TCP connection for sending WebSocket 170 messages and control frames to each other. Unlike plain HTTP, this 171 connection is persistent and can be used for multiple message 172 exchanges. 174 The WebSocket protocol defines message units to be used by 175 applications for the exchange of data, so it provides a message 176 boundary-preserving transport layer. These message units can contain 177 either UTF-8 text or binary data, and can be split into multiple 178 WebSocket text/binary transport frames as needed by the WebSocket 179 stack. 181 The WebSocket API [WS-API] for web browsers only defines callbacks 182 to be invoked upon receipt of an entire message unit, regardless 183 of whether it was received in a single WebSocket frame or split 184 across multiple frames. 186 4. The WebSocket BFCP Sub-Protocol 188 The term WebSocket sub-protocol refers to an application-level 189 protocol layered on top of a WebSocket connection. This document 190 specifies the WebSocket BFCP sub-protocol for carrying BFCP messages 191 over a WebSocket connection. 193 4.1. Handshake 195 The BFCP WebSocket Client and BFCP WebSocket Server negotiate usage 196 of the WebSocket BFCP sub-protocol during the WebSocket handshake 197 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 198 include the value "bfcp" in the Sec-WebSocket-Protocol header in its 199 handshake request. The 101 reply from the Server MUST contain "bfcp" 200 in its corresponding Sec-WebSocket-Protocol header. 202 Below is an example of a WebSocket handshake in which the Client 203 requests the WebSocket BFCP sub-protocol support from the Server: 205 GET / HTTP/1.1 206 Host: bfcp-ws.example.com 207 Upgrade: websocket 208 Connection: Upgrade 209 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 210 Origin: http://www.example.com 211 Sec-WebSocket-Protocol: bfcp 212 Sec-WebSocket-Version: 13 214 The handshake response from the Server accepting the WebSocket BFCP 215 sub-protocol would look as follows: 217 HTTP/1.1 101 Switching Protocols 218 Upgrade: websocket 219 Connection: Upgrade 220 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 221 Sec-WebSocket-Protocol: bfcp 223 Once the negotiation has been completed, the WebSocket connection is 224 established and can be used for the transport of BFCP messages. The 225 WebSocket messages transmitted over this connection MUST conform to 226 the negotiated WebSocket sub-protocol. 228 4.2. BFCP Encoding 230 BFCP messages use a TLV (Type-Length-Value) binary encoding, 231 therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be 232 transported in unfragmented binary WebSocket frames 233 (FIN:1,opcode:%x2) to exchange BFCP messages. The WebSocket frame 234 data MUST be a valid BCFP message, so the length of the payload of 235 the WebSocket frame MUST be lower than the maximum size allowed (2^16 236 +12 bytes) for a BCFP message as described in 237 [I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for 238 reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be 239 followed. 241 While this specification assumes that BFCP encoding is only TLV 242 binary, future documents may define other mechanisms like JSON 243 serialization. 245 5. Transport Reliability 247 WebSocket [RFC6455] provides a reliable transport and therefore the 248 BFCP WebSocket sub-protocol defined by this document also provides 249 reliable BFCP transport. Thus, client and server transactions using 250 WebSocket for transport MUST follow the procedures for reliable 251 transports as defined in [I-D.ietf-bfcpbis-rfc4582bis] and 252 [I-D.ietf-bfcpbis-rfc4583bis] 254 BFCP WebSocket clients cannot receive incoming WebSocket connections 255 initiated by any other peer. This means that a BFCP WebSocket client 256 MUST actively initiate a connection towards a BFCP WebSocket server 258 Each BFCP message MUST be carried within a single WebSocket message, 259 and a WebSocket message MUST NOT contain more than one BFCP message. 261 6. SDP Considerations 263 6.1. Updates to RFC4583bis 265 Rules to generate an 'm' line for a BFCP stream are described in 266 [I-D.ietf-bfcpbis-rfc4583bis], Section 3 268 New values are defined for the transport field: TCP/WS/BFCP and 269 TCP/WSS/BFCP. 271 TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn 272 runs on top of TCP. 274 TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn 275 runs on top of TLS and TCP. 277 6.2. Updates to RFC4582bis 279 When TCP is used as the transport, the port field is set following 280 the rules in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis]. Depending 281 on the value of the SDP 'setup' attribute defined in [RFC4145], the 282 port field contains the port to which the remote endpoint will direct 283 BFCP messages or is irrelevant (i.e., the endpoint will initiate the 284 connection towards the remote endpoint) and should be set to a value 285 of 9, which is the discard port. Connection attribute and port MUST 286 follow the rules of [RFC4145] 287 Some web browsers do not allow non-secure WebSocket connections to be 288 made. So, while the recommendation to use Secure WebSockets (i.e. 289 TCP/WSS) is for security reasons, it is also to achieve maximum 290 compatibility among clients. 292 6.3. SDP Media Attributes 294 [I-D.ram-bfcpbis-sdp-ws-uri] defines a new SDP attributes to indicate 295 the connection Uniform Resource Identifier (URI) for the WebSocket 296 Client. The SDP attribute 'ws-uri' defined in section 3.1 of 297 [I-D.ram-bfcpbis-sdp-ws-uri] MUST be used when BFCP runs on top of 298 WS, which in turn runs on top of TCP. The SDP attribute 'wss-uri' 299 defined in section 3.2 of [I-D.ram-bfcpbis-sdp-ws-uri] MUST be used 300 when BFCP runs on top of WSS, which in turn runs on top of TLS and 301 TCP. When the 'ws-uri' or 'wss-uri' attribute is present in the 302 media section of the SDP, the IP and port information provided in the 303 'c' lines SHALL be ignored and the full URI SHALL be used instead to 304 open the WebSocket connection. The port provided in the 'm' line 305 SHALL be ignored too, as the a=ws-uri or a=wss-uri SHALL provide port 306 number when needed. 308 7. SDP Offer/Answer Procedures 310 7.1. General 312 An endpoint (i.e., both the offerer and the answerer) MUST create an 313 SDP media description ("m=" line) for each BFCP-over-WebSocket media 314 stream and MUST assign a TCP/WSS/BFCP value to the "proto" field of 315 the "m=" line. Furthermore, the SDP answerer (Server) MUST add an 316 "a=ws-uri" or "a=wss-uri" attribute in the "m=" line of each BFCP- 317 over-WebSocket media stream depending on whether it is WS or WSS. 318 This new attribute MUST follow the syntax defined in 319 [I-D.ram-bfcpbis-sdp-ws-uri]. The procedures in this section apply 320 to an "m=" line associated with a BFCP-over-WebSocket media stream. 322 7.2. Generating the Initial Offer 324 An SDP offerer in order to negotiate BFCP-over-WebSocket MUST 325 generate an "m=" line which has: 327 The SDP attributes as defined in Section 4 of 328 [I-D.ietf-bfcpbis-rfc4583bis] 330 The "proto" value in the "m=" line MUST be TCP/WSS/BFCP if 331 WebSocket is over TLS, else it MUST be TCP/WS/BFCP. 333 The offerer SHOULD assign the SDP "setup" attribute with a value of 334 "active" (the offerer will be the initiator of the outgoing TCP 335 connection), unless the offerer insists on being a receiver of an 336 incoming connection, in which case the offerer SHOULD use a value of 337 "passive". The offerer MUST NOT assign an SDP "setup" attribute with 338 a "holdconn" value. If the offerer assigns the SDP "setup" attribute 339 with a value of "passive", the offerer MUST be prepared to receive an 340 incoming TCP connection on the IP and port tuple advertised in the 341 "c=" line and audio/video ports of the BFCP media stream before it 342 receives the SDP answer. 344 The following is an example of an "m=" line for a BFCP connection: 346 Offer (browser): 347 m=application 9 TCP/WSS/BFCP * 348 a=setup:active 349 a=connection:new 350 a=floorctrl:c-only 351 m=audio 55000 RTP/AVP 0 352 m=video 55002 RTP/AVP 31 354 In the above example, the client is intending to setup the TLS /TCP 355 connection and hence the port is set to a value of 9, which is the 356 discard port. 358 7.3. Generating the Answer 360 If the answerer accepts the offered BFCP-over-WebSocket transport 361 connection, in the associated SDP answer, the answerer MUST assign an 362 SDP "setup" attribute with a value of either "active" or "passive", 363 according to the procedures in [RFC4145]. The answerer MUST NOT 364 assign an SDP "setup" attribute with a value of "holdconn". 366 If the answerer assigns an SDP "setup" attribute with a value of 367 "active", the answerer MUST initiate the WebSocket connection 368 handshake by acting as client on the negotiated media stream, towards 369 the IP address and port of the offerer using the procedures described 370 in [RFC6455]. Apart from the SDP attributes of the BFCP media 371 stream, the answer MUST have an "a=ws-uri" or "a=wss-uri" attribute 372 depending on whether BFCP is running over WS or WSS. This attribute 373 MUST follow the syntax defined in [I-D.ram-bfcpbis-sdp-ws-uri]. The 374 "proto" value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is 375 run on TLS, else it MUST be TCP/WS/BFCP. 377 The following example shows a case where the server responds with a 378 BFCP media stream over a WebSocket connection running TLS. It shows 379 an answer "m=" line for the BFCP connection. In this example since 380 WebSockets is running over TLS, the server answers back with "a=wss- 381 uri" attribute in SDP indicating the connection URI: 383 Answer (server): 384 m=application 50000 TCP/WSS/BFCP * 385 a=setup:passive 386 a=connection:new 387 a=wss-uri:wss://bfcp-ws.example.com?token=3170449312 388 a=floorctrl:s-only 389 a=confid:4321 390 a=userid:1234 391 a=floorid:1 m-stream:10 392 a=floorid:2 m-stream:11 393 m=audio 50002 RTP/AVP 0 394 a=label:10 395 m=video 50004 RTP/AVP 31 396 a=label:11 398 7.4. Offerer Processing of the Answer 400 When the offerer receives an SDP answer, if the offerer ends up being 401 active it MUST initiate the WebSocket connection handshake by sending 402 a GET message on the negotiated media stream, towards the IP address 403 and port of the answerer, as per the procedures described in 404 [RFC6455]. 406 7.5. Modifying the Session 408 Once an offer/answer exchange has been completed, either endpoint MAY 409 send a new offer in order to modify the session. The endpoints can 410 reuse the existing WebSocket connection if the ws-uri values and the 411 transport parameters indicated by each endpoint are unchanged. 412 Otherwise, following the rules for the initial offer/answer exchange, 413 the endpoints can negotiate and create a new WebSocket connection on 414 top of TLS/TCP or TCP. 416 8. Authentication 418 Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients 419 and floor control servers SHOULD authenticate each other prior to 420 accepting messages, and RECOMMENDS that mutual TLS/DTLS 421 authentication be used. However, browser-based WebSocket clients 422 have no control over the use of TLS in the WebSocket API [WS-API], so 423 it is RECOMMENDED that standard Web-based methods for client and 424 server authentication are used, as follows. 426 When a BFCP WebSocket client connects to a BFCP WebSocket server, it 427 SHOULD use TCP/WSS as its transport. The WebSocket client SHOULD 428 inspect the TLS certificate offered by the server and verify that it 429 is valid. 431 Since the WebSocket API does not distinguish between certificate 432 errors and other kinds of failure to establish a connection, it is 433 expected that browser vendors will warn end users directly of any 434 kind of problem with the server certificate. 436 A floor control server that receives a message over TCP/WS can 437 request the use of TCP/WSS by generating an Error message, as 438 described in Section 13.8 of [I-D.ietf-bfcpbis-rfc4582bis], with an 439 Error code with a value of 9 (use TLS). 441 Prior to sending BFCP requests, a BFCP WebSocket client connects to a 442 BFCP WebSocket server and performs the connection handshake. As 443 described in Section 3 the handshake procedure involves a HTTP GET 444 method request from the client and a response from the server 445 including an HTTP 101 status code. 447 In order to authorize the WebSocket connection, the BFCP WebSocket 448 server MAY inspect any cookie [RFC6265] headers present in the HTTP 449 GET request. For many web applications the value of such a cookie is 450 provided by the web server once the user has authenticated themselves 451 to the web server, which could be done by many existing mechanisms. 452 As an alternative method, the BFCP WebSocket Server could request 453 HTTP authentication by replying to the Client's GET method request 454 with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers 455 this usage in section 4.1: 457 If the status code received from the server is not 101, the 458 WebSocket client stack handles the response per HTTP [RFC2616] 459 procedures, in particular the client might perform authentication 460 if it receives 401 status code. 462 9. Security Considerations 464 Considerations from [I-D.ietf-bfcpbis-rfc4582bis], 465 [I-D.ietf-bfcpbis-rfc4583bis] and RFC5018 [RFC5018] apply. 467 BFCP relies on lower-layer security mechanisms to provide replay and 468 integrity protection and confidentiality. It is RECOMMENDED that the 469 BFCP traffic transported over a WebSocket communication be protected 470 by using a secure WebSocket connection (using TLS [RFC5246] over 471 TCP). 473 10. IANA Considerations 474 10.1. Registration of the WebSocket BFCP Sub-Protocol 476 This specification requests IANA to register the WebSocket BFCP sub- 477 protocol under the "WebSocket Subprotocol Name" Registry with the 478 following data: 480 Subprotocol Identifier: bfcp 482 Subprotocol Common Name: WebSocket Transport for BFCP (Binary Floor 483 Control Protocol) 485 Subprotocol Definition: RFCXXXX 487 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 488 this specification, and remove this paragraph on publication.]] 490 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' 491 Values 493 This document defines two new values for the SDP 'proto' field under 494 the Session Description Protocol (SDP) Parameters registry. The 495 resulting entries are shown in Figure 1 below: 497 Value Reference 498 -------------- --------- 499 TCP/WS/BFCP RFC&rfc.number; 500 TCP/WSS/BFCP RFC&rfc.number; 502 Figure 1: Values for the SDP 'proto' field 504 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 505 this specification, and remove this paragraph on publication.]] 507 11. Acknowledgements 509 The authors want to thank Robert Welbourn, from Acme Packet, who made 510 significant contributions to the first version of this document. 511 This work benefited from the thorough review and constructive 512 comments of Charles Eckel and Christer Holmberg. 514 12. References 516 12.1. Normative References 518 [I-D.ietf-bfcpbis-rfc4582bis] 519 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 520 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 521 ietf-bfcpbis-rfc4582bis-14 (work in progress), September 522 2015. 524 [I-D.ietf-bfcpbis-rfc4583bis] 525 Camarillo, G., Kristensen, T., and P. Jones, "Session 526 Description Protocol (SDP) Format for Binary Floor Control 527 Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-12 528 (work in progress), September 2015. 530 [I-D.ram-bfcpbis-sdp-ws-uri] 531 R, R. and G. Salgueiro, "Session Description Protocol 532 (SDP) WebSocket Connection URI Attribute", draft-ram- 533 bfcpbis-sdp-ws-uri-00 (work in progress), March 2015. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, 538 . 540 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 541 the Session Description Protocol (SDP)", RFC 4145, 542 DOI 10.17487/RFC4145, September 2005, 543 . 545 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 546 Floor Control Protocol (BFCP)", RFC 5018, 547 DOI 10.17487/RFC5018, September 2007, 548 . 550 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 551 RFC 6455, DOI 10.17487/RFC6455, December 2011, 552 . 554 12.2. Informative References 556 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 557 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 558 Transfer Protocol -- HTTP/1.1", RFC 2616, 559 DOI 10.17487/RFC2616, June 1999, 560 . 562 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 563 DOI 10.17487/RFC2818, May 2000, 564 . 566 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 567 (TLS) Protocol Version 1.2", RFC 5246, 568 DOI 10.17487/RFC5246, August 2008, 569 . 571 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 572 DOI 10.17487/RFC6265, April 2011, 573 . 575 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 577 Authors' Addresses 579 Victor Pascual 580 Oracle 582 Email: victor.pascual.avila@oracle.com 584 Anton Roman 585 Quobis 587 Email: anton.roman@quobis.com 589 Stephane Cazeaux 590 France Telecom Orange 592 Email: stephane.cazeaux@orange.com 594 Gonzalo Salgueiro 595 Cisco Systems, Inc. 596 7200-12 Kit Creek Road 597 Research Triangle Park, NC 27709 598 US 600 Email: gsalguei@cisco.com 601 Ram Mohan Ravindranath 602 Cisco Systems, Inc. 603 Cessna Business Park, 604 Kadabeesanahalli Village, Varthur Hobli, 605 Sarjapur-Marathahalli Outer Ring Road 606 Bangalore, Karnataka 560103 607 India 609 Email: rmohanr@cisco.com 611 Sergio Garcia Murillo 612 Medooze 614 Email: sergio.garcia.murillo@gmail.com