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

[Elwell, John]

OK, so what I think Christer and Andy are saying is that it is not just about having the right the mandatory-to-implement protocols, codecs, etc., but also about sufficient control at the API so that appropriate ones can be selected when interoperating with existing equipment. I would agree with that. Do Christer and Andy consider my text proposal for the charter to be sufficient, or does it need changing or extending?

John

> -----Original Message-----
> From: Hutton, Andrew
> Sent: 21 March 2011 14:16
> To: Elwell, John; Christer Holmberg; Ted Hardie
> Cc: rtc-web at alvestrand.no
> Subject: RE: [RTW] New proposed charter text. Please review
> before the BoF.
>
> Hi,
>
> I think Christer's comment is really important.
>
> If the web application is going to be responsible for
> ensuring interoperability with SIP or anything else then the
> API between the browser and the web application needs to be
> flexible and powerful to enable this interoperability to take
> place. So I believe the charter needs to make it clear that
> the input for this API that the IETF provides to W3C will
> take in to account the fact that the web application has to
> achieve interoperability with non RTC-Web based systems of
> which SIP/SDP based systems are the obvious example.
>
> Regards
> Andy
>
>
>
> > -----Original Message-----
> > From: rtc-web-bounces at alvestrand.no
> > [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Elwell, John
> > Sent: 21 March 2011 07:41
> > To: Christer Holmberg; Ted Hardie
> > Cc: rtc-web at alvestrand.no
> > Subject: Re: [RTW] New proposed charter text. Please review
> > before the BoF.
> >
> >
> >
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> > > Sent: 19 March 2011 11:22
> > > To: Ted Hardie; Elwell, John
> > > Cc: rtc-web at alvestrand.no
> > > Subject: RE: [RTW] New proposed charter text. Please review
> > > before the BoF.
> > >
> > > Hi,
> > >
> > > Regarding interoperability (or, creating new solutions in
> > > general), there are a couple of things we need to consider.
> > >
> > > One is of course the protocols supported by the browser (e.g
> > > RTP, ICE etc).
> > >
> > > The second, which I THINK John is referring to, is to ensure
> > > that web applications (whether they are SIP based or based on
> > > something else) are able to ENABLE the browser protocols and
> > > features in a good and effective way. For that we need to
> > > ensure that the API between the browser and the web app is
> > > powerful enough.
> > [JRE] That might be one of the consequences - if the browser
> > is able to use a protocol that is not interoperable with
> > existing equipment and a protocol that is interoperable, then
> > clearly an application wanting to interoperate would want to
> > be able to choose the latter.
> >
> > That was not the main point of my proposed addition to the
> > charter - the main point was that the set of
> > mandatory-to-implement protocols in the browser should
> > include those that can interoperate in a reasonable way with
> > existing equipment. Based on discussions to date, the most
> > problematic is likely to be codecs, particularly video
> > codecs, because of the cost and performance degradation when
> > transcoding has to be done.
> >
> > John
> >
> >
> > >
> > > In the ucreqs document, we have tried to differentiate
> > > between those two things by having separate browser
> > > requirements and API requirements.
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > >
> > >
> > > ________________________________________
> > > From: rtc-web-bounces at alvestrand.no
> > > [rtc-web-bounces at alvestrand.no] On Behalf Of Ted Hardie
> > > [ted.ietf at gmail.com]
> > > Sent: Friday, March 18, 2011 7:38 PM
> > > 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 10:17 AM, Elwell, John
> > > <john.elwell at siemens-enterprise.com> wrote:
> > > > 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.
> > >
> > > Hi John,
> > >
> > > Unsurprisingly, I am also a fan of interoperability.  But I think
> > > there are multiple ways to scope interoperability.  The charter
> > > currently does it by focusing on the interoperability we
> get at the
> > > protocol level, largely by choosing tools for this toolkit
> > that match
> > > the tools already in place (e.g. RTP, ICE, etc.).  I agree that we
> > > shouldn't select tools that are in place but unusable.  I
> > think we end
> > > up having to trust the working group on this anyway, as it
> > will decide
> > > which tools are unusuable even if we insert a "don't pick unusable
> > > tools" section.
> > >
> > > So the basic question boils down to:  do we also want to
> > assert a need
> > > for interoperability with a specific application or set of
> > > applications in the charter?
> > >
> > > My personal take is no.  Those are use cases, and important
> > ones.  But
> > > the charter is focused on building a toolkit "to enable
> > innovation on
> > > top of a set of basic components."  I have no doubt that
> > someone will
> > > be able to build a fully backwards compatible service using these
> > > components and a gateway,.  But the more important charter
> > goal is to
> > > get the component set right to enable them to build more
> than that.
> > > And I think calling out that specific use case is more
> > likely to limit
> > > our vision than to result in more clarity in picking protocols and
> > > tools.
> > >
> > > Again, just my personal opinion,
> > >
> > > regards,
> > >
> > > Ted Hardie
> > >
> > > >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
> > > >> >>
> > > >>
> > > _______________________________________________
> > > 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
> >
>