IETF Logo Mail Archive

Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text

Harald Alvestrand <harald@alvestrand.no> Sat, 26 January 2013 08:53 UTC

Return-Path: <harald@alvestrand.no>
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 9ACFC21F86F4 for <rtcweb@ietfa.amsl.com>; Sat, 26 Jan 2013 00:53:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88z+XlfnJbTs for <rtcweb@ietfa.amsl.com>; Sat, 26 Jan 2013 00:53:23 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A883F21F86B8 for <rtcweb@ietf.org>; Sat, 26 Jan 2013 00:53:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4CEB839E1DB; Sat, 26 Jan 2013 09:53:19 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeEeNAaXDtk4; Sat, 26 Jan 2013 09:53:11 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:31e1:81c4:c6a6:8ee9] (unknown [IPv6:2001:470:de0a:27:31e1:81c4:c6a6:8ee9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3156F39E0C8; Sat, 26 Jan 2013 09:53:11 +0100 (CET)
Message-ID: <51039976.1000600@alvestrand.no>
Date: Sat, 26 Jan 2013 09:53:10 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se>
In-Reply-To: <5102FE7E.5000109@omnitor.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text
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: Sat, 26 Jan 2013 08:53:24 -0000

On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote:
> On 2013-01-18 17:06, Magnus Westerlund wrote:
>> WG,
>>
>> I would here by like to announce a two week WG last call that ends on
>> the 1st of February.
>>
>> Document is available here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ 
>>
>>
>
> We had a good discussion in December on inclusion of the real-time 
> text medium.
>
> It was decided to document three alternative implementations with pros 
> and cons and after that decide which one to standardize together with 
> the two already mentioned media in rtcweb.
>
> The three alternatives were:
> 1.) An RTP medium similar to audio and video, using RFC 4103 transport.
>
> 2.) A semi-reliable data channel with a standardized label.
>
> 3.) A web service based protocol, such as BOSH and XEP-0301 for 
> real-time text in XMPP with a well specified integration with rtcweb 
> in a common application.
>
> For all three cases, there is a need to have a specification for how 
> calls with audio, video and real-time text are exchanged with SIP 
> based environments, e.g. for interaction with RFC 6443 based emergency 
> services.
>
> Text is a natural part of today's video and audio applications, so all 
> use cases look quite meager without it.
>
>  I suggest that we make a rapid mini-investigation on the real-time 
> text alternatives and decide which variant to include in a use case.

I disagree with this summary on two points:

- I think it's broken to choose between implementation strategies in an 
use case. The use case needs to specify the function that we want to 
achieve.

- I don't recall a declaration by the chairs that text would be included 
in the use cases for RTCWEB.

My memory is flaky, so if you can find the declaration by the chairs, 
I'm happy to let the last point pass.

v2.23.0 | Report a Bug | By Email