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

[Elwell, John]

Hannes,

I didn't write them down because I thought it would be too much for the charter. But most of the following points have been raised in the past:
- Codecs - if mandatory-to-implement codecs are not what are commonly implemented on existing SIP endpoints, until such time as those endpoints are upgraded you need transcoding, which can be expensive and detrimental to performance. 
- RTP multiplexing - there has been some mention of a shim layer between UDP and RTP to allow multiplexing of different streams on the same port. This would require a mediation function - not as harmful as transcoding, but the impacts should at least be considered.
- RTP options - mandating RTP options or payload format options that are not commonly implemented at present (such as RTP/RTCP mux).
- STUN/ICE - not commonly implemented at present.
- Crypto algorithms - if mandatory-to-implement algorithms do not match current practice.
- Call control protocol and options, if that were to be considered in scope. The charter text leaves it open: "Define the communication model in detail, including how session management is to occur within the model.".

I am not saying we can't do any of these things, but we should consider the interworking implications and decide whether they are acceptable.

John


> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:hannes.tschofenig at nsn.com] 
> Sent: 18 March 2011 12:38
> To: Elwell, John; Ted Hardie; rtc-web at alvestrand.no
> Subject: RE: [RTW] New proposed charter text. Please review 
> before the BoF.
> 
> 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
> > 
>