[RTW] [dispatch] The charter formerly know as RTC-WEB take 3

[Erik Lagerway]

+1

Erik Lagerway

On Fri, Jan 28, 2011 at 1:12 PM, Henry Sinnreich
<henry.sinnreich at gmail.com>wrote:

> Hi Markus,
>
> Quoting Adam:
> >> "The selection, design and/or extension of a protocol or protocols for
> >> establishing and controlling media sessions is in scope for the
> >> working group."
>
> Given the overwhelming deployment of SIP for voice and much video as well,
> a
> SIP API is IMO the 1st choice of instantiation for an API.
>
> As for IM and chat, quite frankly, it is pure data and not real time media
> as is the focus here. IM and chat has been around on the Internet in many
> forms for a long time using various protocols.
>
> If we have to chose between two evils: No IM API for now or the double
> complexity of SIP+XMPP stack emulations in the application scripts, I would
> rather go without any until the market and especially innovation makes such
> as decision for us.
>
> Here is really an instance where kicking the can down the road makes a lot
> of sense. Who knows, maybe later social and virtual world protocols may
> change the picture altogether...
>
> Disclaimer: I still think SIMPLE/SIP makes it really simple and works well
> enough for the simple (no pun intended) usage scenarios considered here for
> RTC-Web.
>
> Thanks, Henry
>
>
> On 1/27/11 2:07 PM, "Markus.Isomaki at nokia.com" <Markus.Isomaki at nokia.com>
> wrote:
>
> > Hi Henry,
> >
> > Henry Sinnreich wrote:
> >>
> >>> I believe
> >>> Jingle is more monolithic and easier to handle in this sense.)
> >>
> >> This adds even more to the endless discussions of SIP vs. Jingle,
> >> actually
> >> it also adds a 3rd option and folks who have implemented SIP/SIMPLE may
> >> or
> >> may not be happy about it.
> >>
> >
> > If by 3rd option you mean that the RTC-Web effort would produce its own
> > specific session establishment protocol, I tend to agree with you. If we
> think
> > a standardized session establishment protocol is needed, we should take
> an
> > existing one, and at maximum just worry how it can be transported over
> HTTP or
> > WebSocket (that may be a valid requirement).
> >
> >> Bottom line:
> >> Adding a 3rd option to the signaling will bog down the RTC-Web work even
> >> more. The API should be a separate effort.
> >> Oh, the discussions there...
> >> Don't expect anyone there to give in easily :-), and why can/should
> >> they?
> >>
> >> Let's leave the API out for scope.
> >>
> >
> > To be clear: Are you saying that we should *not* have the session
> > establishment protocol included in the charter? Or which API do you mean?
> > Because in your earlier mail you supported Adam's suggestion:
> >
> >> "The selection, design and/or extension of a protocol or protocols for
> >> establishing and controlling media sessions is in scope for the
> >> working group."
> >
> > Which says that the session establishment protocol is within the scope of
> the
> > work. And if it is, the associated API will surely be defined on the W3C
> side.
> >
> >> Thanks, Henry
> >>
> >
> > Markus
> >
>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110128/d52a8deb/attachment.html>