Re: Proposed Charter Changes

Hi,

Just a few questions to ensure I don¹t misunderstand:

>
>s the name implies, WebRTC 1.0: Real-time Communication Between Browsers
>is to be considered as a first version of APIs for real-time
>communication. The working group will, once WebRTC 1.0: Real-time
>Communication Between Browsers reaches Candidate Recommendation, consider
>proposals for backward-compatible object-oriented extensions to this API.

I assume ³backward-compatible² include the possibility of the 1.0 API
being supported using a js-shim on the evolved object-oriented/inspired
low-level API's?

The word ³extension²; does that mean new functionality ³only² could be
object-oriented or does it also allow for existing functionality in 1.0 to
be supported with low-level oo- API's, replacing 1.0 approach API's, were
the WG to consider that motivated and desirable?


Best Regards
Göran


>
>
>To make things easy to diff, you can find the text for the current
>charter at 
>https://github.com/fluffy/webrtc-charter/blob/gh-pages/current-charter.txt
>
>The proposed version of the charter that the AC voted on is at
>https://github.com/fluffy/webrtc-charter/blob/gh-pages/proposed-charter.tx
>t
>
>The charter I am proposing is in the fluffy branch of that repo and is at
>https://github.com/fluffy/webrtc-charter/blob/fluffy/proposed-charter.txt
>
>The diff of what I am proposing to the charter that the AC reps voted on
>is at 
>https://github.com/fluffy/webrtc-charter/compare/gh-pages...fluffy:fluffy
>
>
>
>The full charter I am proposing is below
>-----------------------------------------------------
>
>Web Real-Time Communications Working Group Charter
>
>The mission of the Web Real-Time Communications Working Group, part of
>the Ubiquitous Web Applications Activity, is to define client-side APIs
>to enable Real-Time Communications in Web browsers.
>
>These APIs should enable building applications that can be run inside a
>browser, requiring no extra downloads or plugins, that allow
>communication between parties using audio, video and supplementary
>real-time communication, without having to use intervening servers
>(unless needed for firewall traversal, or for providing intermediary
>services). APIs enabling supplementary functions, such as recording,
>image capture and screen sharing are also in scope.
>
>Join the Web Real-Time Communications Working Group.
>
>End date	March 2017
>Confidentiality	Proceedings are public
>Initial Chairs	
>Harald Alvestrand
>Stefan Håkansson
>Team Contacts
>(FTE %: 10)	Dominique Hazaël-Massieux
>Usual Meeting Schedule	Teleconferences: approximately 1 per month
>Face-to-face: up to 3-4 per year
>
>Scope
>
>Enabling real-time communications between Web browsers require the
>following client-side technologies to be available:
>
>API functions to explore device capabilities, e.g. camera, microphone,
>speakers,
>API functions to capture media from local devices (e.g. camera and
>microphone, but also output devices such as a screen),
>API functions for encoding and other processing of those media streams,
>API functions for establishing direct peer-to-peer connections, including
>firewall/NAT traversal
>API functions for decoding and processing (including echo cancelling,
>stream synchronization and a number of other functions) of those streams
>at the incoming end,
>Delivery to the user of those media streams via local screens and audio
>output devices (partially covered with HTML5)
>
>Success Criteria
>
>To advance to Proposed Recommendation, each specification is expected to
>have two independent implementations of each feature defined in the
>specification.
>
>To advance to Proposed Recommendation, interoperability between the
>independent implementations (that is, bidirectional audio and video
>communication between the implementations) should be demonstrated.
>
>Out of Scope
>
>The definition of the network protocols used to establish the connections
>between peers is out of scope for this group; in general, it is expected
>that protocols considerations will be handled in the IETF.
>
>The definition of any new codecs for audio and video is out of scope.
>
>Deliverables
>
>Recommendation-Track Deliverables
>
>The working group will deliver specifications that cover at least the
>following functions, unless they are found to be fully specified within
>other working groups' finished results:
>
>Media Stream Functions
>API functions to manipulate media streams for interactive real-time
>communications, connecting various processing functions to each other,
>and to media devices and network connections, including media
>manipulation functions for e.g. allowing to synchronize streams.
>Supplementary functions such as recording of media streams are also in
>scope.
>Audio Stream Functions
>An extension of the Media Stream Functions to process audio streams, to
>enable features such as automatic gain control, mute functions and echo
>cancellation.
>Video Stream Functions
>An extension of the Media Stream Functions to process video streams, to
>enable features such as bandwidth limiting, image manipulation or "video
>mute".
>Functional Component Functions
>API functions that allow to query for the components present in an
>implementation, instantiate them, and connect them to media streams.
>P2P Connection Functions
>API functions to provide interfaces that enable the conveyance of
>parameters necessary to establish peer to peer connections, based on the
>protocols selected by the IETF RTCWeb Working Group. Included in this
>category are also API functions to allow identification of the peer.
>The working group may decide to group the specified functions in one or
>more specifications. The Working Group has already started and will
>continue work on the following specifications:
>
>WebRTC 1.0: Real-time Communication Between Browsers
>
>JavaScript APIs to allow media and data to be sent to and received from
>another browser or device implementing the appropriate set of real-time
>protocols
>Identifiers for WebRTC's Statistics API
>JavaScript APIs that allow access to statistical information about a
>peer-to-peer connection established via the WebRTC API
>as well as on the following specifications jointly developed with the
>Device APIs Working Group:
>
>Media Capture and Streams
>JavaScript APIs that allow local media, including audio and video, to be
>requested from a platform
>MediaStream Recording
>a JavaScript API to record MediaStreams
>MediaStream Image Capture
>a JavaScript API to capture still images from a video MediaStream
>Media Capture Depth Stream Extensions
>An extension to the Media Capture and Streams API to capture depth
>streams (e.g. from 3D cameras)
>Media Capture from DOM Elements
>An extension to DOM elements to allow to capture a media stream from
>their content
>Audio Output Devices API
>JavaScript APIs that let a Web application manage how audio is rendered
>on the user audio output devices
>Screen Capture API
>An extension to the Media Capture and Streams API to use a user's
>display, or parts thereof, as the source of a MediaStream.
>This work will be done in collaboration with the IETF. The W3C will
>define APIs to ensure that application developers can control the
>components or the architecture for selection and profiling of the wire
>protocols that will be produced by the IETF Real-Time Communication in
>WEB-browsers (RTCWeb) Working Group. While the specified API Functions
>will not constrain implementations into supporting a specific profile,
>they will be compatible with the Profile that will be specified by the
>RTCWeb Working Group.
>
>As the name implies, WebRTC 1.0: Real-time Communication Between Browsers
>is to be considered as a first version of APIs for real-time
>communication. The working group will, once WebRTC 1.0: Real-time
>Communication Between Browsers reaches Candidate Recommendation, consider
>proposals for backward-compatible object-oriented extensions to this API.
>
>The specified API Functions and the requirements on their implementation
>must offer functionality that ensures that users' expectations of privacy
>and control over their devices are met - this includes, but is not
>limited to, ensuring that users can control what local devices an
>application can access for capturing media, and are able to at any time
>revoke that access.
>
>Similarly, all the deliverables must address issues of security - this
>includes, but is not limited to, ensuring that arbitrary UDP packets
>cannot be sent to arbitrary destinations and ports. The security and
>privacy goals and requirements will be developed in coordination with the
>IETF RTCWeb Working Group.
>
>Similarly, all deliverables must address issues of accessibility
>including relevant requirements listed in the Media User Accessibility
>Requirements document (MAUR), such as multiple well-synchronized
>instances of the same media type. The accessibility goals and
>requirements will be developed in coordination with the Accessible
>Platform Architectures Working Group.
>
>Other Deliverables
>
>A comprehensive test suite for all features of a specification is
>necessary to ensure the specification's robustness, consistency, and
>implementability, and to promote interoperability between User Agents.
>Therefore, each specification must have a companion test suite, which
>should be completed by the end of the Last Call phase, and must be
>completed, with an implementation report, before transition from
>Candidate Recommendation to Proposed Recommendation. Additional tests may
>be added to the test suite at any stage of the Recommendation track, and
>the maintenance of a implementation report is encouraged.
>
>Other non-normative documents may be created such as:
>
>Primers
>
>Requirements and use case document for specifications.
>Non-normative group notes
>Given sufficient resources, this Working Group should review other
>working groups' deliverables that are identified as being relevant to the
>Working Group's mission.
>
>Milestones
>
>Milestones
>Note: The group will document significant changes from this initial
>schedule on the group home page.
>Specification	FPWD	CR	PR	Rec
>Media Capture and Streams	2011-10-27	Q2 2015	Q1 2016	Q2 2016
>WebRTC 1.0: Real-time Communication Between Browsers	2011-10-27	Q4
>2015	Q4 2016	Q1 2017
>MediaStream Recording	2013-02-25	Q4 2015	Q3 2016	Q1 2017
>MediaStream Image Capture	2013-07-09	Q2 2016	Q2 2017	Q3 2017
>Media Capture Depth Stream Extensions	2014-10-07	Q2 2016	Q2 2017	Q3 2017
>Identifiers for WebRTC's Statistics API	2014-10-21	Q4 2015	Q4 2016	Q1 2017
>Media Capture from DOM Elements	Q1 2015	Q4 2015	Q3 2016	Q4 2016
>Audio output API	Q1 2015	Q3 2015	Q2 2016	Q3 2016
>Screen Capture API	Q1 2015	Q4 2015	Q3 2016	Q4 2016
>WebRTC 1.1:Real-time Communication Between Browsers	Q1 2016	Q2 2017	Q4
>2017	Q1 2018
>
>Dependencies and Liaisons
>
>W3C Groups
>
>HTML Working Group
>The HTML Working Group defines a number of markup elements and APIs that
>serves as the basis on which the RTC APIs have been developed; in
>particular, several specifications of this group extends the <audio> and
><video> elements
>Web Applications Working Group
>Some of the Web Applications Working Group APIs (such as the Web Sockets
>API) have served as inspiration or starting points for the APIs developed
>by the RTC Working Group. The work on Push Notifications provides an
>important feature for many WebRTC use cases. In addition, all the APIs
>developed by this group are based on WebIDL which the Web Applications
>Working Group is specifying.
>Device APIs Working Group
>The Device APIs Working Group jointly develops the media capture-related
>APIs with this group.
>Audio Working Group
>The API developed by the Audio Working Group builds upon the MediaStream
>object built by this group; further collaboration on the management of
>audio output device is expected
>Web Application Security Working Group
>The Web Application Security Working Group is developing guidance on APIs
>that expose sensitive information, and an API to manage permissions, both
>of which matter to several of this group specifications
>Web Cryptography API
>WebRTC connections are encrypted end-to-end; collaboration is expected
>with the Web Cryptography Working Group on exposing and manipulating some
>of the cryptography functions used
>Second Screen Presentation Working Group
>The Second Screen Presentation Working Group is developing APIs to allow
>rendering of media on secondary devices; potential overlap with features
>enabled by the Audio Output Device APIs will need to be looked at
>WAI Protocols and Formats Working Group
>Reviews from the WAI PF Working Group will be required to ensure the APIs
>allow to create an accessible user experience.
>Web and TV Interest Group
>Work on gathering use cases and requirements for Home Networking
>scenarios within the Web and TV Interest Group may uncover aspects that
>affect the design of real-time communications functions. The RTC Working
>Group will coordinate with the Web and TV Interest Group on these use
>cases and requirements as appropriate.
>Privacy Interest Group
>Several of the specifications developed by this group have potential
>impact on the privacy of users; reviews from the privacy interest group
>will be sought on these specifications
>Web Security Interest Group
>Several of the specifications developed by this group have a complex
>impact on the security model of the Web; reviews from the Web Security
>Interest Group will be sought.
>
>External Groups
>
>IETF Real-Time Communication in WEB-browsers group (RTCWeb)
>The RTC APIs developed by this group will build upon the protocols and
>formats developed in the IETF RTCWeb Working Group, which will in general
>handle dependencies to other IETF Working Groups.
>
>Participation
>
>To be successful, the Web Real-Time Communications Working Group is
>expected to have 10 or more active participants for its duration.
>Effective participation to Web Real-Time Communications Working Group is
>expected to consume one work day per week for each participant; two days
>per week for editors. The Web Real-Time Communications Working Group will
>allocate also the necessary resources for building Test Suites for each
>specification.
>
>Participants are reminded of the Good Standing requirements of the W3C
>Process.
>
>Communication
>
>This group primarily conducts its work on the public mailing list
>public-webrtc@w3.org (archives).
>
>The group uses a Member-confidential mailing list for administrative
>purposes and, at the discretion of the Chairs and participants of the
>group, for Member-only discussions in special cases when a particular
>participant requests such a discussion.
>
>Information about the group (deliverables, participants, face-to-face
>meetings, teleconferences, etc.) is available from the Web Real-Time
>Communications Working Group home page.
>
>Decision Policy
>
>As explained in the Process Document (section 3.3), this group will seek
>to make decisions when there is consensus. When the Chair puts a question
>and observes dissent, after due consideration of different opinions, the
>Chair should record a decision (possibly after a formal vote) and any
>objections, and move on.
>
>Patent Policy
>
>This Working Group operates under the W3C Patent Policy (5 February 2004
>Version). To promote the widest adoption of Web standards, W3C seeks to
>issue Recommendations that can be implemented, according to this policy,
>on a Royalty-Free basis.
>
>For more information about disclosure obligations for this group, please
>see the W3C Patent Policy Implementation.
>
>About this Charter
>
>This charter for the Web Real-Time Communications Working Group has been
>created according to section 6.2 of the Process Document. In the event of
>a conflict between this document or the provisions of any charter and the
>W3C Process, the W3C Process shall take precedence.
>
>This charter updates and replaces the first WebRTC Working Group charter
>approved in 2011.

Received on Wednesday, 1 April 2015 21:29:43 UTC