Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

[Harald Alvestrand <[e-mail]>]

On 10/12/11 14:13, Tim Panton wrote:
>
> On 12 Oct 2011, at 12:39, Harald Alvestrand wrote:
>
>> On 10/12/11 12:31, Tim Panton wrote:
>>>
>>> On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:
>>>
>>>> On 10/12/11 11:46, Neil Stratford wrote:
>>>>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand 
>>>>> <[e-mail] <mailto:[e-mail]>> wrote
>>>>>
>>>>>     One of the worries I have with doing a "low level spec"
>>>>>     unconstrained by our present competence (ignorance?) in  is
>>>>>     that I'm reasonably sure we have the knowledge to generate and
>>>>>     parse SDP, because the codebases we are building on already
>>>>>     generate and parse SDP, and the information present there is
>>>>>     enough to set up calls, because we're already setting up calls
>>>>>     using that information.
>>>>>
>>>>>     I'm less sure of our "getting things right" if we start off by
>>>>>     describing the capabilities and control knobs to be exposed in
>>>>>     an unconstrained API.
>>>>>
>>>>>
>>>>> As a counter argument, those very same codebases that generate and 
>>>>> parse SDP also contain internal APIs that look a lot like a low 
>>>>> level spec API, and the information they present is enough to 
>>>>> generate and parse SDP and set up calls.
>>>>>
>>>>> Maybe we don't like those APIs and perhaps they expose too much as 
>>>>> they were never intended to be made public, but they do exist already.
>>>> Yup. And I suspect they're all subtly different.
>>>>
>>>
>>> You could look at that in a positive light -
>>> as evidence that there are multiple ways to solve this problem and 
>>> deduce:
>>> a) it isn't impossibly hard
>>> b) there isn't one 'correct' way of doing it.
>>>
>>> Which would lead me back to specifying as _little_ as possible and 
>>> letting innovation take place.
>>>
>> We have to specify enough for interoperation in at least the use 
>> cases of the scenarios document.
>> In enough detail for interoperation to happen.
>>
>> That could turn out to be a lot, especially if we can't point to 
>> existing specs and say "use that".
>
> So, to paraphrase (and make sure I understand) - your argument is that 
> if we don't use SDP,
> we will have to specify all the fields and associated meanings for 
> every codec we expect to support.
>
> If we do use SDP, then we just point at existing usage and say - 
> 'there, use that' .
>
> If we use a subset or variant on SDP we can say - 'use that, except 
> for this bit to do with port allocation'.
>
> Is that a fair (if informal) summary?
Yes, exactly.

We've been around this bush a few times under the guise of "why don't we 
redefine SDP in JSON" or "why don't we redefine SDP in XML"; this time, 
it somewhat resembles "why don't we reencode SDP as API calls". I 
believe a lot of the same arguments apply.