Re: [rtcweb] Use Case draft

Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> Tue, 01 May 2012 05:06 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
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 BE7FF21F8762 for <rtcweb@ietfa.amsl.com>; Mon, 30 Apr 2012 22:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 VZ8K5-CLIuhe for <rtcweb@ietfa.amsl.com>; Mon, 30 Apr 2012 22:06:26 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7210021F874A for <rtcweb@ietf.org>; Mon, 30 Apr 2012 22:06:24 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-b7-4f9f6f4e670e
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E5.ED.26681.E4F6F9F4; Tue, 1 May 2012 07:06:22 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 07:06:22 +0200
Message-ID: <4F9F6F4C.5060902@ericsson.com>
Date: Tue, 01 May 2012 07:06:20 +0200
From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMCYArLPRP3c00UdOja64WRT6ghN0PSy7XvM_wbxBBB+vA@mail.gmail.com> <4F9ACCC9.2040508@mozilla.com> <4F9E7A7E.1020600@ericsson.com> <4F9EFD60.6000809@jesup.org>
In-Reply-To: <4F9EFD60.6000809@jesup.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] Use Case draft
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: Tue, 01 May 2012 05:06:27 -0000

On 04/30/2012 11:00 PM, Randell Jesup wrote:
> On 4/30/2012 7:41 AM, Stefan Hakansson LK wrote:
>> On 04/27/2012 06:43 PM, Timothy B. Terriberry wrote:
>>> Ted Hardie wrote:
>>>> The chairs would like to ask the working group to focus on the use
>>>> case draft. If you have use cases that need to be added to the
>>>> document or text changes you'd like to suggest, please send them in
>>>
>>> I proposed the following use-case back in February, but there wasn't
>>> much discussion on actually adding it to the document:
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg03357.html
>>>
>>> Let me know if the WG would like to proceed with something like this.
>>
>> I think adding another small derivative of the simple video chat (this
>> one with peer-to-peer file transfer added) makes a lot of sense. For
>> one, we get a use case that requires reliable data (now we only have a
>> req for "short latency datagram" which sound like unreliable to me); in
>> addition we get a requirement for the data channel API to be able to use
>> blobs (as defined in the File API W3C rec) as input/output.
>
> The game case can need both reliable and unreliable data at the same
> time, which gets us reliable, unreliable and multiple streams.

You're right; but currently only game state updates is mentioned. 
Probably that use case should be updated.
>
>> A third good requirement that can be derived (if we want to) is the
>> ability to prioritize data in relation to audio/video.
>
> File transfer or "let me show you the photo I took" while talking would
> do I think.
>
>