< draft-ietf-bfcpbis-bfcp-websocket-04.txt   draft-ietf-bfcpbis-bfcp-websocket-05.txt >
BFCPBIS Working Group V. Pascual BFCPBIS Working Group V. Pascual
Internet-Draft A. Roman Internet-Draft A. Roman
Updates: rfc4582bis, rfc4583bis (if Quobis Updates: rfc4582bis, rfc4583bis (if Quobis
approved) S. Cazeaux approved) S. Cazeaux
Intended status: Standards Track France Telecom Orange Intended status: Standards Track France Telecom Orange
Expires: September 24, 2015 G. Salgueiro Expires: March 11, 2016 G. Salgueiro
Ram. Ravindranath Ram. Ravindranath
Cisco Cisco
S. Garcia Murillo S. Garcia Murillo
Medooze Medooze
March 23, 2015 September 8, 2015
The WebSocket Protocol as a Transport for the Binary Floor Control The WebSocket Protocol as a Transport for the Binary Floor Control
Protocol (BFCP) Protocol (BFCP)
draft-ietf-bfcpbis-bfcp-websocket-04 draft-ietf-bfcpbis-bfcp-websocket-05
Abstract Abstract
The WebSocket protocol enables two-way realtime communication between The WebSocket protocol enables two-way realtime communication between
clients and servers. This document specifies a new WebSocket sub- clients and servers. This document specifies a new WebSocket sub-
protocol as a reliable transport mechanism between Binary Floor protocol as a reliable transport mechanism between Binary Floor
Control Protocol (BFCP) entities to enable usage of BFCP in new Control Protocol (BFCP) entities to enable usage of BFCP in new
scenarios. scenarios.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 24, 2015. This Internet-Draft will expire on March 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 4 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 4
4. The WebSocket BFCP Sub-Protocol . . . . . . . . . . . . . . . 5 4. The WebSocket BFCP Sub-Protocol . . . . . . . . . . . . . . . 4
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. BFCP Encoding . . . . . . . . . . . . . . . . . . . . . . 5 4.2. BFCP Encoding . . . . . . . . . . . . . . . . . . . . . . 5
5. Transport Reliability . . . . . . . . . . . . . . . . . . . . 6 5. Transport Reliability . . . . . . . . . . . . . . . . . . . . 6
6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' Values . . . 6 6.1. Updates to RFC4583bis . . . . . . . . . . . . . . . . . . 6
6.2. SDP Media Attributes . . . . . . . . . . . . . . . . . . 7 6.2. Updates to RFC4582bis . . . . . . . . . . . . . . . . . . 6
6.3. SDP Media Attributes . . . . . . . . . . . . . . . . . . 7
7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.2. Generating the Initial Offer . . . . . . . . . . . . . . 7 7.2. Generating the Initial Offer . . . . . . . . . . . . . . 7
7.3. Generating the Answer . . . . . . . . . . . . . . . . . . 8 7.3. Generating the Answer . . . . . . . . . . . . . . . . . . 8
7.4. Offerer Processing of the Answer . . . . . . . . . . . . 9 7.4. Offerer Processing of the Answer . . . . . . . . . . . . 9
7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 9 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 9
8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 9 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 11 10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 11
10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP
'proto' Values . . . . . . . . . . . . . . . . . . . . . 11 'proto' Values . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The WebSocket [RFC6455] protocol enables two-way message exchange The WebSocket [RFC6455] protocol enables two-way message exchange
between clients and servers on top of a persistent TCP connection between clients and servers on top of a persistent TCP connection,
(optionally secured with TLS [RFC5246]). The initial protocol optionally secured with Transport Layer Security (TLS) [RFC5246].
handshake makes use of HTTP [RFC2616] semantics, allowing the The initial protocol handshake makes use of Hypertext Transfer
WebSocket protocol to reuse existing HTTP infrastructure. Protocol (HTTP) [RFC2616] semantics, allowing the WebSocket protocol
to reuse existing HTTP infrastructure.
The Binary Floor Control Protocol (BFCP) is a protocol to coordinate The Binary Floor Control Protocol (BFCP) is a protocol to coordinate
access to shared resources in a conference. It is defined in access to shared resources in a conference. It is defined in
[I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants [I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants
and floor control servers, and between floor chairs (i.e., and floor control servers, and between floor chairs (i.e.,
moderators) and floor control servers. moderators) and floor control servers.
Modern web browsers include a WebSocket client stack complying with Modern web browsers include a WebSocket client stack complying with
the WebSocket API [WS-API] as specified by the W3C. It is expected the WebSocket API [WS-API] as specified by the W3C. It is expected
that other client applications (those running in personal computers that other client applications (those running in personal computers
and devices such as smartphones) will also make a WebSocket client and devices such as smartphones) will also make a WebSocket client
stack available. This document updates [I-D.ietf-bfcpbis-rfc4582bis] stack available. This document updates [I-D.ietf-bfcpbis-rfc4582bis]
and [I-D.ietf-bfcpbis-rfc4583bis] in order to enable the usage of and [I-D.ietf-bfcpbis-rfc4583bis] in order to enable the usage of
BFCP in these scenarios. BFCP in these scenarios.
The transport over which BFCP entities exchange messages depends on The transport over which BFCP entities exchange messages depends on
how the clients obtain information to contact the floor control how the clients obtain information to contact the floor control
server (e.g. using an SDP offer/answer exchange per server (e.g. using an Session Description Protocol (SDP) offer/answer
[I-D.ietf-bfcpbis-rfc4583bis] or the procedure described in RFC5018 exchange per [I-D.ietf-bfcpbis-rfc4583bis] or the procedure described
[RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two transports for in RFC5018 [RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two
BFCP: TCP and UDP. This specification defines a new WebSocket sub- transports for BFCP: TCP and UDP. This specification defines a new
protocol (as defined in section 1.9 in [RFC6455]) for transporting WebSocket sub-protocol (as defined in section 1.9 in [RFC6455]) for
BFCP messages between a WebSocket client and server. This sub- transporting BFCP messages between a WebSocket client and server.
protocol provides a reliable and boundary preserving transport for This sub-protocol provides a reliable and boundary preserving
BFCP when run on top of TCP. Since WebSocket is a reliable transport for BFCP when run on top of TCP. Since WebSocket provides
transport, the extensions defined in [I-D.ietf-bfcpbis-rfc4582bis] a reliable transport, the extensions defined in
for sending BFCP over unreliable transports are not applicable. This [I-D.ietf-bfcpbis-rfc4582bis] for sending BFCP over unreliable
document normatively updates [I-D.ietf-bfcpbis-rfc4582bis] and transports are not applicable. This document normatively updates
[I-D.ietf-bfcpbis-rfc4583bis]. [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis].
This document does not restrict the selection nor prevent the usage
of other transport mechanisms for the BFCP protocol. Transport
selection is entirely at the discretion of the application. As an
example, an RTCWeb applications may choose to use either DataChannel
or WebSocket transport for BFCP, while non-RTCWeb applications could
still benefit from the ubiquity of the WebSocket protocol and make
use of the transport for BFCP defined in this document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Definitions 2.1. Definitions
BFCP WebSocket Client: Any BFCP entity capable of opening outbound BFCP WebSocket Client: Any BFCP entity capable of opening outbound
skipping to change at page 6, line 17 skipping to change at page 6, line 11
[I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for [I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for
reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be
followed. followed.
While this specification assumes that BFCP encoding is only TLV While this specification assumes that BFCP encoding is only TLV
binary, future documents may define other mechanisms like JSON binary, future documents may define other mechanisms like JSON
serialization. serialization.
5. Transport Reliability 5. Transport Reliability
WebSocket [RFC6455] is a reliable protocol and therefore the BFCP WebSocket [RFC6455] provides a reliable transport and therefore the
WebSocket sub-protocol defined by this document is a reliable BFCP BFCP WebSocket sub-protocol defined by this document also provides
transport. Thus, client and server transactions using WebSocket for reliable BFCP transport. Thus, client and server transactions using
transport MUST follow the procedures for reliable transports as WebSocket for transport MUST follow the procedures for reliable
defined in [I-D.ietf-bfcpbis-rfc4582bis] and transports as defined in [I-D.ietf-bfcpbis-rfc4582bis] and
[I-D.ietf-bfcpbis-rfc4583bis] [I-D.ietf-bfcpbis-rfc4583bis]
BFCP WebSocket clients cannot receive incoming WebSocket connections BFCP WebSocket clients cannot receive incoming WebSocket connections
initiated by any other peer. This means that a BFCP WebSocket client initiated by any other peer. This means that a BFCP WebSocket client
MUST actively initiate a connection towards a BFCP WebSocket server MUST actively initiate a connection towards a BFCP WebSocket server
Each BFCP message MUST be carried within a single WebSocket message, Each BFCP message MUST be carried within a single WebSocket message,
and a WebSocket message MUST NOT contain more than one BFCP message. and a WebSocket message MUST NOT contain more than one BFCP message.
6. SDP Considerations 6. SDP Considerations
6.1. 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' Values 6.1. Updates to RFC4583bis
Rules to generate an 'm' line for a BFCP stream are described in Rules to generate an 'm' line for a BFCP stream are described in
[I-D.ietf-bfcpbis-rfc4583bis], Section 3 [I-D.ietf-bfcpbis-rfc4583bis], Section 3
New values are defined for the transport field: TCP/WS/BFCP and New values are defined for the transport field: TCP/WS/BFCP and
TCP/WSS/BFCP. TCP/WSS/BFCP.
TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn
runs on top of TCP. runs on top of TCP.
TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn
runs on top of TLS and TCP. runs on top of TLS and TCP.
6.2. Updates to RFC4582bis
When TCP is used as the transport, the port field is set following When TCP is used as the transport, the port field is set following
the rules in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis]. Depending the rules in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis]. Depending
on the value of the 'setup' attribute, the port field contains the on the value of the SDP 'setup' attribute defined in [RFC4145], the
port to which the remote endpoint will direct BFCP messages or is port field contains the port to which the remote endpoint will direct
irrelevant (i.e., the endpoint will initiate the connection towards BFCP messages or is irrelevant (i.e., the endpoint will initiate the
the remote endpoint) and should be set to a value of 9, which is the connection towards the remote endpoint) and should be set to a value
discard port. Connection attribute and port MUST follow the rules of of 9, which is the discard port. Connection attribute and port MUST
[RFC4145] follow the rules of [RFC4145]
Some web browsers do not allow non-secure WebSocket connections to be Some web browsers do not allow non-secure WebSocket connections to be
made. So, while the recommendation to use Secure WebSockets (i.e. made. So, while the recommendation to use Secure WebSockets (i.e.
TCP/WSS) is for security reasons, it is also to achieve maximum TCP/WSS) is for security reasons, it is also to achieve maximum
compatibility among clients. compatibility among clients.
6.2. SDP Media Attributes 6.3. SDP Media Attributes
[I-D.ram-bfcpbis-sdp-ws-uri] defines a new SDP attributes to indicate [I-D.ram-bfcpbis-sdp-ws-uri] defines a new SDP attributes to indicate
the connection URI for the WebSocket Client. The SDP attribute 'ws- the connection Uniform Resource Identifier (URI) for the WebSocket
uri' defined in section 3.1 of [I-D.ram-bfcpbis-sdp-ws-uri] MUST be Client. The SDP attribute 'ws-uri' defined in section 3.1 of
used when BFCP runs on top of WS, which in turn runs on top of TCP.
The SDP attribute 'wss-uri' defined in section 3.2 of
[I-D.ram-bfcpbis-sdp-ws-uri] MUST be used when BFCP runs on top of [I-D.ram-bfcpbis-sdp-ws-uri] MUST be used when BFCP runs on top of
WSS, which in turn runs on top of TLS and TCP. When the 'ws-uri' or WS, which in turn runs on top of TCP. The SDP attribute 'wss-uri'
'wss-uri' attribute is present in the media section of the SDP, the defined in section 3.2 of [I-D.ram-bfcpbis-sdp-ws-uri] MUST be used
IP and port information provided in the 'c' lines SHALL be ignored when BFCP runs on top of WSS, which in turn runs on top of TLS and
and the full URI SHALL be used instead to open the WebSocket TCP. When the 'ws-uri' or 'wss-uri' attribute is present in the
connection. The port provided in the 'm' line SHALL be ignored too, media section of the SDP, the IP and port information provided in the
as the a=ws-uri or a=wss-uri SHALL provide port number when needed. 'c' lines SHALL be ignored and the full URI SHALL be used instead to
open the WebSocket connection. The port provided in the 'm' line
SHALL be ignored too, as the a=ws-uri or a=wss-uri SHALL provide port
number when needed.
7. SDP Offer/Answer Procedures 7. SDP Offer/Answer Procedures
7.1. General 7.1. General
An endpoint (i.e., both the offerer and the answerer) MUST create an An endpoint (i.e., both the offerer and the answerer) MUST create an
SDP media description ("m=" line) for each BFCP-over-WebSocket media SDP media description ("m=" line) for each BFCP-over-WebSocket media
stream and MUST assign a TCP/WSS/BFCP value to the "proto" field of stream and MUST assign a TCP/WSS/BFCP value to the "proto" field of
the "m=" line. Furthermore, the SDP answerer (Server) MUST add an the "m=" line. Furthermore, the SDP answerer (Server) MUST add an
"a=ws-uri" or "a=wss-uri" attribute in the "m=" line of each BFCP- "a=ws-uri" or "a=wss-uri" attribute in the "m=" line of each BFCP-
skipping to change at page 12, line 24 skipping to change at page 12, line 23
Protocol (SDP) Format for Binary Floor Control Protocol Protocol (SDP) Format for Binary Floor Control Protocol
(BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-11 (work in (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-11 (work in
progress), February 2015. progress), February 2015.
[I-D.ram-bfcpbis-sdp-ws-uri] [I-D.ram-bfcpbis-sdp-ws-uri]
R, R. and G. Salgueiro, "Session Description Protocol R, R. and G. Salgueiro, "Session Description Protocol
(SDP) WebSocket Connection URI Attribute", draft-ram- (SDP) WebSocket Connection URI Attribute", draft-ram-
bfcpbis-sdp-ws-uri-00 (work in progress), March 2015. bfcpbis-sdp-ws-uri-00 (work in progress), March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. DOI 10.17487/RFC4145, September 2005,
<http://www.rfc-editor.org/info/rfc4145>.
[RFC5018] Camarillo, G., "Connection Establishment in the Binary [RFC5018] Camarillo, G., "Connection Establishment in the Binary
Floor Control Protocol (BFCP)", RFC 5018, September 2007. Floor Control Protocol (BFCP)", RFC 5018,
DOI 10.17487/RFC5018, September 2007,
<http://www.rfc-editor.org/info/rfc5018>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
6455, December 2011. RFC 6455, DOI 10.17487/RFC6455, December 2011,
<http://www.rfc-editor.org/info/rfc6455>.
12.2. Informative References 12.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012.
Authors' Addresses Authors' Addresses
Victor Pascual Victor Pascual
Quobis Quobis
Email: victor.pascual@quobis.com Email: victor.pascual@quobis.com
 End of changes. 25 change blocks. 
66 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35