Re: Proposed Charter Changes

I think we need to be _very_ clear about what we mean by ‘compatibility’ -
I think it is reasonable to expect that future post 1.0 releases of the webRTC standard(s) should
be compatible with 1.0 .
For me that means : 
1) The wire format is fully compatible -> 1.0 and 1.1 browsers and devices can exchange media
and data channels with no gateways.  
	This is largely an IETF matter, but the W3C should avoid doing anything that precludes it.
2) Web apps written to the 1.0 standard should work in 1.1 implementations. (if we went to 2.0 that expectation
might be relaxed somewhat). 

However…. I don’t expect this to apply to apps which have manipulated the SDP directly
(as described by Chris Wendt <chris-w3c@chriswendt.net>

> We’ve had to essentially hack the system with the current SDP exchange in many respects and at a minimum pass a bunch of redundant information.
)

I think it is reasonable to expect javascript programmers to add dynamic polyfill here if it detects that
the browser implements a new version of the standard and use that pollyfill to tweak bandwidths or mark
which track is from a screenshare (for example).

So I expect that 1.1 (and to a lesser extent 2.0) would implement all the javascript object/methods/properties and callbacks
specified in 1.0 - but I don’t expect the content of the supposedly 'opaque blobs’ to backwards compatible.

In some ways this is regrettable - since almost all of my webRTC apps to date have had to mess with the SDP,
but I’m still hoping that as we get to 1.0 the need for this will be reduced. 

Having spent the last month working with web devs and watching their first exposure to the ‘joys’ of SDP 
I think that for webRTC to be a popular API, we may need to remove SDP as an API mechanism so we
should not make charter decisions now that preclude that future choice.


Tim.

Received on Sunday, 5 April 2015 10:42:24 UTC