[RTW] Overall framework document

[David Singer]

I think this is an interesting layer, indeed.

On Nov 7, 2010, at 17:06 , markus.isomaki at nokia.com wrote:

> Hi,
> 
> I believe a lot of the RTW standards/interoperability work is not creating new protocols or codecs or such, but making choices on which ones everyone willing to interoperate needs to support and in which manner. Here I mean for instance things like RTP/RTCP for transport, ICE/STUN/TURN for NAT traversal, X as the video codec, Y as the audio codec and so on. I'm not a big expert on the JS APIs (and there it seems to be some really new "component-level" work is needed more) but I presume similarly we should define which APIs at minimum the browser/web environment needs to offer and which would be additional/optional.

The mandatory elements/attributes/APIs etc. should be (at least) those that are applicable to 'any protocol', i.e. any instantiation of a video terminal.

> 
> So, I would say that one of the outcomes from this work has to be such a high level framework document. (Some people would call it a profile but others don't like that word.) I don't really see otherwise how we can reach interoperability.

We need to reach interoperability at a number of levels:  the markup, the APIs, the protocols, the codecs, the encryption, and so on.  I think we need to develop a layered approach and get the framework architecture (layers) right, and then interop at every level.

> If we do that document well, it will state really clearly what everyone is expected at minimum (MUST) to support to get something useful done and interoperable, while leaving enough flexibility for the additional things. And of course all the protocols would still have to follow their feature/extension negotiation mechanisms, i.e. always explicitly negotiate X and Y, even if the framework says they are a MUST. (Because we want to interoperate with folks that may not follow the framework fully as well, as far as possible. The framework just tries to make sure that the interop can happen at the level as expected among implementations that really follow it.)

You always negotiate, indeed, because at some point the mandatory features are not the best (someone comes up with a better idea).  Indeed, often they are not the 'best' in some respect from the start -- they are chosen for ease of implementation, simplicity, simple licensing, etc.

> Based on this thinking I have two questions:
> * Do people agree that we need such a framework document? (Or do you really think that it is enough to work on the bits and pieces only, and some outer intelligence will make the different implementations to pick all the same choices, or support ALL of the possible choices?)

I think it's critical we get an architecture in place, and get the 'framework' of the discussion going.  I'm not terribly interested in repeating all the realy hard work that others have done on the nitty-gritty of why videoconferencing is hard.  I am interested in the unique problems and opportunities that web-embedding brings.  I am certain we need to do this in a properly layered, orthogonal way, so we don't have to revise every layer when there is a good idea that improves one.

> * If so, where should that be done? (IETF would seem like a natural option, although IETF has not really done much of this kind of work.)

I rather thought the W3C should take on the markup, DOM, styling, etc.  The IETF would do protocols.  I hope we can decompose into several protocols (as I said, I don't see any reason except privacy issues why discovery -- converting a person-ID to IP address -- shouldn't be separate from conversation -- actually sending packets).

> 
> Perhaps work on that kind of high level thing would also give us a better view what we are missing on the component level.
> 
> Third question:
> * Do we need some kind of a requirements document to start writing down what we think this work should enable the browser apps to do? (I don't think would be such a bad idea. That could give a bit more structure to the discussions we are having.)

I think it's a great idea.

> 
> Regards,
> 	Markus 
> 
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web

David Singer
Multimedia and Software Standards, Apple Inc.