[RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"

[Elwell, John]

Harald,

With one exception, this draft charter does not mention signalling (SIP/SDP), and I assume it is intended to be out of scope, although that is not explicitly stated.

The one exception is "8) RFC 4574 based Label support for identifying streams purpose".
This is an SDP attribute. How would this be used if SDP is indeed out of scope? If SDP is in scope, we certainly need more text describing its relevance.

John


> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no 
> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Harald Alvestrand
> Sent: 06 January 2011 11:54
> To: 'dispatch at ietf.org'
> Cc: rtc-web at alvestrand.no
> Subject: [RTW] Charter proposal: The activity hitherto known 
> as "RTC-WEB at IETF"
> 
> This is the first of 3 messages going to the DISPATCH list 
> (in the hope 
> of keeping discussions somewhat organized).
> 
> This is the draft of a charter for an IETF working group to 
> consider the 
> subject area of "Real time communication in the Web browser 
> platform". 
> This is one of a paired set of activities, the other one being a W3C 
> activity (either within an existing WG or in a new WG) that 
> defines APIs 
> to this functionality.
> 
> The two other messages will contain the W3C proposed charter and a 
> kickoff for what's usually the most distracting topic in any such 
> discussion: The name of the group.
> Without further ado:
> 
> -------------------------------------
> 
> Version: 2
> 
> Possible Names:
> <This space deliberately left blank for later discussion>
> 
> Body:
> 
> Many implementations have been made that use a Web browser to support 
> interactive communications directly between users including voice, 
> video, collaboration and gaming, but until now, such 
> applications have 
> required the installation of nonstandard plugins and browser 
> extensions. 
> There is a desire to standardize such functionality, so that 
> this type 
> of application can be run in any compatible 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 between users using RTP
> * interoperate with compatible voice and video systems that 
> are not web 
> based
> * support direct flows of non RTP application data between 
> browsers for 
> collaboration and gaming applications
> 
> 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 considered as one of the candidates
> 
> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
> will be considered
> 
> 4) a baseline video codec. H.264 and VP8 will be considered
> 
> 5) Diffserv based QoS
> 
> 6) NAT traversal using ICE
> 
> 7) RFC 4833 based DTMF transport
> 
> 8) RFC 4574 based Label support for identifying streams purpose
> 
> 9) Secure RTP and keying
> 
> 10) support for IPv4, IPv6 and dual stack browsers
> 
> 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 RFC 4833 
> DTMF, RTP 
> and RTCP statistics, state of DTLS/SRTP,  and signalling state.
> 
> 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,
> 
> Milestones:
> 
> February 2011 Candidate "sample" documents circulated to DISPATCH
> 
> March 2011 BOF at IETF Prague
> 
> April 2011 WG charter approved by IESG. Chosen document sets 
> adopted as 
> WG documents
> 
> May 2011 Functionality to include and main alternative 
> protocols identified
> 
> July 2011 IETF meeting
> 
> Aug 2011 Draft with text reflecting agreement of what the 
> protocol set 
> should be
> 
> Nov 2010 Documentation specifying mapping of protocol 
> functionality to 
> W3C-specified API produced
> 
> Dec 2011 Protocol set specification to IESG
> 
> April 2012 API mapping document to IESG
> 
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>