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. 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. 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.) 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?) * 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.) 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.) Regards, Markus