Changing subjects to reflect main point, as usual.... On 02/26/11 04:16, Silvia Pfeiffer wrote:
I agree with basically all of these things. More concrete comments below.
On Sat, Feb 26, 2011 at 2:01 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,
Sorry for not having produced these charter comments earlier as most would apply to earlier versions also. However, I do have a number of comments on it and think the charter could be restructured to become a much better charter. But lets start with the different comments.
The most fundamental issue with the charter is that it contains to much technical solution candidates, rather than talking about the goals and and general direction for achieving them. I think one needs to extract the few higher level goals from this list and work them into the charter in other ways. Certain things we likely can select, like RTP. But there is clearly a question on what profile and extensions that should be supported.
I also think one of the biggest uncertainties and fuzziness in the charter is because the model isn't agreed on. The discussion about the session management is clear due to that the model for the work aren't agreed on. I see two ways here. Either we manage to lock down the model prior to the chartering, or we have a charter that included this model discussion. Frankly I see the later as most likely as agreement on the model will require agreement with IETF's partner in this work. Thus the charter should take a bit more height for having such model discussion.
It is already obvious that any codec selection for this is going to be a difficult and possibly take time. To avoid this from de-railing the truly fundamental parts of the RTC-WEB solution, I am suggesting that this should be taken in its own WG, or if not possible at least as a separate WG item, with its own deadlines, so that it doesn't hold up the main work. That is likely anyway a good idea for long term purpose, so that only the codec selection part can be updated, and not the fundamental part when the set of codecs become out-dated. I had already lost interest in this group because I thought it would just end up in endless baseline codec discussions. I agree with removing the baseline codec from the charter, if only to enable the group to move forward at all.
I am not sure I agree though with creating a separate WG for it.
Instead I think it would make much more sense to accept that we will always have a heterogeneous codec world and create a simple codec negotiation protocol. I think we have consensus that we will have codec negotiation in any realistic scenario (whether the actual negotiation protocol is in scope or out of scope is a current matter of debate).
I think we need a baseline codec set, for all the normal reasons. I think that among us, we have experience enough in managing working group discussions that it's possible to discuss things one subject at a time. Developing yet another protocol suite that requires external profiling in order to achieve interoperability is something I find deeply distasteful.
I still don't understand the diffserv based QoS. This seems very unrealistic to be usable from a web-browser perspective. This as no device in any setting other than being an ISP controlled device is likely to be allowed to set DSCP. I think QoS can be excluded at this stage completely. Especially as there are a lack of methods for providing end-point devices with a traffic class to DSCP mapping valid in the currently attached network.
The charter could also be clearer on the need for basic datagram and byte stream functionality between two peers. The higher motivation for it is there, but not requirements. Where I see rate control and security of those channels being the most important ones.
I am also missing a clear requirement for enabling future extensions of functionality of the RTC-WEB components in the browser. That was another key issue I also have with the charter - I was under the impression the group is there to solve the RTC communication on the Web (!), i.e. in Web browsers using HTML5 and HTTP. The charter is, however, so much wider and I am starting to wonder if we are trying to create an unwieldy solution to an unclear problem.
I am sorry that you have misunderstood. The effort was started in order to enable real-time browser-to-browser communication, which HTTP is fundamentally unsuitable for; HTTP-server-mediated communication is (to a large degree) possible to achieve without standardization.