Original text:
Overview: Real Time Protocols for Browser-based Applications <del> draft-ietf-rtcweb-overview-16 </del>  Abstract participants. This document is intended to serve as the roadmap to the WebRTC <del> specifications.  It defines terms used by other pieces of specification, lists references to other specifications that don't need further elaboration in the WebRTC context, and gives pointers to other documents that form part of the WebRTC suite. </del>  By reading this document and the documents it refers to, it should be possible to have all information needed to implement an WebRTC 2.2. <del> The total WebRTC effort consists of two pieces: </del>  A protocol specification, done in the IETF <del> A Javascript API specification, done in the W3C </del>  Together, these two specifications aim to provide an environment <del> where Javascript embedded in any page, viewed in any compatible browser, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, where the browser environment does not constrain the types of application in which this functionality can be used. </del>  The protocol specification does not assume that all implementations implement this API; it is not intended to be necessary for HTML specification W3C.WD-html5-20110525.  See also "WebRTC User Agent".  An implementation of the Interactive Connectivty Establishment <del> (ICE) RFC5245 protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle). </del>  Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another exchange, as defined in RFC3264 section 3. Communication that happens in order to establish, manage and <del> control media paths. </del>  The communication channels used between entities participating in signaling to transfer signaling.  There may be more entities in conjunction with its backend servers, to implement these functions. This means that two vital interfaces need specification: The <del> protocols that browsers talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. </del>  <del> Note that HTTP and Websockets are also offered to the Javascript </del>  application through browser APIs. As for all protocol and API specifications, there is no restriction For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a <del> standardized signaling mechanism (e.g.  SIP over Websockets) or a </del>  proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators' servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. <del> XMPP over Websockets or BOSH) or a proprietary signaling mechanism </del>  used between the application running in the browser and the web server. <del> The choice of protocols, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document. </del>  The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: deciding when to send data: Congestion management, bandwidth estimation and so on. <del> Data framing: RTP and other data formats that serve as containers, and their functions for data confidentiality and integrity. </del>  Data formats: Codec specifications, format specifications and functionality specifications for the data passed between systems.

Reviewer comments:
From Magnus, on mailing list, with response: Actually both the IETF effort and the W3C effort consists of lots of moving parts. Would "A Javascript API, defined by a set of specifications [cite]" scan better?
"This means that two vital interfaces need specification: The protocols that browsers talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality." I would add a "use to" between "browsers" and "talk"
You write "Websockets" in many places. The w3c spec seems to prefer "WebSockets"
"The choice of protocols, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document." I would like to add "inter-server signaling" before "protocols" to be very clear here.
"Data framing: RTP and other data formats that serve as containers, and their functions for data confidentiality and integrity." Should SCTP be mentioned here for clarity?
All suggestions taken except the "inter-server signalling" one - the choice of protocols for client-server signalling is also out of scope for this document, so I added "client-server and inter-server" instead.
"ICE Agent: An implementation of the Interactive Connectivty Establishment (ICE) [RFC5245] protocol. An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle)." Just a not to verify that this is right: RFC 5245 defines "Agent" the same way as this document specifies "SDP agent" and refers to RFC 3264 for a definition of Agent. The term "Ice Agent" appear later in the terminology section though not as a separate definition but as an explanation of controlling and controlled agent... Nit picking here. ;-)
"Signaling: Communication that happens in order to establish, manage and control media paths." Signaling is also used for data channels
Data channels lack a term here. You have defined media and media path
Re Agent: RFC 5245 section 2 says "In a typical ICE deployment, we have two endpoints (known as AGENTS in RFC 3264 terminology) that want to communicate. They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can perform an offer/answer exchange of SDP [RFC3264] messages." RFC 5245bis says "In a typical ICE deployment, we have two endpoints (known as ICE AGENTS) that want to communicate. They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can exchange ICE candidates." The binding to SDP has apparently been loosened in 5245bis. I think we should move the reference to 5245bis - we already have normative dependencies on that from dualstack-fairness and bundle, so it's not a new blocker.
Added data channel and moved pointers to 5245bis.
" The total WebRTC effort consists of two pieces:" I would say "two major pieces" or "parts" since we have a lot of documents and components, so just saying two pieces seems an underestimation.
" Together, these two specifications aim to provide an environment where Javascript embedded in any page, viewed in any compatible browser, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, where the browser environment does not constrain the types of application in which this functionality can be used." This is a very complex sentence. Can this be simplified?
I tried restructuring it.
"It defines terms used by other pieces of specification," Doesn't feel right to me, but I could be reading in Swenglish here. "other specifications" or "other pieces of specifications"
"other pieces of specification" should probably read "other parts of the WebRTC protocol suite". The intent was to capture that terms of art like "WebRTC browser" and "WebRTC endpoint" are defined here and used elsewhere.
Changed to "other parts of the WebRTC protocol specifications".
"This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web"." Later in the document you mention non-browsers such as gateways. Do you want to include them in the abstract? ..."to make sure all the parts"... I feel that "that" is missing between "sure" and "all"
Not really - the focus here is that it has to be usable on the Web. There's time enough to mention non-browsers later in the document. My English sense says that the sentence works both with and without "that" - I'll defer to native speakers of US-English for this one.
Closing as "no change needed" (editor's judgment).

Revised text:
Overview: Real Time Protocols for Browser-based Applications  <ins> draft-ietf-rtcweb-overview-17 </ins> Abstract participants. This document is intended to serve as the roadmap to the WebRTC  <ins> specifications.  It defines terms used by other parts of the WebRTC protocol specifications, lists references to other specifications that don't need further elaboration in the WebRTC context, and gives pointers to other documents that form part of the WebRTC suite. </ins> By reading this document and the documents it refers to, it should be possible to have all information needed to implement an WebRTC 2.2.  <ins> The total WebRTC effort consists of two major parts, each consisting of multiple documents: </ins> A protocol specification, done in the IETF  <ins> A Javascript API specification, defined in a series of W3C documents </ins> Together, these two specifications aim to provide an environment  <ins> where Javascript embedded in any page, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, as long as the browser supports this specification. The browser environment does not constrain the types of application in which this functionality can be used. </ins> The protocol specification does not assume that all implementations implement this API; it is not intended to be necessary for HTML specification W3C.WD-html5-20110525.  See also "WebRTC User Agent". <ins> An abstraction that allows data to be sent between WebRTC endpoints in the form of messages.  Two endpoints can have multiple data channels between them. </ins> An implementation of the Interactive Connectivty Establishment  <ins> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle). </ins> Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another exchange, as defined in RFC3264 section 3. Communication that happens in order to establish, manage and  <ins> control media paths and data paths. </ins> The communication channels used between entities participating in signaling to transfer signaling.  There may be more entities in conjunction with its backend servers, to implement these functions. This means that two vital interfaces need specification: The  <ins> protocols that browsers use to talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. </ins>  <ins> Note that HTTP and WebSockets are also offered to the Javascript </ins> application through browser APIs. As for all protocol and API specifications, there is no restriction For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a  <ins> standardized signaling mechanism (e.g.  SIP over WebSockets) or a </ins> proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators' servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g.  <ins> XMPP over WebSockets or BOSH) or a proprietary signaling mechanism </ins> used between the application running in the browser and the web server.  <ins> The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document. </ins> The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: deciding when to send data: Congestion management, bandwidth estimation and so on.  <ins> Data framing: RTP, SCTP and other data formats that serve as containers, and their functions for data confidentiality and integrity. </ins> Data formats: Codec specifications, format specifications and functionality specifications for the data passed between systems.