Re: [rtcweb] No Plan

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 03 June 2013 21:09 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A2611E80EC for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.237
X-Spam-Level:
X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvMDvD8f7C+d for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:09:15 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 5E91121E809D for <rtcweb@ietf.org>; Mon, 3 Jun 2013 14:02:47 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id ju6d1l0071vXlb853x2j5f; Mon, 03 Jun 2013 21:02:43 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id jx2j1l00J3ZTu2S3dx2jpj; Mon, 03 Jun 2013 21:02:43 +0000
Message-ID: <51AD0472.9020506@alum.mit.edu>
Date: Mon, 03 Jun 2013 17:02:42 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <CALiegfk6XchF4U1Orpd6oJsydz-VGtBQ=CwaWrPa_KjsaQynYQ@mail.gmail.com> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <CALiegfm4R=3mGqTOxBfvCfnsRg=fe=XapA6s-QQNjrsAkg5HEA@mail.gmail.com> <51A8F3EF.9080702@alum.mit.edu> <CALiegfkfz=qVM_wB21BBOypMTwTjkyG97zAmzHVpA6WHK2DA6w@mail.gmail.com>
In-Reply-To: <CALiegfkfz=qVM_wB21BBOypMTwTjkyG97zAmzHVpA6WHK2DA6w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370293363; bh=EkXP7pB8Hbs0xFQktjAQ/VtVuXHKR0bl0KMNtIYXrlI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oYRf9kjSZBwsd4q0jBCHSqSw5Lw5SE3zyEne3bPRXv18/9yJPFQB+25G5wsZSDlCo DlilG8pLkAiehOdu2UoxSEhKmeczBC7i4nFk3odeQMO4WyBZXEjrRyV0LWalqHkN68 kfP/HCTE+QLpaG59DTeKJlHQBSorJYgM21vguhqNBcCJhWtLUI3lE8cgPooHQEbdBc QuhP5zYy9eCo8BEu4ECLlmiqxFMj8bYLLGetdGzbmAmhlFwKtMte1bN3E1MygB7ho0 rny3FlKMLJGGHFC5SwkFVtNHJztOr4rfs2BySfEwKFrqA0tOAHTUuGCJJFEzRQBXLB O4u5lhtXLCsIQ==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] No Plan
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 21:09:30 -0000

On 6/3/13 6:28 AM, Iñaki Baz Castillo wrote:
> 2013/5/31 Paul Kyzivat <pkyzivat@alum.mit.edu>du>:
>>> 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