Re: [rtcweb] No Plan

[Paul Kyzivat <[e-mail]>]

On 6/3/13 6:28 AM, Iñaki Baz Castillo wrote:
> 2013/5/31 Paul Kyzivat <[e-mail]>:
>>> That can be implemented on top of DataChannel anyway, I see no need
>>> for mandating it as a new RTP media stream negotiated via SDP.
>>
>>
>> IIUC, Gunnar is expecting that virtually every app that provides real time
>> voice communication should also provide RTT. (And this has a habit of
>> showing up as a legal mandate.)
>>
>> Leaving the decision about how to transport RTT to be reinvented by each
>> application doesn't seem like a good way to achieve that.
>
>
> Hi Paul. Standarizing the "app layer" in WWW does not work, nobody
> wants it. What about if somebody (a website) wants to send custom
> emoticons within the realtime text? should the WG define a "text
> document format" for RTT? Each website does it in the custom way it
> likes.
>
> Tons of webs offer chat since years, why do we need a standard for it
> now? A user in website-A will never chat with a user in website-B
> anyway.

I think this comes down to whether you think text/chat is "application" 
or "media".

Contrast it to video. My web app can send an image as part of a web 
page. It is "just a part of the application". And video is "just" a 
matter of sending a bunch if images in succession. So why isn't that 
still just "application" stuff? Why should we need RTP for it?

One answer may be that the difference is that the real-time requirements 
for text aren't as demanding as they are for voice or video. But there 
are other good reasons for identifying interactive text as media. One 
reason is what we are arguing right how: the desire to negotiate 
properties of the transmission. (Should it be byte-by-byte or 
line-by-line.) Another is that, like voice and video there is likely to 
be a demand to record it for later analysis and playback, or to 
broadcast it to a collection of people.

When text is treated as media, then treating it in parallel with other 
media makes more sense. (For instance ensuring the that the text is 
synchronized with the other media, both initially and when recorded and 
played back later.)

>> Leaving the decision about how to transport RTT to be reinvented by each
>> application doesn't seem like a good way to achieve that.
>
> The Web has succeeded because each website has the capability of
> reinventing the application by adding its own innovation and features.
> Otherwise there would not be so many different social networks or
> travel websites offereing "the same".

There is the good and the bad of this.

There are lots of web sites that off something they call "chat".
And they are all different. So I can't be sure if I will have a 
transcript of the chat at the end or not. Or any record of it after the 
fact.

It is evident to me that we can't prevent chat being done this way. But 
it doesn't make it best practice.

>> If that is good enough for RTT, then why not voice and video too? Just send
>> it over a data channel in any format you like. We don't need to standardize
>> how to do it.
>
> JS can not retrieve the audio/video bits received from the peer and
> convert them into audio/video to be sent to the local multimedia
> devices.

Maybe true for audio, but not video. If the video bits were sent over a 
data channel the JS could retrieve them and put them into a window. (It 
would be a pig, but possible.)

> That's why the WG defines a media format (I mean RTP +
> security) and an API for providing such a multimedia flow to the JS
> app.
>
> The same is not true for text chat which can be achieved in tons of
> ways in the WWW, without the need of a standard.

I agree there are some differences. But there are also a lot similarities.

	Thanks,
	Paul