Re: Moving forward with SDP control

     That doesn't matter. Think of OOP "encapsulation". The API defines 
a contract. It is well within its right to declare SDP as an 
undefined/opaque token outside the scope of the API. Anyone who relies 
upon its contents is relying on implementation details that will change 
over time and break their application. They have no one to blame but 
themselves.

     A lower-level API can then step in to manipulate the SDP, but this 
remains an implementation detail for Application Developers.

Gili

On 19/07/2013 5:28 PM, Peter Thatcher wrote:
>
> You're right that you don't have to choose the key, and you don't have 
> look at it if don't want to.  But, it's still given to you, and you 
> still have to transport it to the remote side.  No matter how buried 
> it is in an opaque blog, it's still in there.
>
> On Jul 19, 2013 2:02 PM, "cowwoc" <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>
>     Hi Peter,
>
>         It sounds like I'm missing something. As a web developer, I
>     have haven't had to choose a SDES crypto key in order to initiate
>     video chat. The underlying WebRTC implementation might have done
>     so and I passed this opaque blob (SDP) over the wire, but I never
>     had to touch it myself.
>
>         So what am I missing here?
>
>     Thanks,
>     Gili
>
>     On 19/07/2013 3:45 PM, Peter Thatcher wrote:
>>     On Fri, Jul 19, 2013 at 10:55 AM, cowwoc <cowwoc@bbs.darktech.org
>>     <mailto:cowwoc@bbs.darktech.org>> wrote:
>>
>>         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 user.
>>
>>             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.
>>
>>
>>     Then how does the SDES crypto key chosen by one side get to the
>>     other side?  You can say it's not modifyable, but it's still
>>     readable, unless the signalling is done over a channel that the
>>     JS has no access to or control over.
>>
>>         Gili
>>
>>
>>         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 
>>>
>>>
>>
>>
>