On Thu, Jan 6, 2011 at 12:54 PM, Harald Alvestrand
<harald@alvestrand.no> wrote:
On 01/06/11 20:18, Henry Sinnreich wrote:
Okay "direct flows of non-RTP application data" goes beyond scope creep;
to satisfy this completely, we are talking an end-point-to-end-point tunnel,
which will run afoul of a lot of folks who dearly love packet inspection.
Why should the IETF and W3C abide by the folks who love deep packet
inspection? I would like to see some IESG guidance here, since it is
contrary to Internet and to the Web. Break of privacy, etc.
To accelerate clarity here, what does Harald and people on the list think?
At the workshop, several use cases were identified where stuff that is not audio or video needed to be communicated from one browser to another quickly enough that relaying via backend web server(s) is problematic - the canonical poster child is the movement of bullets in a first-person shooter game, but there are other cases; I think Lisa mentioned that in Second Life, the placement of audio sources in the stereo field needs to be communicated reasonably synchronously with the sound itself.
I am hesitant to rule point-to-point traffic that isn't audio or video out of scope, given the discussion at the workshop; certainly, given the RAVEN RFC (RFC 2804), I do not want to rule it out of scope because it's hard to write packet inspection state machines that can tell what's going on here.
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.
The plan also is to be able to leverage DTLS to allow the creation of secure transports, which will have additional implications for DPI.
Harald