[RTW] Baseline in or out of scope (Re: WG charter, take 4)

[Harald Alvestrand]

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 at 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.