Re: [rtcweb] RTT (was :No Plan )

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Mon, 03 June 2013 11:26 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 9D16121F8F2F for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 04:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 H27u2dJBikFE for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 04:26:48 -0700 (PDT)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id E9AB121F9424 for <rtcweb@ietf.org>; Mon, 3 Jun 2013 04:26:47 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for <rtcweb@ietf.org>; Mon, 3 Jun 2013 13:26:06 +0200 (CEST)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id B74543A1F5 for <rtcweb@ietf.org>; Mon, 3 Jun 2013 13:26:06 +0200 (CEST)
Message-ID: <51AC7D4F.6090708@omnitor.se>
Date: Mon, 03 Jun 2013 13:26:07 +0200
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: rtcweb@ietf.org
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
Subject: Re: [rtcweb] RTT (was :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 11:26:54 -0000

On 2013-06-03 12:28, Iñaki Baz Castillo wrote:
> 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.
As I see it, RTCWEB has a goal to enable audio, video and data 
communication  between a user in Website-A and a user in Website-B.

Sometimes I have seen in the discussion that we shall not build silos 
again.

To me, that means create and use standards for the features of common 
interest.

Video, real-time text and audio are the three real-time media of common 
interest.
All three are possible to transport as you like, but the RTCWEB activity 
is about making it in a similar way to enable interoperability and ease 
inclusion in web applications.

Even the isolated web designer who makes the dedicated site only 
offering communication between users of that site and the customer 
service will be glad to find common ways to include the three real-time 
communication modalities as components rather than being forced to 
invent everything again.

And users will be happy to find that it works in similar ways in 
different sites. ( just as you are happy to find the gas pedal located 
in the same place in every car )

There are more reasons why standards are good for this purpose, but I 
stop here. We had a discussion in November - January. It just popped up 
again because of how interop plans with SIP were expressed in the "No 
Plan". And it was not the "No Plan" itself that was limiting, it was 
rather the way the need for legacy interop was described in the No Plan 
draft.

My conclusion is again: whatever transport we select for Real-Time Text 
in the WebRTC environment, there is a need to standardize it.

/Gunnar