[RTW] WG charter, take 4

[Harald Alvestrand]

This is the current charter text - it's updated somewhat based on 
discussions on the list.

In particular, there's now suggested language about the relationship to 
session management protocols.
We'll make this an explicit discussion at the BOF, with the aim of 
getting one of three conclusions in the charter:

- The WG will not address session management protocols
- The WG will choose one or more session management protocols
- The WG will discuss session management protocols, and do what makes sense.

The last one is the one suggested by the current charter text; the other 
possible outcomes should be easier to write text for.

Comments welcome!

Harald

(Note: The below is not going out in < 80 columns, I think. Please 
forgive the formatting issue.)

------------------------------------------------

Version: 4

Name: RTCWEB
WG Chair(s): Cullen Jennings <fluffy at cisco.com>

Body:

Many implementations have been made that use a Web browser to support 
direct, interactive communications, including voice, video, 
collaboration, and gaming. In these implementations, the web server acts 
as the signaling path between these applications, using locally 
significant identifiers to set up the association. Up till now, such 
applications have typically required the installation of plugins or 
non-standard browser extensions. There is a desire to standardize this
functionality, so that this type of application can be run in any 
compatible browser and allow for high-quality real-time communications 
experiences within the browser.

Traditionally, the W3C has defined API and markup languages such as HTML 
that work in conjunction with with the IETF over the wire protocols such 
as HTTP to allow web browsers to display media that does not have real 
time interactive constraints with another human.

The W3C and IETF plan to collaborate together in their traditional way 
to meet the evolving needs of browsers. Specifically the IETF will 
provide a set of on the wire protocols, including RTP, to meet the needs 
on interactive communications, and the W3C will define the API and
markup to allow web application developers to control the on the wire 
protocols. This will allow application developers to write applications 
that run in a browser and facilitate interactive communications between 
users for voice and video communications, collaboration, and gaming.

This working group will select and define a minimal set of protocols 
that will enable browsers to:
have interactive real time voice and video pairwise between browsers or 
other devices using RTP
have interactive real time application data for collaboration and gaming 
pairwise between browsers


Fortunately very little development of new protocol at IETF is required 
for this, only selection of existing protocols and selection of minimum 
capabilities to ensure interoperability. The following protocols are 
candidates for including in the profile set:

1) RTP/ RTCP

2) a baseline audio codec for high quality interactive audio. Opus will 
be one of the codecs considered

3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will 
be some of the codecs considered

4) a baseline video codec. H.264 and VP8 will be some of the codecs 
considered

5) Diffserv based QoS

6) NAT traversal using ICE

7) media based DTMF

8) support for identifying streams’ purpose using semantics labels 
mappable to the labels described in RFC 4574

9) Secure RTP and keying

10) support for IPv4, IPv6 and dual stack browsers

Please note the above list is only a set of candidates that the WG may 
consider and is not list of things that will be in the profile the set.

This group's primary aim is to enable web applications to manage 
real-time communication sessions with other web-context applications 
that implement this specification. When making choices, the working 
group will also consider the impact of those choices on interoperability 
with other devices that create or manage multimedia sessions, including 
the complexity imposed
on any gateways which may be required.

The Working group will identify information needed for session 
negotiation and management in web contexts, and its output documents 
will describe the relationship of this to information carried in session 
protocols used in other standardized contexts.

The Working Group will consider the possibility of defining a browser 
component that implements an existing session negotiation and management 
protocol.

The working group will cooperate closely with the W3C activity that 
specifies a semantic level API that allows the control and manipulation 
of all the functionality above. In addition, the API needs to 
communicate state information and events about what is happening in the 
browser to applications running in the browser. These events and state 
need to include information such as: receiving DTMF in the RTP, RTP and 
RTCP statistics, and the state of DTLS/SRTP handshakes. The output of 
this WG will form input to the W3C group that specifies the API, and if 
there are parts of the mapping between the API and the protocols that 
need to be done outside of the W3C, this group will do it.

The working group will follow BCP 79, and adhere to the spirit of BCP 
79. The working group cannot explicitly rule out the possibility of 
adopting encumbered technologies; however, the working group will try to 
avoid encumbered technologies that require royalties or other
encumbrances that would prevent such technologies from being easy to use 
in web browsers.

The following topics will be out of scope for the initial phase of the 
WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, 
Geolocation, IM & Presence, NSIS, Resource Priority. RTP Payload formats 
will not be done in this WG.

Deliverables:
An overview document describing the architecture
A scenarios document describing scenarios that are expected to be supported
A profile document specifying the protocols and options that must be 
supported by a conforming implementation
(If needed) A mapping document describing the relationship between the 
protocols and the W3C-defined API.


Milestones:

May 2011 Main alternatives identified in drafts

Aug 2011 WG draft with text reflecting agreement of what the profile set 
should be

Sept 2011 Scenarios specification to IESG as Informational

Nov 2011 Draft available of documentation specifying mapping of protocol 
functionality to W3C-specified API produced. This is an input to W3C API 
work.

Dec 2011 Profile specification to IESG as PS

Apr 2012 Mapping document submitted to the IESG as Informational (if needed)