Re: New version of Peer Connection draft

On 04/13/2013 07:22 AM, Stefan Hakansson LK wrote:
> On 4/12/13 10:16 PM, Matthew Kaufman (SKYPE) wrote:
>>> -----Original Message-----
>>> From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>>> Sent: Friday, April 12, 2013 12:20 AM
>>> To: public-webrtc@w3.org
>>> Subject: Re: New version of Peer Connection draft
>>>
>>> On 4/12/13 12:49 AM, Matthew Kaufman (SKYPE) wrote:
>>>> So I opened a whole bunch of bugs in the bug tracker back in January,
>>>> and I was hoping that the next draft update would address some of
>>>> them. Unfortunately, it doesn't appear that such has happened.
>>> Matthew, under the current division of responsibilities between the W3C
>>> and the IETF, the responsibility for specifying the majority of the 
>>> things you
>>> filed bugs for on Jan 29th lies with the IETF. (Stream multiplexing 
>>> over a single
>>> transport flow, RTP usage, SDP, data channel protocol, ...)
>> Ultimately it is the responsibility of the W3C to provide (or not 
>> provide) a specification that can be used to produce a browser that 
>> implements the specification and JavaScript code that uses it. Right 
>> now, no such specification exists.
>>> So I don't think we should specc that up in this document, but I 
>>> agree to that
>>> in many cases the references are missing.
>>
>> Not only are references missing but, as I point out in several of the 
>> bugs, the references provided are wholly inadequate if one wanted to, 
>> for instance, write a web browser that implemented the specification.
> I agree (I think) to both points: it must be possible to implement 
> something that interops with other implementations (and behaves the 
> same from an app perspective) from the eventual Rec developed, and 
> we're not there yet. We have a lot of work ahead of us.

Actually the W3C has plenty of tradition in creating specs that don't 
give all the information needed to implement them; in some cases, there 
are even arguments that multiple implementations, with no public spec 
that describes them, are a reasonable things to have. This is not the 
case for this use case; we need interoperability. But interoperability 
is not, per se, an API function.

The onus of specifying interoperability is on the IETF. The onus of 
making sure the API is adequate to exercise that interoperability is on 
the W3C.

Received on Wednesday, 17 April 2013 06:02:52 UTC