[RTW] WG charter, take 4

[Elwell, John]

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

I would be inclined to say instead:
"These events and state 
need to include information such as: receiving DTMF in the RTP, RTP and 
RTCP statistics, and the security status of RTP sessions." 

This would bring it more into line with item 9 earlier, which refrains from mentioning a specific key management protocol.

Also a nit: "NSIS" appears twice in the same list.

John

> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no 
> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Harald Alvestrand
> Sent: 24 February 2011 13:45
> To: RTC-Web at alvestrand.no
> Subject: [RTW] WG charter, take 4
> 
> 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)
> 
> 
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>