Original text:
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- <del> overview.  The major use cases for WebTC technology are real-time </del>  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 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 <del> 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). </del>  More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes.  While there are techniques to allow them 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 <del> 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. </del>  4.3.

Reviewer comments:
As discussed, a couple of minor typos and corrections.
The travis failures here aren't Michael's fault.
I've looked up the missing reference dates and added them. Travis seems happier.

Revised text:
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-  <ins> overview.  The major use cases for WebRTC technology are real-time </ins> 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 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  <ins> 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). </ins> More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes.  While there are techniques to allow them 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  <ins> 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. </ins> 4.3.