Change:
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> <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

Discussion:
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).