On Sat, Feb 26, 2011 at 8:02 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
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.
With a codec negotiation protocol, you don't need a profile to clients interoperable: either the clients support a common codec or they don't. In latter case no communication is possible. I agree that the goal of a common baseline codec across all applications is an ideal to aspire to. However, experience from HTML5 shows that unless all vendors are on the same page, you can end up in endless discussions about this topic without any real effect. The choice of codec seems to be more of a business issue than a technical interoperability issue.
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.
I doubt both of these statements about HTTP are true any longer. During the time of creation or RTP/RTSP, I would have agreed. However, with HTTP streaming through byte ranges and with Web sockets that keep connections open, I wonder if these claims about HTTP are so true any more. I can understand that you want to allow the use of RTP/RTSP as well, seeing as that's been the traditional way of doing live streaming. However, I would want us to keep an open mind about the actual protocols and technologies being used. The Web runs after all over HTTP and if HTTP turns out to be usable for this use case - even if there may be some disadvantages to it - I would not want to exclude it. My main interest in this activity is to see RTC work with HTML5. Cheers, Silvia.