[RTW] New proposed charter text. Please review before the BoF.

Fri Mar 18 13:37:40 CET 2011

Hi John, 

What aspects would like you to be taken into consideration? It sounds a
bit like you have some requirements in mind but you do not want to write
them down. 

Ciao
Hannes

> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no 
> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of ext Elwell, John
> Sent: Friday, March 18, 2011 2:04 PM
> To: Ted Hardie; rtc-web at alvestrand.no
> Subject: Re: [RTW] New proposed charter text. Please review 
> before the BoF.
> 
> Ted,
> 
> I think there needs to be some mention of interop with 
> existing real-time applications using IETF protocols (such as 
> SIP, RTP). Something along the lines of:
> "Work should take account of browser-based applications that 
> require to interoperate with existing applications using IETF 
> protocols such as SIP and RTP and commonly deployed audio and 
> video codecs. Solutions that require mediation functions to 
> achieve interoperation might be acceptable, provided such 
> functions are not unduly complex, expensive or detrimental to 
> performance."
> 
> John 
> 
> > -----Original Message-----
> > From: rtc-web-bounces at alvestrand.no 
> > [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Ted Hardie
> > Sent: 17 March 2011 16:18
> > To: rtc-web at alvestrand.no
> > Subject: [RTW] New proposed charter text. Please review 
> > before the BoF.
> > 
> > Name: Real-Time Communication in WEB-browsers (RTCWeb)
> > 
> > There are a number of proprietary implementations that 
> provide direct
> > interactive rich communication using audio, video, collaboration,
> > games, etc. between two peers' web-browsers. These are not
> > interoperable, as they require non-standard extensions or plugins to
> > work.  There is a desire to standardize the basis for such
> > communication so that interoperable communication can be established
> > between any compatible browsers. The goal is to enable innovation on
> > top of a set of basic components.   One core component is to enable
> > real-time media like audio and video, a second is to enable datagram
> > and byte stream data transfer directly between clients.
> > 
> > This work will be done in collaboration with the W3C.  The IETF WG
> > will produce architecture and requirements for selection 
> and profiling
> > of the on the wire protocols. The architecture needs to be 
> coordinated
> > with W3C.  The IETF WG work will identity state information 
> and events
> > that need to be exposed in the APIs as input to W3C. The W3C will be
> > responsible for defining APIs to ensure that application developers
> > can control the components.
> > 
> > The security goals and requirements will be developed by the WG. The
> > security model needs to be coordinated with the W3C.  The work will
> > also consider where support for extensibility is needed. RTP
> > functionalities, media formats, security algorithms are example of
> > things that commonly needs extensions, additions or replacement, and
> > thus some support for negotiation between clients is required.
> > 
> > The WG will perform the following work:
> > 1.     Define the communication model in detail, including 
> how session
> > management is to occur within the model.
> > 2.     Define a security model that describes the security goals and
> > how the communication model can achieve these goals.
> > 3.     Define how NAT and Firewall traversal is to occur.
> > 4.     Define which RTP functions and extensions that shall be
> > supported in the client and their usage for real-time 
> media, including
> > media adaptation to ensure congestion safe usage.
> > 5.     Define what functionalities in the solution, such as media
> > codecs, security algorithms, etc., that can be extended and how the
> > extensibility mechanisms works.
> > 6.     Define a set of media formats that must or should be 
> supported
> > by a client to improve interoperability.
> > 7.     Define how non RTP datagram and byte stream data 
> communication
> > between the clients can be done securely and in a 
> congestion safe way.
> > 8.     Provide W3C input for the APIs that comes from the
> > communication model and the selected components and 
> protocols that are
> > part of the solution.
> > 
> > 
> > This work will be done primarily by using already defined 
> protocols or
> > functionalities. If there is identification of missing protocols or
> > functionalities, such work can be requested to be done in another
> > working group with a suitable charter or by requests for 
> chartering it
> > in this WG or another WG. 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, Location services, IM & Presence, 
> Resource Priority.
> > 
> > The products of the working group will support security and 
> keying as
> > required by BCP 61 and be defined for IPv4, IPv6, and dual stack
> > deployments. 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 
> 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.
> > 
> > Milestones:
> > 
> > Aug 2011 Architecture and Security and Threat Model sent to W3C
> > 
> > Aug 2011 Use cases and Scenarios document sent to W3C
> > 
> > Sept 2011 Architecture and Security and Threat Model to IESG 
> > as Informational
> > 
> > Sept 2011 Use cases and Scenarios for RTCWeb document sent 
> to IESG as
> > Informational
> > 
> > Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
> > 
> > Dec 2011 Information elements and events APIs Input to W3C
> > 
> > Apr 2012 API to Protocol 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
> > 
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
> 