[RTW] New proposed charter text. Please review before the BoF.
Tschofenig, Hannes (NSN - FI/Espoo)
hannes.tschofenig at nsn.com
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
>
More information about the RTC-Web
mailing list