Draft: draft-ietf-rtcweb-security

Commentary: As discussed , a couple of minor typos and corrections . 
 The travis failures here are n't  's fault . 
 I 've looked up the missing reference dates and them . Travis seems happier .
The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications
between Web browsers, generally called "WebRTC" I-D.ietf-rtcweb-
overview.  The major use cases for WebTC technology are real-time
audio and/or video calls, Web conferencing, and direct data transfer.
Unlike most conventional real-time systems, (e.g., SIP-basedRFC3261
soft phones) WebRTC communications are directly controlled by some
Web server.  A simple case is shown below.
The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications
between Web browsers, generally called "WebRTC" I-D.ietf-rtcweb-
overview.  The major use cases for WebRTC technology are real-time
audio and/or video calls, Web conferencing, and direct data transfer.
Unlike most conventional real-time systems, (e.g., SIP-basedRFC3261
soft phones) WebRTC communications are directly controlled by some
Web server.  A simple case is shown below.
Many other resources are accessible but isolated.  For instance,
while scripts are allowed to make HTTP requests via the
XMLHttpRequest() API those requests are not allowed to be made to any
server, but rather solely to the same ORIGIN from whence the script
came xref target="RFC6454"/> (although CORS CORS and WebSockets
RFC6455 provide a escape hatch from this restriction, as described
below.)  This SAME ORIGIN POLICY (SOP) prevents server A from
mounting attacks on server B via the user's browser, which protects
both the user (e.g., from misuse of his credentials) and the server B
(e.g., from DoS attack).
Many other resources are accessible but isolated.  For instance,
while scripts are allowed to make HTTP requests via the
XMLHttpRequest() API those requests are not allowed to be made to any
server, but rather solely to the same ORIGIN from whence the script
came RFC6454 (although CORS CORS and WebSockets RFC6455 provide a
escape hatch from this restriction, as described below.)  This SAME
ORIGIN POLICY (SOP) prevents server A from mounting attacks on server
B via the user's browser, which protects both the user (e.g., from
misuse of his credentials) and the server B (e.g., from DoS attack).
In ordinary operation, the site learns the browser's IP address,
though it may be hidden via mechanisms like Tor
[http://www.torproject.org] or a VPN.  However, because sites can
cause the browser to provide IP addresses, this provides a mechanism
for sites to learn about the user's network environment even if the
user is behind a VPN that masks their IP address.  Implementations
wish to provide settings which suppress all non-VPN candidates if the
user is on certain kinds of VPN, especially privacy-oriented systems
such as Tor.
In ordinary operation, the site learns the browser's IP address,
though it may be hidden via mechanisms like Tor
[http://www.torproject.org] or a VPN.  However, because sites can
cause the browser to provide IP addresses, this provides a mechanism
for sites to learn about the user's network environment even if the
user is behind a VPN that masks their IP address.  Implementations
may wish to provide settings which suppress all non-VPN candidates if
the user is on certain kinds of VPN, especially privacy-oriented
systems such as Tor.