Draft: rtcweb-overview

Commentary: 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  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 " 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  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 , " Does n'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 " 
 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 . 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 ) .
This document is intended to serve as the roadmap to the WebRTC
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.
This document is intended to serve as the roadmap to the WebRTC
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.
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.
Together, these two specifications aim to provide an environment
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.
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).
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.
An implementation of the Interactive Connectivty Establishment
(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).
Communication that happens in order to establish, manage and
control media paths.
Communication that happens in order to establish, manage and
control media paths and data paths.
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.
This means that two vital interfaces need specification: The
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.
The choice of protocols, and definition of the translation between
them, is outside the scope of the WebRTC protocol suite described in
the document.
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.
Data framing: RTP and other data formats that serve as containers,
and their functions for data confidentiality and integrity.
Data framing: RTP, SCTP and other data formats that serve as
containers, and their functions for data confidentiality and
integrity.