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

[Elwell, John]

Ted,

In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention. Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal.

Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example.

John


> -----Original Message-----
> From: Ted Hardie [mailto:ted.ietf at gmail.com] 
> Sent: 18 March 2011 17:01
> To: Elwell, John
> Cc: rtc-web at alvestrand.no
> Subject: Re: [RTW] New proposed charter text. Please review 
> before the BoF.
> 
> On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John
> <john.elwell at siemens-enterprise.com> wrote:
> > 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."
> >
> 
> So, my personal read is that these work items:
> 
> "4.     Define which RTP functions and extensions 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., 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."
> 
> and this general statement which follows the work items:
> 
> "This work will be done primarily by using already defined protocols
> or functionalities. "
> 
> Those seem to cover the same ground as your "take account of".  If
> your aim is to get to something more concrete, like "you must be able
> to build a browser-based SIP softphone using the tools identified by
> this group", I think you need to unpack that a bit more.  Some of the
> presence aspects of that toolkit, for example, may not be identified
> here.
> 
> To put this another way, my personal read is that we're aiming to
> create the toolkit needed to build real-time media applications in web
> contexts.  Any specific application, including a SIP softphone, would
> be a use of the toolkit; those will be covered by something like
> draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the
> charter.
> 
> Again, just my personal take on this.
> 
> regards,
> 
> Ted Hardie
> 
> 
> > 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
> >>
>