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

Re: Moving forward with SDP control

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 19 Jul 2013 13:55:03 -0400
Message-ID: <51E97D77.1080300@bbs.darktech.org>
To: Peter Thatcher <pthatcher@google.com>
CC: "piranna@gmail.com" <piranna@gmail.com>, Kiran Kumar <g.kiranreddy4u@gmail.com>, Likepeng <likepeng@huawei.com>, Cullen Jennings <fluffy@iii.ca>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
Hi Peter,

     That's not necessarily true.

  * The only reason the user is exposed to this information in the first
    place is because the specification declared the bootstrap process
    out the scope.
  * Assuming we accept this design decision, we still don't have to give
    users access to the internals. The specification can declare this
    blob as an off-limits opaque token that MUST NOT be modified by the

     The only reason the user is currently exposed to implementation 
details is that the Signaling layer and Application API have been packed 
into a single structure: SDP. If we separate these two, there would be 
no need to expose internals to the end-user.


On 19/07/2013 1:31 PM, Peter Thatcher wrote:
> Everything that needs to be signalled needs to be available to the JS 
> because it's up the JS to signal it.  For example, if SDES is used, 
> crypto keys must be available to the JS because its up to the JS to 
> send it to the remote side.  There's no way for you to signal it 
> without having access to it.
> On Fri, Jul 19, 2013 at 9:49 AM, piranna@gmail.com 
> <mailto:piranna@gmail.com> <piranna@gmail.com 
> <mailto:piranna@gmail.com>> wrote:
>     >     That is not strictly true. Any immutable low-level property
>     should be hidden from the application developer. Meaning, as an
>     application developer I don't care that the signaling layer is
>     using encryption key "9823cuj980ru890e" and yet (I think) this
>     shows up in the SDP. If I don't ever need to know about it, I
>     shouldn't have access to it.
>     >
>     +1 
Received on Friday, 19 July 2013 17:55:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC