Re: [rtcweb] No Plan

Iñaki Baz Castillo <ibc@aliax.net> Mon, 03 June 2013 10:28 UTC

Return-Path: <ibc@aliax.net>
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 AD8E621F93F8 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 03:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 RM8Scppkpm8Q for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 03:28:30 -0700 (PDT)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id D01C721F934B for <rtcweb@ietf.org>; Mon, 3 Jun 2013 03:28:29 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id 6so2236324qeb.31 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 03:28:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ZnlmmH+vJYe9dP0nyH6q8FoyMb2RarcqYxmav0sFR0o=; b=LijcPb9Owz4YVlnYwhhA9glsQ89uwJsz/LphYg7Q9DrLbmpjyrbrHNEkIWjV3jNU9s OlPx3E2Zh9wYQt0sRl8v6AdC7o5peqBwfeQqDIOM8zPTMrk3m6s6ZxWWB2OEyS25so0i kRK6JeGj5TeXOipKbqeHTbA96TCKMpCOeT9TB7eqb+qAnFSqNn8rusRLiM4nzx/ULn7s gvd/5yQs/Y4nZPfMh4V1FqLK52Nv4FHPVuHfVR8kD5UbHLF1DsZwnHZlY70hmdOB+02R DODXZfeVYoCLZTWLFIN7fopDViD4QN57etoL3on1Rj/RybB4MoSJRhBqFTQnLd4LNqnX iNRQ==
X-Received: by 10.229.149.198 with SMTP id u6mr5789873qcv.20.1370255309133; Mon, 03 Jun 2013 03:28:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.26.103 with HTTP; Mon, 3 Jun 2013 03:28:09 -0700 (PDT)
In-Reply-To: <51A8F3EF.9080702@alum.mit.edu>
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>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Mon, 3 Jun 2013 12:28:09 +0200
Message-ID: <CALiegfkfz=qVM_wB21BBOypMTwTjkyG97zAmzHVpA6WHK2DA6w@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnTQnbYu8CD5V1HUYBQMoepmvqFUU3AgO/P7AUFOQuo7BhrdfW+aCGr4Ffx9EY+EfHBLcre
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 10:28:36 -0000

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.



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




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



Regards.




--
Iñaki Baz Castillo
<ibc@aliax.net>