Technical Summary
This document discusses a number of usages of browser based
real-time communication and data transfer capabilities
and establish requirements for these usages. The document
is intended to be used both in IETF and W3C during the
development of the WebRTC specifications.
Working Group Summary
The document has been under development during a longer period
and a larger number of use cases has been proposed then what
is included in the document. These that have been included
has been considered the most basic, most relevant to core
functionality and without significant controversies.
Document Quality
There has been some concerns about the structure of the document,
but the WG see no significant need to address this. The document
is requested to be published as a documentation of the
core consideration around usages that was of interest during
the first part of the WebRTC work. The other expected usage of this
document will be to analyze if the resulting protocol solution
will enable the considered use cases.
The document has been reviewed and commented on by a significant
number of people within the WG, including persons active in the W3C
WEBRTC WG.
Personnel
Magnus Westerlund is the Document Shepherd.
Richard Barnes is the Responsible Area Director.
RFC Editor Note
One minor change to address Stephen's DISCUSS.
OLD:
A malicious web application might use the browser to perform Denial
Of Service (DOS) attacks on NAT infrastructure, or on peer devices.
Also, a malicious web application might silently establish outgoing,
and accept incoming, streams on an already established connection.
NEW:
A malicious web application might use the browser to perform Denial
Of Service (DOS) attacks on NAT infrastructure, or on peer devices.
For example, a malicious web application might leak TURN credentials
to unauthorized parties, allowing them to consume the TURN server's
bandwidth. To address this risk, Web applications should be
prepared to revoke TURN credentials and issue new ones. Also, a
malicious web application might silently establish outgoing,
and accept incoming, streams on an already established connection.