Subject: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 21 Feb 2013 18:38:13 +0100

Hi all,

We have submitted a new Internet draft to describe the WebSocket
Protocol as a Transport for the Binary Floor Control Protocol (BFCP).
We are looking forward to your review comments.

http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00

Best regards,
-Victor

On 2/15/13 6:17 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt
>has been successfully submitted by Victor Pascual and posted to the
>IETF repository.
>
>Filename:       draft-pascual-dispatch-bfcp-websocket
>Revision:       00
>Title:          The WebSocket Protocol as a Transport for the Binary Floor
>Control Protocol (BFCP)
>Creation date:  2013-02-15
>Group:          Individual Submission
>Number of pages: 9
>URL:
>http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-websocket-
>00.txt
>Status:
>http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket
>Htmlized:
>http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>
>
>Abstract:
>   The WebSocket protocol enables two-way realtime communication between
>   clients and servers.  This document specifies a new WebSocket sub-
>   protocol as a reliable transport mechanism between Binary Floor
>   Control Protocol (BFCP) entities to enable usage of BFCP in new
>   scenarios.  This document normatively updates
>   [I-D.draft-ietf-bfcpbis-rfc4582bis] and
>   [I-D.draft-ietf-bfcpbis-rfc4583bis]
>
>
>
>
>
>The IETF Secretariat
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2013 16:32:14 -0500

Victor,

A question for you:

Another possibility is to map bfcp over a data channel as being 
specified for rtcweb.

If that were done, would it be a suitable alternative to bfcp over 
websocket?

We are also going to need bfcp support in conjunction with CLUE.
And CLUE is going to have its own data channel. We are aiming to use an 
rtcweb-compatible data channel so that we can have rtcweb browser based 
clue clients.

If bfcp also worked over a data channel, then these multiple uses of 
data channels could all coexist on a single SCTP association. And they 
could work the same regardless of whether or not there are web clients.

	Thanks,
	Paul

On 2/21/13 12:38 PM, Victor Pascual Avila wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: <[email-masked]>
Date: Fri, 22 Feb 2013 16:40:38 +0000

Hi Paul,

Having BFCP over data channel would limit the applicability of BFCP to webrtc (other formulation: it would require the webrtc framework to get BFCP in the browser), while we might want to have BFCP protocol in web client outside of webrtc.

Stéphane.

-----Message d'origine-----
De : Paul Kyzivat [mailto:[email-masked]] 
Envoyé : jeudi 21 février 2013 22:32
À : [email-masked]
Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt

Victor,

A question for you:

Another possibility is to map bfcp over a data channel as being specified for rtcweb.

If that were done, would it be a suitable alternative to bfcp over websocket?

We are also going to need bfcp support in conjunction with CLUE.
And CLUE is going to have its own data channel. We are aiming to use an rtcweb-compatible data channel so that we can have rtcweb browser based clue clients.
      
If bfcp also worked over a data channel, then these multiple uses of data channels could all coexist on a single SCTP association. And they could work the same regardless of whether or not there are web clients.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 23 Feb 2013 20:29:57 -0500

> Having BFCP over data channel would limit the applicability of BFCP to webrtc (other formulation: it would require the webrtc framework to get BFCP in the browser), while we might want to have BFCP…

I guess I didn't explain myself well enough.

What I am suggesting is bfcp over the DTLS/SCTP stack that is being used 
for RTCWEB data channels, and that the mechanisms used to negotiate the 
stream numbers for each direction be compatible with RTCWEB. In this way 
a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g. 
C-based) implementation is also possible.

This is the same direction we are investigating for the clue data channel.

The term "data channel" here is perhaps overloaded, because it could 
mean a real RTCWEB data channel, or something similar for other 
environments. Ideally we would just use SCTP terms, but it has no term 
for a bidirectional "channel", only unidirectional streams. But this 
should end up being formalized in the SDP.

	Thanks,	
	Paul

---

From: <[email-masked]>
Date: Sun, 24 Feb 2013 09:28:20 +0000

That was my understanding. My point is that on the browser, the data channel is part of the webrtc stuff. While websocket is to me more suitable for such browser to server exchange.
Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE endpoint since, unless I am wrong, a CLUE endpoint will also have to support bfcp over tcp (or udp) to interwork with legacy ?

Stéphane.
________________________________
De : Paul Kyzivat
Envoyé : 24/02/2013 02:32
À : CAZEAUX Stephane OLNC/OLPS
Cc : [email-masked]
Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Feb 2013 05:43:30 +0800

On 2/24/13 5:28 PM, [email-masked] wrote:
> That was my understanding. My point is that on the browser, the data
> channel is part of the webrtc stuff. While websocket is to me more
> suitable for such browser to server exchange.
> Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE
> endpoint since, unless I am wrong, a CLUE endpoint will also have to
> support bfcp over tcp (or udp) to interwork with legacy ?

First, AFAIK there are currently no plans to put bfcp over a data 
channel, but I think there should be.

My reason is because that is a mechanism that could be supported by a an 
RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint 
may still need to support bfcp over tcp or udp for legacy interworking.

It would also be possible for an RTCWEB clue client to use bfcp over a 
websocket.

The question is: how many of these alternatives do we want to define and 
then ask people to support in their products. The more alternatives we 
have the less likely we are to get interoperability.

We have now started down the path of remapping existing protocols (first 
SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is 
defining data channels over SCTP and and CLUE is tentatively planning to 
put its protocol over that. So maybe we had better have a discussion of 
where we are trying to go, and if what we are doing will get us to a 
good place.

	Thanks,
	Paul

> Stéphane.
> ------------------------------------------------------------------------
> De : Paul Kyzivat
> Objet : Re: [dispatch] FW: New Version Notification for
> draft-pascual-dispatch-bfcp-websocket-00.txt
>