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

[Magnus Westerlund]

Hi,

I have realized that I haven't comment openly on the charter text. I am
satisfied with this charter proposal. I do wished it was clearer what we
should do with relay based fallback for NAT/FW traversal.

Cheers

Magnus

Ted Hardie skrev 2011-03-17 17:18:
> 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
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------