[RTW] The charter formerly know as RTC-WEB take 3

[Cullen Jennings]

In my dispatch co-chair role, I tried to take all the comments I had seen on the list about this charter and see if I could address them in a new version of the charter. I probably messed up in some places. There were some conversation that did not seem to be converging so I did not make any changes for theses. Have a read and if you think something needs to be changed, propose text changes along with the reasons why and we will keep the evolving this charter.

Thanks
Cullen 

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

Version: 3

Possible Names:

RTCWEB
WEBRTC 
STORM: Standardized Transport Oriented for Realtime Media 
BURN: Browsers Using Realtime Media
WAVE: Web And Voice/Video Enablement
WAVVE: Web And Voice Video Enablement
REALTIME
WEBCOMM
WREALTIME
WEBTIME
WEBFLOWS
BRAVO  Browser Realtime Audio and VideO
COBWEB COmmuication Between WEBclients
WHEELTIME



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 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.

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 that 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.

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.

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 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 W3C defied API to IETF protocols to IESG as
         Informational. This depends on the W3C API work.