W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Proposal: Different specifications for different target audiences

From: Kiran Kumar <g.kiranreddy4u@gmail.com>
Date: Mon, 22 Jul 2013 12:49:21 +0530
Message-ID: <CAGW1TF4fCyBYZUbMv2LVRxDxSH53A5FpckqBbFO5uF3YRxHEbw@mail.gmail.com>
To: "piranna@gmail.com" <piranna@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, public-webrtc <public-webrtc@w3.org>, tim panton <thp@westhawk.co.uk>, cowwoc <cowwoc@bbs.darktech.org>, Roman Shpount <roman@telurix.com>
IMHO Signalling (SIP, XMPP etc) should not be a part of browser. Browser
implementation should be independent of the signalling as it is now.
I agree that Low level API should abstract implementation details (of
media, sockets, transport etc).
I would like to have one more layer on top of this, to abstract even this,
Low level API (few members are calling it as Middle level API).
Both of these should be in control of Browser.


On Mon, Jul 22, 2013 at 8:47 AM, piranna@gmail.com <piranna@gmail.com>wrote:

> Maybe not directly plain SIP but an API that abstract it so maybe in the
> future it's being used XMPP instead (I've been working in this
> server-agnostic issue), but definitely "SIP in the browser" (or equivalent)
> as WebRTC spec defined signaling channel is not a bad idea... +1
> El 22/07/2013 05:03, "Eric Rescorla" <ekr@rtfm.com> escribió:
> On Sun, Jul 21, 2013 at 7:41 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>>  On 21/07/2013 9:31 PM, Eric Rescorla wrote:
>>>      What does "SIP in the browser" mean? I assume you don't mean
>>> literally.
>>>  No, I mean it literally. Minimally, the JS would have no meaningful
>>> visibility into the signaling messages (i.e., the JS would just request
>>> that the messages be transmitted) and maximally you would
>>> actually send messages via SIP.
>>>     In my original proposal, the implementation of the low-level API is
>>> all about parsing the signaling layer. The high-level API never sees the
>>> signaling layer and it definitely is not "SIP in the browser". I disagree
>>> with exposing SIP anywhere, even in the lower-level API. If you want to use
>>> SIP in the signaling implementation that's fine, but the object API should
>>> not expose these implementation details to the outside world.
>> Yes, and as I said, the WG rejected this approach, just as it rejected the
>> low-level API approach. My point was merely that "high-level",
>> "mid-level",
>> and "low-level" are terms that already have meaning in this WG. It would
>> be useful if you used them in a fashion consistently with that meaning.
>> If you have a proposal that doesn't fit into that taxonomy, then I suggest
>> you use a new name, rather than confusing reusing an old one.
>>         Were Web Developers well-represented when this was first
>>>> discussed? Do you have a breakdown of who voted in favor or against?
>>>  It's in the W3C email archives, meeting minutes, etc.
>>>     I consider that a non-answer. I have pointed you to a specific
>>> document that shows that the majority of Web Developers are against the
>>> current API proposal, complete with a list of names and why they are
>>> against the proposal. It's not reasonable to ask me to wade through months'
>>> worth of email archives.
>> I didn't ask you to do anything. You asked me a question, I told you how
>> to find
>> the answer. If you don't feel like doing it, it's hard to see why I
>> should do it
>> for you.
>> -Ekr
Received on Monday, 22 July 2013 07:20:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC