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: Iñaki Baz Castillo <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>: >>> 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
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Richard Barnes
- Re: [rtcweb] No Plan Cullen Jennings
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Martin Thomson
- [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Mary Barnes
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan - PT based MUX Cullen Jennings
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- Re: [rtcweb] No Plan Mark Rejhon
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- [rtcweb] RTT (was Re: No Plan) Matthew Kaufman
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Matthew Kaufman
- Re: [rtcweb] RTT (was Re: No Plan) Paul Kyzivat
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was Re: No Plan) Gunnar Hellstrom
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Barry Dingle
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- [rtcweb] Translating Plan A into No Plan (Was: No… Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Eric Rescorla
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] Translating Plan A into No Plan (Was… Martin Thomson
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] RTT (was :No Plan ) Paul Kyzivat
- Re: [rtcweb] No Plan - but what's the proposal Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Jonathan Lennox
- Re: [rtcweb] No Plan Jim Barnett
- Re: [rtcweb] Translating Plan A into No Plan (Was… Roni Even
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- [rtcweb] Repair Flows and No Plan (Was: No Plan) Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was :No Plan ) BeckW
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] Repair Flows and No Plan (Was: No Pl… Sergio Garcia Murillo
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Silvia Pfeiffer
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- [rtcweb] Plan xyz discussions; MMUSIC <> RTCweb R… Flemming Andreasen
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Peter Thatcher