On Thu, Jan 6, 2011 at 1:25 PM, Justin Uberti <juberti@google.com> wrote:
Right. The thinking was that since we need to do a fair amount of work to allow audio and video to be exchanged safely and reliably peer-to-peer, we should allow web applications (with some limits) to use this transport mechanism for exchanging their own application data.
From a practical perspective, once you say "application data", the ability to limit this seems to approach zero pretty quickly. Even ignoring the network-based firewall, doesn't this now require me to have a browser-based firewall, to express my policies for what traffic I permit over this?
The plan also is to be able to leverage DTLS to allow the creation of secure transports, which will have additional implications for DPI.
Agreed. More importantly, I think that reinforces the idea that this is not a simple add-on to audio/video functionality. As I argued in draft-hardie-mdtls-session, you are really creating a multi-flow session layer. I personally think that's a fine thing, but it is not an adjunct to a charter-it's the top-line bullet item in my view. regards, Ted PS. As an aside, both Jake and I have since left Panasonic and the project mentioned in the draft cited above. I do not believe that the sponsor lab will release the code created for it at this time so the discussion I had with some folks on that in Beijing will likely need to take other paths.
Harald
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web